2019 was a great year for BlueWallet. Although it is a new wallet and still in its infancy, we did get some some media coverage, we did get some recognition from industry experts and we did get some users to remind us how much we suck and how much better it can still be. All that, working on the project on our free time in a pure open source fashion.

This year blew away our wildest expectations on what we thought we could achieve. To give you a bit of perspective, at this time last year we were releasing the android version of the app and our Lightning wallets feature right before Christmas. And probably, at that time, most of you hadn’t really heard about Blue.

Talking about Lightning. While the Lightning Network slowly matures, and after doing our part to put it on the spotlight and bringing the attention it actually deserved. We decided to take a step back and work on the layer that really matters. The base layer.

In the core, BlueWallet is (and always was) a non-custodial on-chain bitcoin wallet, born out of the frustration and ashes of the 2017 Bull market. When fees were high and the majority of wallets still had not implemented segwit and flexible fees. Paying $20 in fees for a transaction because your wallet’s fee estimation was broken? That was a real deal back then.

The very first release of BlueWallet fixed exactly that: segwit, flexible fees (starting from 1 sat/byte), and RBF (replace-by-fee).

During the next cycle of adoption (this is how I like to call the bull-run) I expect to see exactly the same thing we saw in 2017: with that many people discovering the advantages of Bitcoin and making their first happy transactions. The block space will again be an extremely scarce commodity.

After another block reward halving, a more mature fee market will develop, and we will witness a natural competition for block space. This is why I think it is important to prepare for that in advance: your bitcoin wallet app (as a customer-facing software) should be the one to act in your best interests, trying to save as much pennies on transactions as possible and, at the same time, give you the full control you need and should have.

In preparation for that, at BlueWallet we implemented:

• CPFP — Bump transaction (child-pays-for-parent) — a technique that allows you to spend incoming transaction that is unconfirmed by sending it to your another address, but with the total fees higher than the original transaction. This helps if it takes forever for your incoming transaction to confirm on the blockchain.
• RBF — Bump transaction (replace-by-fee) — if you sent a transaction and it’s still unconfirmed you can replace it with the one with higher fees, making it more attractive for miners to mine, thus, speeding up the confirmation.
• RBF — Cancel transaction — a technique similar to regular RBF, but where the replacement transaction’s output is the address you control, thus, paying yourself, effectively cancelling the transaction.
• Batch send — when creating a transaction add as many payees as you want. This helps to save on fees when having to pay multiple destinations. Making a nice UI/UX on this one was a challenge.
• Flexible fees (starting from 1 sat per byte) and fee recommendations fetched from a real up-to-date bitcoin node.
• Finally, from now on, we are promoting BIP84 Native SegWit wallets as the default wallet when users create a new wallet. We were warned and actually advised against that, as that triggers a stream of complaints from users who can’t withdraw coins from exchanges because exchanges still don’t recognize ‘bc1……’ addresses. But it’s time. Really. Users should take their complaints to obsolete exchanges. Native segwit will allow saving on fees even more.

I like to repeat that BlueWallet is preparing for war, and this war will be for block space. Once another billion of Earth inhabitants realize the benefits of hard, censorship-resistant and non-confiscatable money.

If this is the kind of fight you want to be part of, protecting the Bitcoin user interests over miners and corporate players, you know where to go. And you are much welcomed!

That was not the only features we were busy with. Among many, some new and also remarkable features:

• Connect to your own Bitcoin Node through Electrum server for maximum self-sovereignty, no SPVs, full node fashion.
• Watch-only ZPUB wallets. Just scan the QR code with a ZPUB or input a ZPUB into the text field directly. XPUB and YPUB are supported as well.
• With recent transition to PSBT under the hood, we added a workflow to have your transaction signed on your hardware wallet in a pure air-gapped fashion. Just mark your watch-only ZPUB wallet as working with an external HW wallet, then create a transaction and feed the QR code with the unsigned PSBT to your hardware wallet. Sign it on hardware wallet, scan it back to BlueWallet and broadcast it to the network. You have just conveniently made a transaction on your mobile device, while keeping your private keys on a secure hardware wallet, truly air-gapped! This is still in beta and only the CryptoAdvance device is 100% supported, but we will work on testing and polishing the integration with other hardware wallets.

