Bitcoin Forum
May 05, 2024, 02:45:13 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Lisp Implementation of BIP0032 (HD Wallets)  (Read 1173 times)
Krona Rev (OP)
Full Member
***
Offline Offline

Activity: 129
Merit: 100



View Profile
September 21, 2013, 07:28:31 PM
Last edit: November 27, 2014, 10:52:13 AM by Krona Rev
 #1

Update (Oct/Nov 2014): My github account was deleted for some reason, so the code below is no longer available there.
I found an alternative host for the code.
This is a good reminder that github.com is a third party site and there is no reason to believe they will not delete your repo.
----------------------------------------------------------------------
I've written a basic implementation of BIP0032 (HD Wallets) in Steel Bank Common Lisp (SBCL) and published it on github for anyone interested:

https://github.com/kronarev/bip0032sbcl
https://mathgate.info/bip0032sbcl/bip0032sbcl.tgz

There's no real user interface, but the basic functions are there (e.g., for private and public child key derivations). A file unittests.lisp demonstrates how to call the function using the test vectors given with BIP0032.

https://en.bitcoin.it/wiki/BIP_0032_TestVectors

It is only intended to work under Unix-based operating systems as the hash functions are performed by openssl, sha256sum and sha512sum.

I wrote this mostly to help me understand some of the technical details underlying bitcoin. I did it in Lisp because I like Lisp and because Lisp uses arbitrary-precision arithmetic.

It might be useful for people who want to generate more unit tests for HD Wallets.

In addition to computing addresses and WIF private keys for BTC, there is also code for computing addresses and WIF private keys for LTC and FTC.

I welcome feedback, even if (especially if?) it's to point out a mistake I've made in the implementation.

Promechard: Proprietary Metablock Chains for Arbitrary Data: https://bitcointalk.org/index.php?topic=411974.0
1714877113
Hero Member
*
Offline Offline

Posts: 1714877113

View Profile Personal Message (Offline)

Ignore
1714877113
Reply with quote  #2

1714877113
Report to moderator
1714877113
Hero Member
*
Offline Offline

Posts: 1714877113

View Profile Personal Message (Offline)

Ignore
1714877113
Reply with quote  #2

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

Posts: 1714877113

View Profile Personal Message (Offline)

Ignore
1714877113
Reply with quote  #2

1714877113
Report to moderator
1714877113
Hero Member
*
Offline Offline

Posts: 1714877113

View Profile Personal Message (Offline)

Ignore
1714877113
Reply with quote  #2

1714877113
Report to moderator
1714877113
Hero Member
*
Offline Offline

Posts: 1714877113

View Profile Personal Message (Offline)

Ignore
1714877113
Reply with quote  #2

1714877113
Report to moderator
Krona Rev (OP)
Full Member
***
Offline Offline

Activity: 129
Merit: 100



View Profile
November 15, 2013, 10:28:14 AM
 #2

I don't think anyone is using my lisp code, but I wanted to post an update just in case. After the post above, I added an interface file (bip0032sbcl.lisp) and a file (make.lisp) that could be used to generate a command line executable (bip0032sbclexec). Someone could then use this executable to do BIP0032 operations without using lisp at all. There are examples in the README.md at the github link above.

I discovered a bug in the interface code that I fixed today. If anyone is using it, I strongly recommend that they get the fixed version.

Here is a bit more detail for those interested. In BIP0032, one can use extended private keys to derive two kinds of children. One uses "private derivation" and the other uses "public derivation". "private derivation" is used if the 31'st bit is set to 1. The bug was that I set the 32'nd bit to 1 instead of the 31'st. As a consequence, "public derivation" was always being used. As an example, the buggy version did this:

Ask for extended private key of private child 1 of a certain extended private key (all in hex):
Code:
./bip0032sbclexec ckdpriv Ao6S99sRJ5H2HHiQD5yAwk1rLFCjpbV4mNAvLr2LpkyY 7PXDSih7ZzE1bbomW6CwGpSwAnSgkeKwZXe4x9D6XRnj 1

BbGJWhs4RTX4JoGYcnWZDeGVJ1YRUcFnTZUKz4Aoc8dB
7MCsRVh3myvssjZAc4zkS9nyGx1Sm7a99FpQUyi6W4MN

Ask for extended private key of public child 1 of the extended private key:
Code:
./bip0032sbclexec ckd Ao6S99sRJ5H2HHiQD5yAwk1rLFCjpbV4mNAvLr2LpkyY 7PXDSih7ZzE1bbomW6CwGpSwAnSgkeKwZXe4x9D6XRnj 1

BbGJWhs4RTX4JoGYcnWZDeGVJ1YRUcFnTZUKz4Aoc8dB
7MCsRVh3myvssjZAc4zkS9nyGx1Sm7a99FpQUyi6W4MN

The results are the same, while they should be different.

Retrying the operations with the corrected version, we get:

Code:
./bip0032sbclexec ckdpriv Ao6S99sRJ5H2HHiQD5yAwk1rLFCjpbV4mNAvLr2LpkyY 7PXDSih7ZzE1bbomW6CwGpSwAnSgkeKwZXe4x9D6XRnj 1

81JYCmcp9JmKYabjEBpcm3SBoLVfFXEkRRneF4jXgjp3
9EmGBeqvxz6cRN2TRFTPo7ipR4Mx4qthBrMXSbszRtyU

./bip0032sbclexec ckd Ao6S99sRJ5H2HHiQD5yAwk1rLFCjpbV4mNAvLr2LpkyY 7PXDSih7ZzE1bbomW6CwGpSwAnSgkeKwZXe4x9D6XRnj 1

BbGJWhs4RTX4JoGYcnWZDeGVJ1YRUcFnTZUKz4Aoc8dB
7MCsRVh3myvssjZAc4zkS9nyGx1Sm7a99FpQUyi6W4MN

Now they're different.

Promechard: Proprietary Metablock Chains for Arbitrary Data: https://bitcointalk.org/index.php?topic=411974.0
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!