Bitcoin Forum
August 15, 2022, 06:46:43 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / Re: BIP0032 Hierarchical Deterministic Wallet key generator bip32utils (Python) on: August 20, 2014, 09:36:33 PM
Can you describe like I'm 5 how can I get the first address of the first account with this tool according to BIP-0044 given I know the xpub?
It should be m/44'/0'/0'/0/0

If you have the extended public key corresponding to m/44h/0h/0h/0 (note the syntax in BIP32 has changed) in a file, say test.xpub, you can simply:

Code:
$ bip32gen -i xpub -f test.xpub -o addr 0
1NaKvDgeVnXqvTpFzzngmH1RG9cN3BkVfh

This translates as "starting with an extended public key stored in file 'test.xpub', generate the address associated with child number 0, and write it to stdout". (Address shown is from an xpub from an arbitrary wallet seed).
2  Bitcoin / Development & Technical Discussion / Re: Proposal: Base58 encoded HD Wallet root key with optional encryption on: June 16, 2014, 03:53:27 PM
So, is this proposal stable enough now to turn into a formal BIP?  Is this in progress already? I would like to add a second implementation of this, as part of my bip32utils package.

Finally, would it be too much of a stretch to be able to use this encoding as way to export an extended private key from inside the hierarchy, instead of at the root?  It would fit in the "64 byte root key" encoding.
3  Bitcoin / Development & Technical Discussion / Re: BIP0032 Hierarchical Deterministic Wallet key generator bip32utils (Python) on: February 05, 2014, 09:48:45 PM
Ah, that makes sense.  I didn't consider that any of this work was rushed because, frankly, if I were to rush a bit of code, it simply wouldn't run.
No worries.  I wanted get something up for people to review, and perfect is the enemy of good enough.
4  Bitcoin / Development & Technical Discussion / Re: BIP0032 Hierarchical Deterministic Wallet key generator bip32utils (Python) on: February 05, 2014, 06:59:41 PM
I generated BIP0032 test vector #1 using the command in your readme and got the desired result.

I then created my own master key with bip32gen and used your Base58 module to decompose the output and compare it with the serialisation format as specified by BIP0032.  I managed to recover the private key just fine.
Good.  Thanks for testing.

I did have a quick look at the code but I didn't get so far with it.  I got a little confused as your style changed.  For example, compare the extended key version handling in fromExtendedKey
Code:
       # Verify address version/type
        version = raw[:4]
        if version.encode('hex') == '0488ade4':
            keytype = 'xprv'
        elif version.encode('hex') == '0488b21e':
            keytype = 'xpub'
        else:
            raise ValueError("unknown extended key version")
to that in ExtendedKey
Code:
       version = '\x04\x88\xB2\x1E' if private is False else '\x04\x88\xAD\xE4'

On this topic:  Would 0x0488ade4 and 0x0488b21e be better as module constants?  How easy would it be to add support for testnet keys?
Yes, it would be cleaner to make those module constants; I was in a bit of a rush to get this part implemented.  That's good feedback for cleanup.

That's all I have time for today.  Hopefully I'll find time to move some funds around tomorrow.
Please take into account the experimental nature of the software.
5  Bitcoin / Development & Technical Discussion / Re: BIP0032 Hierarchical Deterministic Wallet key generator bip32utils (Python) on: February 05, 2014, 05:00:30 PM
I'll play with this tomorrow and post some feedback here.
Thanks, looking forward to it.
6  Bitcoin / Development & Technical Discussion / Re: Proposal: Base58 encoded HD Wallet root key with optional encryption on: February 04, 2014, 08:18:10 PM
This proposal is next up for development in my bip32utils library.  Do you have any indication yet what a BIP number might be for it, and do you have a proposed short name for it?  Otherwise, I'll call it the "riplin export format" Smiley
7  Bitcoin / Development & Technical Discussion / BIP0032 Hierarchical Deterministic Wallet key generator bip32utils (Python) on: February 04, 2014, 07:52:59 PM
I've published an experimental version of my bip32utils library and generator script:

https://github.com/jmcorgan/bip32utils

This is pure Python implementation of the BIP0032 draft standard, as recently amended by Peter Wiulle in a pull request on the BIP github account, and is dependent only on the Python ecdsa library available in pypi.

BIP0032 describes a mechanism for generating a hierarchical tree of ECDSA private and public key pairs in a deterministic way using an initial seed.  In addition, one can export an extended private key for a particular tree node that allows generating public and and private child keys underneath, or export an extended public key that only allows generating public keys for child nodes below it in the hierarchy.

There are number of use cases this enables, including single seed backup for an entire hierarchy, allowing auditors to have access to transactions but without the ability to spend them, the ability for a website to generate receive addresses without a compromise allowing spending from those addresses, and delegation of spending authority to keys lower in the hierarchy.

The bip32utils library provides a Python class encapsulating a node in this hierarchy, and a command-line Swiss army knife style script bip32gen that uses this class to create keys in a hierarchy from either entropy or an extended key import format.