We still have a lot of work to do:

• Ongoing integration with HodlHodl. Non-custodial fiat-to-btc trading is an important bitcoin infrastructure project. It’s a hedge against all regulated exchanges going bad with AML/KYC.
• When LND will be stable enough we will include it as part of the wallet, allowing users to switch their lightning wallets into non-custodial mode, and gradually make it the default mode. But custodial lightning brought some unexpected benefits, such as practically unlimited incoming capacity, instant on, zero onchain footprint. It makes sense to maintain both and explore possible synergies here.
• Multisig wallets are hard to tackle, mostly UI/UX wise. A proper joining ceremony is a hard task to design. The ceremony of creating a transaction and inviting all participants to sign it, can also be a challenge.
• To reach maximum security, it makes sense to use only multisig wallets with all keys residing on your own devices, preferably hardware wallets from different manufacturers. Designing, implementing and testing this flow is not easy.
• Sign message with your wallet/verify. I strongly feel that your private keys should help you with authentication on 3rd-party services, but what’s the proper way to do that we do not know, yet.
• Provide-UTXO — when creating a transaction, supply UTXO to use in form of JSON document. This allows using the wallet on a completely offline/air-gapped device, provided you carry with you your up-to-date UTXO set. Then you sign it, broadcast via SMS/pigeons/whatever and congrats! You can transact even from a desert island.
• Choose UTXO / UTXO spend strategies — when creating a transaction, choose which UTXO (or UTXO strategy) you want to use. For example, you could strive for the smallest fees (use higher-value outputs first), optimize for amounts used (sum of input amounts are close to total output amounts — might produce dust output), or you could consolidate (use all available inputs — yes this completely destroys privacy but helps to prepare for a period of high fees) etc.
• Coinjoin — a proper coins mix service with other peers is tricky, but we might attempt it.
• RBF-Service. A trustless server that broadcasts your replacement transactions with higher fees if previous transaction wasn’t confirmed in a timeframe you specified. You can start with 1 sat/byte transaction and gradually increase fee until it’s confirmed in a reasonable time (with the smallest fee possible). Automatically. This is only an idea at the moment.
• NFC. Users will be able to ‘tap-to-share’ their receive address to other users, and other NFC-capable devices. This will eliminate the requirement for users to have to fiddle with their device’s display brightness, and having to move around their camera view in order to scan a QR Code. This feature will also be useful for our upcoming BTCPayServer integration.
• Push notifications have been set aside for too long, but they will be eventually done.

And some other more experimental consumer ideas that we are already sharing with the community and putting it out there. The list doesn’t end there, but one needs to keep some secrets as well :) Feel free to bring your ideas on!

Just some statistics of the year:

• 32 production releases
• 738 commits
• 27 contributors

A special thanks to all the contributors, you guys rock! 🤘

To summarize, we are preparing for war! It will be a war about block space, it will be a war about providing the users with the right tools to fight against corporate interests trying to take advantage of Bitcoin. Join us, we promise it won’t be a boring one!

https://github.com/bluewallet/bluewallet

Cheers!

Preparing for war — how was 2019 and a glimpse of the future was originally published in bluewallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Lightning-powered App (Lapp)? In general, this is any application which works with Lightning network. In our case, this is any web-page that can receive payments or pay you back (not only that but more on that later).

Since BlueWallet added Lightning integration, our users made thousands of payments, and we have some stats and insights to share (which we will in further blog posts), but for now, we want to bring closer users and real business. We want to make it easier for regular people to discover great goods and services, allow them to interact with Lapps, pay and get paid easily.

Its been one year since Lightning network mainnet launch, and it’s time to take it seriously.

Thus, the very first thing to meet & greet users on the Lapp Browser will be a Lapp Marketplace — a simple collection of Lapps worth of your attention.

How does it work?

In the essence, Lapp Browser is a webview that navigates to Lightning-enabled webpages. The webview has javascript code injected, which bridges user’s Lightning wallet with the Lapp, allowing a more smooth interaction. The interaction part itself can evolve a lot in the future to be and feel more native, more integrated, etc.

BlueWallet partially conforms to webln specification (which is still in early alpha), so any Lapp that implements that spec will integrate with the wallet more naturally. Ideally, paying and getting paid in Lapp will be within one button tap (not a hustle of switching between apps and copypasting bolt11 strings).

