bismuthfoundation / bismuthrpc Goto Github PK

This job is a little more evolved than the others I posted.
It needs a deeper understanding of the wallet and, and some specs could be missing, so it will need someone at ease with the current code and some exchanges with me.

https://github.com/EggPool/BismuthRPC/blob/master/RPCServer/Commands.md

The 4 following commands are to be coded in one go by the same person.
See rpckeys.py and try_keys.py for the encryption/decryption logic.
See also https://eli.thegreenplace.net/2010/06/25/aes-encryption-of-files-in-python-with-pycrypto for background info

• encryptwallet - (passphrase) - Encrypts the wallet with (passphrase).
  Bismuth uses a more secure encryption scheme, AES based, that uses also an IV.
  This call returns the random IV used, that has to be stored with the passphrase. Both are needed to unlock the wallet.
• walletpassphrase - (passphrase) (timeout) - Stores the wallet decryption key in memory for (timeout) seconds.
  passphrase is composed of the IV given by the encryptwallet or walletpassphrasechange call, plus the passphrase itself.
• walletpassphrasechange - (oldpassphrase) (newpassphrase) - Changes the wallet passphrase from (oldpassphrase) to (newpassphrase).
  Bismuth uses a more secure encryption scheme, AES based, that uses also an IV.
  This call returns the random IV used.
• walletlock - * Removes the wallet encryption key from memory, locking the wallet. After calling this method, you will need to call walletpassphrase again before being able to call any methods which require the wallet to be unlocked.

This one is an almost "self contained" job.
But it's not for a first time contributor, show you understood the code and have a working dev setup before working on this.

It's something I could do, but I prefer to involve other people.

This are the wallet encryption methods.

4 rpc commands are involved:

• encryptwallet - (passphrase)
• walletpassphrase - (passphrase) (timeout)
• walletpassphrasechange - (oldpassphrase) (newpassphrase)
• walletlock
  (see commands.md for details)

The encryption is coded and running, see rpckeys.py and try_keys.py
Encrypting the wallet means encrypting the private key string in all account json files, and update their "encrypted" property.
I'm available on Bismuth slack and Discord to give further info if you think you can handle this.

Any json-rpc client or lib is supposed to be used.
But it would be good to include a command line python client, taking command and parameters from the command line, sending to the server, and printing back the result.

Good as a debug tool, and sample calls.
testing/test1.py can be used as a sample base code, "just" need to wraps up the calls.

I'll do it myself in a few days if noone else did.

From https://github.com/EggPool/BismuthRPC/blob/master/RPCServer/Commands.md

Add this method in wallet.py (and link from nodeclient)

importprivkey - (bitcoinprivkey) (account) (rescan=true)
Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a rescan is done, looking for existing transactions. Optional (rescan) parameter added in 0.8.0.

Check with node code and tools from @maccaspacca. Add methods to keys.py that take a private key, regenerates public key as well as address.
https://bitcoin.org/en/developer-reference#importprivkey

Coins that support BIP65 can be more easily integrated by DAX through atomic swaps.

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

Blocknet is such platform.
Found more info there
https://github.com/BlocknetDX/blocknet-docs/blob/master/blocknetDXservice-node.md
and
https://github.com/BlocknetDX/blocknet-docs/blob/master/blocknetFAQ.md

So, no surprise, json-rpc is a pre-requisite. Then OP_CHECKLOCKTIMEVERIFY support.
The json-rpc server may be able to "translate" that to (a future) bismuth core functionality.

This would need more research and possibly some tech assistance from someone at ease with blocknet.

Posted here as a memo.

From @Aareon

Reference: https://en.bitcoin.it/wiki/Running_Bitcoin

A wallet transaction includes any transaction for any given address belonging to said wallet.

Usage: -walletnotify=echo “Transaction received... TXID: %s”

@iyomisc , maybe you could work on these 3 commands:

• getbestblockhash - * version 0.9 Returns the hash of the best (tip) block in the longest block chain.
• getblock - (hash) - Returns information about the block with the given hash.
  https://bitcoin.org/en/developer-reference#getblock
• getconnectioncount - * Returns the number of connections to other nodes.

https://github.com/EggPool/BismuthRPC/blob/257d20cd43574b8148d13db89c63ac73fa7c46e1/RPCServer/rpcwallet.py#L194

If you want to help, I'm trying to define small isolated tasks.

Clean stopping the server from a method is not as straightforward as it would seem.

See the method and related links in the code:
https://github.com/EggPool/BismuthRPC/blob/0c5cc312b2d2a3079767107441175af57b4f220f/RPCServer/nodeclient.py#L54

Someone with Tornado experience could help solve this faster than I would, so I won't go further for now. If you have any hint or solution to this, feel free to tell!

The current POC server only understands jsonrpc2.

In practice, json-rpc objects do work without a change, they just need an added property "jsonrpc"=2
See if this can be configured in jsonprcserver lib.
If not, maybe auto add this property to received post data when missing, so we can deal with both versions of json-rpc.

https://github.com/EggPool/BismuthRPC/blob/257d20cd43574b8148d13db89c63ac73fa7c46e1/RPCServer/rpcwallet.py#L166

If you want to help, I'm trying to define small isolated tasks.

Specifically adding the option for HTTPS secured passwords over RPC. Internal network RPC is ok, but it only takes one bad actor in a business to cause issues. Adding the options for HTTPS secured RPC will help keep exchange systems and wallets safer. This would also place Bismuth a step ahead of others in terms of helping lead crypto towards better security.