SLICk - Small Lightweight multIcoin Client

[Nachtwind]

Current Version: 0.1.0 -development haltet but source available-

Description and Background:
SLICk is an attempt to create a lightweight wallet for VPS Users like me.
For me it was a big problem that Bitcoind was taking just too much memory and CPU for everyday use. Bitcoind also took way too much Harddisk space so i looked for alternatives and didnt find much.
The BitcoinJ Project was a nice start to create my own client. Using JPosse as example on how to use Servlets for RPC i began writing a small application to serve Virtualminer as bitcoind replacement. As some time went by and everything went just too smooth (even though using JAVA) i decided to add the capability of running a Litecoin Wallet to Bitcoinj/SLICk which ended up in modifing a lot of the base BitcoinJ code but also resulted in a small java application that can handle Bitcoin and Litecoin by just using different configuration files.

Configuration files:
Configurations can be split into two major areas: User and Chain
The part for the user lists the filenames of the wallet and blockchain file and how often the client should update. Also users can set a fixed fee and setup the RPC information.
The other part is the area which the normal user shouldnt touch. It basically lists all the network parameters of a blockchain like Genesis Hash, TargetTimespan and so on.
(Will add an example later)

RPC calls:
I have implemented a few RPC calls that are useful for websites. I dont plan on introducing GetWork and similar stuff into SLICk since it is not meant to be a replacement for bitcoind. Also i didnt add any Account features as they are in the original client. First of all because i created the client for people who use a db to track accounts anyway and because i dont like the built in account system.

Native RPC Calls:
getbalance
getnewaddress
getreceivedbyaddress("Address")
sendtoaddress("Address,Coins)
validateaddress("Address")
getblockcount()
getinfo()
getdifficulty()
getconnectioncount()
getblocknumber()
listtransactions()
settxfee (0.005)
sendmany ("Address",Coins,"Address",Coins...)
stop()

Custom RPC Calls:
I also created a few RPC calls that i thought to be useful at my own projects and therefore introduced them into this client as well.

getKeyPoolsize() -- Returns the number of keys in the wallet
savewallet() -- Triggers the saving of the wallet
ListPubKeys() -- Returns a list of all public Keys
SetMaxConnection(num) -- Changes the maximum amount of connections on the fly and saves it to the config file
TempMaxConnection(num) -- Changes the maximum amount of connections on the fly. Setting is lost after restart
EchoToCli("Some Message") -- Show some text on the command line
getConfidence(TransactionID) -- Returns the confirmations of a given Transaction ID


Changelog:
0.1.0
- Internal testing phase began.

Performance:
It takes about 3 hours to download the full Bitcoin blockchain at my home computer, less than an hour for Litecoin. This looks different for my VPS but its a very slow one when it comes to writing to disk...... Memory usage is ok: The Bitcoin client is running for a few days straight now and takes 100MB mem, the litecoin client roughly 95MB.. so both look good.




Download Links:
Source "As is": virtualminer.eu/SlickSrc.7z

I will update this once i find some time to keep developing it again...


how to run: copy the contents from btc.config or ltc.config (those work..) into slick.config and run the following command:
java -cp [youjarfile] com.windwallet.Main slick.config

[Nachtwind]

ok, to be honest i dont see the difference at the moment - could you explain this to me? THe way i handled it so far was to reproduce the same "answers" the original client gave me. Also i was testing all this all the time through a PHP RPC class and for the moment the client works without problems as substitute for my original client on two php projects.

[Mike Hearn]

That's really cool but it might not be a good idea to get too far from bitcoinj base. Otherwise you'll find it difficult to rebase on top of newer versions that have many bugfixes, performance improvements and other useful things.

[Nachtwind]

That's really cool but it might not be a good idea to get too far from bitcoinj base. Otherwise you'll find it difficult to rebase on top of newer versions that have many bugfixes, performance improvements and other useful things.

Thats a problem i see myself. Primarily my idea was to have a wallet with bitcoinj as backend but this grew impossible when adding litecoin to it. But at the moment the changes are rather small - the analog to the prodNet() function there is a custNet() function that takes the config file as parameter and fills the network parameters from there. Also there are numerous smaller "fixes" to other functions to work with custNet() parameters and scrypt in general.

[Mike Hearn]

You could try and merge some of the changes upstream, but honestly, I'm not sure I care about litecoin. Is there some massively compelling reason you want to support that?

[Nachtwind]

You could try and merge some of the changes upstream, but honestly, I'm not sure I care about litecoin. Is there some massively compelling reason you want to support that?

Yes, because i intended the client to work with bitcoin and litecoin and virtually every other *coin that is available atm - but only worked out BTC and LTC so far

[Atruk]

You could try and merge some of the changes upstream, but honestly, I'm not sure I care about litecoin. Is there some massively compelling reason you want to support that?

Yes, because i intended the client to work with bitcoin and litecoin and virtually every other *coin that is available atm - but only worked out BTC and LTC so far

Keep in mind that all of the altcoins have their own little wallet quirks that are going to require maintenance. Reciever files in DevCoin, Pay Per Share mining in PPCoin, tec.

[Nachtwind]

You could try and merge some of the changes upstream, but honestly, I'm not sure I care about litecoin. Is there some massively compelling reason you want to support that?

Yes, because i intended the client to work with bitcoin and litecoin and virtually every other *coin that is available atm - but only worked out BTC and LTC so far

Keep in mind that all of the altcoins have their own little wallet quirks that are going to require maintenance. Reciever files in DevCoin, Pay Per Share mining in PPCoin, tec.

Thats why i just included BTC and LTC so far.. i would like to tackle NMC next, but dont have the time right now.

[crazy_rabbit]

Looking forward to it! :-)

