BITCOIN CORE

[Husna QA]

Ya, menurutku yang sering jadi kendala ada di perangkat storage (HDD/SDD), karena pada saat Bitcoin core melakukan proses download Block, maka Disk Usage akan tinggi karena sedang terjadi penulisan data (block-block baru) ke Storage tersebut. Kemungkinan lainnya, ukuran dbcache terlalu kecil.

Kalau HDD, head-nya itu tentu perlu ekstra pada waktu proses baca tulis saat download data yang cukup banyak seperti data blockchain Bitcoin (full node).

Oh ya satu hal yang mungkin perlu diingat juga mengenai kapasitas harddrive untuk menyimpan data blockchain tersebut, jangan sampai kebablasan full itu harddrive-nya gara-gara running full node. Saya pernah mengalami HDD sampai full terisi, jadi pada hilang sebagian file yang lain.

btw kalau dari HD eksternal lebih lambat, apa sebaiknya dicopy saja blockchain dari HD eksternal itu ke laptop?. atau download blockchain dari awal lagi?.
soalnya ini juga yang bikin males buka wallet bitcoin core, apa lagi sudah berbulan-bulan mengendap.

Saya pernah test speed read & write harddisk yang dihubungkan secara eksternal via USB dan coba dilangsungkan ke PC-nya, hasilnya yang via USB lebih kecil kapasitas transfer datanya.

[abhiseshakana]

Ibaratkan -reindex itu secara umum, sedangkan -reindex-chainstate itu secara khusus menangani.

Dua-duanya adalah argumen umum pada Bitcoin Core, dan digunakan pada situasi tertentu. Jika file-file block LevelDB corrupt maka yang digunakan adalah argumen -reindex, tetapi jika yang mengalami corrupt adalah UTXO Set (chainstate LevelDB), sedangkan file Blocks dalam kondisi yang baik maka yang digunakan adalah argumen -reindex-chainstate untuk memangkas waktu pengerjaan.

btw kalau dari HD eksternal lebih lambat, apa sebaiknya dicopy saja blockchain dari HD eksternal itu ke laptop?. atau download blockchain dari awal lagi?.
soalnya ini juga yang bikin males buka wallet bitcoin core, apa lagi sudah berbulan-bulan mengendap.

Jika agan merasa file-file (database) Bitcoin Core yang ada HD eksternal kondisinya baik (tidak ada yang corrupt) maka bisa saja dilakukan copy-paste untuk menghemat waktu. Jika file wallet.dat yang digunakan sama maka agan bisa meng-copy keseluruhan isi folder Bitcoin, tetapi jika menggunakan file wallet.dat yang berbeda maka agan bisa melakukan copy kecuali file wallet.dat dan folder database (biasanya sih untuk file wallet.dat yang berbeda akan diperlukan argumen -rescanblockchain)

[Husna QA]

Saya pernah juga mengalami sampai melakukan proses -reindex gara-gara waktu itu kelupaan menjalankan 2 versi Bitcoin Core berbarengan di dua OS dengan folder data Blockchain Bitcoin yang sama. Lumayan lama juga prosesnya karena memang datanya juga sudah ratusan gigabyte. Sementara untuk Rescanning, waktu itu setelah mencoba proses import Private key dari wallet lain.

Oh ya, beberapa command line di Bitcoin Core bisa dilihat juga di Console. Untuk melihatnya ketikkan baris perintah Help.

Code:

== Blockchain ==
getbestblockhash
getblock "blockhash" ( verbosity )
getblockchaininfo
getblockcount
getblockfilter "blockhash" ( "filtertype" )
getblockhash height
getblockheader "blockhash" ( verbose )
getblockstats hash_or_height ( stats )
getchaintips
getchaintxstats ( nblocks "blockhash" )
getdifficulty
getmempoolancestors "txid" ( verbose )
getmempooldescendants "txid" ( verbose )
getmempoolentry "txid"
getmempoolinfo
getrawmempool ( verbose )
gettxout "txid" n ( include_mempool )
gettxoutproof ["txid",...] ( "blockhash" )
gettxoutsetinfo
preciousblock "blockhash"
pruneblockchain height
savemempool
scantxoutset "action" [scanobjects,...]
verifychain ( checklevel nblocks )
verifytxoutproof "proof"

== Control ==
getmemoryinfo ( "mode" )
getrpcinfo
help ( "command" )
logging ( ["include_category",...] ["exclude_category",...] )
stop
uptime

== Generating ==
generatetoaddress nblocks "address" ( maxtries )

