Next steps for bitcoinj

[Mike Hearn]

I just uploaded the version switch to 0.9-SNAPSHOT. Before we proceed, it's worth reflecting a little on how far we've come in the last two years:

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

With that said, here are my upcoming priorities:

1. Finish off the threading changes, this means running tx confidence listeners unlocked.
2. Simplifying the wallet code and rewriting re-org handling to be less buggy.
3. Implementing the basic fee rules (not a fully blown optimiser)
4. Audit mode for BuildCheckpoints
5. Maybe some memory usage optimisations to take the pressure off older Android phones with large wallets.

I also want to encourage Matija to submit his deterministic wallets code and we can start getting it ready to merge. I only looked at it briefly because he never asked me to so I don't know if it's finished, but I think deterministic wallets are one of the next most important user visible features because it makes backups so much more robust.

There might be a few other misc API changes in there. If I get time, I might play with a Netty 4 port as I believe (need to check) it should resolve the reentrancy issue that's causing deadlocks in issue 381.

[Travis Savo]

I'd like to throw my own personal wish list on top if I may be so bold.

I have a design need in my code which is presently very hard to support: The replaying of block chains. I understand that the current design presupposed that you are saving your wallets along with your blockchains, but my requirements preclude such an option as it requires generating wallets with keys that may already have transactions and needing to sync those.

I've looked at the work done in Multibit with the ReplayableBlockChain, and while it's a step in the right direction in that it allows you to replay a wallet, the only way to get the data is from the PeerGroup.

This means downloading it every time. I was really confused by this design at first, as I was expecting the block store to provide me with some way of accomplishing this once it's been populated, but everything I've been hacking apart tells me no. I've looked at how all the stores implement replaying: By choosing the oldest block to be the head, and downloading everything the comes afterwords.

So I'd like to propose a separation between PeerGroup and BlockStore, namely a BlockProducer which PeerGroup can implement, and a BlockReader which BlockStore can implement.

I'm envisioning a scenario where a PeerGroup gets hooked up to a file or database writer, instead of a block chain, and the blocks are all written out to the database. Then, later, when you want to replay a wallet, you can replace the PeerGroup with a Database reader for a completely offline solution. You can also build a hybrid BlockWriter that pulls from the DB, and listens to Peers for new blocks/transactions.This would allow for trivial replaying of wallets very quickly.

I was sure in looking over the code that something like this would already exist, but everything I've seen always has PeerGroup being the one who initiates blocks flowing through the system.

Am I missing something? Does this already exist? Can we replay a wallet without redownloading the entire BlockChain if we don't know the key creation date? Is this what 'deterministic wallets' refers to?

Thanks for everything...

-T

[Mike Hearn]

-matija

So I'd like to propose a separation between PeerGroup and BlockStore, namely a BlockProducer which PeerGroup can implement, and a BlockReader which BlockStore can implement.

That design wouldn't work because it's the Peer (not group) that pumps data into the BlockChain and from there BlockStore. The reason the block stores throw the data away is that 

a) The SPV block store throws out all transaction data by design, it's too intensive to keep all of it on constrained devices.

b) The H2FullPrunedBlockStore throws out data as part of the ultraprune algorithm, same as a regular bitcoind

There is no mode in which every transaction is stored.

However, if you just run a regular Satoshi node locally and connect to that, you get pretty much the same thing as reading the block chain data directly. There is a BlockImporter program in the tools directory that can read the blk?????.dat files directly and you could pass all blocks found there directly to the BlockChain object, but as those files are created by a satoshi node anyway you may as well just use that.

 

However the real question is why do you want to insert arbitrary private keys into your wallet. That is not an operation that should ever be useful for anything. I'm sure your task can be solved in a better way.

[Mike Hearn]

On Thu, Apr 11, 2013 at 3:15 PM, Mike Hearn <he...@google.com> wrote:

If I get time, I might play with a Netty 4 port as I believe (need to check) it should resolve the reentrancy issue that's causing deadlocks in issue 381.

I looked into this and it appears Netty 4 does indeed resolve this issue along with a bunch of others.

[Travis Savo]

Brain wallets. You put in a pass phrase and that gives you your private key. Zero storage is a requirement here.

Turns out blockloader in tools was purrrrfect. In fact based on that code I'm now just building output hash -> transaction hash maps so I can do fast scanning for relevant transactions. Works brilliantly. Thank you a thousand times.

--
You received this message because you are subscribed to the Google Groups "bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mike Hearn]

Brain wallets are a bad idea and will never be supported in bitcoinj barring some research breakthrough. If you use a brain wallet you WILL end up losing your money.

[Tiago Rinck Caveden]

Why would brain wallets be riskier than a good encryption password for all your backups?  (I'm assuming you're considering them risky because we can forget it... or is it some other reason?)

Tiago Rinck Caveden

[Travis Savo]

They're susceptible to brute force attacks.

With an encrypted wallet, your pass phrase can be compromised, and if they don't have your wallet, there's no danger. With brain wallets, the pass phrase is the wallet, removing one factor of protection.

[Dev Random]

What about HD wallets?

On 13/04/13 02:02, Mike Hearn wrote:
> Brain wallets are a bad idea and will never be supported in bitcoinj
> barring some research breakthrough. If you use a brain wallet you WILL
> end up losing your money.

--
Miron

[Travis Savo]

HD wallets are a different animal, and are as susceptible to attacks as any encrypted wallet. They just came up with a clever protocol for generating and signing keys in a chain such that different levels of access can be granted to different parties without giving away the keys to the kingdom.

-T

[Dev Random]

Right. The main advantage is that only one secret needs to be backed
up, as opposed to the growing keypool that needs periodic backup with
non-HD.

> <mailto:bitcoinj%2Bunsu...@googlegroups.com>.