Topic: [PULL] private key and wallet export/import (Read 39596 times)

dumpprivkey and importprivkey long been upstream, and in released software.

dumpwallet and importwallet are not yet merged.

Hi!
Does this patch also exist for the current 0.7.1 version?

I'd sure love to see this happen...

On the other hand, we'd like to encourage to have a multitude of implementations making up the network in order for it to be more robust. Some vulnerability in satoshi node might not affect the other implementations und such protect the blockchain somewhat or make an attack on it much less effective.

That should be enough for my experiments.


I did not mean to imply that your modular blockchain wasn't an improvement over Satoshi's client. I was just curious whether you and Genjix collaborated or shared any code. I believe you are both doing some similar things. Each implementation might test the other, or if either approach for a particular component is superior, why not steal like artists?

Genjix' libbitcoin license is also Affero GPL, while FellowTraveler is suggesting a new hybrid Lesser-AGPL, which might be more appropriate.

There's a lot of stuff it could do, but not implemented yet.  However, accessing it via Python CLI gets you just about anything you want in the blockchain.  It could easily be ported to support piping from regular CLI, but loading the blockchain every call would be slow.  However, my current focus is on full-fledged client with all its innovative features.  But I don't want to get too derailed on that... (PM me if you want more info about how you might use it). 

The point was that for importing new addresses, it helps to be able to do a full blockchain scan for its balance in reasonable time without contacting a separate service.  If one is going to implement an "import private key" function, you should be able to tell the user, in a reasonable amount of time, what is that balance of that key.  In this case, a separate client that uses none of my code, could still make a dll/system call to my library, which will load the entire blockchain from disk and scan for a full list of TxOuts, within 20s. 

On that note, I would argue I didn't exactly reinvent the wheel.... the Satoshi client is a wheel that spins at 1000 RPM permanently attached to a satoshi axle.  My code is a wheel that spins at 10,000 RPM and can be used with any axle.  I'm not sure it's possible to do (single-threaded) blockchain scanning any faster (after all, I am an expert on C++ data structures).

Sounds excellent. Looking forward to playing with it. I'm curious, does Armory support plaintext i/o for command line pipes? Have you and Genjix (libbitcoin) shared C++ code or are you both reinventing wheels?

I'll try to remember to PM you what you need.

I'm one of those developers!  I'll be releasing a client in the near future, and I can pretty easily support Firstbits.  And with the full-RAM version of the client (that holds the entire blockchain in RAM), I can resolve a firstbits address in 0.5 seconds without contacting any server... pretty slick

I went to the firstbits site but didn't see the technical information I needed to be able to implement it.  Any links?

Btw, my client will have a completely decoupled blockchain interface and wallet.  In fact, you don't even need to wait for Armory to be released, because you can already use the full-set of blockchain tools that I have, written in C++.  https://github.com/etotheipi/BitcoinArmory/tree/master/cppForSwig  It's a ton of code, but it can all be boiled down to a small interface of a couple-dozen calls.   It can do a full blockchain scan from cold boot in about 20s (collect all tx for any address directly from disk).  PM me if you have any interest in leveraging it.

Ah, right.  Yes, what FreeMoney said is correct about the current implementation, and we have not changed it.  It still would result in 1asd2 and 1asd2s.  We talked about changing it to make both addresses longer in such a case, but discarded the idea in favor of maintaining consistency.  We didn't want it to retroactively change any firstbits that could have already been handed out, as that would be dangerous.

Genjix's libbitcoin will contain firstbits. He went on a tangent removing the '1' prefix, which has subtle but incompatible implications. I believe he's returned to your implementation. FreeMoney and Puik had a short conversation about order within blocks. It should be possible to find real-world test cases.

I never thought about using the "server" portion of Electrum running locally to support the custom wallet.  Hmm.

I like Electrum's approach still there is no real difference between a remote server and a local daemon.  The issue is still duplication of work.  If some fix needs to be made to the daemon then electrum needs to make the same change also. 