== Mining ==
getblocktemplate ( "template_request" )
getmininginfo
getnetworkhashps ( nblocks height )
prioritisetransaction "txid" ( dummy ) fee_delta
submitblock "hexdata" ( "dummy" )
submitheader "hexdata"

== Network ==
addnode "node" "command"
clearbanned
disconnectnode ( "address" nodeid )
getaddednodeinfo ( "node" )
getconnectioncount
getnettotals
getnetworkinfo
getnodeaddresses ( count )
getpeerinfo
listbanned
ping
setban "subnet" "command" ( bantime absolute )
setnetworkactive state

== Rawtransactions ==
analyzepsbt "psbt"
combinepsbt ["psbt",...]
combinerawtransaction ["hexstring",...]
converttopsbt "hexstring" ( permitsigdata iswitness )
createpsbt [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...] ( locktime replaceable )
createrawtransaction [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...] ( locktime replaceable )
decodepsbt "psbt"
decoderawtransaction "hexstring" ( iswitness )
decodescript "hexstring"
finalizepsbt "psbt" ( extract )
fundrawtransaction "hexstring" ( options iswitness )
getrawtransaction "txid" ( verbose "blockhash" )
joinpsbts ["psbt",...]
sendrawtransaction "hexstring" ( maxfeerate )
signrawtransactionwithkey "hexstring" ["privatekey",...] ( [{"txid":"hex","vout":n,"scriptPubKey":"hex","redeemScript":"hex","witnessScript":"hex","amount":amount},...] "sighashtype" )
testmempoolaccept ["rawtx",...] ( maxfeerate )
utxoupdatepsbt "psbt" ( ["",{"desc":"str","range":n or [n,n]},...] )

== Util ==
createmultisig nrequired ["key",...] ( "address_type" )
deriveaddresses "descriptor" ( range )
estimatesmartfee conf_target ( "estimate_mode" )
getdescriptorinfo "descriptor"
signmessagewithprivkey "privkey" "message"
validateaddress "address"
verifymessage "address" "signature" "message"

== Wallet ==
abandontransaction "txid"
abortrescan
addmultisigaddress nrequired ["key",...] ( "label" "address_type" )
backupwallet "destination"
bumpfee "txid" ( options )
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse )
dumpprivkey "address"
dumpwallet "filename"
encryptwallet "passphrase"
getaddressesbylabel "label"
getaddressinfo "address"
getbalance ( "dummy" minconf include_watchonly avoid_reuse )
getbalances
getnewaddress ( "label" "address_type" )
getrawchangeaddress ( "address_type" )
getreceivedbyaddress "address" ( minconf )
getreceivedbylabel "label" ( minconf )
gettransaction "txid" ( include_watchonly verbose )
getunconfirmedbalance
getwalletinfo
importaddress "address" ( "label" rescan p2sh )
importmulti "requests" ( "options" )
importprivkey "privkey" ( "label" rescan )
importprunedfunds "rawtransaction" "txoutproof"
importpubkey "pubkey" ( "label" rescan )
importwallet "filename"
keypoolrefill ( newsize )
listaddressgroupings
listlabels ( "purpose" )
listlockunspent
listreceivedbyaddress ( minconf include_empty include_watchonly "address_filter" )
listreceivedbylabel ( minconf include_empty include_watchonly )
listsinceblock ( "blockhash" target_confirmations include_watchonly include_removed )
listtransactions ( "label" count skip include_watchonly )
listunspent ( minconf maxconf ["address",...] include_unsafe query_options )
listwalletdir
listwallets
loadwallet "filename"
lockunspent unlock ( [{"txid":"hex","vout":n},...] )
removeprunedfunds "txid"
rescanblockchain ( start_height stop_height )
sendmany "" {"address":amount} ( minconf "comment" ["address",...] replaceable conf_target "estimate_mode" )
sendtoaddress "address" amount ( "comment" "comment_to" subtractfeefromamount replaceable conf_target "estimate_mode" avoid_reuse )
sethdseed ( newkeypool "seed" )
setlabel "address" "label"
settxfee amount
setwalletflag "flag" ( value )
signmessage "address" "message"
signrawtransactionwithwallet "hexstring" ( [{"txid":"hex","vout":n,"scriptPubKey":"hex","redeemScript":"hex","witnessScript":"hex","amount":amount},...] "sighashtype" )
unloadwallet ( "wallet_name" )
walletcreatefundedpsbt [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...] ( locktime options bip32derivs )
walletlock
walletpassphrase "passphrase" timeout
walletpassphrasechange "oldpassphrase" "newpassphrase"
walletprocesspsbt "psbt" ( sign "sighashtype" bip32derivs )

