Yeah, given that it's a simple c commandline tool, it's pretty easy to compile and then use it "offline"... so at worst it might just give an incorrect result for one of the conversions... but like you say, even that would be relatively easy to double check. I was fairly sure I actually had a compiled version of that floating about somewhere, but I think I lost it in one of my system rebuilds  Thanks for reminding me that I should go and create some new ones  |
|
|
|
Wow. I had no idea about those. I felt fine with myNode, but these seem much better solutions. Have any of you two tried myNode to tell me if it's worse? I'm looking forward to try them once my vacations end.  I didn't bother with MyNode as I didn't want to pay for the "premium" option as (aside from the support feature) it just gives things which are included in RaspiBlitz and Umbrel by default. I've tried both RaspiBlitz and Umbrel... RaspiBlitz works quite nicely with a touchscreen for a completely standalone Node setup, but is quite capable of running "headless" (which is how I used it), where you just ssh into the Pi to access the back-end as required, and can use the browser based interfaces for other things (block explorers etc). I'm currently running Umbrel v0.4... it's pretty nice (previously mentioned security issues aside), and for the most part you can control most of it via the browser (again, you have access via ssh if you need). v0.4 also added some nifty little features like "pi-hole" (ad blocking for you network etc) Overall, I think Umbrel "looks" more polished than RaspiBlitz and seems slightly more cohesive... and is what I'll probably end up using long-term... but honestly, either of them are fairly solid setups, and as the Umbrel dev's state quite openly, the current security setup isn't quite ready for primetime, so I'm not really committing vasts amount of time/resources to it as yet If you don't mind the slowness and don't want to be known that you're running a node, you'd use Tor. I can't think of another reason why you should run a node through Tor. 041936] Both RaspiBlitz and Umbrel support Tor... from memory it has to be explicitly turned on for RB, with Umbrel it's the default setup. Honestly, there doesn't really seem to be much in the way of slowness really... but then I didn't do the IBD using the Pi (I copied the block and chainstate data from another node)... |
|
|
|
After tearing apart half the house, I found an old tablet with a bookmark to Coinbase on it. I tried one of my classic old logins and it worked! Did this Coinbase account also have the ETH that you believe you had?  And does the 12 word recovery phrase that you have match the one to the Coinbase account? From memory, the Coinbase account (username/password etc) is custodial... whereas the Coinbase wallet is not... and would be recovered with a 12/24 word phrase etc. Are you sure you have recovered everything?
If you're talking about Bitcoin mining, you need serious planning (such as location, cooling and electricity cost) and decent capital (An ASIC cost thousand dollars, while PC with a GPU only cost hundred dollars).
Have you seen the cost of GPUs lately?   Seriously tho... As the others mention, You need some heavy duty hardware (ASIC) for BTC mining. The only way to get Bitcoin with a GPU rig is to use a service like Nicehash which mines altcoin algorithms, but pays in BTC (after taking a slice of course  )... or to mine altcoins directly with a pool and then exchange/sell for BTC. |
|
|
|
|
Most of the popular multicoin walllets offering staking tend to be "app based", running on mobile devices... ones are like "crypto.com" etc. which don't natively support Tor.
However, there are ways to ensure that all traffic from your device or computer are routed through Tor... alternatively, a "lesser" solution would be to use a standard VPN service to "anonymize" yourself.
|
|
|
|
... a binary encoded plate might serve as the backup of the main plate that holds characters in form of letters and numbers. And each of both plates could be hidden in the different places thus increasing the probability of SEED restoring in the case of any disaster.
This is indeed how I view this solution. It is another option for people to make a backup of their seeds. It's cheap, doesn't require a lot of tools or hard to get equipment... and unless you live next door to a factory with a large vat of acid towering over your property or near a volcano, it should be relatively hard wearing for all but the most extreme situations. No reason you can't have one of these AND a "normal" steel backup with words/letters etc... redundant backups are a "good thing"™ Obviously, it's not the best solution for trying to enable recovery by your less than technical heirs... but that's not really the core objective of this particular solution, as far as I can tell. There are 10 types of people in this world... those that understand binary and those that don't.
|
|
|
|
Not really something I've really looked into... but from what I'm understanding from reading the descriptions and watching the demo, is that this system is a way for two peers to find, connect and manage a (fully encrypted) WebRTC connection between themselves without requiring any sort of central co-ordinator of some description? With the added benefit of being able to set a fee that needs to be (continuously) paid for the connection to continue. I assume the call fee is only able to be charged by the "receiver" of a call? Ie. You can't set a 10000 sat/min fee on your node, call someone else and after they answer they have to send you payment (after the first 60 seconds)? And is there a notification warning that pops up when you call someone/the call is connected that advises of their current fee? In any case, it's definitely a fascinating idea... and I can see the potential benefits for existing Bitcoin/LN Node operators... but the overheads required to set this up for someone who doesn't already have a node are quite high. |
|
|
|
You seem to be speaking of "the blockchain"™... as if there is only a singular instance of it which a malicious actor can alter and thereby affect everyone. In reality, any malicious actor will be able to do whatever they like to their copy of the blockchain data... with whatever code they want to use. However, as illustrated by pooya87 illustrated, any "non valid" data created by this malicious actor will be rejected by everyone else running "non modified" nodes. Also, you keep talking about manipulating the blockchain... the data is not manipulated... it is "created" (ie. transactions are created, blocks are mined)... the entire concept of the blockchain rests on the fact that it is immutable... so the data cannot be "manipulated". So, I am thinking I am not understanding what you actually mean when you say: The blockchain itself is not doing any checks on the code that must manipulate it and therefore it can be manipulated in many possible ways, apparently conforming to the shared protocol.
In what ways is "the blockchain" being manipulated? |
|
|
|
With regards to the "weird" privkey format, I'm wondering if it was some sort of coding error where, for whatever reason, the pure Hex encoded key was converted to Base58 and then printed. They skipped the whole mainnet and compressed key bytes (ie. 0x80 + hexkey + 0x01)... and also failed to create/append the checksum bytes. Possibly a regression bug with code where someone was testing each step in the process at some point and then didn't "uncomment" their code and/or accidently used the wrong version of a script or something? Possibly a test batch that were accidently used/shipped instead of being destroyed? I generally like to go with Hanlon's Razor: never attribute to malice that which is adequately explained by stupidity So, one would hope that the "non-standard" privkey was just a simple mistake of some sort... and not necessarily and exercise in trying to prevent people from actually redeeming their coins. However, even ignoring the "weird" privkey format, the really troubling aspect to all of this... the coins were swept (and partially returned and then swept again)... with what appears to be an intact hologram!!?! But then, there only seems to be this single case... although I suppose without a list of addresses it is impossible to check if this is actually an isolated case, or simply the only reported case. |
|
|
|
I have some good news and some bad news.
Good news is that three days passed after I replaced cables/port and my Seagate drive is working like a charm, so it looks like I don't have to purchase new drive after all.
I left it running 24/7, every parameters are looking very good and there are no issues with crashes or bad sectors, CrystalDiskInfo is showing healthy drive. One thing which I'm fairly sure wasn't mentioned as yet... have you checked the actual voltages coming out of the PSU? There are some utilities that might be able to display these values... but the most accurate way is to check using a multimeter and direct measuring the values. A number of years ago, I had a PSU that was "dying" and was "occasionally" only providing ~10-11V on the the 12V rail... probably didn't help that I had a stupid number of HDDs installed in a stupid RAID array [1]But I digress, the "less than ideal" voltage meant that I was getting weird issues with a drive "disappearing" randomly and/or straight up data corruption and r/w errors etc. At first I suspected it might be the drive, but it came up clean in all tests... I changed cables etc... still got weird stuff happening. It wasn't until I checked the voltages and noticed that the 12V rail was sometimes dropping down to values nowhere near 12V that I was able to finally figure it out and solve the issue. New PSU... "proper" (and stable) voltages... and the drive worked perfectly after that.
As for the "best hard drive for a node" question... I'm fairly happy with the blocks on (1TB) HDD and "chainstate" symlinked to SSD solution that I've been using. Not sure what it would be like with an IBD, but I've got 2 copies of the blockchain at the moment... so I don't anticipate it being an issue. Even when I set up my Pi node using one of the "cheap" USB3.0 1TB Seagate external HDDs (firstly with RaspiBlitz and then Umbrel), I was able to shortcut that process quite substantially by simply copying all the required data from my other node instead of having to "suffer" through a full sync.
[1] - RAID10 with a bunch of old NAS drives I got gifted by a friend... because I could (Mobo had a built in RAID controller)... I had never used RAID before and felt like experimenting with stuff... and then realised I had too much data installed to "undo" it all |
|
|
|
it looks exactly like that, but when i type in the private key in electrum the "next" button becomes grey and i cant click on it anymore.
it only accept the public key .
That only happens when there's at least one wrong character in the private key. It has a checksum so that if you've typed it wrong, the inputted private key will be invalid. With that, look for possible typos. By the way, it's case-sensitive. This. You need to double check every character you are typing in. You also might want to check that the private key is actually in one of the following formats: For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5 on mainnet (9 on testnet). Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet (c on testnet). refer: https://en.bitcoin.it/wiki/Private_key#Base58_Wallet_Import_formatWhat character does the private key start with? 5, L or K? or does it start with something completely different? As mentioned earlier: DO NOT post your full private key anywhere or send it to anyone! |
|
|
|
o_e_l_e_o is correct... this seems like a blockchain.com problem. Which, unfortunately, means you're at the mercy of blockchain.com support whilst trying to get it sorted. Here is my btc adress 3LhZCEArqM2KsNGUKhqrC2rixojHMjda9Z
What wallet is this btc address from? Your blockchain.com trading account, your blockchain.com webwallet or some other external wallet? |
|
|
|
If you read the release notes for 0.21.0, you'll see the descriptor wallets are regarded as "experimental" and should not be the "default" wallet type created: https://bitcoincore.org/en/releases/0.21.0/Additionally, the import and export functionality for these types of wallets is different: As Legacy Wallets and Descriptor Wallets use different mechanisms for storing and importing scripts and keys the existing import RPCs have been disabled for descriptor wallets. New export RPCs for Descriptor Wallets have not yet been added.
The following RPCs are disabled for Descriptor Wallets:
- importprivkey
- importpubkey
- importaddress
- importwallet
- dumpprivkey
- dumpwallet
- importmulti
- addmultisigaddress
- sethdseed
So, as you can see... there are no "Export" functions for descriptor wallets as yet. So you will not be able to export anything at this time. Note that v0.21.1 is just the update to support Taproot... so the 0.21.0 info regarding descriptor wallets should still hold true. Essentially, unless you explicitly need descriptor support (and you can only use it for importing at this time), I would suggest that you continue to use the "legacy" wallet option by making sure that the "descriptor wallet" option is not used during wallet creation. |
|
|
|
Unfortunately, most of the test vectors I've seen don't get as finely grained as the individual steps in an algorithm... instead they'll focus on the "initial input" and the "final output" In any case, you might want to have a look at this: https://github.com/steve-vincent/bip38Granted, it's Python 2.7... but it's a "working" BIP38 python project and might offer some insights as a starting point. |
|
|
|
Did you see the note on the btcrecover docs page: Just be aware that the JTR kernel doesn't scale as well once you get past ~2x GPUs...
So, it would seem that simply cranking up the number of GPUs may not necessarily result in vastly superior hashing rates and it's possible that you're running into this issue where the added GPUs are just not being utilised properly due to the lack of scaling. Have you tried a machine that just has 2x GPUs and tested to see what sort of performance you get there? In the examples further down the page, they seem to use a setup that uses five instances of 2x 2080ti to achieve a "10 GPU" rig. So, you might want to do as ETFbitcoin has suggested and benchmark a few different setups to find the best $/hashrate setup. |
|
|
|
You're using SegWit UTXOs... have you included the appropriate "segwit" arguments? from LedgerJS repo: createPaymentTransactionNew
To sign a transaction involving standard (P2PKH) inputs, call createTransaction with the following parameters
Parameters
...
-redeem script: is the optional redeem script to use when consuming a Segregated Witness input
...
-segwit: is an optional boolean indicating wether to use segwit or not
...
-useTrustedInputForSegwit: trust inputs for segwit transactions
Note, you may not need to specify all of these arguments for your particular transaction. |
|
|
|
hello, i have bitcoin core.
I downloaded my blockchain,
I can open my wallets,
1 Opening hour of 1 wallet,
I don't see anything,
no coins, no transactions,
There must be, it is SURE ...
As per my previous response to your other thread... if you have a fully synced, non-pruned Bitcoin Core node (ie. it has ~400 Gigs of blockchain data downloaded and stored and is currently up to block# 694088 or higher)... and you load in a wallet.dat and the wallet is rescanned, which it seems to be given that it is taking an hour to open the wallet.dat... and you then see nothing... Then the wallet is empty! You're not even seeing any transaction history, so the wallet files appear to be completely unused. It's also possible that the wallet files could be altcoin wallets, although they would still likely contain some sort of transaction history and they'd just show up as "unconfirmed, not in mempool" type transactions in the history list (as they would not be in the Bitcoin blockchain data). is it possible that the funds are hidden,
incorrectly downloaded, because of modified option?
on my address,
Normally there are parts on it!
The funds cannot be "hidden". Bitcoin is a "public" blockchain. All transactions are visible to everyone. If the wallets contained the private keys to any addresses that were used in a transaction on the blockchain, then they would show up in the transaction history. Bitcoin Core has plenty of checks to ensure that the downloaded data is valid. That is how blockchains work... each block in the chain builds on the previous one, so any invalid block is easily identified and discarded. So, if things were incorrectly downloaded, you'd have invalid blocks and you'd either get warnings about it, or Bitcoin Core will ignore then invalid blocks and redownload the correct data. Again, assuming fully synced, non-pruned node, if you're seeing no transaction history, then the wallets are unused. If you see transaction history, but a zero balance, then the wallet is empty. |
|
|
|
Yes its the latter . Bitcoin qt got
1,password
2.passphrase
No... that is not how Bitcoin QT (aka Bitcoin Core) works. Bitcoin QT originally had NO password at all, there was no wallet file encryption. Version 0.4.0 (Sep 2011), they added wallet encryption: https://bitcoin.org/en/release/v0.4.0Bitcoin QT/Core has never used a recovery "passphrase" system that wallets like Exodus/Jaxx/Coinomi/Electrum and hardware wallets use. Bitcoin QT/Core has always relied on making backups of the wallet.dat file. Maybe people forget the password and just got the passphrase. At least in my case i download bitcoin core put the same password and the same passphrase and got my old info and the old configuration.
If you download Bitcoin Core onto a new computer and run it, it will create a brand new wallet.dat file with completely new private keys/addresses... even if you use the same password as a previous wallet, the private keys/addresses will be different. You can NOT recover your wallet in Bitcoin Core simply by using the same password. You absolutely must have a copy of the previous wallet.dat file... if you don't have a copy, then you will never recover your old wallet. How i can explain the hole bunch of encrypted key with metadata its will be impossible i think.
No, it's not impossible. All you are seeing is the "new" keys/addresses that have been created in your new wallet. Again, with Bitcoin Core, to recover your old wallet, you need a backup copy of the original wallet.dat... there is no recovery passphrase option available. |
|
|
|
In any case, this really should not be happening. It's not "normal". I have both a desktop with a SATA HDD running Win10+Bitcoin Core, and a Pi with a USB3.0 external HDD running Umbrel, and neither exhibit this behaviour. There seems to be something peculiar to your specific setup that is causing this, and I fear that you are going to continue to get these invalid block errors unless something in your setup (ie. hardware config) changes. |
|
|
|
If you have a fully synced Bitcoin Core... and you load a wallet.dat into it (and it has been rescanned) and the balance is zero, then the wallet is, unfortunately, empty. If you have transaction history showing, then you can probably trace where/when the coins were sent. If you have no transaction history (as well as zero balance), then the wallet was never used. Just because you have a lot of old wallets, it doesn't mean those wallets actually contain anything. |
|
|
|
|
Show Posts
