Makes sense, thanks!

Is possible to use a deterministic wallet with the reference client at https://bitcoin.org/en/download? I know Armory can generate a deterministic wallet, but it's not clear to me if/how I can do the same with bitcoind.

Thanks!

The memory footprint is minimal. All data is stored on disk (in Berkeley DB files).

On my machine (Windows) it uses about 100MB (constant--does not increase over time)

Looked into this a bit further. In https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp there are 6 hardcoded seeds for the main network:

        vSeeds.push_back(CDNSSeedData("bitcoin.sipa.be", "seed.bitcoin.sipa.be"));
        vSeeds.push_back(CDNSSeedData("bluematt.me", "dnsseed.bluematt.me"));
        vSeeds.push_back(CDNSSeedData("dashjr.org", "dnsseed.bitcoin.dashjr.org"));
        vSeeds.push_back(CDNSSeedData("bitcoinstats.com", "seed.bitcoinstats.com"));
        vSeeds.push_back(CDNSSeedData("bitnodes.io", "seed.bitnodes.io"));
        vSeeds.push_back(CDNSSeedData("xf2.org", "bitseed.xf2.org"));

Whereas testnet only has 2 seeds:

        vSeeds.push_back(CDNSSeedData("bitcoin.petertodd.org", "testnet-seed.bitcoin.petertodd.org"));
        vSeeds.push_back(CDNSSeedData("bluematt.me", "testnet-seed.bluematt.me"));

Both of which appear to be down as of May 20, 2014.

Still, I don't understand why this would bring the testnet client down. Doesn't it keep a list of previously connected peers?

Looking at the bitcoind logs, entries like the one below worked (bitcoind is up to date with the latest block). However, Armory doesn't start up for testnet.

addnode=95.85.39.28

That seems to be the problem, thanks! I added one of these seeds as the trusted peer to Testnet3 on Android and I'm connected now.

However, I haven't been able to get Armory to work. I tried all of the following in bitcoin.conf with no success:

seednode=95.85.39.28:18333
seednode=95.85.39.28
addnode=95.85.39.28:18333
addnode=95.85.39.28

(one line like that for all of the seeds you provided)

For the past 2-3 days I have been unable to send or receive any transactions on testnet. I tried two different Android clients (Tesnet3 and Mycelium) and 3 different machines running Armory/bitcoind on different networks. One of my friends also has this issue.

I suspect I cannot connect to other peers and that's what causes the problem. According to http://blockexplorer.com/testnet blocks are getting processed though.

Is anyone aware of any issues? Any ideas on how I could troubleshoot further?

http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/


Note: The cryptographic algorithm used by the Bitcoin protocol is based on ECC

Thank you very much! That's good feedback.

It may actually be the case that coordinating transactions internally it simpler than it might seem at first. I do not intend to interfere substantially with bitcoind. The goal of this project is strictly to provide account management services. All network operations (send/receive funds) would be relayed to bitcoind.

 In my opinion the majority of operations are limited to two components at a time (server+database; server+bitcoind; bitcoind+database). The only operations I can think of that involve all 3 components are sendfrom and sendmany. But, the devil is in the details, and your points are well taken.

Thank you again!

I didn't realize I had posted enough detail for you to draw such a conclusion, but if that is indeed the case, by all means, please educate me. I don't mean to be sarcastic. I would truly appreciate your input. How would you make it better?



Agreed. The goal of my post is to gauge if there is any community interest in such a project. Time will tell if I actually deliver something useful or beneficial.

Look, if the point you're trying to make is "you don't have the skills to build this project"*, why not just get involved? If you are too busy to code, perhaps you can get involved in an advisory role?

Every post on the topic of account management seems to eventually lead to "the stuff built into bitcoind is not good enough and may be removed in the future; build your own." The moment you're separating account functionality out of bitcoind and into a separate process you're already dealing with distributed transactions. Would it not be better to have a publicly scrutinized and tested subsystem for this?


*even though you have absolutely no idea who I am and what my experience level is, and you've apparently concluded this based on a few paragraphs I wrote and what I do for a living

Well, no, not if you're building a new system from scratch That's the use case I have in mind.

That's very cool, thanks for all the detail!

If that were true I'd be filthy rich by now 

Indeed, but that only applies to keys. Account info is unrecoverable obviously (hence my other comment about user balances).

Also, it's nice that you can recover the key to an address if you know the wallet seed, but if you lose the wallet how do you keep track of which addresses you control in the first place? Is it possible to build a list just from the wallet seed?

Well, that's what I'm proposing: if you are building a website, you wouldn't have to build the account management part (including keeping track of account balances and a log of transactions that led to those balances) from scratch.

Yes, that's what I'm thinking of. Instead of rolling your own account management, you would have an off-the-shelf component. That component exists inside bitcoind right now but it's not very robust.

To be clear, this is by no means a complete solution. I am just giving you some of our thoughts. You should still adopt a hot/cold wallet strategy and keep most of the funds completely offline.

I ran into some of these questions with the system I am building.

One tentative solution my coworker and I have come up with is to keep the wallet on a separate server than the one that is user-facing (i.e. the website). I will call the web server WS and the separate machine that is interfacing with the Bitcoin network the transaction server, or TS.

In our proposed architecture the WS does not connect directly to the TS. This way, if a hacker gets into your WS, they do not have access to your wallet, or even know where your wallet is running. The TS does not even need to be accessible from the internet (does not need a public IP).

Instead, all communication between the WS and the TS happens via a message queue. The message broker can run on the same machine as the WS or on a third server. Anytime the WS requires information from the wallet (such as funds received at an address) it pushes a message on the queue and waits for a reply.

The TS listens to the message queue and processes any requests. Sensitive requests, such as sending funds to an external address, can go through a separate authorization process. For example, if users want to withdraw funds from their account, a request is pushed to the queue, but the TS does not immediately process it. Instead, it waits for a human administrator to approve the request. The human can either contact the user (via phone, email, etc.) to authenticate the request, or decide based on other criteria if the transfer should be authorized. In the future we may automate this (for example by introducing a two-factor authentication process) but for now we want to keep it simple.

Apart from securing your wallet you will have other issues to deal with. There are not many Bitcoin clients designed to work in a server environment and to deal with concerns such as disaster recovery, load balancing, etc. The only one I’ve come across is https://bitsofproof.com, but I don’t know how good it is.

Some of the issues to think about:

• How to reliably and securely back up your wallet
• What happens to your system if you are servicing a large number of users simultaneously
• How to keep track of the balance in each user’s account

The latter is of particular concern for me. See this thread for more info:
https://bitcointalk.org/index.php?topic=586013.0

I posted some ideas here:
https://bitcointalk.org/index.php?topic=586013.0

I appreciate any feedback!