== Zmq ==
getzmqnotifications

[vv181]

Sedikit nambahin penjelasan Om @abhiseshakana.

Selain penjelasan di atas, perbedaan dua konfigurasi tersebut bisa merujuk ke quote berikut.

-reindex:
    wipes the chainstate (the UTXO set)
    wipes the block index (the database with information about which block is where on disk)
    rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
    rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index

-reindex-chainstate:
    wipes the chainstate
    rebuilds the chainstate using the blocks in the index you had before

The latter should be strictly faster, as it does not need to rebuild the block index first.
Perhaps the progress bar during reindex confuses you: that progress is only for the rebuilding of the index.
The recreation of the chainstate happens after that rebuild is completed.

You should use -reindex only when you were running in pruning mode, or if you suspect the blocks on disk are actually corrupted.
Otherwise, when you only suspect corruption of the chainstate (which is far more likely), use -reindex-chainstate.

Sepengalaman saya, cara mengetahui file/database mana yang error/corrupt bisa liat dari debug.log Bitcoin Core tersendiri. Jika ada pesan error yang yang mengindikasikan file "blocks/index/*.ldb" (Blocks Index LevelDB) atau "blocks/blk*.dat" (Raw Blocks), maka konfigurasi --reindex yang dipakai. Sedangkan jika filenya "chainstate/*.ldb"(Chainstate LevelDB) baru pakai --reindex-chainstate.

[Chikito]

btw kalau dari HD eksternal lebih lambat, apa sebaiknya dicopy saja blockchain dari HD eksternal itu ke laptop?. atau download blockchain dari awal lagi?.
soalnya ini juga yang bikin males buka wallet bitcoin core, apa lagi sudah berbulan-bulan mengendap.

Saya pernah test speed read & write harddisk yang dihubungkan secara eksternal via USB dan coba dilangsungkan ke PC-nya, hasilnya yang via USB lebih kecil kapasitas transfer datanya.

Soalnya kapasitas HD di laptop saya ini nge-pas banget kalau ngopi semua blockchain dari HD Eksternal. Takutnya itu mempengaruhi peforma laptop dan makan memori, mungkin ada setting tertentu untuk mem-freeze-kan sehingga kalau dibutuhkan saja baru jalan.

btw kalau dari HD eksternal lebih lambat, apa sebaiknya dicopy saja blockchain dari HD eksternal itu ke laptop?. atau download blockchain dari awal lagi?.
soalnya ini juga yang bikin males buka wallet bitcoin core, apa lagi sudah berbulan-bulan mengendap.

Jika agan merasa file-file (database) Bitcoin Core yang ada HD eksternal kondisinya baik (tidak ada yang corrupt) maka bisa saja dilakukan copy-paste untuk menghemat waktu.

Nah itu belum tahu apa masih bagus atau enggak, soalnya pernah saya hubungkan, lama sekali untuk sinkronisasinya, gak sabaran sehingga saya close wallet dan cabut hdd eksternal tersebut sampai sekarang.

[Husna QA]

Soalnya kapasitas HD di laptop saya ini nge-pas banget kalau ngopi semua blockchain dari HD Eksternal. Takutnya itu mempengaruhi peforma laptop dan makan memori, mungkin ada setting tertentu untuk mem-freeze-kan sehingga kalau dibutuhkan saja baru jalan.

Jangan dipaksakan mas jika sekiranya kapasitas HDD internalnya memang nge-pas. Oh ya HDD eksternal-nya itu yang dicolok langsung via USB saja atau menggunakan semacam enclosure docking yang ada tambahan lagi power untuk listriknya? Saya pribadi lebih prefer menggunakan yang ada tambahan power lagi untuk yang eksternal.

Kalau saya memodifikasi MacBook, dulu memang sengaja memilih tipe yang masih ada DVD Drive-nya namun sekarang sudah jarang digunakan, jadinya saya ganti untuk menempatkan SSD kedua dengan menggunakan harddrive caddy sebagai braketnya. SSD kedua tersebutlah yang saat ini saya jadikan tempat menyimpan data blockchain bitcoin, sementara aplikasi Bitcoin Core-nya sendiri terinstall di harddisk pertama.

[Chikito]

