Blockstream announced the acquisition of Bitcoin wallet provider GreenAddress on Wednesday. In a post on the company’s official blog, Blockstream President Adam Back noted, “GreenAddress has a demonstrated track record of delivering an industry-leading product that prioritizes security, privacy and convenience.”
GreenAddress has been quick to implement new Bitcoin features, such as fee estimation and replace-by-fee, into its own wallet. Also, GreenAddress developer Lawrence Nahum is a supporter of the Bitcoin Core scalability roadmap and says he’s excited about the improvements that are coming to Bitcoin in the near future.
Bitcoin Magazine reached out to Nahum to get the details on what GreenAddress will be working on now that it is under the Blockstream umbrella of Bitcoin products and services.
Implementing CHECKSEQUENCEVERIFY
Nahum was quick to bring up the upcoming implementation of OP_CHECKSEQUENCYVERIFY (CSV) to improve the refund process on their 2-of-2 multisignature addresses.
One of the key features of GreenAddress is the ability to complete what are essentially instant Bitcoin transactions. This works by putting user funds in a 2-of-2 multisig address where the two parties are the user and GreenAddress. If someone trusts GreenAddress to not double spend a transaction, then he or she can trust this user’s GreenAddress wallet to do the same.
A refund transaction is also pre-signed and held by the user to prevent funds being locked up in an address that requires a signature from GreenAddress to send a transaction. Currently, a pre-signed nLocktime refund transaction is emailed to the user when a transaction is received on a 2-of-2 address (including change transactions). This transaction becomes valid after a predetermined amount of time.
With CSV, the refund process can be handled directly on the blockchain. The gist of it is that a 2-of-2 multisignature address will be controlled only by the user after a certain amount of time has passed.
CSV also will get rid of a window of trust that is involved with the current nLocktime process. This window of trust involves the problem of an nLocktime transaction ID not being set in stone until it is confirmed on the blockchain; this issue is known as transaction malleability.
Nahum noted that he wants to wait until MAST (Merkalized Abstract Syntax Tree) is available before implementing CSV due to reasons related to user privacy.
“Once MAST is into play, you only see the 2-of-2,” he explained. “You don't see the [refund transaction] unless it is used, which means you only reveal the nLocktime when you do recovery with MAST.”
In other words, MAST would enable the same level of privacy for these addresses as they enjoy today with the added benefit of CSV.
Building a Bitcoin and Sidechains Wallet Library
In addition to working on its own wallet, the GreenAddress team will also be working on a library that any developer will be able to use.
“The library will help us deliver better and consistently to all platforms without rewriting a lot of code for each platform,” said Nahum.
The library is in C but it will have bindings to other major languages such as Java and Python. Other C libraries, such as libsecp256k1, will also be reused in this new library from the GreenAddress team.
“With the library, we do not want to reinvent the wheel,” added Nahum. “But we do want C to support all platforms, so we are reusing where applicable.”
Nahum explained that C was chosen as the language for the library because it can work everywhere and it’s also easy to interface with other popular languages. As an example provided by Nahum, bitcoinj can be used on iOS with some frameworks, but running it on a hardware wallet would be difficult.
According to Nahum, support for various features enabled in Blockstream’s Elements Alpha sidechain also will be supported in the library.
“So far, we have support for some of the features of Elements Alpha and we want to complete support, plus add support for features that will be released in the future (at least the ones that are applicable to the wallet),” said Nahum. “We already added support for Confidential Transactions in GreenAddress before Scaling Bitcoin Hong Kong as we were experimenting with the tech.”
“But our support was very proof-of-concept,” he said. “A lot more work is needed to make our support more robust.”
“Our goal with the library is to make it easier for us and other developers to build powerful, secure, and fast multi-platform wallets for Bitcoin that support sidechains. I think this is good for the library as it makes it more modular and it allows people to innovate more. It will also be a way to get an early peek at features that could eventually come to Bitcoin.”
Nahum would like the C library to work with Bitcoin mainnet, the testnet and sidechains.
The Long-Term Vision for GreenAddress
Long term, the plan for GreenAddress is to provide its users with a user-friendly, convenient wallet while also learning as little about them as possible.
“Our ideal place is where we don't know which transactions are involved, yet we can validate the things users wants us to validate such as two-factor authentication or spending limits,” explained Nahum. “The less data we have the better.”
Nahum also shared his excitement for new improvements, such as Schnorr signatures, that should be added to Bitcoin in the near future.
“Schnorr is going to be great,” he said. “Finally, multi-signature and single-signature transactions will cost the same in fees and will look the same from outside. Plus, the transaction will be smaller.
“With some of these improvements, we can not only improve privacy and security but also ease-of-use, as there will be less for users to keep track of (i.e. no nLocktime files) while having better privacy and atomic security,” Nahum concluded.
While the Bitcoin Core wallet still has better privacy features, GreenAddress offers unique protection against malware via two-factor authentication. GreenBits, another wallet from the GreenAddress team, also allows users to avoid trusting a third party by allowing them to connect to their own full nodes.