Bitcoin Forum
December 09, 2016, 12:14:27 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 »  All
  Print  
Author Topic: [PULL] private key and wallet export/import  (Read 35865 times)
blueadept
Full Member
***
Offline Offline

Activity: 225


View Profile
December 20, 2011, 06:35:56 PM
 #161

But how does the local blockchain work if the addresses are not already indexed? I understand the client/wallet only keeps record of its own addresses and linked transactions, but... really? I should think that firstbits (or first ~48 bits) would make an excellent Primary key (with a highly unlikely collision list). How much extra data would such an address index require? Wouldn't that greatly simplifying and modularize the design?

The local blockchain indexes transaction hashes.  Transaction inputs reference those transaction hashes and then the matching outputs are checked.

Eventually, if the idea of splitting the wallet part from the peer-to-peer portion that communicates with other nodes and keeps track of the blockchain becomes reality, addresses will need to be indexed for fast searching anyway.  Implementing that now would speed up key import, though.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 20, 2011, 10:59:58 PM
 #162

160 000 blocks with 100 addresses of 33 byte each is half a gigabyte. Surely 'not indexing' would have been an optimization unnecessary for beta software?

... or was it believed that a malicious node could flood everyone's hard drive with minimal cost? ...or?

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
December 20, 2011, 11:13:01 PM
 #163

160 000 blocks with 100 addresses of 33 byte each is half a gigabyte. Surely 'not indexing' would have been an optimization unnecessary for beta software?

... or was it believed that a malicious node could flood everyone's hard drive with minimal cost? ...or?

I dunno, but I have heard developer resistance to this index, I have been promoting it for a while.  In the past, developers seemed to have the sentiment that it served no purpose other than private key imports, which at the time, they considered an obscure thing only advanced users would do (part of what motivated me to pump out physical bitcoins).

So, as you can imagine, I'm pleased to see a bandwagon chanting that we need the index.  It really isn't that complex, it just needs to be done.

Such an index need not contain all 33 bytes of a key - if it indexed only 4 bytes, it would use a fraction of the space, at the expense that collisions would require extra blocks to be needlessly checked on occasion, so for example we might read 8 blocks when we only really needed to read 2.  A negligible penalty, this would be more than acceptable, because it would still eliminate having to check well over 99% of the block chain that does not contain addresses with that prefix whenever someone imports or sweeps a private key or rescans their wallet.

In fact, I have believed that there should be a facility to reindex the block chain.  Building this second index could be part of that.  Right now, there is:

- blk0001.dat - the block chain itself (not a database file, but just a blob of binary data)
- blkindex.dat - the index we have now (keyed on transaction ID's) - which COULD be rebuilt entirely from blk0001.dat with a -reindex switch, except that there presently exists no implementation to do this.

Adding this index would just create a new .dat file that would point to blk0001.dat, which could be generated from scratch with a hypothetical -reindex switch.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 21, 2011, 12:32:09 AM
 #164

Should talk about a new pull request for a firstbits index be in a new thread?  It seems like there is enough support for it here.

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 21, 2011, 02:31:24 AM
 #165

Firstbits are incredibly useful, but I think it should see more side adoption. There have already been a few minor tweaks to the algorithm (like collision handling within the same block).

As for the index, 4 bytes, 5, whatever, it should be possible to calculate the optimal radix-prefix periodically. I just can't imagine the index is a significant portion of the blockchain (before merkle tree pruning). But it's absence has philosophical consequences.

I think private key import is cool, but my consistent drum beating (from the side-lines) is for simplification, transparency, and modularization. I believe bitcoin could have been a lot further along if the core did not attempt to protect users, the wallet was plain text, the local blockchain and wallet were completely independent, and generally more hacker-friendly ... is the opaque nature of the bitcoin client a matter of different philosophies (monolithic GUI vs. Unix utilities), or the evolutionary consequence of man-decades of work and discussion over performance, scalability, and usability?

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
December 21, 2011, 03:32:55 AM
 #166

I think private key import is cool, but my consistent drum beating (from the side-lines) is for simplification, transparency, and modularization. I believe bitcoin could have been a lot further along if the core did not attempt to protect users, the wallet was plain text, the local blockchain and wallet were completely independent, and generally more hacker-friendly ... is the opaque nature of the bitcoin client a matter of different philosophies (monolithic GUI vs. Unix utilities), or the evolutionary consequence of man-decades of work and discussion over performance, scalability, and usability?

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 21, 2011, 03:45:56 AM
 #167

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.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
December 21, 2011, 04:15:34 PM
 #168

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.
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.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 21, 2011, 04:46:43 PM
 #169

Firstbits are incredibly useful, but I think it should see more side adoption. There have already been a few minor tweaks to the algorithm (like collision handling within the same block).

As for the index, 4 bytes, 5, whatever, it should be possible to calculate the optimal radix-prefix periodically. I just can't imagine the index is a significant portion of the blockchain (before merkle tree pruning). But it's absence has philosophical consequences.

I think private key import is cool, but my consistent drum beating (from the side-lines) is for simplification, transparency, and modularization. I believe bitcoin could have been a lot further along if the core did not attempt to protect users, the wallet was plain text, the local blockchain and wallet were completely independent, and generally more hacker-friendly ... is the opaque nature of the bitcoin client a matter of different philosophies (monolithic GUI vs. Unix utilities), or the evolutionary consequence of man-decades of work and discussion over performance, scalability, and usability?
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.
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 21, 2011, 05:40:05 PM
 #170

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.

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.


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.

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 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.

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?).

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 21, 2011, 05:46:41 PM
 #171

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?).
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.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 22, 2011, 08:14:16 PM
 #172

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.
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.