Jangan dipaksakan mas jika sekiranya kapasitas HDD internalnya memang nge-pas. Oh ya HDD eksternal-nya itu yang dicolok langsung via USB saja atau menggunakan semacam enclosure docking yang ada tambahan lagi power untuk listriknya? Saya pribadi lebih prefer menggunakan yang ada tambahan power lagi untuk yang eksternal.

HD 2,5 bekas copotan laptop lama yang rusak Mobo-nya. jadi saya beliin Casing eskternalnya aja untuk supaya bisa konek ke laptop. Saya pernah juga nyari casing yang ada power suply ke listrik/enclosure docking, tapi katanya gak cocok karena lebih prefer ke HD 3,5 atau HD yang biasa di PC.

[ABCbits]

Jangan dipaksakan mas jika sekiranya kapasitas HDD internalnya memang nge-pas. Oh ya HDD eksternal-nya itu yang dicolok langsung via USB saja atau menggunakan semacam enclosure docking yang ada tambahan lagi power untuk listriknya? Saya pribadi lebih prefer menggunakan yang ada tambahan power lagi untuk yang eksternal.

HD 2,5 bekas copotan laptop lama yang rusak Mobo-nya. jadi saya beliin Casing eskternalnya aja untuk supaya bisa konek ke laptop. Saya pernah juga nyari casing yang ada power suply ke listrik/enclosure docking, tapi katanya gak cocok karena lebih prefer ke HD 3,5 atau HD yang biasa di PC.

Sebagai alternatif, bisa menggunakan kabel dengan ekstra head sebagai suplai energi tambahan.


Sumber: aliexpress[dot]com/item/USB-3-0-Male-to-Micro-USB-3-Y-Cable-with-Extra-usb-Power-USB3-0/32922855027.htm

[Husna QA]

HD 2,5 bekas copotan laptop lama yang rusak Mobo-nya. jadi saya beliin Casing eskternalnya aja untuk supaya bisa konek ke laptop. Saya pernah juga nyari casing yang ada power suply ke listrik/enclosure docking, tapi katanya gak cocok karena lebih prefer ke HD 3,5 atau HD yang biasa di PC.

Contoh yang saya punya seperti ini mas, bisa untuk HDD 2.5 dan juga HDD 3.5:



Sementara kalau yang dipasang internal, harddrive tambahannya saya tempatkan seperti ini:

 

Sebagai alternatif, bisa menggunakan kabel dengan ekstra head sebagai suplai energi tambahan.

