In my watching only Electrum account it says I have a balance of 960 mbtc. Every time I try to send the money a standard wallet nothing happens it just says pending. Is there any way where I can get my money off of a watching only account to a normal wallet??
Like I said, you did not send any coins anywhere. You are simply watching an address, nothing more. Go back to PC where your Bitcoins are. |
|
|
|
|
The way I understand it, you didn't actually send any coins then, you just added an Address and Electrum tracks transactions for it, so essentially your coins are somewhere else.
|
|
|
|
|
If you have Electrum on Android(or iPhone) it should have an ability to send the coins to whichever address you want. There should be a tab called Send where you can input your amount and address(please always TRIPLE check the address is the same as the one you are sending to).
|
|
|
|
|
Without telling us what app, we can't magically figure it out.
|
|
|
|
|
First, I understand you are panicked. But you made an account where?
|
|
|
|
|
Using libsecp256k1+sipa's ec grind commit(which uses endomorphism) I get at most 13 million public keys per second(per core) using a batch of 4096. Which means 4 cores would equal roughly 52 million keys per second on my 8700k. If we use both compressed and uncompressed, I guess it automatically goes to ~104Mkeys/s.
|
|
|
|
|
Thank you. I'll have a look at libsecp256k1 + your proposed changes.
|
|
|
|
well apparently it is against some moderators rule to question this apparent attempt to hack private keys - so carry on! seriously hope this never succeeds.
This tool is to bruteforce private keys. Bruteforcing means to try out every possible combination. You can't forbid someone to try out each number (since private keys are basically just big numbers). The keyspace is big enough for a randomly generated private key to be never found by such a bruteforce tool. This is not hacking in any way. It is just 'trying out numbers' (and it will not succeed in finding private keys generated by proper wallets/clients/etc..). Oh, I get that it wont succeed, however, several of the posts here are specifically about targeting specific wallets with high enough balances. Which is even worse!!! Do you know what the likelyhood is of getting 1 right out of 256 bit(well, slightly less than that) keys is? |
|
|
|
I wrote that answer. The current speed of the public keys generation on my laptop is 185 MKeys/s (I compute only compressed keys, only the "x" coordinates). It's real. If I computed "y" coordinates too I could exploit the fact that (x,y) and (x, p-y) (that is the "symmetrie") are 2 valid points and maybe I would get more speed. I'm talking about public keys generation, not addresses generation. The performance of addresses generation is obviously lower, about 12.7 MAddresses/s (always on cpu) If we compare vanitygen and my library on writing addresses speed (not only generation) the difference is even bigger: --> https://bitcointalk.org/index.php?topic=25804.msg23710724#msg23710724Secp256k1 library too is using optimizations to get more speed: https://bitcointalk.org/index.php?topic=2934774.msg30174356#msg30174356Should I assume that you do not wish to make the math available? Or is it already implemented in libsecp256k1? Cause millions of combos per second is pretty good, on a CPU too. |
|
|
|
|
Yes, block withholding is possible, but people with 50% of the hash power do not mine in pools, they are the pool. Not sure how it is now, but generally in the past it was possible for someone with >51% of the hashpower to mine blocks and not broadcast them immediately then after a while, spend his coins on exchanges, afterwards releasing his mined blocks to the network thus double spending.
|
|
|
|
not to sound to ignorant - but I gotta ask, is this just to crack btc addresses with the intent of stealing the btc ?
Not sure, I mean it's a fun pet project, but in reality it's actually infeasible. So nobody here can actually steal any bitcoins. |
|
|
|
Also, it's actually wasteful checking for only one address, one should maintain a list of bitcoin addresses. Also, for a speed up, one can also use two loops, one for bitcoin addresses, whose pubkeys are unknown, and those who are known. This way you avoid doing unnecessary sha256+ripemd hashing giving some speed up.
Brainflayer uses a Bloom filter so it can check hundreds of millions of RIPEMD160 addresses simultaneously, although these days with a lot (10%+) of false positives. I don't know whether it would be possible to shoehorn a Bloom filter implementation (including the filter data) into a GPU application. The Brainflayer implementation addresses 2^32 bits (512MB of RAM), but the filter is badly saturated by the large number of Bitcoin addresses, so you would need to use a lot more RAM for the filter data. Sorry I am not familiar with bloom filters. Bitcoin addresses are indeed a lot, but not many of them are of interest. It's pointless to add a Bitcoin address with a balance of <0.01 or <0.10 to the list. Keep the list more or less small, I mean the first 200k blocks have enough coins I guess, if they aren't spent. |
|
|
|
Also, it's actually wasteful checking for only one address, one should maintain a list of bitcoin addresses. Also, for a speed up, one can also use two loops, one for bitcoin addresses, whose pubkeys are unknown, and those who are known. This way you avoid doing unnecessary sha256+ripemd hashing giving some speed up. Even compressed Bitcoin addresses, whose pubkeys are known can be uncompressed. Another thing to add, a user on the crypto stackexchange says he managed to create a more efficient OpenCL kernel just for this https://crypto.stackexchange.com/questions/54622/optimized-modular-multiplicative-inverse-for-bitcoin-secp256k1 |
|
|
|
Just wanted to give a heads up that I went up and patched vanitygen to compile against latest OpenSSL, whose interface has changed in the last few years. I also found that the opencl kernel works just fine without any changes on modern GTX 10XX cards. I personally get 60+MKey/s. https://github.com/weallknowthis/vanitygen/tree/dev |
|
|
|
|
Has a block been mined that included your transaction? Also, this is Bitcoin discussion, however I have no trouble helping when help is needed.
|
|
|
|
|
I mined when GPUs were still a thing on Bitcoin. It's true that everybody has some GPU, and back then I did have one barely playing on it, that I used to mine with. ASICs on the other hand were expensive, not easily available for purchase, have a tax on them and can be a pain in the ass to import, adding more cost.
One can see how it can be a hurdle to obtain them. They also have no resale value after a while.
|
|
|
|
is there any forecast to fix compatibility with new cards?
Only if there is incentive to do so, but...and this is a big but. The original author of vanitygen has not been seen for years, so even if there is someone out there who could, you would have to use a fork of this software. However, if you can tell me what the issue is with newer cards, maybe we can think of a solution. OpenCL not working? Errors, or slow generation? |
|
|
|
|
Yes this is just about the keypairs. Alright, so I understand that you get 2 bitcoin addresses per one private key depending on compressed/uncompressed. But still 30 million keys, is quite a lot. Even vanitygen can only do 500k/s with point addition(though we do include sha256 and ripemd160 hashing).
|
|
|
|
|
Sucks that more hashing power was not added :/, the bitcoin difficulty increased, whereas the speed on here has remained more or less the same. We used to have a block a month, now it's once per 3 months(and will increase).
|
|
|
|
|
Show Posts
