Topic: [BOUNTY - CANCELLED BTC] : read only blockchain patch for bitcoind (Read 3804 times)

The reason multi-wallet hacks like this are so easy is because we (in particular, sipa and Matt) have been working toward proper support for multiple wallets for some time now. With Satoshi's original code, it would have been very difficult - these are some big changes to refactor the code. 0.6 contained sipa's changes to abstract the CWallet class, and 0.7 or 0.8 will probably include Matt's abstraction layer for the blockchain. When all these bigger refactoring are complete, there will probably be a small change to tie it all together in a user-friendly way - until then, end users won't notice the bigger under-the-hood stuff that's been going on

I can't help feeling that the better way is to separate out the wallet-handling code, with an RPC interface between that and the blockchain + network code, and an option of running it the current way with the two modules in one prcess.  Still, there may be situations where multiple wallets in one client is better.

After some testing and fixes, the prototype is now able to move funds between the two wallets and get correct results from getinfo/listtransactions.

I can see these milestones:
1. Adding/removing users (preferably without need to restart bitcoind)
2. Permissions (for commands like "stop")
3. Performance. Maybe this turns out to be non-issue, but from my experience with bitcoind it may be possible for users to DoS each other.

Yes, I plan to contact the dev team. The code is very well written and multiple wallet support is already halfway there. Thus this patch isn't very invasive and 90% of it is in RPC code. It should not be an obstacle for future updates.

rapeghost, way to stab for effect!

rini17, I think there is interest...the more code people see the more likely they'll be to pony up some funds to pay for development. You might want to break your 150BTC estimate into smaller chunks that can be paid per milestone.

This thread is about "a patch" but to think longterm about this, it may help to get some feedback from the core dev team. From what I've been told on IRC, the direction they want to go is to to seperate the blockchain and network code from the wallet handling code. I haven't been able to find a github issue that specified this succinctly so creating such an issue might be a good start.

Or just hack it out...either way!

fuck. yeah.

I am trying to add multiple independent wallets/users support to bitcoind. It is planned to work this way: There will be one bitcoind normally running, but it will use multiple wallet.dat files. Every RPC user will have its own file, and they will be authenticated by existing RPC username/password (so, no change necessary at the client).

The code is at: https://github.com/jurov/bitcoin . I have some issues with testnet, so the code is almost untested as of now. It will create two files wallet.dat and wallet2.dat . The first one is accessed normally by username and password from bitcoin.conf, the second one has "2" added in the end of both username and password, for example:


However I want to know first whether there is enough interest in this solution. I guess the work necessary to bring it up to par quality and especially security-wise will be around 150 BTC.

* stabs Nyaaan in the face *

Chmod the blockchain after it is downloaded so nobody can write to it.

 that was the initial idea, but its not as simple as saying it, code it if you think its so simple

Why not have a flag in each client "Download blockchain" and a path to where the Blockchain (should) reside. That way those without the checkmark simply try to read the file, and those with the checkmark read and write to the file.

I completely agree here.
On my VPS, if I give someone access and they need to run their own bitcoind, it ends up with an extra 2gb+ space being chewed up by THEIR blockchain, if instead, my personal bitcoind could handle the blockchain, and the other users bitcoind's would simply control their own wallets and use the single blockchain instance provided by my primary bitcoind, it'd save a lot of time and resources for setting up several bitcoind's.

So essentially we're looking to have separate daemons for the wallet management and the blockchain validation?

As I've pointed out before on IRC,  this isn't the way to accomplish what you want. A "one write many read" blockchain can not be accomplished with a simple patch— it would take either significant and hazardous rewrite of BDB, or a hazardous rewrite of bitcoin to use something custom instead of BDB.   Even if someone managed to pull it off I'm doubtful we'd take it upstream.

Instead, it appears to be generally agreed that we want to split the blockchain and the wallet— so you could have one trusted blockchain and N wallets (GUI or CLI/RPC) talking to it across the network.

That's why I said patch bitcoind!

It appears the devs have discussed this though a bounty like this is probably the only way to get code written. See Mike Hearn's post here: https://bitcointalksearch.org/topic/m.892772

Another reason for this project to happen(linking roughly to where relevant discussion is): https://bitcointalksearch.org/topic/m.892743

By the way... I'll add 5 BTC as well. Would love to see this happen!

Bump + Weex:
I attempted this already. The API's are incompatible.

We need it based on Bitcoind.

I'm adding another 5 BTC bounty to this making the total bounty: 20 BTC

neofutur has requested something based on "the old , secure and trusted C code : bitcoind". As someone who has enjoyed using BitcoinSpinner a bit, why not patch bitcoind so it supports direct calls via BCCAPI ( http://code.google.com/p/bccapi/ ) or the protocol it uses?

Not that it's secure?

BitVPS is adding another 5 BTC to this bounty.

Conditions: The only thing i care about is that it works on Linux.

I'm willing to back active development in two areas.

1) A thin client / server blockchain standard.

That is, a single remote machine worries about the blockchain, and clients can request balances off of it (sacrificing anonymity), and interact directly with this server for transactions.  The wallet can be stored on either their mobile device (for servers that are run by external entities, like MtGox), or can be stored on the server (for servers that are run at home).

I don't care about actual server/client implementation so much as a defined protocol set and working libraries, open license.

2) Super Blocks.  An advancement in the storage of the block chain, whereby the block chain (ledger) is processed for addresses that still hold a positive balance, and the ledger becomes closed and cryptographically archived such that ALL clients can securely depend on a simple cryptographic hash of the whole Super Block.  The culled addresses with balances begin a new Super Block.

This way, new clients may download the entire block chain, but would not have to hash every transaction in the old Super Blocks, as they are known by all to be accurate and trustworthy by a simple file hash.  Only the transactions in the current Super Block block-chain would have to be articulately hashed.  This would also allow for optical storage and transfer of Super Blocks to be distributed on DVD or Blu-Ray instead of internet download, such as for Merchant POS terminals and servers.

I will fund 5 BTC, to each, given the active development of these projects, once they have established a name for themselves and their work in the IRC Bitcoin community.

yes it seems some other clients ( java or python code ) do it, but the bounty is for the old , secure and trusted C code : bitcoind

I may be saying something that isn't true, but: Can't Armory do that? Or is it that other client, Electrum or what's its name?

Or I may be confusing the features in both of them.
If I recall correctly, Armory can have watch only wallets, which isn't what you want. You want a watch only blockchain.
But Electrum(?) can read the blockchain from a central server, who may or may not be managed by yourself, if I'm not mistaken.