Nah itu bisa jadi alternatif; Saya jadi teringat server yang menggunakan 2 port LAN atau lebih untuk menambah kestabilan saat proses transfer data.
Data Blockchain Bitcoin cukup besar (yang full) jadi mesti rada ekstra terutama harddrive untuk menyimpan data tersebut ketika menjalankan Bitcoin Core. btw, saat ini Bitcoin Blockchain Size sudah mencapai 399 GB lebih (https://ycharts.com/indicators/bitcoin_blockchain_size).

[Chikito]

Sebagai alternatif, bisa menggunakan kabel dengan ekstra head sebagai suplai energi tambahan.

Nah itu bisa jadi alternatif; Saya jadi teringat server yang menggunakan 2 port LAN atau lebih untuk menambah kestabilan saat proses transfer data.

Itu apa tidak terbaca sebagai transfer data semua ya?, bukan malah jadi suply untuk colokan 1-nya?, soalnya saya lihat ada juga yang jual di olshop local, di gambar tersebut jelas, 2 colokan tersebut 1 warna biru (usb 3.0) satunya default (Usb 2.0), Saya bingung laptosa saya gak ada colokan buat USB 3-nya. takutnya salah colok malah kebalik data and power suply-nya.

Data Blockchain Bitcoin cukup besar (yang full) jadi mesti rada ekstra terutama harddrive untuk menyimpan data tersebut ketika menjalankan Bitcoin Core. btw, saat ini Bitcoin Blockchain Size sudah mencapai 399 GB lebih (https://ycharts.com/indicators/bitcoin_blockchain_size).

Saya barusan check wallet bitcoin core di HD eksternal saya itu ada 348 GB, artinya mesti download sekitar 50+ GB blockchain lagi.

[Husna QA]

Itu apa tidak terbaca sebagai transfer data semua ya?, bukan malah jadi suply untuk colokan 1-nya?, soalnya saya lihat ada juga yang jual di olshop local, di gambar tersebut jelas, 2 colokan tersebut 1 warna biru (usb 3.0) satunya default (Usb 2.0), Saya bingung laptosa saya gak ada colokan buat USB 3-nya. takutnya salah colok malah kebalik data and power suply-nya.

Ya mas, keduanya sama-sama berfungsi untuk transfer data dan perantara penghantar supply listrik ke harddrive. Jadi ketika hanya dicolokkan salah satupun tetap bisa digunakan, namun tentunya supply kelistrikan pun hanya berasal dari satu colokkan head tersebut saja.

Input/outpunya tetap jadi satu ke drive yang terhubung meskipun menggunakan 2 head seperti di atas/tidak merubah pembacaan partisi yang ada di harddrive.

Kalaupun di laptopnya hanya ada port USB 2, kedua head di atas (USB 2 ataupun 3) bisa digunakan semuanya namun tentunya fitur kecepatan transfer pada colokan USB 3 nya tidak bisa dimaksimalkan karena sumber data dari laptopnya maksimal untuk USB 2.

USB 2.0 memiiiki kecepatan transfer data sekitar 480 Mbps, sedangkan USB 3.0 menawarkan kecepatan hingga 4,8 Gbps alias 10 kali lebih cepat. Perlu diingat, kecepatan transfer itu juga tergantung pada perangkat yang digunakan dikoneksikan

Saya barusan check wallet bitcoin core di HD eksternal saya itu ada 348 GB, artinya mesti download sekitar 50+ GB blockchain lagi.

Dan saat ini masih akan terus bertambah lagi datanya. Di laptop saya untuk file size pada folder blocks saja sudah mencapai segini:

[vv181]

Kebetulan beberapa hari lalu ada bahasan mengenai --reindex dan --reindex-chainstate, hari ini, node di Raspberry Pi saya mengalami power failure. Saat saya coba nyalain lagi, tampilan error yang muncul sebagai berikut:

Code:

2022-04-09T12:46:53Z Opening LevelDB in /mnt/ext/bitcoin/blocks/index
2022-04-09T12:46:53Z Fatal LevelDB error: Corruption: CURRENT points to a non-existent file: NotFound: /mnt/ext/bitcoin/blocks/index/MANIFEST-004859: No such file or directory
2022-04-09T12:46:53Z You can use -debug=leveldb to get more complete diagnostic messages
2022-04-09T12:46:53Z Fatal LevelDB error: Corruption: CURRENT points to a non-existent file: NotFound: /mnt/ext/bitcoin/blocks/index/MANIFEST-004859: No such file or directory
2022-04-09T12:46:53Z : Error opening block database.
Please restart with -reindex or -reindex-chainstate to recover.
2022-04-09T12:46:53Z Aborted block database rebuild. Exiting.

Kalau saya coba liat-liat penjelasan dari file yang ditunjukkan error itu adalah:

Manifest
A MANIFEST file lists the set of sorted tables that make up each level, the corresponding key ranges, and other important metadata. A new MANIFEST file (with a new number embedded in the file name) is created whenever the database is reopened. The MANIFEST file is formatted as a log, and changes made to the serving state (as files are added or removed) are appended to this log.

Current
CURRENT is a simple text file that contains the name of the latest MANIFEST file.

Saya cek di folder blocks/index terdapat file MANIFEST-004869 dan isi dari file CURRENT tersendiri "MANIFEST-004859". Saya sendiri masih kurang mengerti mengenai file itu ditujukkan untuk apa(hanya sebagai log, atau mungkin untuk tujuan lainnya), untungnya sebelum saya coba melakukan --reindex, saya iseng coba me-rename file MANIFEST-004869 menjadi MANIFEST-004859. Hasilnya ternyata bitcoind nya running lagi seperti biasa. Walaupun, pas awal-awal sempat ada error

Code:

leveldb: Compaction error: IO error: /mnt/ext/bitcoin/chainstate/811167.ldb: Bad message

Tapi sampai saat ini, aplikasi Bitcoind, Electrs, dan C-lightning, masih berjalan lancar. Mungkin agan-agan di sini ada yang mengerti untuk file tersebut dikhususkan untuk apa? Atau ternyata memang node saya ada yang corrupt lalu harus melakukan recovery(--reindex-chainstate) lagi?

EDIT:
Ternyata untuk node testnet ane juga mengalami isu serupa seperti di atas. Bedanya, cara me-rename di atas tidak berhasil, jadinya saya harus melakukan --reindex-chainstate.

Code:

#log di bawah ini setelah merename file MANIFEST
2022-04-09T14:30:01Z Opening LevelDB in /home/bitcoin/.bitcoin/testnet3/blocks/index
2022-04-09T14:30:01Z Fatal LevelDB error: Corruption: no meta-nextfile entry in descriptor
2022-04-09T14:30:01Z You can use -debug=leveldb to get more complete diagnostic messages
2022-04-09T14:30:01Z Fatal LevelDB error: Corruption: no meta-nextfile entry in descriptor
2022-04-09T14:30:01Z : Error opening block database.
Please restart with -reindex or -reindex-chainstate to recover.
: Error opening block database.

Code:

2022-04-09T14:31:19Z Using obfuscation key for /home/bitcoin/.bitcoin/testnet3/chainstate: 95f1c90194f7ef86
2022-04-09T14:31:19Z : Error initializing block database.
Please restart with -reindex or -reindex-chainstate to recover.

[abhiseshakana]

Saya cek di folder blocks/index terdapat file MANIFEST-004869 dan isi dari file CURRENT tersendiri "MANIFEST-004859". Saya sendiri masih kurang mengerti mengenai file itu ditujukkan untuk apa(hanya sebagai log, atau mungkin untuk tujuan lainnya), untungnya sebelum saya coba melakukan --reindex, saya iseng coba me-rename file MANIFEST-004869 menjadi MANIFEST-004859. Hasilnya ternyata bitcoind nya running lagi seperti biasa. Walaupun, pas awal-awal sempat ada error

File "manifest" berisi list dari file-file ldb (Sorted tables) di folder block index maupun folder chainstate. Setiap ada perubahan data pada sorted table maka isi dari file "manifest" juga akan turut menyesuaikan (ditandai dengan perubahan nama/index nomor pada file manifest tersebut).

File "Current" hanya menyajikan nama/index nomor dari file manifest yang terakhir disimpan di folder block index maupun folder chainstate. Jadi langkah agan melakukan rename pada file MANIFEST-004869 menjadi MANIFEST-004859 menurut saya sudah benar, karena isi/list dari MANIFEST-004859 sesuai dengan file-file ldb (Sorted tables) yang ada. Mungkin saat terjadi sedikit error setelah melakukan rename manifest, terdapat sebuah revisi pada file manifest tersebut (untuk menyesuaikan dengan file-file ldb yang ada).

* Untuk jawaban yang detail sebaiknya kita colek agan @ETFbitcoin

[Husna QA]

Code:

#log di bawah ini setelah merename file MANIFEST
2022-04-09T14:30:01Z Opening LevelDB in /home/bitcoin/.bitcoin/testnet3/blocks/index
2022-04-09T14:30:01Z Fatal LevelDB error: Corruption: no meta-nextfile entry in descriptor
2022-04-09T14:30:01Z You can use -debug=leveldb to get more complete diagnostic messages
2022-04-09T14:30:01Z Fatal LevelDB error: Corruption: no meta-nextfile entry in descriptor
2022-04-09T14:30:01Z : Error opening block database.
Please restart with -reindex or -reindex-chainstate to recover.
: Error opening block database.

Code:

2022-04-09T14:31:19Z Using obfuscation key for /home/bitcoin/.bitcoin/testnet3/chainstate: 95f1c90194f7ef86
2022-04-09T14:31:19Z : Error initializing block database.
Please restart with -reindex or -reindex-chainstate to recover.

Untuk yang ini, file MANIFEST yang di rename nya apakah mengikut kode yang ada di file CURRENT pada folder testnet3?

Sementara itu mengenai Fatal LevelDB error: Corruption: no meta-nextfile entry in descriptor semalam saya sempat baca-baca komentar @laanwj pada salah satu diskusi di github (https://github.com/bitcoin/bitcoin/issues/6606#issuecomment-136385890), levelDB corruption biasanya terjadi dikarenakan ada data corrupt pada disk atau memory ketika proses penulisan data, yang mana pada kasus agan vv181 di atas jelas terjadi setelah perangkatnya mengalami power failure.

"Error reading from database: Database corrupted" levelDB corruption is usually caused by disk or memory corruption (while writing to disk).
You could try using -par=1 to restrict syncing to one thread and then -reindex. Sometimes this helps when, for example, the CPU is overheating.

[vv181]

Untuk yang ini, file MANIFEST yang di rename nya apakah mengikut kode yang ada di file CURRENT pada folder testnet3?

Iya Om, sudah sesuai dengan isi file CURRENT dan juga sesuai dengan error di debug.log-nya.

levelDB corruption biasanya terjadi dikarenakan ada data corrupt pada disk atau memory ketika proses penulisan data, yang mana pada kasus agan vv181 di atas jelas terjadi setelah perangkatnya mengalami power failure.

Selain karena itu sepertinya karena HDD saya juga memang sudah bermasalah Om, ternyata untuk kemaren saat melakukan --reindex-chainstate, ada error lainnya(tidak sempat saya catat) sehingga harus melakukan --reindex. Hari baru saya cek lagi, ada error:

Code:

2022-04-09T17:33:08Z *** Corrupt block found indicating potential hardware failure; shutting down
2022-04-09T17:33:08Z Error: A fatal internal error occurred, see debug.log for details
2022-04-09T17:33:08Z ERROR: ConnectTip: ConnectBlock 0000000000000611120bd5fc1e72f2262924e8855ec5828e2070aa42cb2b4b3f failed, bad-txnmrklroot, hashMerkleRoot mismatch
2022-04-09T17:33:08Z Failed to connect best block (bad-txnmrklroot, hashMerkleRoot mismatch)
2022-04-09T17:33:08Z loadblk thread exit

Dan juga yang terakhir:

Code:

2022-04-10T15:48:11Z ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at FlatFilePos(nFile=40, nPos=18863821)
2022-04-10T15:48:11Z *** Failed to read block
2022-04-10T15:48:11Z Error: A fatal internal error occurred, see debug.log for details
2022-04-10T15:48:11Z Failed to connect best block (Failed to read block)
2022-04-10T15:48:11Z loadblk thread exit

Sedangkan untuk yang mainnet, walaupun awalnya berjalan, akhirnya ada error berikut:

Code:

2022-04-09T20:16:40Z WriteBatch memory usage: db=txindex, before=14.0MiB, after=14.1MiB
2022-04-09T20:16:50Z UpdateTip: new best=00000000000000000008ed0f38ed28c64b70372552bdaad1b4e2132934a2e944 height=731167 version=0x20002004 log2_work=93.450951 tx=724412317 date='2022-04-09T20:16:43Z' progress=1.000000 cache=90.9MiB(681235txo)
2022-04-09T20:16:50Z leveldb: Level-0 table #254843: started
2022-04-09T20:16:50Z WriteBatch memory usage: db=txindex, before=14.1MiB, after=14.1MiB
2022-04-09T20:16:50Z leveldb: Level-0 table #254843: 10340029 bytes OK
2022-04-09T20:16:51Z leveldb: Delete type=0 #254839
2022-04-09T20:19:54Z UpdateTip: new best=000000000000000000036716bf32bdf8f483a67f8b9090e0fef26155bc2ae084 height=731168 version=0x2000e004 log2_work=93.450964 tx=724412634 date='2022-04-09T20:18:24Z' progress=1.000000 cache=91.0MiB(681860txo)
2022-04-09T20:19:54Z WriteBatch memory usage: db=txindex, before=0.0MiB, after=0.0MiB
2022-04-09T20:37:25Z LevelDB read failure: Corruption: not an sstable (bad magic number)
2022-04-09T20:37:25Z Fatal LevelDB error: Corruption: not an sstable (bad magic number)
2022-04-09T20:37:25Z You can use -debug=leveldb to get more complete diagnostic messages
2022-04-09T20:37:25Z Error: Error reading from database, shutting down.
2022-04-09T20:37:25Z Error reading from database: Fatal LevelDB error: Corruption: not an sstable (bad magic number)

Jadi langkah agan melakukan rename pada file MANIFEST-004869 menjadi MANIFEST-004859 menurut saya sudah benar, karena isi/list dari MANIFEST-004859 sesuai dengan file-file ldb (Sorted tables) yang ada. Mungkin saat terjadi sedikit error setelah melakukan rename manifest, terdapat sebuah revisi pada file manifest tersebut (untuk menyesuaikan dengan file-file ldb yang ada).

Entah cara me-rename tersebut memang bisa dijadikan solusi alternatif atau tidak, kalau lihat berdasar hasil terbaru di atas tidak berhasil Om. Walaupun besar kemungkinan letak permasalahannya ada di HDD saya.

[Husna QA]

Entah cara me-rename tersebut memang bisa dijadikan solusi alternatif atau tidak, kalau lihat berdasar hasil terbaru di atas tidak berhasil Om. Walaupun besar kemungkinan letak permasalahannya ada di HDD saya.

Mungkin sebelum melakukan -reindex ataupun -reindex-chainstate di Bitcoin Core, terlebih dulu periksa apakah ada bad sector pada harddrive-nya atau tidak, kalau misalkan masih aman mungkin bisa dilanjut untuk men-defragment HDD-nya (Saya kurang tahu apakah di Raspberry Pi ada software untuk ini atau tidak).

Saya sendiri masih belum yakin apakah dengan cara me-rename file MANIFEST tersebut di atas bisa benar-benar berhasil atau tidak kalaupun HDD agan vv181 tidak bermasalah, meskipun tidak menutup kemungkinan juga akan hal itu.

Analogi sederhana saya, seperti proses men-download file dengan cara biasa dan dengan menggunakan torrent, ketika perangkat yang digunakan mendadak mati (ketika proses tersebut belum selesai), untuk cara yang pertama kalaupun ada file yang tersimpan kemungkinan file akan corrupt, sementara untuk cara kedua besar kemungkinan masih bisa dilanjut proses download-nya. Nah saya tidak tahu persis untuk file MANIFEST pada folder chainstate tersebut mirip dengan cara yang mana. -cmiiw-

[ABCbits]

--snip--
* Untuk jawaban yang detail sebaiknya kita colek agan @ETFbitcoin

Saya tidak familiar dengan file MANIFEST-... dan saya hampir tidak pernah menemukan diskusi yang membahas file tersebut, sehingga saya tidak bisa memberikan solusi.

Walaupun, pas awal-awal sempat ada error

Code:

leveldb: Compaction error: IO error: /mnt/ext/bitcoin/chainstate/811167.ldb: Bad message

Dan juga yang terakhir:

Code:

2022-04-10T15:48:11Z ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at FlatFilePos(nFile=40, nPos=18863821)
2022-04-10T15:48:11Z *** Failed to read block
2022-04-10T15:48:11Z Error: A fatal internal error occurred, see debug.log for details
2022-04-10T15:48:11Z Failed to connect best block (Failed to read block)
2022-04-10T15:48:11Z loadblk thread exit

HDD yang digunakan jelas bermasalah, coba
1. Cek status S.M.A.R.T dan lakukan testing pada HDD tersebut. https://wiki.archlinux.org/title/S.M.A.R.T.
2. Menggunakan kabel dan port yang berbeda.

[Husna QA]

-UPDATE-  BITCOIN CORE 23.0

Ternyata tanggal 25 April 2022 yang lalu Bitcoin Core sudah ada versi terbarunya yakni versi 23.0 (Terima kasih agan vv181 atas informasi mengenai versi 23.0 ini). Informasi ini bisa juga dilihat di banner News forum.

• Link download: https://bitcoincore.org/bin/bitcoin-core-23.0/
  (direkomendasikan untuk memverifikasi file yang didownload, caranya bisa lihat di awal-awal thread atau lihat pada link tersebut dibagian Verify your download);
• Source code: https://github.com/bitcoin/bitcoin;
• Untuk catatan rilis selengkapnya mengenai fitur baru atau perbaikan apa saja yang ada di versi 23.0 ini bisa dilihat disini:
  https://bitcoincore.org/en/releases/23.0/
  Diantaranya, pada versi Bitcoin Core 23.0 ini sudah bisa meng-generate Taproot address:

Wallet
-snip-
• Newly created descriptor wallets will contain an automatically generated tr() descriptor which allows for creating single key Taproot receiving addresses.
-snip-
GUI changes
-snip-
• The Bech32 checkbox has been replaced with a dropdown for all address types, including the new Bech32m (BIP-350) standard for Taproot enabled wallets.

Berikut ini contoh Taproot address yang saya generate barusan di Bitcoin Core 23.0:

[Chikito]

-UPDATE-  BITCOIN CORE 23.0

Ya saya sudah mencobanya,



btw untuk fitur sign message, sama seperti mencoba wallet/address yang lain yaitu belum bisa.



dan ada kendala juga ketika mau dump private key, baik itu legacy, segwit dan taproot address.



Apa saya salah di command atau bagaimana?, seingat saya pernah dump private key, gk pernah nemu yang seperti ini, kecuali enter the wallet passphrase, tapi itu sudah saya coba juga, tapi msh dapat error, atau karena taproot ini?

[abhiseshakana]

Apa saya salah di command atau bagaimana?, seingat saya pernah dump private key, gk pernah nemu yang seperti ini, kecuali enter the wallet passphrase, tapi itu sudah saya coba juga, tapi msh dapat error, atau karena taproot ini?

Kalo melihat penjelasan di release note 23.0 (https://bitcoincore.org/en/releases/23.0/), maka argumen dumpprivkey dan importmulti tidak bisa digunakan saat descriptor wallets aktif. Coba tambahkan argumen descriptors=false saat melakukan perintah dumpprivkey.