The tests directory contains scripts that verify conformance to the BIP0032 test vectors as published.

This is an initial effort that hasn't received a great deal of testing and feedback, so I would recommend against relying on this for anything but token amounts of BTC until it is more mature.

Feedback is welcome.
8  Economy / Service Announcements / Re: BitcoinWisdom.com - Live Bitcoin/LiteCoin Charts on: December 13, 2013, 03:28:12 AM
Feature request:

bitcoinaverage.com has done a good job of aggregating exchange data and calculating weighted sums for individual currencies.  They export a simple JSON API to retrieve the values, which update once per minute.

I'd find it very useful to be able to look at, say, the USD global average price (bid/ask/last) with the same charting display you use with raw exchange data.

Thanks for your consideration.
9  Bitcoin / Development & Technical Discussion / Re: Cold storage using encrypted, bootable DVDs with SPV wallet and seed on: November 03, 2013, 09:21:50 PM
I'm working on this cold storage concept by developing a plaintext image that has everything needed (Tor, Electrum, what else?), except the user's wallet data.  The ISO image would be able to then be customized by the end user by adding his wallet data to the image, and remastering it, but with encryption turned on.

Of course, said master image would need to withstand scrutiny that it doesn't contain malware, won't steal your bitcoins when you boot it, etc.  I'm developing it for my own personal use; everyone else will either need to do that themselves, or have some level of trust.

The remastering scripts themselves are simple and easy to check, so as long as you start with an original ISO that you trust, you can trust the output.
10  Bitcoin / Development & Technical Discussion / Cold storage using encrypted, bootable DVDs with SPV wallet and seed on: November 03, 2013, 09:01:30 PM
I have developed a set of scripts that allow one to take an existing Ubuntu Live DVD ISO image file, customize it, and remaster a new image with all of the contents encrypted with LUKS:

https://github.com/jmcorgan/cryptubuntu

When booting from the DVD, a passphrase is requested to mount the encrypted root filesystem with on-the-fly decryption.

There are many uses for this; consider creating data backups along with the OS and all the software necessary to interact with it.  I use it in my professional work to deliver archived milestones of development projects (with the build environment intact).  The encryption allows the DVD to contain business proprietary and confidential information on it without worrying about 3rd party access.

In the context of Bitcoin, this also allows a new sort of cold storage: By putting a SPV client with a deterministic wallet on it, you can make cheap copies that can live in different places, any of which could provide you access to your bitcoin in an emergency.  Just boot the DVD, provide the decryption passphrase, and let the SPV client download the need blockchain data, which goes into a RAM overlay.  At present this is only ~250MB or so.  With the deterministic seed, access to any of the generated addresses in the future is assured.

The DVD contents, unlike USB drives, are read only.  One may argue the longevity of recordable-DVD storage media vs. USB flash drives, but since they are so cheap to make, you can make many copies.

Since the remastering scripts can take their own output ISO images as the starting point for futher customization and encryption, I'm working on this cold storage concept by developing a plaintext image that has everything needed (Tor, Electrum, what else?), except the user's wallet data.  The ISO image would be able to then be customized by the end user by adding his wallet data to the image, and remastering it, but with encryption turned on.

Of course, this doesn't making choosing a decryption passphrase any simpler; you are essentially daring anyone who has access to the DVD to crack your password to grab your bitcoin.  So all the usual passphrase selection rules apply.  Humans don't supply much entropy.

