Bitcoin Forum
December 04, 2016, 12:32:09 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 808293 times)
BurtW
Legendary
*
Offline Offline

Activity: 1778

All paid signature campaigns should be banned.


View Profile WWW
November 14, 2011, 03:51:36 PM
 #381

So, as soon as there's a disconnection, all users need to generate the new common public key. But then you need to detect someone disconnecting, somehow.

As soon as someone stops participating, the common public key is recalculated without theirs. To detect this each participant needs to send everyone else some sort of keep-alive signal signed with their private key every minute or so. This is an obvious solution.

ByteCoin
First, I like the "adding keys" solution better than my "muliplying keys" solution so I suggest we go that route.

It seems to me there is a workable solution here all we need to do is solve a few logistical issues!  Fun.  Going off line is kind of a nasty issue in that from the time one participant goes off line to the time this is detected and the common starting point is recalculated the efforts of the entire network of participants is wasted.  I think there are two separate "going off line" use cases.

1) a participant decides to shut down for whatever reason - in this case an "I am going to stop participating" message could be broadcast.
2) a participant goes offline without a message (power failure, etc.) - in this case we want a mechanism to detect this as soon as possible and get back on track

In a peer-to-peer implementation could't we have each node monitor just it's connected nodes and then broadcast a "node X went offline" to the entire network as soon as it detects one of it's peers has gone offline?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
1480854729
Hero Member
*
Offline Offline

Posts: 1480854729

View Profile Personal Message (Offline)

Ignore
1480854729
Reply with quote  #2

1480854729
Report to moderator
1480854729
Hero Member
*
Offline Offline

Posts: 1480854729

View Profile Personal Message (Offline)

Ignore
1480854729
Reply with quote  #2

1480854729
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480854729
Hero Member
*
Offline Offline

Posts: 1480854729

View Profile Personal Message (Offline)

Ignore
1480854729
Reply with quote  #2

1480854729
Report to moderator
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
November 14, 2011, 04:09:37 PM
 #382

So if I got this right:
If person A wants me to search for a vanity address for him, but I would also like to search for vanity addresses for n other people simultaneously, the result that I find, with which person A can generate his desired vanity address, is only usable to person A if he has a certain piece of information from all these n other people?
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 14, 2011, 04:10:48 PM
 #383

So if I got this right:
If person A wants me to search for a vanity address for him, but I would also like to search for vanity addresses for n other people simultaneously, the result that I find, with which person A can generate his desired vanity address, is only usable to person A if he has a certain piece of information from all these n other people?
Correct.

runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
November 14, 2011, 04:28:15 PM
 #384

^ I see. Could you describe the discrepancy below?

(The explanation assumes you know something about EC cryptography)
Person 1 makes a private key Priv1, and calculates the public key Pub1. Person 2 gets Pub1, creates a new private key Priv2, and adds (EC source point) * Priv2 to it, creating Pub2. Now, if Pub2 hashes to a nice vanity address Vnice, then Person 2 sends Priv2 to Person 1. Person 1 then adds Priv1 to Priv2, getting Privnice. [emphasis added]
To do this [verify that a VAGT is spendable], the rewarding transaction must be spendable by providing a number which, when used to multiply the generator, yields a point which when added to a specified public key point yields a new public key point which hashes to a value that gives the required vanity address.
As far as I can understand from BTCurious' explanation, verification that Priv2 is useful for Person 1 to generate his desired vanity address can be done, if both Priv2 and Pub2 is included in the spending transaction, by verifying that Pub2 is indeed the accompanying public key to Priv2, hashing Pub2 to see if the desired vanity pattern is present in the resulting address.
Your verification sounds a lot harder (and indeed difficult to implement in Bitcoin script). Is BTCurious' explanation just an over-simplification?

Thirdly, you'd have to that appropriate precautions to stop relayers from stripping your solution out of your transaction and claiming it for themselves.
Good point! I hadn't thought of this. I will have to give that some thought.
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 14, 2011, 04:57:51 PM
 #385

Well, my "Pub2" in the explanation you quoted, is actually the public key associated with (priv1 + priv2). I don't quite follow all the schemes that are being devised for verification though Tongue

BurtW
Legendary
*
Offline Offline

Activity: 1778

All paid signature campaigns should be banned.


View Profile WWW
November 14, 2011, 05:28:34 PM
 #386

I just wanted to describe my current understanding of the basic claim algorithm here to make sure I am on the same page:

At the time a desired public key is found the node that has just found the desired public key has two pieces to the puzzle: the very "last" piece and their own private key that corresponds to their published key.

Every other node has one additional piece of the puzzle and the requestor has the "first" piece of the puzzle.

Every node has the public keys from every other node and the private key corresponding to their published key.

So the problem is to collect all the pieces together to complete the puzzle.  It makes sense to me to have all the nodes send their pieces to the requesting node.

Let's assume a node finds the desired public key and it broadcasts a message "I found public key 1xxxx... and I am claiming the prize".  In this message it includes the following:

  • Its own private key, encrypted by the requestor's public key.
  • The private key that found the desired public key, encrypted to the requestor's public key.
  • Its new public key to be used for subsequent searching.
  • The payment address for the claim.

Every node can then encrypt their current private key with the requestors public key, create a new public key and broadcast a message containing the encrypted private key and the new public key out to the network.

Every node then accepts the new public keys from everyone else, calculates the new starting point, and begins searching for the remaining patterns.

Meanwhile the requestor can assemble all the keys together, verify the claim and then pay the finder.

Is that close to what we are talking about?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
November 14, 2011, 05:36:19 PM
 #387