+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.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 22, 2011, 08:26:58 PM
 #173

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.
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.

+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.

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

https://bitcointalk.org/index.php?topic=50936.0

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 22, 2011, 08:39:57 PM
 #174

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

https://bitcointalk.org/index.php?topic=50936.0

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. 

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 22, 2011, 08:43:28 PM
 #175

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.

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.

One little possible wrinkle though. We have been ordering two transactions that would otherwise have the same firstbits if they were not in the same block according to their appearance in the block data (first to appear being first). We are investigating switching to giving them both the longer firstbits. An example:

Block 1:
1asd1234567...

Block 2:
1asd2fkkkgrt...
1asd2sqp434...

Currently 1asd2fkkkgrt... would have FB of 1asd2 and 1asd2sqp434... would have FB of 1asd2s.

It seems like it might be better to not need the extra rule of tiebreaking with order of appearance and instead to give each the FB as if the similar address came before. In this case giving 1asd2fkkkgrt...  a FB of 1asd2f. It seems more elegant to use a rule of "String required to differentiate an address from all addresses in the SAME and previous blocks" and have nothing about order in the block.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 22, 2011, 09:52:41 PM
 #176

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.

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.

One little possible wrinkle though. We have been ordering two transactions that would otherwise have the same firstbits if they were not in the same block according to their appearance in the block data (first to appear being first). We are investigating switching to giving them both the longer firstbits. An example:

Block 1:
1asd1234567...

Block 2:
1asd2fkkkgrt...
1asd2sqp434...

Currently 1asd2fkkkgrt... would have FB of 1asd2 and 1asd2sqp434... would have FB of 1asd2s.

It seems like it might be better to not need the extra rule of tiebreaking with order of appearance and instead to give each the FB as if the similar address came before. In this case giving 1asd2fkkkgrt...  a FB of 1asd2f. It seems more elegant to use a rule of "String required to differentiate an address from all addresses in the SAME and previous blocks" and have nothing about order in the block.
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.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
December 23, 2011, 05:36:43 AM
 #177

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.

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 Smiley

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.


Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 23, 2011, 05:39:02 AM
 #178

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.

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 Smiley

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.
I'll try to remember to PM you what you need.
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 23, 2011, 08:53:09 AM
 #179

... resolve a firstbits address in 0.5 seconds without contacting any server... completely decoupled blockchain interface and wallet... 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).

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?

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
December 23, 2011, 05:57:10 PM
 #180

... resolve a firstbits address in 0.5 seconds without contacting any server... completely decoupled blockchain interface and wallet... 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).

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?

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).

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Pages: « 1 2 3 4 5 6 7 8 [9] 10 »  All
  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!