nagnagnag2
|
|
March 27, 2013, 11:16:23 PM |
|
1 BTC bounty for a fix for 13.x catalyst + vanitygen patch working, with source and builds for Linux, Windows, etc.
I will add 0.1 BTC to that.
|
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
|
|
March 27, 2013, 11:54:17 PM |
|
Is samr7 still developing Vanitygen?
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
March 28, 2013, 09:14:03 AM |
|
hes inactive since a long time
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
wtfvanity
|
|
March 28, 2013, 01:49:17 PM |
|
hes inactive since a long time
Date Registered: June 08, 2011, 10:59:48 PM Last Active: October 24, 2012, 03:59:55 PM
|
WTF! Don't Click Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
|
|
|
malevolent
can into space
Legendary
Offline
Activity: 3472
Merit: 1725
|
|
April 02, 2013, 07:21:54 PM |
|
I think he may return; last time he came back with a new version of vanitygen after 11 months of inactivity.
|
Signature space available for rent.
|
|
|
Lethos
|
|
April 06, 2013, 10:29:48 PM |
|
I'm sure some might find this funny, but has anyone tried this on a Raspberry Pi - vanitygen that is. I got a little project going (My RPi will arrive soon) and it might be nice to have a few of my preferred bitcoin tools on there.
I don't expect fast results, I just wondered if anyone had done it.
|
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
April 06, 2013, 11:37:56 PM |
|
the CPU is too bad for it
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
|
April 07, 2013, 03:49:12 PM |
|
Pardon my abilities, but I think the error may come from the bignum implementation. At least, after removing the functions that cause it to crash, I started re-adding them, then I started to remove pieces of code from functions and ended up with an OK compile which led me to this theory. To further support my theory, change this: typedef struct { bn_word d[BN_NWORDS]; } bignum; to this typedef struct { bn_word d[0]; } bignum; The program won't work correctly, but the calc_addr.cl kernel will compile.
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
MeatPopsicle
Newbie
Offline
Activity: 49
Merit: 0
|
|
April 08, 2013, 08:53:14 AM |
|
How'd you figure out the functions that were causing it to crash?
|
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
|
April 08, 2013, 12:25:19 PM |
|
How'd you figure out the functions that were causing it to crash?
I was more than clear in my post. Anyway, I was still wrong. After talking on the #opencl channel on freenode, an OpenCL C compiler developer said that the issue is caused by incorrect instructions produced by the OpenCL compiler.
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
drrussellshane
|
|
April 08, 2013, 12:41:30 PM |
|
Forgive me if this is a stupid post, but is vanitygen safe?
That is to say, are the keys that it generates always 100% working keys that can be imported into a Bitcoin client? Is there a chance of creating a "bad private key" from vanitygen, such that one cannot, for some reason, import said key into a wallet?
Are the keys that are generated with vanitygen random enough, or at least as random as addresses generated with the standard Bitcoin client?
Also, I am assuming that smarter folks than I have made sure that this little program doesn't create keys and then send them all back to the vanitygen creator or something else likewise nefarious, right?
|
Buy a TREZOR! Premier BTC hardware wallet. If you're reading this, you should probably buy one if you don't already have one. You'll thank me later.
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
|
April 08, 2013, 01:04:03 PM |
|
Forgive me if this is a stupid post, but is vanitygen safe?
That is to say, are the keys that it generates always 100% working keys that can be imported into a Bitcoin client? Is there a chance of creating a "bad private key" from vanitygen, such that one cannot, for some reason, import said key into a wallet?
Are the keys that are generated with vanitygen random enough, or at least as random as addresses generated with the standard Bitcoin client?
Also, I am assuming that smarter folks than I have made sure that this little program doesn't create keys and then send them all back to the vanitygen creator or something else likewise nefarious, right?
The keys should be safe in terms of importing and should be cryptographically safe. I've examined OpenSSL's code and saw that it creates a screenshot of the screen and uses that as seed, then it also uses CryptGenRandom for further seeding on Windows. You are free to seed it yourself as well.
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
Shevek
|
|
April 08, 2013, 02:28:13 PM |
|
Forgive me if this is a stupid post, but is vanitygen safe?
That is to say, are the keys that it generates always 100% working keys that can be imported into a Bitcoin client? Is there a chance of creating a "bad private key" from vanitygen, such that one cannot, for some reason, import said key into a wallet?
Go here, https://www.bitaddress.org , and select the "wallet details" option. Then put there the private key created by vanitygen (you can download the html-js code and create your own page, if you don't trust) and check it Are the keys that are generated with vanitygen random enough, or at least as random as addresses generated with the standard Bitcoin client?
The second option (AFAIK from my last contact with the program) Also, I am assuming that smarter folks than I have made sure that this little program doesn't create keys and then send them all back to the vanitygen creator or something else likewise nefarious, right?
The code is open for your revision.
|
Proposals for improving bitcoin are like asses: everybody has one 1SheveKuPHpzpLqSvPSavik9wnC51voBa
|
|
|
MeatPopsicle
Newbie
Offline
Activity: 49
Merit: 0
|
|
April 08, 2013, 04:09:06 PM |
|
How'd you figure out the functions that were causing it to crash?
I was more than clear in my post. Anyway, I was still wrong. After talking on the #opencl channel on freenode, an OpenCL C compiler developer said that the issue is caused by incorrect instructions produced by the OpenCL compiler. Need to borrow a shovel?
|
|
|
|
yuzhe
Newbie
Offline
Activity: 24
Merit: 0
|
|
April 09, 2013, 11:29:44 AM Last edit: April 09, 2013, 01:37:51 PM by yuzhe |
|
Hello, I've created workaround for buggy 13.x catalyst driver, needs some testing though (especially the miner and win32). For the impatient: linux: $ git clone https://github.com/wyuzhe/vanitygen.git $ cd vanitygen $ make oclvanitygen $ ./oclvanitygen -vv -D x:y 1Blah
In case you get odd output like: Match idx: 0 CPU hash: 0ecfec41290a506e784a4521597213398abf9a98 GPU hash: 08e030855f47c3141a5808d8767a89562ec5c655 Found delta: 497669 Start delta: 1
It means the compiler backend is still outputting broken code (although it compiles). To fix that try: ./catalystwrap ./oclvanitygen -vv -D 0:0 1ov
Windows users can try applying the dll override script in the directory of official vanitygen binaries [edit: link with resulting archive removed due security concerns]. The gory details: https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbeIn short, ATI LLVM-IR backend miscompiles stuff like: uint x, b, c; x += (a < b)
The boolean result of (a < b) is expressed as byte (u8 in crash report), but VLIW architectures know no such thing. Workaround is using artificially complex expressions which cannot be readily expressed as setcc in llvm ir (but will be optimized away during R600 lowering anyway).
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1036
|
|
April 09, 2013, 11:38:40 AM |
|
Hello, I've created workaround for buggy 13.x catalyst driver, needs some testing though (especially the miner and win32). For the impatient: linux: $ git clone https://github.com/wyuzhe/vanitygen.git $ cd vanitygen $ make oclvanitygen $ ./oclvanitygen -vv -D x:y 1Blah
In case you get odd output like: Match idx: 0 CPU hash: 0ecfec41290a506e784a4521597213398abf9a98 GPU hash: 08e030855f47c3141a5808d8767a89562ec5c655 Found delta: 497669 Start delta: 1
It means the compiler backend is still outputting broken code (although it compiles). To fix that try: ./catalystwrap ./oclvanitygen -vv -D 0:0 1ov
win32 binaries are available at: https://www.dropbox.com/s/lddvyiyl58uhgio/vanitygen-0.22-catalystmod.zipHowever received little to no testing, so comments are welcome. The gory details: https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbeIn short, ATI LLVM-IR backend miscompiles stuff like: uint x, b, c; uint x += (a < b)
The boolean result of (a < b) is expressed as byte (u8 in crash report), but VLIW architectures know no such thing. Workaround is using artificially complex expressions which cannot be readily expressed as setcc in llvm ir (but will be optimized away during R600 lowering anyway). Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.
|
|
|
|
yuzhe
Newbie
Offline
Activity: 24
Merit: 0
|
|
April 09, 2013, 11:42:33 AM |
|
Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.
Actually, the vanitygen binaries are verbatim from official zip, plus just opencl dlls stitched in the archive. Naturally you should test on untrusted machine, as every binary code posted on forums. For paranoid users, i'd recommend to use the linux version.
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1036
|
|
April 09, 2013, 11:48:27 AM |
|
Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.
Actually, the vanitygen binaries are verbatim from official zip, plus just opencl dlls stitched in the archive. Naturally you should test on untrusted machine, as every binary code posted on forums. For paranoid users, i'd recommend to use the linux version. Then why does the github https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbe show that "the fix" is modified calc_addrs.cl, oclengine.c, oclvanitygen, etc which would indicate new binaries?
|
|
|
|
yuzhe
Newbie
Offline
Activity: 24
Merit: 0
|
|
April 09, 2013, 12:02:26 PM Last edit: April 09, 2013, 12:57:26 PM by yuzhe |
|
Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.
Actually, the vanitygen binaries are verbatim from official zip, plus just opencl dlls stitched in the archive. Naturally you should test on untrusted machine, as every binary code posted on forums. For paranoid users, i'd recommend to use the linux version. Then why does the github https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbe show that "the fix" is modified calc_addrs.cl, oclengine.c, oclvanitygen, etc which would indicate new binaries? win32 is just downgrade of opencl compiler - no further changes made at this point. I'll provide script to build resulting archive to avoid further implications. I'n the meantime, I'd like to offer you 1BTC for factual evidence aforementioned archive is "virused up" - since it was created on a linux workstation, it is higly unlikely but I'd prefer to be on the safe side - I'm certainly no expert in that area. I've removed the link from my post, in case your accusation is proven to be true.
|
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
|
April 09, 2013, 04:07:45 PM |
|
The fix does not work, I compiled from source, updated CL kernel. I used APP SDK's OpenCL.dll and and amdocl64.dll files, but unfortunately the program hangs before it even prints "Compiling kernel". It doesn't crash, it just hangs with these DLLs and huge CPU usage, but nothing.
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
|