~snip~
This is basically the solution but it's kind of redundant.
A simpler one would be to just sign the tx that would spend all his coins right now. And store that transaction on a server. Write code in your favourite language that broadcasts the tx after Y amount of time just for an added layer of security. And open up a port on your server where the application can listen to.
If the application doesn't get pinged once every X months, weeks, whatever, then it calls the function, and after Y amount of time, the tx will be broadcasted.
So he has to ping the server every X interval, and if he somehow fucks up and forgets, he has Y more time to stop the application from broadcasting his coins.
Hell if you want I can probably set this up for you in node.js right now.
That's not really redundant. Your solution involves trust. OP could theoretically broadcast the transaction earlier (e.g. working together with the recipient). This should definitely be considered. Heretik's solution on the other hand doesn't involve any trust. The owner of the coins is the only one who can initiate that transaction (by not creating a new one). IMO that's the best solution for a dead mans switch (at least the best i can think of). |
|
|
|
|
That's the preferred way, yes.
I am not aware of a way to verify the version PIP installs automatically.
However, i believe PIP is verifying the signature itself. But i'm not sure about this.
|
|
|
|
Bitcoin doesn’t use 2FA. I don’t see why the forum would need to.
Bitcoins aren't simply accessed using a publicly known account name and a (probably less than 10 character long) password. Sure, for people with a very good memory or user who use a password manager, that's not a problem at all. But the majority does probably have a relatively(!) weak password, i believe. A 2FA (a simple mail would be enough) wouldn't hurt and should be relatively easy to implement, IMO. |
|
|
|
To verify electrum on linux: 1. Get ThomasV's PGP key: gpg --keyserver pool.sks-keyservers.net --recv-keys 2BD5824B7F9470E6
(verify yourself, don't trust me) 2. Get the signature file (from electrum.org) 3. Verify: gpg --verify electrum_signature_file.asc electrum_downloaded_file.tar
You should see this line output (among others): Good signature from "Thomas Voegtlin (https://electrum.org) "
That's the important line. |
|
|
|
Yes, it is showing up fone on my end now too.... except that in Bitpay's new desktop wallet, it shows that there is no transaction. I sent another small amount to the same wallet and it appeare instantly, and now has already confirmed. yet, the wallet does not show anything on the firsttransaction
Did you send your second (small) transaction to the same address ? If so, it seems like bitpay's wallet does have some connection/display issues. If not, can you verify that the address you have sent your first transaction to does indeed belong to your wallet ? You can see all addresses of your wallet under Settings -> Advanced > Wallet information |
|
|
|
|
You need to export/import the private key, not the public address.
But it probably is easier if you simply create a new wallet in electron cash using the seed (24 word seed) from electrum.
If you however want to use the single private key, simply go to the 'address' tab in electrum, right click on the address which received the btrash, and click on 'private key'.
Then copy it and create a new wallet in electron cash using this private key.
|
|
|
|
It will, your client is missing the up-to-date information. Therefore it is showing you the last state it has. Regarding the fees, 40 sat/B would be a bit overkill. You can check the current mempool status at https://jochen-hoenicke.de/queue/#1,8h. Currently a fee between 10 and 20 sat/B is enough to get a relatively quick confirmation. |
|
|
|
It seems like your client isn't properly synced. A rescan should fix this. First, did you already create a backup of your wallet.dat ? If not, immediately do one! Second, if you don't necessarily want to use core, you might simply use a lightweight client (e.g. electrum). You can export your private keys from core and import them into electrum. Since electrum is a lightweight client you don't need the whole blockchain stored. For your next transaction pick a slightly higher fee. Or, if you have time, 1 sat/B should be fine (which could take longer to confirm). |
|
|
|
|
Running XP is heavily discouraged.
It is full of bugs and vulnerabilities which aren't (and never will be) fixed.
Anyone which is capable of downloading kali linux would be able infect your system without you noticing it.
This could (and most probably will) lead to a loss of funds.
There are multiple bots online who are actively searching for XP hosts, simply to infect them and include them into their botnet.
The only way to run XP which isn't completely discouraged would be in a complete isolated offline environment. Anything else is just asking for getting hacked.
|
|
|
|
You're basically telling me that I need this many keys 2.207.984.167.552, -at least- to run through every possible combination of 7-letter words, and maybe land into the pattern I want. I'll (slightly) go against bob123's answer here: that number doesn't give you all possible combinations (it also gives you duplicate (wrong) combinations). Without doing the math, I guess it's the number of combinations you need to try for 50% chance of getting the right one. It is not the number to have a 50% chance. It is the average number needed to find the correct key. The correct amount of tries until you find the suitable private key (on average) is 2.207.984.167.552 ( 58^X with X = 7). The amount of keys to have a 50% chance (on average) would be 1.103.992.083.776 ( 58^X / 2 with X = 7) I have mentioned that's the average (multiple times). Is there anything else which you think is wrong (even slightly)?  |
|
|
|
i still will get the forked coins later on in the future right?
For the 100th time.. YES. So its the 12 word electrum phrase that is what is needed?
You need the PRIVATE KEYSBut they can be derived FROM THE SEED. So basically.. YES. Thus that is the phrase that is needed for bch claim in electron cash and the bitcoin fork soon?
It is needed for ANY fork.. ANY. |
|
|
|
2018-11-11 12:27:53 (ERROR) -- ArmoryQt.py:1862 - Failed to setup SDM
Traceback (most recent call last):
File "ArmoryQt.py", line 1857, in startBitcoindIfNecessary
File "SDM.pyc", line 190, in setupSDM
BitcoindError: bitcoind not found
You need core to be synced AND running. Also make sure it is the latest version (0.17.0) |
|
|
|
If you take my own address for example : 1KingZeeW97uLvngcUA3R6QJx18Fn78ddb
You're basically telling me that I need this many keys 2.207.984.167.552, -at least- to run through every possible combination of 7-letter words, and maybe land into the pattern I want.
Basically, yes. But you also could have found the private key to that address after your first or second key. But on average, yes. You need to calculate that many keys to find an address with a prefix of 7 chars. Since there is quite some good hardware available currently, this doesn't take too much time. |
|
|
|
The amount of request your personal core instance can handle depends on your hardware. The CPU and Disk I/O are the main bottleneck. Your network bandwidth will probably allow more requests than your hardware can handle. I can't give you an exact (or estimated) number since i haven't tried overwhelming my full node yet |
|
|
|
Are you sure? I thought it showed worst case scenario time? I'm talking about samr7's vanitygen. I know it might take a lot less if you get lucky, but it shouldn't go above that time. It calculates the time to reach 100% probability of getting a specific pattern. I don't know how this specific vanitygen works in terms of displaying the estimated time. But searching randomly is the best approach (You can't get better than randomly searching; searching successively would create vulnerabilities since those private keys wouldn't even be close to random anymore). Calculating the maximum amount of time and the time it takes to have a 50% probability is the same for all vanity address generator. You mean 34? The pattern is inside the address, not the private key! I'm going to edit your maths in the next quote.
34 (more or less) is the length of the address. But the set of possible characters is 58 (addresses are encoded in base58). The charset is: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz See this part I don't understand. How are you calculating all this? The pattern is in the output, not the input.
If you want to have 1 (specific) out of 58 characters at the first position, you need to generate 58 private keys (which will result in 58 addresses starting with different characters ON AVERAGE, since the hash function is producing a pseudo-random output). For 2 chars, you need to create 58 * 58 addresses (which also means creating 58*58 private keys) to get your desired prefix (again: on average). Therefore it is: 58^X with a prefix of X chars to find the correct private key / address. And for a 50% probability (how it is displayed in another vanitygen (not sure about the name currently)) you'll have to divide it by 2. Therefore (58^X) / 2 for a 50% probability. See what I dont understand is how does calculating n number of private keys, gets you closer to generating your wanted private key. How does the process of elimination go? If it were truly random then we'd just be blindly generating random keys constantly.
It doesn't get you any closer. You are just calculating a massive amount of private keys (and addresses) until you have found one with the desired prefix. There is no elimination at all. You can compare it to calculating the probability of having 10 times a 6 in a row when rolling a dice. You can not predict when you will have those 10 6's in a row. But you can mathematical estimate a number of rolls to get a 50% probability (it gets boring, i know.. but: on average). So, vanitygens DO randomly generate private keys. They estimate that you need Y private keys (and therefore addresses) generated until you have found your desired one. |
|
|
|
In fact, it is randomly generating private keys, trying to find a private key which results in an address with the desired prefix. The estimated time can be calculated using stochastic. Note that this time is always an average. There is never a guarantee that you'll find your desired private key in the estimated time. It might take 1 second or 10 years. Since the hashing function is generating a pseudo-random output, you can calculate how much private keys needs to be generated to find an address with a specific prefix (on average!). To be more precise: There are 58 different characters inside an address. To find a private key which results in an address with the prefix of 1 chosen character, you'll need to calculate 24 (= 58 / 2) private keys to have a 50% probability. To get an address with a prefix of 2 chosen chars, you'll need to calculate 1682 (= 58 * 58 / 2) private keys ( to have a 50 % chance of finding a suitable private key). The formula for X chosen chars (with a 50% probability) is: Priv_Keys_to_be_calculated = 58^X / 2 |
|
|
|
|
High ressource usage while reindexing is completely normal.
Core is verifying each block currently. This results in high CPU/HDD usage.
If you are running the GUI, you should be able to see how long it takes at the bottom bar.
According to your log, you are currently at blk00695.dat.
Without the GUI, you can check how much blk**.dat files there are to estimate the time it still needs to index.
|
|
|
|
If you already have the correct private keys (those which contained BTC when the fork happened), simply download a BCH wallet [1] and import them into the wallet. I'd recommend to run the BCH wallet inside of a virtual machine.. just to be on the safe side. [1] e.g. https://www.bitcoinabc.org/ (no guarantee that this wallet works and is non-malicious) |
|
|
|
|
Unfortunately there is no way for you to get the BTC back (neither by 'refunding' in terms of reverting the transaction nor by finding the thief).
It is not possible to send more than received. The last transaction contains more than 20 inputs. blockchain.com just isn't showing them without clicking on the transaction itself.
Instead of trying to find the thief (which is kind of uselesss, especially if he has used a mixer) you should rather try to find out how he got access to your private keys (which i assume he had since you are talking about a thief and not about a scammer).
If you had a desktop wallet and don't know how he got access to your private keys, make sure to check your whole system for malware. And in case of doubt rather set up a fresh OS.
Do you have any clue on how the theft happened ?
|
|
|
|
I'm not going to show you the log file, since this wouldn't help. I alreade checked the log file and there is nothing unusual. But thank you.
If it's not working for you, the solution is inside of the logs. Just because you weren't able to find it, it doesn't mean that the logs are useless. If you don't want to post your log files, that's alright. But don't claim that it 'would not help', since this is definitely up to us. |
|
|
|
|
Show Posts