(Disclaimer: I am not bash script proficient and I'm sure there are many ways to improve things, particularly with corner cases and error checking.  It works for me right now.)
11  Bitcoin / Bitcoin Discussion / Re: NFC Ring call to arms for implementation suggestions on: September 27, 2013, 07:36:42 PM
So, when are you going to update the bitcoinstarter page?  Since you didn't make the goal there, the pledged BTC should be returned.  However, you have it "pending extension", whatever that means, and the pledged BTC is tied up.
12  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: August 22, 2013, 02:54:22 AM
(As an aside: ZC could potentially be used externally to Bitcoin in a decentralized CoinJoin as a method of mutually blinding the users in a DOS attack resistant way. This would allow ZC to mature under live fire without taking its costs or committing to a specific protocol network-wide.)

This is an extremely interesting idea.  Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?
13  Economy / Service Announcements / Re: [ANN] LocalBitcoins.com - a location-based bitcoin to cash marketplace on: August 12, 2013, 04:43:43 AM
You also might find this helpful: http://bitcoinaverage.com/             
Thanks, this is useful.
14  Economy / Service Announcements / Re: [ANN] LocalBitcoins.com - a location-based bitcoin to cash marketplace on: August 11, 2013, 05:03:15 PM
Feature request: calculate a weighted average of and/or history of trading prices for each fiat currency.

I know that most people price their trades based on some formula using bid/ask/last prices from the major exchanges.  However, given the divergence in prices between Mt. Gox and other exchanges, it would be very useful to have a bid/ask/last/depth based on what local bitcoin traders have actually decided to set their prices to.

As the volume of local exchanges increases, this consensus could displace using unreliable centralized exchanges as a pricing mechanism, and instead show the market price when taking into account things like the risk premium of in-person trades and the delay times involved.

Another interesting set of data would be to plot the market price in different geographical areas vs. the average for that currency.

I'd contribute some BTC to a bounty for implementing this.
15  Bitcoin / Development & Technical Discussion / Re: bitcoin protocol magic numbers and reason on: July 31, 2013, 02:44:42 AM
One day people will infer all sorts of things from these numbers.
This highlights an issue with "code as documentation".  It fails to distinguish between implementation decisions that were arbitrary and those implementation choices that are crucial for correctness.

Someone writing a new bitcoin implementation could focus their energy on what is important to get right vs. something that "just happened" to be done that way and could have been done otherwise to no ill effect.

I'm aware of the argument that reimplementations must match the Satoshi client bug for bug in order to prevent a divergence of consensus, and that such divergence can carry a high economic price.  However, unless the reasons for any given behavior are written down, as the original developers move on, this tribal knowledge gets lost.  It is replaced by the guesswork of future developers.

The consensus of the development team seems to be that even if a well-written protocol specification were completed, they would not feel bound to consider it authoritative.

So be it.  But as bitcoin implementations need to go beyond traditional "software on PC" (think POS terminals, embedded systems, smartcards, dedicated silicon nodes, etc.), without a specification to test against, it is very difficult to assure quality and correctness.
16  Bitcoin / Bitcoin Discussion / Re: Forbes : the Biggest threat to Bitcoin is Gavin on: April 07, 2013, 07:05:24 PM
We're getting there, but it will take time. I really hope in a year or two there will be at least three or four different bitcoin implementations all producing blocks, validating transactions, etc. And in ten years there will be a dozen or more.

Gavin--First, thanks for your and the other devs' work.  The rest of the world and I get the product of your labor for free.  That's pretty cool.

Second--if you really want to have multiple, interoperable implementations, I think you have to get past the "source code is the protocol documentation" idea.

I understand the argument that additional implementations must mirror bitcoind behavior exactly, including bugs, or else risk block chain splits that could have a large financial impact.  However, source-code-as-documentation does not work well as a guide to other implementers.  It fails to distinguish between behavior that is essential and behavior that is contingent and arbitrary (just happened to be that way, could be otherwise.)

Developers writing additional implementations are unable to objectively verify that what they have done is proper, without some standard from which they can create unit and overall feature tests.

Yes, I'm familiar with what exists now on the wiki and elsewhere.  It is useful as a learning tool, and others have written bitcoin-related functionality based on it.  But documentation written by "reverse engineering" the thinking of developers based on source code suffers from the same problems.

Of course, it is possible to get into documentation paralysis, where so much time is spent nailing down details that actual development stalls.  However, this can be solved in an incremental and iterative way rather than an all-at-once, serial fashion.  I think merely having the sanction of the bitcoind dev team and a vision that someday the bitcoind code will follow the spec, not the other way around, would motivate a lot of people to participate.

This isn't a complaint, per se--you guys are doing the work and giving it away, and you are of course free to do whatever you wish.  Consider this a polite request to reconsider your team's attitude toward formalizing the protocol using something beside the source code itself.

Regards,

A very happy bitcoind user and fellow full-time open source developer.
17  Bitcoin / Bitcoin Discussion / Re: Payment QR codes: a Potential for Abuse? on: March 01, 2013, 04:15:45 AM
I have noticed that some QR codes presented by merchants for payment encode not only the destination address, but the amount of the transaction. This is, I am sure, meant to be a convenience for the buyer. However, it would be quite easy for an unscrupulous operator to encode some much higher amount than the legitimate price into the QR code, thus scamming an unwary customer. In a system wherein charges are difficult to reverse, and wherein many wallet programs lack a confirmation dialogue box, it would behoove all to be wary..

Can you show an example of this?
18  Bitcoin / Bitcoin Discussion / Re: Unclaimed bitcoins......... on: February 28, 2013, 05:23:20 AM
...but I think it is worth thinking about because this could turn out to be a lot of money later on down the road.
It could turn out to be a lot of money of course, but it's a lot of money that is not yours, so what is it worth to you to think about money that is not yours?
Shouldn't you think more about your own money, instead of someone elses money?
I think we have a junior politician in the making.
19  Bitcoin / Bitcoin Discussion / Re: If bitcoin succeeds... what will be the greatest contributing factor? on: February 04, 2013, 02:45:26 PM
I think the greatest contributing factor will be the ability to pay for...a beer in BTC.
+1 for being able to buy a beer with bitcoin  Grin
20  Bitcoin / Bitcoin Discussion / Re: Will you continue using Bitcoin if a evil governement/organisation join in on: January 30, 2013, 06:50:51 PM
Let say that a country like Iran or Nk start using BTC to finance some of their activities...
How do you know they aren't already?
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!