3 question -checking the sha256 installation file is not enough to make sure that the file is good?
No. That only provides half of the verification to ensure the file is good. Just to expand on this a little... checking the sha256 of the install file against what is shown in the sha256sums.asc is only "good" if you've confirmed that the sha256sums.asc has been successfully "signed". Otherwise, someone could simply create a "fake" sha256sums.asc that includes the sha256sum of their "fake" installer listed... by checking the digital signature of the sha256sums.asc file (against the signatures of trusted developers), you know that the file and the info in it isn't fake, and therefore all the sha256sums listed inside are valid. |
|
|
|
|
Pretty sure that the wallet.xpt file is just part of Mozilla Firefox. I would be very surprised if this was in any way related to Bitcoin and/or Bitcoin Core.
If you open the file in a text editor and it starts with the text "XPCOM TypeLib" and then a bunch of "garbled characters", then it is 100% NOT a Bitcoin Core wallet file.
|
|
|
|
Certainly not any sort of wallet or key identifier that I have ever seen before...   It's possible that the website or service you used for generating them was using them as some sort of extra encryption or recovery mechanism or custom transaction identifier... but without knowing what the website/service actually was, it's going to be mighty difficult figuring out the process required. And your mails didn't include anything like addresses or transaction IDs? Just the 64 char hex string and the 40(5x8) char string? |
|
|
|
Posting to see my inevitable low IQ score... I've finally been found out Well, it was a fun ride. |
|
|
|
Because I'm an idiot with bad time management... I decided that I could spare some time getting WSL and electrs up and running again... but I seem to be stuck getting electrs to start up  I don't remember having to do anything too special to make it work... but when I attempt to start electrs I get: hcp@HCP-PC:~/electrs$ ./target/release/electrs
Starting electrs 0.9.6 on x86_64 linux with Config { network: Bitcoin, db_path: "/home/hcp/electrs/bitcoin", daemon_dir: "/mnt/e/Bitcoin", daemon_auth: CookieFile("/mnt/e/Bitcoin/.cookie"), daemon_rpc_addr: 127.0.0.1:8332, daemon_p2p_addr: 127.0.0.1:8333, electrum_rpc_addr: 127.0.0.1:50001, monitoring_addr: 127.0.0.1:4224, wait_duration: 10s, jsonrpc_timeout: 15s, index_batch_size: 10, index_lookup_limit: None, reindex_last_blocks: 0, auto_reindex: true, ignore_mempool: false, sync_once: false, disable_electrum_rpc: false, server_banner: "Welcome to electrs 0.9.6 (Electrum Rust Server)!", args: [] }
[2022-03-30T23:47:35.040Z INFO electrs::metrics::metrics_impl] serving Prometheus metrics on 127.0.0.1:4224
[2022-03-30T23:47:35.040Z INFO electrs::server] serving Electrum RPC on 127.0.0.1:50001
[2022-03-30T23:47:35.053Z INFO electrs::db] "/home/hcp/electrs/bitcoin": 9 SST files, 0.000007245 GB, 0.000000009 Grows
[2022-03-30T23:47:35.056Z INFO electrs::db] closing DB at /home/hcp/electrs/bitcoin
Error: electrs failed
Caused by:
0: bitcoind RPC polling failed
1: daemon not available
2: JSON-RPC error: transport error: Couldn't connect to host: Connection refused (os error 111)
hcp@HCP-PC:~/electrs$
Really not sure what is causing the issue... any one else come across this? |
|
|
|
Eh.. yes. But installation of electrumx is not so easy for Windows and as I may easily use it with Electrum, I will stay with that for now.
This is very true... I actually found it was just easier to setup ElectrumX using WSL (Windows Subsystem for Linux) and Ubuntu   Actually, now that I think of it, I wasn't using ElectrumX at all... I was using electrs (but still running under Ubuntu using WSL) Did you try your connection with both enabled and disabled TOR in Trezor Suite?
Umbrel forces TOR only... so it's not an option to disable it in Trezor if I want to run it through the Electrum Server on my Pi/Umbrel Node. I could probably get ElectrumX electrs back up and running fairly easily under WSL to test a "non-TOR" setup, but I shut it all down when I setup the Umbrel node... and I'm kinda time limited at the moment |
|
|
|
|
It amazes me that people still think they can beat the math. The entire point of a "house edge" is that, in the long term, the house is always going to come out on top. They don't even need to try and scam or use "fixed" number generators... a pure RNG will give them the 1% they require.
Admittedly, a single user can "beat" this over the (very) short term... as it's entirely possible for a short term winning streak... but if you don't walk away, you're going to give it all back and then some.
For me personally, dabbling in bot scripts was never an exercise to beat the house and make money... it was more an exercise of the brain to see if I could actually code something that did what I wanted it to... or to turn another users algorithm into a working script within the confines of the dice bot scripting system.
|
|
|
|
I do not have anything in logs of EPS - maybe I will try monitor port and see if there is any transmission.
I hope you already found a way to deal with the issue in question [I wanted to run it as well, but due to various reasons, I've given up (looks like I have to wait for direct Bitcoin Core support)]. Using EPS with anything other than Electrum has also been very hit and miss... I've just come back from an extended period "offline"... my Umbrel server is still ticking along nicely... and I'm happy to report that simply copy/pasting the onion URL from Umbrel using then "Connect Wallet -> Electrum Wallet (Desktop)" option into the Bitcoin Settings in Trezor Suite (Settings -> Crypto -> Bitcoin) worked perfectly (After I remembered to actually turn on the Tor proxy... LOL) Trezor Suite connected without any trouble and it all seems to be working pretty much seamlessly. Keen to see if they do end up with Bitcoin Core support tho, that would also be kinda neat. |
|
|
|
"Incoming"? The word used in the title of the blog post is "Upcoming". These two words mean quite different things. I've read that post twice now... and I'm still not entirely sure what they are even talking about. In the article he talks about new features for the wallet. Naturally, in our official promotional brochures at the time, we did not think it appropriate to make such marginal statements. So our investors could only read a small part of our plans. In particular, we talked about changing the user interface and turning the app into a personal finance combine. That quote is saying that they talked about changing the user interface etc back in 2016... it doesn't mean there are new features coming to the wallet now (or any time soon). |
|
|
|
Ahhh good ol' BRD wallet... I remember getting annoyed at that wallet years ago because the developer had implemented this thing where you had to enforce a bunch of security features on your device for the wallet to work. I don't recall the specific details but I vaguely remember it annoyed me greatly at the time because I was heavily into Android OS development/testing and it was making life difficult trying to do that and test "Bread" (as it used to be known). Interesting that they sold out... that is one way to make money from creating a "free" wallet I suppose |
|
|
|
|
pooya87 is totally on the money here... Unfortunately, knowing the "plain text" and "encrypted text" in this instance is of no benefit in determining what the encryption key is. You're not able to "work backwards" in this instance.
Your only option will be bruteforce.
|
|
|
|
Blockchain.com (at the time, I believe they were blockchain.info) has in the past, inadvertently accepted invalid transactions. I don't remember exactly how their software was tricked. IIRC, people had submitted the invalid transactions to an interface on blockchain.info's website.
Sounds like something that ol' mate "amaclin" did once upon a time with his "bitcoin doubler" escapades... It seemed they were able to get a large number of "non-standard" transactions showing on blockchain. info as it was called at the time. (refer: https://bitcointalk.org/index.php?topic=1356143.msg13804131#msg13804131) |
|
|
|
Can I turn the question around and ask why you think you need to delete an old wallet? What do you think you can gain from deleting a wallet as opposed to having it on your harddrive? |
|
|
|
Anyways, now I can't get the flash drive to open on my computer., is it possible that its not compatible with my newer computer?
What OS are you running? Windows? If so, does it make the USB connected noise when you plug the flash drive in? Do you get any "error" notifications saying the device has failed to be recognised or initialised? 12 years is quite a long time for flash drives... so, it is possible that the device is actually dead. |
|
|
|
What version of Bitcoin Core are you running @thekingsking? The latest one is 22.0 and the issue shouldn't be present on that one...
^^^-- This. I suspect the OP has run into the "first character" bug... but as RickDeckard has pointed out, it shouldn't be an issue if they update to the very latest version. |
|
|
|
Can't say I would recommend that method unless you have some way to guarantee that the PC you've used to create the encrypted file is (and always will be) kept 100% offline. Otherwise, the "traditional" offline methods of securely and safely storing your seed backups on (waterproof) paper and/or steel plates, using a fireproof safe, multiple offsite backups etc are probably your best option. Having said that, whatever you do end up doing, make sure you actually do make backups of your wallet phrase!  |
|
|
|
is there some way to securely run BTCRecover seed phrase recovery on cloud rigs, like vast.io?
The short answer (ignoring all the performance/cost issues is), is "No, it is not secure". You're putting data on the cloud... the security related issues with this should be obvious |
|
|
|
Perhaps there could be some way to implement this as a Layer 2 solution that would enable some sort of "trustless" mechanism to enforce the transfers etc? |
|
|
|
|
Yes, it is entirely possible to copy all the blockchain data from one node to another... I did exactly this when setting up an umbrel node on a Raspberry Pi. I copied all the blocks from a Windows box, onto the harddrive being used by the Raspberry Pi/Umbrel.
As noted, make sure you also copy the chainstate, or you'll have to wait for you new node to reindex the entire blockchain (can take some hours depending on your hardware).
I second the recommendation to ensure that you initially use the same version of Bitcoin Core to avoid any database version issues, but by all means update afterwards once you've confirmed that everything has transferred OK and is working correctly.
|
|
|
|
I'm a little confused. How exactly did you delete an unconfirmed transaction? Are you just talking about an "unconfirmed" invoice that is showing in the "Receive Queue" on the "Receive" tab? I can see a "delete" option here:  Which will remove the "request", but any unconfirmed transaction that has been broadcast by the sender will still reflect in your wallet (on the "History" tab):  There is no "delete" option for actual unconfirmed transactions:  If this is the case, it would seem that you generated a request for payment, but no transaction was ever actually broadcast to the network. Consequently, you'd need to follow up with the person who was meant to be sending you BTC and ask them why they haven't sent it... or to provide a transaction ID/details for the payment they made. |
|
|
|
|
Show Posts
