<<  >> (p.3)
    Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 1155143 times)

    • samr7 (OP)
    Full Member
    ***
    Offline

    Activity: 140
    Merit: 440

    Firstbits: 1samr7


    View Profile
    July 06, 2011, 07:22:06 AM
     #41
    Quote from: davux on July 06, 2011, 01:12:27 AM
    By the way, did you find anything about the single-proc behaviour? I'm not sure my laptop would handle the heat of having both CPUs working anyway, but other people with several CPUs might be interested in taking advantage of all of them.

    Quote from: BitVapes on July 06, 2011, 05:25:13 AM
    this is cool.   I noticed it seems to only fill up 1 cpu core.  Should I kick off multiple instances so as to max out all my CPU power?   Or will it be redundant re-searching keyspace it already searched for my vanity phrase?

    That's correct.  For the time being, you need to kick off one instance for each CPU core you want to use.  The key space searches won't be coordinated, but it's quite unlikely that any two instances of this program that are ever started by anybody will ever check the same keys.

    Quote from: phillipsjk on July 06, 2011, 05:47:56 AM
    Proper entropy is hard.

    Process ID is 16 bits. Unix time is about 26 bits of entropy (assuming 2 year span, second resolution). Total Entropy: 42 bits. (unless I am missing a source of entropy)

    Digging through OpenSSL 1.0.0d, the main source of entropy for the default RNG on Linux would appear to bedev/urandom, or failing that,dev/random ordev/srandom.  In fact, if you want to, you can load it up in strace and watch it opendev/urandom and read random bytes.

  • SgtSpike
    Legendary
    *
    Offline

    Activity: 1400
    Merit: 1005



    View Profile
    July 06, 2011, 07:25:47 AM
     #42
    Quote from: error on July 06, 2011, 07:15:13 AM
    Quote from: SgtSpike on July 06, 2011, 07:13:40 AM
    Quote from: EricJ2190 on July 06, 2011, 06:55:34 AM
    Quote from: RylandAlmanza on July 06, 2011, 05:59:44 AM
    Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!

    Not sure if I qualify as "trusted" but here is a quick Cygwin build: http://www.sendspace.com/file/yzsf0z
    Thanks.  I get this error though:

    Quote
    assertion "check_upper || ((bnlow2 == NULL) && (bnhigh2 == NULL))" failed: file
    "vanitygen.c", line 482, function: get_prefix_ranges
        113 [sig] vanitygen 956 open_stackdumpfile: Dumping stack trace to vanitygen
    .exe.stackdump

    You probably should paste that file somewhere.

    Doesn't mean anything to me...

    Quote
    Stack trace:
    Frame     Function  Args
    0028C6B4  763E1184  (00000128, 0000EA60, 00000000, 0028C7D8)
    0028C6C8  763E1138  (00000128, 0000EA60, 000000A4, 0028C7BC)
    0028C7D8  610C92FA  (00000000, 00000128, 0028C7F8, 00000000)
    0028C8B8  610C6057  (00000000, 00000000, 00000000, 00000000)
    0028C908  610C643C  (000003BC, 0028C930, 00000002, 00000004)
    0028C9C8  610C6551  (000003BC, 00000006, 0028C9F8, 610C65F5)
    0028C9D8  610C658C  (00000006, 0028CE80, 763F8B12, 61FB0000)
    0028C9F8  610C65F5  (61180054, 00406480, 004063AF, 000001E2)
    0028CA28  6100109B  (004063AF, 000001E2, 00406910, 00406480)
    0028CAE8  0040212C  (00000000, 00D3331D, 0028CC78, 00D316B8)
    0028CCA8  00403F02  (00000000, 00000080, 00D53730, 00001F5C)
    0028CCF8  00404A58  (0028CD36, 00000000, 0028CD68, 61007038)
    0028CD68  61007038  (00000000, 0028CDA4, 61006980, 7EFDE000)
    End of stack trace

  • samr7 (OP)
    Full Member
    ***
    Offline

    Activity: 140
    Merit: 440

    Firstbits: 1samr7


    View Profile
    July 06, 2011, 08:45:53 AM
     #43
    Quote from: SgtSpike on July 06, 2011, 07:13:40 AM
    Thanks.  I get this error though:

    Quote
    assertion "check_upper || ((bnlow2 == NULL) && (bnhigh2 == NULL))" failed: file
    "vanitygen.c", line 482, function: get_prefix_ranges
        113 [sig] vanitygen 956 open_stackdumpfile: Dumping stack trace to vanitygen
    .exe.stackdump

    Wow SgtSpike, you must have been trying patterns prefixed with varying numbers of 1s in order to trigger this bug.  Well beyond my humble test suite.  Anyway, it's mostly clear what went wrong and I'll post a new version in a bit.

  • samr7 (OP)
    Full Member
    ***
    Offline

    Activity: 140
    Merit: 440

    Firstbits: 1samr7


    View Profile
    July 06, 2011, 09:45:59 AM
     #44
    New version 0.4 pasted.  Soon it'll go on github, but not yet.

    • Fix assertion failure when using exact prefixes starting with more than one 1, reported by SgtSpike
    • Include a Win32 binary

  • samr7 (OP)
    Full Member
    ***
    Offline

    Activity: 140
    Merit: 440

    Firstbits: 1samr7


    View Profile
    July 06, 2011, 09:48:49 AM
     #45
    Quote from: znort987 on July 06, 2011, 09:03:52 AM
    Proper seeding of crypto-hard primitives is a hard problem,
    which has been worked on and solved (/dev/urandom).

    Unless I'm missing something, the above method is rather lame
    as opposed to what a standard linux kernel implementation does.

    I can't agree more.  However, EC_KEY_generate_key() gets random numbers from the well-scrutinized OpenSSL RNG, also used by the official bitcoin client and probably half the HTTPS servers on the internet.  And indeed, on Linux, OpenSSL will usedev/urandom.  I wouldn't be too worried about it, if there's a serious problem, we'll probably find out on the news.

  • sirky
    Sr. Member
    ****
    Offline

    Activity: 404
    Merit: 250



    View Profile
    July 06, 2011, 11:30:17 AM
     #46
    Quote from: EricJ2190 on July 06, 2011, 06:55:34 AM
    Quote from: RylandAlmanza on July 06, 2011, 05:59:44 AM
    Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!

    Not sure if I qualify as "trusted" but here is a quick Cygwin build: http://www.sendspace.com/file/yzsf0z

    Thanks a lot for this!

  • riush
    Member
    **
    Offline

    Activity: 73
    Merit: 10


    View Profile
    July 06, 2011, 11:39:57 AM
     #47
    Meh. Now I generated a hand full of nice addresses and the import doesn't work... Gotta try recompiling the most current patch to bitcoin later...
    Can anybody verify the import works?

    btw. to run on multiple cores I just use this.. it's not nice, but it works (for me Wink):
    Code:
    threads = []

    (ARGV[1].to_i rescue 1).times do
      threads << Thread.start do
        puts `./vanitygen #{ARGV[0]}`
        Process.kill("INT", Process.pid)
      end
    end

    Signal.trap("INT") do
      puts "exiting"
      threads.each {|t| t.kill}
    end

    threads.each {|t| t.join}

    run it like `ruby vanitygen.rb 1bit 4`
    1MKKiJhUJgqKyfCLeo7bB1bvELNEM8wUbz

  • pB11
    Newbie
    *
    Offline

    Activity: 12
    Merit: 2


    View Profile
    July 06, 2011, 12:23:52 PM
    Last edit: July 06, 2011, 01:00:20 PM by pB11
     #48
    Quote from: samr7 on July 06, 2011, 07:22:06 AM
    Digging through OpenSSL 1.0.0d, the main source of entropy for the default RNG on Linux would appear to bedev/urandom, or failing that,dev/random ordev/srandom.  In fact, if you want to, you can load it up in strace and watch it opendev/urandom and read random bytes.
    Indeed, my mistake. time() is not the only source of entropy by default.
    I didnt look deep enough.
    Code:
    openssl-1.0.0d/crypto/rand/md_rand.c: ssleay_rand_bytes():
    if (!initialized)
    {
    RAND_poll();
    initialized = 1;
    }
    Btw using just time() was quite secure anyway. Assuming Vanitygen runs at least several minutes, the amount of keys to brute-force is >2^64:
     - 15 bit PID
     - 21 bit timeframe (1 month)
     - 7-8 bit CPU speed, + a few bits of time uncertainty each EC_KEY_generate_key()
     - 2^20+ keys to generate  

  • dserrano5
    Legendary
    *
    Offline

    Activity: 1974
    Merit: 1053



    View Profile
    July 06, 2011, 02:03:47 PM
     #49
    Quote from: riush on July 06, 2011, 11:39:57 AM
    btw. to run on multiple cores I just use this.. it's not nice, but it works (for me Wink):

    I do:

    Code:
    $ for I in {1..4}; do (./vanitygen -r foo; killall vanitygen) & done

    The first to finish kills the others Smiley.

  • drrussellshane
    Hero Member
    *****
    Offline

    Activity: 546
    Merit: 501


    View Profile
    July 06, 2011, 06:43:56 PM
     #50
    Sorry for my noobness... how does one import keys?
    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.

  • SgtSpike
    Legendary
    *
    Offline

    Activity: 1400
    Merit: 1005



    View Profile
    July 06, 2011, 07:22:53 PM
     #51
    Quote from: samr7 on July 06, 2011, 08:45:53 AM
    Quote from: SgtSpike on July 06, 2011, 07:13:40 AM
    Thanks.  I get this error though:

    Quote
    assertion "check_upper || ((bnlow2 == NULL) && (bnhigh2 == NULL))" failed: file
    "vanitygen.c", line 482, function: get_prefix_ranges
        113 [sig] vanitygen 956 open_stackdumpfile: Dumping stack trace to vanitygen
    .exe.stackdump

    Wow SgtSpike, you must have been trying patterns prefixed with varying numbers of 1s in order to trigger this bug.  Well beyond my humble test suite.  Anyway, it's mostly clear what went wrong and I'll post a new version in a bit.
    I excel at breaking stuff.  Cheesy

    And thank you VERY much for posting a binary as well.  Much appreciated - I hate trying to compile on a Windows box, and I'm a chicken with my head cut off in Linux.

  • SgtSpike
    Legendary
    *
    Offline

    Activity: 1400
    Merit: 1005



    View Profile
    July 06, 2011, 09:03:57 PM
     #52
    Is there a way to make the search caps-insensitive?

  • gentakin
    Member
    **
    Offline

    Activity: 98
    Merit: 10


    View Profile
    July 06, 2011, 09:57:23 PM
     #53
    Use regular expressions. Like this:

    [g|G][e|E|3][n|N][t|T|7]    and so on. This matches Gent, gent, g3N7, ..

    Adding * allows repeating the character.
    G[e|E]*n  matches GeeeeEEEeeeen, Gen and Gn. If you want to have at least 1 occurence of the character, use + instead of *.

    That's how I know regexps. Not sure if it is actually the pcre-style regexp syntax used in vanitygen.
    1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb

  • dserrano5
    Legendary
    *
    Offline

    Activity: 1974
    Merit: 1053



    View Profile
    July 07, 2011, 05:18:00 AM
     #54
    Quote from: drrussellshane on July 06, 2011, 06:43:56 PM
    Sorry for my noobness... how does one import keys?

    You need to use a modified bitcoin client (read the OP) and run:

    Code:
    bitcoind importprivkey 5KhUstDBWc...

    The string to use is the "Privkey" as returned from vanitygen.


    Quote from: gentakin on July 06, 2011, 09:57:23 PM
    Adding * allows repeating the character.
    G[e|E]*n  matches GeeeeEEEeeeen, Gen and Gn. If you want to have at least 1 occurence of the character, use + instead of *.

    That's how I know regexps. Not sure if it is actually the pcre-style regexp syntax used in vanitygen.

    What you describe, particularly the '+' bit, applies to both GNU extended and Perl compatible regexen.

  • SgtSpike
    Legendary
    *
    Offline

    Activity: 1400
    Merit: 1005



    View Profile
    July 07, 2011, 05:40:49 AM
    Last edit: July 07, 2011, 06:42:53 AM by SgtSpike
     #55
    Quote from: gentakin on July 06, 2011, 09:57:23 PM
    Use regular expressions. Like this:

    [g|G][e|E|3][n|N][t|T|7]    and so on. This matches Gent, gent, g3N7, ..

    Adding * allows repeating the character.
    G[e|E]*n  matches GeeeeEEEeeeen, Gen and Gn. If you want to have at least 1 occurence of the character, use + instead of *.

    That's how I know regexps. Not sure if it is actually the pcre-style regexp syntax used in vanitygen.
    Thank you much!

    EDIT:  Hmmm, didn't work.  "Invalid character '[' in prefix 1[p|P]etc..."

  • dserrano5
    Legendary
    *
    Offline

    Activity: 1974
    Merit: 1053



    View Profile
    July 07, 2011, 07:04:21 AM
     #56
    Quote from: SgtSpike on July 07, 2011, 05:40:49 AM
    EDIT:  Hmmm, didn't work.  "Invalid character '[' in prefix 1[p|P]etc..."

    You don't need the pipe: 1[Aa][Bb][Cc]. In some shells you may have to escape/quote the square brackets. Safest is to enclose the whole regex in single quotes (double quotes in windows' cmd).

  • SgtSpike
    Legendary
    *
    Offline

    Activity: 1400
    Merit: 1005



    View Profile
    July 07, 2011, 08:26:33 AM
     #57
    Quote from: an0therlr3 on July 07, 2011, 07:04:21 AM
    Quote from: SgtSpike on July 07, 2011, 05:40:49 AM
    EDIT:  Hmmm, didn't work.  "Invalid character '[' in prefix 1[p|P]etc..."

    You don't need the pipe: 1[Aa][Bb][Cc]. In some shells you may have to escape/quote the square brackets. Safest is to enclose the whole regex in single quotes (double quotes in windows' cmd).
    I have the targets stored in a text file.  I tried encapsulating each regex in single and double quotes, both errored out.  It seemed that the command window changed the double quotes to an o with two dots over it, and the single quotes to one of those AE letter combos.  Not sure what's up with that.

    Regardless, still getting the invalid character '[' error without pipes in the text file.  Any other suggestions?

  • Shevek
    Sr. Member
    ****
    Offline

    Activity: 252
    Merit: 250



    View Profile
    July 07, 2011, 09:23:55 AM
     #58
    Quote from: pB11 on July 06, 2011, 12:23:52 PM
    Btw using just time() was quite secure anyway. Assuming Vanitygen runs at least several minutes, the amount of keys to brute-force is >2^64:
     - 15 bit PID

    To be used once (for one key). If used twice or more times, the full chain of keys can be compromised.

    Quote from: pB11 on July 06, 2011, 12:23:52 PM
    - 21 bit timeframe (1 month)

    Again, to be used once. Consecutive keys will have a time variation about perhaps 8~10 bits.

    Quote from: pB11 on July 06, 2011, 12:23:52 PM
    - 7-8 bit CPU speed, + a few bits of time uncertainty each EC_KEY_generate_key()

    To be used for one key. The entropy between keys drastically falls.

    Quote from: pB11 on July 06, 2011, 12:23:52 PM
    - 2^20+ keys to generate  

    I don't understand your claim: each key needs 256 bits to be builded. And these 256 bits should have high entropy quality (ideally, 256 bits of entropy). So, picking up 256 bits really random is a hard task.

    Guys: velocity and good entropy cannot be pushed together. Use these vanity addresses only if you like strong emotions.
    Proposals for improving bitcoin are like asses: everybody has one
    1SheveKuPHpzpLqSvPSavik9wnC51voBa

  • Pieter Wuille
    Legendary
    *
    qt
    Offline

    Activity: 1072
    Merit: 1203


    View Profile WWW
    July 07, 2011, 09:28:57 AM
     #59
    That's not entirely true: as addresses are only 160 bits, it suffices to try 2^160 private keys to have a reasonable chance of finding one that matches a given address. Thus, a private key only needs 160 of randomness.

    Furthermore, if you limit eg. four base58 characters of the address to particular string (as this patch allows you to), you already lock log(58^4)/log(2)=23.4 bits of those 160 bits through other means.

    I say you need 136.6 bits of entropy per vanity key found (assuming the above restriction), not per attempt, as the attacker cannot observe your failed attempts.
    I do Bitcoin stuff.

  • Shevek
    Sr. Member
    ****
    Offline

    Activity: 252
    Merit: 250



    View Profile
    July 07, 2011, 09:39:35 AM
     #60
    Quote from: Pieter Wuille on July 07, 2011, 09:28:57 AM
    That's not entirely true: as addresses are only 160 bits, it suffices to try 2^160 private keys to have a reasonable chance of finding one that matches a given address. Thus, a private key only needs 160 of randomness.

    Th 160-bit reduction of addresses of public keys is a way to keep shorter chains with still good collision resistance. But inside this, there is a true 256-bit public key

    Thus, the task-force needed to blow up a private key (that is: the number of tries in EC-product in order to find one private key that matches the targeted public key) is ~2^256 because the EC-multiplier is just a 256 bit number (a 78-decimal-digit integer, if you want).

    If you resign 96 bits of good entroy, you are giving a chance to an attacker to resolve your priv. key after 2^160 tries. It is still huge but... why resign the full strength of the elliptic curve?
    Proposals for improving bitcoin are like asses: everybody has one
    1SheveKuPHpzpLqSvPSavik9wnC51voBa
    Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 191 »
      Print  
Page 2
Viewing Page: 3

IRLBTC™ © 2026 IRLBTC.com