I completely agree that the wallet and the nodes need to be separated.  This is pretty much what Electrum is doing.

https://bitcointalksearch.org/topic/announce-electrum-lightweight-bitcoin-client-50936

+1

I have always thought this also.  It seems to me the daemon is too tightly coupled with the Satoshi wallet and that requires either significant code surgery, sticking with limits of the existing wallet, or a lot of wheel inventing.

What if the daemon would removed into a new project.  Wallets could communicate the w/ daemon via encrypted JSON or socket messages. (i.e. check balance of this address, submit this transaction, what is current block count).

It would also abstract the differences between light clients, and full clients.  A light client is communicating w/ a daemon running on another computer (public, private, whatever).  A full client is communicating w/ a copy of the daemon running locally.

As an example on how this tight coupling generates a significant barrier for new projects:

I did some proof of concept work on a smartcard to use it as a secure private keys storage device. Due to the limits of smartcard resources the card would only contain the private key generation code and signing aspects.  This would require a custom wallet format which contains only the address and an identifier to reconstruct the private key in the smartcard.  I got the card portion working (albeit slowly in my proof of concept) and talking w/ a non-compliant  public wallet handler.  However the amount of work needed to couple this w/ the Satoshi client, make it compliant w/ protocol was a significant barrier.

They've always been ordered in the same order as they appear within a block's raw data.  So if one address appears before the other address within the same block's raw data (and they're both brand new addresses with the same firstbits), then that first address will get the shorter firstbits, and the second address will have to add at least one character to get its unique firstbits.

What are puik and genjix working on related to firstbits?  If they are using a different type of assumption for collisions within a block, their results won't match up with those at firstbits.com.

That notion of 'mine' can and should be part of the wallet (or in that tier) not twisted up in the public global data model.



Is there a thread discussing modularization of the Satoshi client? I think a lot of people have simply focused their attention away to alternatives: libbitcoin, node.js bitcoinjs, and various web clients.



I'd like to see a discussion started though. I think awareness of firstbits needs to increase. I introduced a few developers who seemed surprised but immediately interested. As for collisions in the block, I thought they were first ordered within the block and then later assumed to be simultaneous within the block. There was a slight word-change to the algorithm, at least enough that someone had to make a change (maybe puik or genjix?).

I agree regarding Firstbits.  I think it'd be great to see it in a 3rd-party client, but I don't think it should be placed in the standard client yet.  Although, just FYI, the algorithm has stayed exactly the same since Firstbits was released.  It's just, no one except myself knew how it worked with collisions in the same block when that question arose.

This.  The daemon should have nothing to do with wallets.  It should relay transactions, download new blocks, and maintain a local copy of the block chain along with needed indexes.

Independence of concerns would go a long way to accelerate development and experimentation. Personally, I'd like to host the bitcoind south of the polar circle, pay someone for the service, or more trivially have a single standard bitcoind on a shared host (/var). A lot of the web clients and mobile apps seem to be recreating a wheel that shouldn't have needed to be recreated. If the blockchain and index is too big, slow, or bandwidth too expensive, then we should outsource the responsibility.

I agree with several of the points you have made here:

I do think the wallet encryption is a waste of effort.  But a side benefit is that the design of bitcoind has been pushed toward supporting addresses it thinks are "mine" without needing to know the actual private key.  That has some good use cases.

I do think the local blockchain and wallet should be completely independent.  However, this index, if added, would put bitcoind within reach of offering features where someone can implement their own wallet on top of bitcoind.  The built-in wallet, in such a case, could be completely ignored.  If this index gets built, bitcoind could easily support a "give me all unspent tx's for these addresses" RPC command, which would make a third-party wallet app on top of bitcoind much more feasible.  Another RPC command to dump a transaction to the P2P network, and a way to get notifications/callbacks of incoming transactions/blocks would seal the deal.

tl;dr: many of the built-in features are far from the best implementation, but given this index and a few other trivial RPC commands, those built-in features can be ignored, replaced, and left for deprecation.