Topic: Get unspent outputs for given address? (Read 2805 times)
Someone seems to be tackling the first parts of that - look for the threads by drvillo on the mailing list. Once he has made the simple change suggested there, the FullPrunedBlockStore will receive full blocks whilst the chain is being downloaded (as well as the utxo deltas). You can then insert the contents of the blocks into SQL tables in the manner that any database app would, it's not very complicated. There's a ton of interest in this feature so I'm sure it'll be implemented by someone soon.
I've been wanting the same information without the full block chain in a decentralized manner. AFAIK, SPV does work to get this information since its not in the headers.
I've been looking into getting the information from Electrum servers (see https://github.com/spesmilo/electrum/blob/master/lib/wallet.py#L1023). My lack of Python knowledge has been holding me back a little on extracting what i need. But it is a way to get the information without a single point of failure.
Feel free to write up a nice implementation in Java for me.
I've been looking into getting the information from Electrum servers (see https://github.com/spesmilo/electrum/blob/master/lib/wallet.py#L1023). My lack of Python knowledge has been holding me back a little on extracting what i need. But it is a way to get the information without a single point of failure.
Feel free to write up a nice implementation in Java for me.
Hi Mike,
Thanks for the reply. I will try to do as you suggested. From your post, I take it that full verification mode is necessary to do what I want.
Thanks for the reply. I will try to do as you suggested. From your post, I take it that full verification mode is necessary to do what I want.
I don't have any plans to implement that.
If you wanted to implement it, you'd do so by adding code to FullPrunedBlockStore. Unlike most block stores it's based on a full-blown embedded SQL database, which means it's very slow, but you can fairly easily add new tables and extend the queries as necessary. I haven't tried it, but I don't think it would be very difficult to do. If you implement this please consider submitting a patch for it.
However, do be aware that bitcoinj full verification mode is not designed for speed, at all. If you care about performance it would be better to extend bitcoind to support this using an additional LevelDB.
If you want this to make a web hosted wallet though, I'd suggest to think carefully about whether you really want to do that. It's a very painful endeavour.
If you wanted to implement it, you'd do so by adding code to FullPrunedBlockStore. Unlike most block stores it's based on a full-blown embedded SQL database, which means it's very slow, but you can fairly easily add new tables and extend the queries as necessary. I haven't tried it, but I don't think it would be very difficult to do. If you implement this please consider submitting a patch for it.
However, do be aware that bitcoinj full verification mode is not designed for speed, at all. If you care about performance it would be better to extend bitcoind to support this using an additional LevelDB.
If you want this to make a web hosted wallet though, I'd suggest to think carefully about whether you really want to do that. It's a very painful endeavour.
Hi Mike,
Any plans to add feature to get list of unspent outputs for a given address? (Address is not in wallet). Technically this information should be there in every client. Even bitcoind currently does not allow such a query though, so if you implement it, bitcoinj will be "ahead" of bitcoind...
How hard is this to add? Perhaps you can give me pointers to which files to look at.
Any plans to add feature to get list of unspent outputs for a given address? (Address is not in wallet). Technically this information should be there in every client. Even bitcoind currently does not allow such a query though, so if you implement it, bitcoinj will be "ahead" of bitcoind...
How hard is this to add? Perhaps you can give me pointers to which files to look at.
Jump to: