Nunchuk’s architecture differs from other wallets’ for a number of reasons. But a major one is our decision to heavily reuse Bitcoin Core code. 2/
Why is reusing Bitcoin Core code a big deal?
* Bitcoin Core is the unofficial spec of the Bitcoin protocol.
* Bitcoin Core is the most peer-reviewed and battle-tested in all of cryptocurrencies.
* Bitcoin Core has important protocol upgrades coming, such as Schnorr signatures. 3/
By leveraging Core, @nunchuk_io is able to kill two birds with one stone: gaining access to powerful and reliable Bitcoin tools, while staying lean and cutting down on the number of dependencies. 4/
The Nunchuk library creates a higher abstraction on top of Bitcoin Core’s inner building blocks, while reusing much of its logic such as: transaction and signature verification, PSBT, output descriptor, and Branch-and-Bound coin selection algorithm. 5/
But the Nunchuk library does a lot more than that. Some highlights include:

(I) Hardware Support

An easy-to-use interface to manage hardware signers, including the ability to health-check them. 6/
(II) Wallet Management
High-level classes to manage UTXOs, various types of transactions, signers, and wallets.

(III) Encryption
Encryption support out of the box via sqlcipher. Nunchuk data stored on the user’s computer can optionally be protected with a passphrase. 7/
(IV) Minimal Dependencies
 
Every dependency is a potential attack surface.

Nunchuk deliberately steers away from the browser as a runtime dependency. 8/
The browser-as-a-platform has been a popular choice among developers in recent years, because it short-circuits the development lifecycle, allowing you to ship code faster. 9/
The downside is that the browser and its derivatives, Electron-powered apps, are notorious for being insecure. Not to mention a resource hog. Thus, the browser is not a good fit for mission-critical applications such as a Bitcoin wallet. 10/
Nunchuk took the longer but ultimately safer route of going native. The Nunchuk library can be easily compiled into native applications, while remaining maximally cross-platform. 11/
(V) Client-Server Architecture


As great as Bitcoin Core software has become, it was _never_ designed to be a server.

Satoshi actually intended for Core to be used as a mining node, talk about evolving software requirements 🙂. 12/
Backing your wallet with a vanilla Bitcoin Core node for blockchain data works well only if:
* You use Bitcoin exclusively for yourself, and
* Your node runs on the same local network as your wallet

13/
This architecture greatly limits the number of potential use cases. It breaks down the moment you need to access your node remotely & securely, or when you have multiple wallets or individuals wanting to share the same node.

Yet, that is the future we envision with multisig. 14/
By connecting the Nunchuk library to a real server that sits on top of Core, instead of a vanilla Core node, we allow our architecture to be loosely-coupled, safer, and more robust. 15/
Nunchuk works out of the box with any server running Electrum protocol v1.4, including the personal server @getumbrel (Nunchuk + GetUmbrel = match made in heaven), electrs or ElectrumX.

TOR proxy can be enabled for improved privacy. TLS support is currently in the works. 16/
For more information, head over to our Github repo. Feel free to contribute, or fork to create your own wallet!

Cypherpunks code. Let's code. 17/
P.S. More tutorials and articles will be coming in the next few weeks.

For a sneak peek of what Nunchuk library could do, check out: https://twitter.com/hugohanoi/status/1327184760049868800
You can follow @hugohanoi.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.