Why are we doing this?

There’s no way to know what the future of wallets will be.

Imagine a world where you have full control of your money. Bitcoin is the main currency online and offline. You open your wallet app where you are able to easily pay your bills, send money to your family, buy stuff online, topup your phone, etc.

This is the world we want to live in. And this experiment is a first step to start learning how can we build this on top of the Lightning Network.

Whats next

Lots of work to be done. At the moment very few Lapps implement webln spec. Although this spec is still in alpha stage, it feels like a way to go. For example, every Dapp supports web3 specs, so developers might want to build their next Lapp considering webln compatibility. Except for frictionless send and receive, this spec also drafts providing identity to Lapp (so Lapp can seamlessly create an account and authorize you; no personal information leaked though, only anonymous public key is shared), and also mechanisms to sign messages with your identity, and verify other people signatures. Please, give this spec some love.

Disclaimer

BlueWallet’s Lightning integration is custodial by default, but you can easily connect it with your own LND instance for the same experience (everything we do is opensource).

Be warned, there might be bugs (please report them). Actually, with this release we’ve hit a sort of “beta” jackpot: Lapp browser is in beta, Lightning integration is in beta, and BlueWallet itself is still in beta. Don’t use it for large amounts! Be reckless, but not too reckless.

Handy links

• https://bluewallet.io
• Our Lightning integration announcement
• A glimpse on the future
• Marketplace sources

BlueWallet introduces Lapp Browser and Lapp Marketplace was originally published in bluewallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

BlueWallet has just released support for the Lightning Network. Being a 2nd layer scaling solution, Lightning promises low-fees and instant payments. But as a drawback brings a lot of complexities and unfamiliarities to unsuspecting users.

Completely aligned with Bitcoin’s “be your own bank” for sovereign individuals, Lightning requires users to run their own Lightning nodes (besides their own Bitcoin node), open and manage state channels with other nodes (this is what makes a network), maintain liquidity (both incoming and outgoing) in channels, and basically, do a hard ‘node operator’ work. This is the cost of independence from financial institutions.

Our approach to Lightning is different.

We decided to hide the complexity of running a node under the hood and take over the work of hub operator.

This makes the user experience smooth, bringing Lightning payments to anyone who is at least remotely acquainted with cryptocurrencies and mobile wallets.

We called it LndHub, an opensource wrapper around LND. This is “3rd layer solution” (as we jokingly call it; of course this is not real 3rd layer).

This is how it works: the user sends his bitcoins to a dedicated top-up address, and this balance is added to his account on LndHub. Then, the user can use this balance to pay Lightning invoices. But under the hood, it’s actually LndHub who pays the invoice, deducting the user’s account balance. It works the same way when the user wants to receive a Lightning payment — it’s LndHub who creates Lightning invoice and actually receives coins on one of its channels.

This has its drawbacks. Basically, user transfers his funds in custody to a 3rd party (and we all know that trusted 3rd parties are security holes, thanks to Nick Szabo). But how much of a problem is that? Let’s think a bit about it. Trust is minimized to an absolute minimum required to carry its duties. On the other hand, Lightning is expected for day-to-day use, and how much the average user usually has in his pocket for daily expenses? Probably, $50 for groceries and coffee? A fair tradeoff risking those for an exchange of usability.

Of course, on-chain Bitcoins private keys should be in full user’s control. Not your keys — not your coins, as they say. We are thinking of it as “savings” account (as opposed to Lightning — “current” account).

Other drawbacks include centralisation of the network. Given lots of users start using LndHub, amount of funds and liquidity it holds will also grow, turning LndHub into a major Hub on the network. This was anticipated in the dawn of Lightning development, and we don’t see a problem with that. Network still remains open, and is free to morph and mutate as per current economic reality.

Luckily, LndHub is completely opensource, which means any tech-savvy user can deploy his own instance of LndHub and use it with his wallet. This instance can even be shared with the party, such as friends and family: each member will have his own independent balance and transaction history. Should be pretty convenient for someone to onboard more people to the Lightning party. Just install lnd, bitcoind, lndhub and in your wallet settings put a link to your hub. Share the link with your friends and help them config their wallets. Done!

This also mitigates effects of hub centralization, letting the user maintain control over his on-chain and off-chain funds.

To sum this up, here’s a quick pros and cons list:

Pros:

• Improves user experience, allowing to onboard more users
• Completely removes technicalities, like opening and maintaining channels and liquidity (both incoming and outgoing)t
• Improves chances of successful payment routing
• Receiving payments is a breeze (lndhub and lnd are 100% online, no need for Watchtowers)
• Single LndHub (if self-hosted) can help share lightning experience with many users (think friends and family)

Cons:

• Funds are held by a 3rd party (but only small amounts for everyday use). Mitigated by opensourcing LndHub.
• Minor network centralization
• Less private. Hub operator knows who paid whom. Luckily, trust is minimized as Hub doesn’t know who is on sending and who is on receiving end, and what is being paid for. And again, LndHub is opensource for people needing extra privacy.

What next?

You can give it a try with BlueWallet mobile app (iOS and Android), check out code for LndHub or BlueWallet (both are opensource and MIT licensed), and let us know what you think! Of course, there might be bugs, so be careful and please report them. LndHub API spec is also open, so you can build your own product on top of it.

For bonus cypherpunk points you can build wallet binaries yourself and plugnplay your own bitcoind/lnd/lndhub!

Handy links

• http://lndhub.io
• http://lndhub.io/about
• https://bluewallet.io
• https://itunes.apple.com/us/app/bluewallet-bitcoin-wallet/id1376878040
• https://play.google.com/store/apps/details?id=io.bluewallet.bluewallet
• https://github.com/BlueWallet/lndhub
• https://github.com/BlueWallet/Bluewallet

BlueWallet brings zero-configuration Lightning payments to iOS and Android was originally published in bluewallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article we will study what is Replace-By-Fee transactions and how to use them. Surprise, with RBF you can try to do doublespends!

Imagine situation when Alice sends coins to Bob. She creates and signs the transaction, and broadcasts it to the network for confirmation. Unfortunately, the transaction hangs unconfirmed for a long time, as it has low fee (or an ok fee under other circumstances, but at this point of time unconfirmed transactions queue is too big and miners prefer transactions with higher fees). What can Alice do? Her options: a) wait for a confirmation (might take a while) b) wait till transaction gets cancelled (most miners will exclude it from mempool) and freed coins would be spendable again (i.e. create transactions using those coins and most pools won’t reject it as doublespend, as old transaction got cleared from mempool) c) replace transaction, increasing the fee (RBF).

Thus, RBF — replace of existing transaction with a new one, increasing the fee. “Replace” means that new transaction will use same inputs (i.e. coins) as old one, and this would not be considered as doublespend (i.e. cheating). As result, only one transaction will be confirmed, mined and added to blockchain (most probably the one with higher fee).

RBF was introduced in BIP-0125

But kind of transaction is potentially replaceable? Good question. Transaction replacement was introduced by the Bitcoin designer himself Satoshi Nakamoto, but disabled at some point. It was then improved/upgraded to RBF and shipped in Bitcoin Core 0.12+. For replaceability, there’s a designated int field called nSequence, which signals which transaction is an older version and which one is younger. So, for the transaction to be replaceable nSequence should be lower than MAX (0xffffffff — 1). By default, most wallets set nSequence to maximum and you have to manually enable transactions replacement ability in settings. Here’s how it looks in Electrum:

An example of decoded transaction:

... 
"inputs": [ 
    { 
       "addresses": [ "...." ], 
       "output_index": 0, 
       "output_value": 1010000, 
       "prev_hash": "...", 
       "script": "...", 
       "script_type": 
       "pay-to-pubkey-hash", 
       "sequence": 0 
    }, 
...

Sequence is indicated for each transaction input.

In Electrum after you enable RBF you’ll be able to increase transaction fee right in GUI. Right click the transaction and you’ll see it. But now we are going to manually create RBF transaction. Why? First of all, to better understand what’s going on. Second, for more versatility. In case of manual RBF we can specify totally different destination addresses, which can be considered a doublespend.

This is how it works. Alice wants to pay Bob for goods. Alice creates, signs and broadcasts transaction (which transfers coins to Bob), but intentionally sets low (or zero) fee. If Bob is not cautious enough he accepts unconfirmed transaction as payment and sends goods to Alice. After that Alice replaces the transaction with output addresses which Alice controls. Basically, Alice returns her funds. Bob got scammed. How can Bob avoid that? First, if Bob wants to accept unconfirmed transactions (for speed), don’t accept replaceable transactions (where nSequence is lower than MAX). Of course, ideal case when Bob waits for enough confirmations.

Now let’s try to do an RBF with doublespend.

This is a real live example that can be verified on blockchain.

We shall use neat opensource tool github.com/OutCast3k/coinbin which can create transactions with arbitrary inputs and outputs. It works almost completely inside browser tab without server interaction. Live version is available on coinb.in but you are encouraged to download it and run from localhost.

Let’s create New → Transaction. Get a private key in WIF format and load unspent outs for that key. In Outputs tab set destination address, set amount. In Advanced Options dont forget to tick “Make this a RBF transaction” — in that case, nSequence won’t be set to MAX. Click Submit.

Transaction is created. Note the Transaction Fee — it’s the difference between sum of available coins (inputs) and sum of all sent coins (outputs). This difference is a miner fee, and it’s set to zero in this example. Click Sign, copypaste the transaction hex, same private key and finally sign the transaction:

Broadcast the transaction (you can use any endpoint):

This is how the transaction looks:

Now, let’s use RBF. Create new transaction, and take outs from the same WIF. Let’s specify totally different destination address! One of the destinations we are going to set to 1CWHWkTWaq1K5hevimJia3cyinQsrgXUvg — this is donate address of coinb.in creator. Set the Amount so the fee is significant for miner for a quick confirmation.

Note the Inputs tab — if the source wallet was used multiple times and has lots of transactions, we would have to manually specify only inputs we used in transaction we are going to replace (basically remove all other inputs and leave only the ones we need).If we have hundreds of inputs that might be quite a tedious work.

Sign it:

Broadcast:

This is how it looks now on blockchain.info. New transaction has all chances to be included in block before the ancestor.

Wait. Got a confirmation:

We have just replaced transaction using RBF, notoriously, we sent the coins to a different from original destination address.

A few words about security and doublespends

Not always nSequence=MAX guarantees that transaction is final and can’t be replaced. You could try NOT ticking “Make this a RBF transaction”, but:

• Not all nodes will agree to relay the new tx version, referring to mempool-conflict
• Some nodes will accept this transaction
• Websites like blockchain.info will basically scream that this is a DOUBLE SPEND
• Not all pools will mine this new transaction, as it is a doublespend. Some pools will mine it, but it might take more time (comparing to when all pools mine your transaction)
• If new transaction is finally included in block — this is absolutely legit and does not contradict to consensus rules. If someone got scammed this way — there’s no place he can complain about it.

Thus, we come to a conclusion that any transaction without at least two confirmations is unreliable. Why two, not one? Short answer: orphaned blocks.

References:

• github.com/bitcoin/bips/blob/master/bip-0125.mediawiki — BIP-0125
• github.com/OutCast3k/coinbin — Sources coinb.in
• en.bitcoin.it/wiki/Transaction_broadcasting — list of endpoints, some might accept doublespend transactions.

Bonus!

Real life story. Once upon a time a website using our bitcoin payment gateway got hacked, and hacker requested a 2 BTC payout from gateway. Gateway at that time had hardcoded low fee (0.0001), so hacker’s transaction got stuck unconfirmed. It gave us enough time to study the situation, and replace the transaction with different (our’s) destination address. We increased the fee to 0.1 to speed up. Hacker got nothing. Lesson — use RBF to do good!

Real life story 2. I was refilling bitmedia.io acount with bitcoin. Account refill there works with depositing to same deposit address, and total amount of user’s balance gets summed up of all incoming to that address transactions. Only 6 confirmation transactions are counted. I wanted to top up faster, so I used RBF several times. When the transaction got finally confirmed, the final credited balance was multiplied by the times I used RBF! I instantly submitted a support ticket, and as a bug bounty I got to keep extra 0.3 BTC. Lesson — check how your systems behave with RBF! I wonder how many systems in the wild are vulnerable to this…

Originally published at habrahabr.ru.