Is it me, or this program has been stuck at version 0.17 forever?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 14, 2011, 05:48:17 PM
 #388

In this message it includes the following:

  • Its own private key, encrypted by the requestor's public key.
  • The private key that found the desired public key, encrypted to the requestor's public key.
  • ...

I don't believe that there's any additional security to be gained by encrypting the private keys. So long as one party does not release their private key then the resulting vanity address is equally secure. If the revealed private keys are published in plaintext then all parties can verify that the private keys match the public keys. It's probably more important that the revealed private keys are signed with the public key to stop a MITM DOS attack.

The hard part will be ensuring that payment is sent for vanity keys and preventing DOS attacks.

bwagner: From what you write, it appears that you understand the scheme correctly.

ByteCoin
BurtW
Legendary
*
Offline Offline

Activity: 1778

All paid signature campaigns should be banned.


View Profile WWW
November 14, 2011, 09:02:38 PM
 #389

Since nodes will come and go, workload lists will vary from node to node, and workload subnets will develop I think we need to add the following to the claim message:

Let's assume a node finds the desired public key and it broadcasts a message "I found public key 1xxxx... and I am claiming the prize".  In this message it includes the following:

  • Its own private key (maybe encrypted by the requestor's public key - see below).
  • The private key that found the desired public key (maybe/maybe not encrypted to the requestor's public key).
  • Its new public key to be used for subsequent searching.
  • The payment address for the claim.
  • The list of all public keys used to make the desired vanity key.
  • The entire message signed by the sending node

I forgot to include the signature in my last post.  So if we sign using the OLD private key then we must encypt the private key in the message because it is the key used to sign the message.  If we sign with the NEW private key then I guess the private key in the message can be clear text.  Still thinking on that one.

Then only the nodes on the list need respond with the private key/new public key messages.  And the same thing goes for these messages the private key can be clear if it is not the key used to sign the messages.


Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
November 15, 2011, 12:23:48 AM
 #390

This sounds really cool. It would be neat to have a site that sells vanity addresses based on their difficulty that you would not need to trust.

BurtW
Legendary
*
Offline Offline

Activity: 1778

All paid signature campaigns should be banned.


View Profile WWW
November 19, 2011, 12:56:32 AM
 #391

Just wondering where everyone went.  We were having a great discussion and then everyone just dropped it Sad Is anyone working on this?  Did the discussion move to PM?  I think this is a very cool idea and would like to be involved if anyone else would like to work on it.

It is a pretty broad project so maybe everyone thinks it is too much effort?

Perhaps a white paper is the best place to start.  I could consolidate all the discussions so far into a wiki page if everyone thinks that is the next step.

Have we reached general agreement on the main issues?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 19, 2011, 10:57:58 AM
 #392

It's still interesting, but I don't have a lot of time to work on it at the moment.
I'd still keep a close eye on any development though.

2weiX
Legendary
*
Offline Offline

Activity: 1638


View Profile
November 21, 2011, 03:22:46 PM
 #393

if someone could make a noobs guide to adding those to ones' bitcoin client...?
BurtW
Legendary
*
Offline Offline

Activity: 1778

All paid signature campaigns should be banned.


View Profile WWW
November 21, 2011, 04:17:20 PM
 #394

Are you asking how to import your vanity address into your client?

Personally, I store all the vanity addresses/accounts I find in my https://strongcoin.com account since it is much easier to import private keys into StrongCoin than into the standard client.  You can also very easily import mini private keys (from physical Bitcoins) into StrongCoin.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
2weiX
Legendary
*
Offline Offline

Activity: 1638


View Profile
November 21, 2011, 05:05:11 PM
 #395

Are you asking how to import your vanity address into your client?

Personally, I store all the vanity addresses/accounts I find in my https://strongcoin.com account since it is much easier to import private keys into StrongCoin than into the standard client.  You can also very easily import mini private keys (from physical Bitcoins) into StrongCoin.

that is swell, thank you!

i am not at all familiar with the different options.
the next question will unveil my utter ignorance of how the bitcoin protocol works.

vgen gives me:
an address
a key

i do import the KEY (base58) and am then able to pass the "address" part around for ppl to pay me?
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
November 21, 2011, 05:08:50 PM
 #396

Yes. You can import the key to strongcoin or if you install a tool like pywallet, you can import the key into the regular bitcoin client.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
c_k
Donator
Sr. Member
*
Offline Offline

Activity: 242



View Profile
November 27, 2011, 08:26:48 AM
 #397

Code:
>oclvanitygen.exe -d 1 -N Mtest
Prefix 'Mtest' not possible
Hint: valid namecoin addresses begin with "M" or "N"

>oclvanitygen.exe -d 1 -N Ntest
Prefix 'Ntest' not possible
Hint: valid namecoin addresses begin with "M" or "N"

Is there something wrong with v0.17 Windows x86+x64 binaries when generating namecoin addresses?

Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 09, 2011, 08:11:09 PM
 #398

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

Rassah
Legendary
*
Offline Offline

Activity: 1624


Director of Bitcoin100


View Profile
December 09, 2011, 08:59:23 PM
 #399

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

It doesn't, but you can create a new unencrypted one, import your address, and move all your money out of the encrypted one, before encrypting the new one. Don't know if there is a way to extract keys out of encrypted wallets though :/

paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
December 09, 2011, 09:25:43 PM
 #400

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

It doesn't, but you can create a new unencrypted one, import your address, and move all your money out of the encrypted one, before encrypting the new one. Don't know if there is a way to extract keys out of encrypted wallets though :/

or you could use the comandline options and unlock your wallet for 10-15 minutes, enough time to import few private keys with pywallet Wink

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
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 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 ... 155 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!