[Nachtwind]

Status update:
Currently adding TRC to it and putting some minor finishing touches to everything.

When that is done i am going to upload the source/jar files

[Nachtwind]

@Nachtwind
Gibt es einen client mit dem ich Litecoins empf/senden kann, ohne die ganze blockchain runterzuladen?

Translated: Is there a client that i can use for sending/receiving Litecoins without having to download the full blockchain



Not that i know. Even with SLICK you have to download the chain.

Translated: Soweit ich weis nicht, auch SLICK lädt die gesamte Blockchain runter. Achja, bitte deutschsprachige Nachrichten im entsprechenden Forum schreiben.

[sacko]

Danke für die Info.

Achja: Es steht dir frei, die deutsche Sprache als hier fehlplatziert oder womöglich unangemessen zu betrachten, doch, solltest du deutsche Wurzeln haben, dann ... (du kennst meine Meinung)

[Nachtwind]

sacko: Wie gesagt, - bitte hier englisch sprechen, dann haben alle was davon.
sacko: Like I said, please talk english here, so everyone can follow the discussion.


Sorry for the delay.. was not home for the weekend, and couldnt include TRC yet. Current list of whats to do till the release:

- including TRC
- fixing some minor "config" trouble (currently you call the program with the config file as parameter, yet some places in bitcoinJ need this parameter and cannot get it without too heavy modification.. and i want to avoid that)
- fixing some minor bugs

[crazy_rabbit]

Looking forward to it though, gonna be exciting.

[Nachtwind]

Uploading my current snapshot of sources. Due to a shortage on time i will just do this for the moment..

[Nachtwind]

...i forgot to upload the dependencies.. mea culpa. Doing that in a few min.

[crazy_rabbit]

...i forgot to upload the dependencies.. mea culpa. Doing that in a few min.

Did you have a chance to see the Terracoin DEV's update? I think it will solve the hash problem you were having.

[kaoD]

This could be scary but you said you have created a lightweight RPC server bitcoind, based on JPosse, I just looked at that code, it isn't RPC, it just returns JSON, this would not work with any existing software, kinda disappointment I could have really used this.

RPC just means Remote Procedure Call so he wasn't lieing. You've probably confused RPC with XML-RPC which is the standard used in Bitcoin-QT.

[kaoD]

No, I was going by http://json-rpc.org/wiki/specification and that specification wasn't found in the program, it was just JSON returns, no JSON-RPC returns.

Again, RPC is not JSON-RPC. If you can Call Procedures Remotely, it's RPC!

[kaoD]

Otherwise why is he returning JSON?

Because JSON is a handy object notation? I've done some RPC implementations which worked through JSON but weren't JSON-RPC compliant (mainly over RESTful services).

And you're right, it's Bitmessage the one that uses XML-RPC. Got both mixed up.