Two factor Recovery, sending to bech32 & updates

Two Factor Authentication Recovery

We would like to update the community on new improvements and features we have added to GreenAddress. Previously, we blogged about the new long term two factor recovery procedure we were planning to implement, so users who have lost the ability to access their bitcoins can now recover them. This recovery procedure is now implemented and available on the desktop and Android versions of our software. Our Terms of Service is also updated in preparation for the CSV changes coming soon, and to clarify the details of the recovery procedure. We would like to thank everyone for their patience as we worked to provide a method to recover lost access.

Updated Desktop App

In addition to implementing the new recovery procedure, we have ported the GreenAddress Chrome application as an interim step as we move focus towards building on more native frameworks. The new desktop application is based on libwally, our libsecp256k1-based wallet library. It also fully supports hardware wallets like the Trezor One and Ledger Nano S, with support planned for other hardware wallets.  

Although we are deprecating the Chrome application and our Web Wallet, they are still usable for the time being. Note that the Chrome application and Web Wallet will not be updated in the future and will eventually be removed in the coming months, so we strongly encourage migrating to the desktop application or smartphone apps.

Updates & Bug Fixes

Updates and bug fixes include the following:

  • Added support for sending to native SegWit addresses (bech32)
  • Added support for the new two factor reset and dispute procedure
  • Fixes and improvements related to BIP 70
  • System messages are now shown to the user on startup
  • Various improvements to hardware wallet support

Android specific updates and fixes include:

  • Moving to the latest Android SDK
  • UI and notification updates for Oreo
  • Removing support for pre-KitKat devices
  • Updated SPV checkpoints
  • Removing support for dead Android platforms (e.g. MIPS)

Improving Recovery & Trustlessness

As we noted in our previous blog post, we will be taking advantage of CSV (CHECKSEQUENCEVERIFY), a feature in Bitcoin that allows us to greatly improve recoverability for GreenAddress users. Support for this feature will be included in future GreenAddress releases.

CSV will allow us to do the following:

  • Make recovery processing completely trustless and atomic
  • Remove the need for nLockTime files
  • Remove the need for an email address for nLockTime notifications
  • Have all newly generated addresses in wallets automatically be able to be recovered
  • Minimize trust requirements in GreenAddress

The biggest improvement CSV enables is reducing the amount of trust users have to place in GreenAddress. With CSV, users will no longer have to worry about GreenAddress shutting down nor will they have to trust GreenAddress to provide out of band nLockTime transactions.

We will continue to provide more information as the deployment time approaches. We are very excited about the improvements to our user experience that CSV will bring!

New Native iOS App and GreenAddress Development Kit

We are also excited to announce a new native iOS app which will include an updated and rebranded UI, and will be based on our new GreenAddress Development Kit (GDK). The GDK is based on libwally and provides a high-level coding interface for anyone that wants to access GreenAddress programmatically. Along with CSV implementation updates, we will provide more information on the new iOS app and GDK as their respective release times approach.


We appreciate you taking the time to read this announcement. We would like to remind users again to enable a second two factor method as a backup if they currently only have a single method enabled. As always, we are busy working on other new features and enhancements to the platform, and will update the community about them in the future.

If you have questions or comments, you can reach us at


Lawrence and the GreenAddress Team

picture of a safe with a time lock

Two Factor Authentication Recovery


We’d like to update you on our progress with enabling two factor resets for users who have lost access to their second factor authentication. For those affected, we are happy to announce that we will be enabling access to your coins following the procedure outlined below. We would like to thank everyone for their patience while we worked through providing a solution to this issue. Please take care to read this information carefully to ensure you understand how the procedure will work.

Terms Of Service

We will be refreshing our Terms Of Service at to clarify the details of the reset procedure. We’ll announce this update separately here and via the usual channels.

Eligible Users

The reset procedure applies to users that have their mnemonic available but do not have access to any two factor authentication method. If you have lost your mnemonic then GreenAddress does not have the technical means to recover your wallet, therefore the recovery procedure cannot be used to help you.

If your mnemonic has been made public, or someone else has access to it and disputes the recovery process, then the reset procedure cannot be carried out and you will need to contact support.

Reset Procedure

The short summary is that we will be allowing users to access their coins by requesting a two factor reset from within the wallet, which will enable access after a grace period.

Please note: at no point will we require the user’s mnemonic, and you should not give them to anyone who asks, including support.

We will release new wallet versions with support for the reset procedure in the coming months. Once you are logged in to the wallet, you can request a two factor reset from the settings menu. You must provide an email address for use as recovery two factor authentication and upon which we can contact you in case of any issue throughout the grace period.  Note that this applies even if you already have an email setup in the wallet. The email address can be an anonymous email account if you wish, but you must ensure it is one that is secure and readable only by you. If you lose access to the email you use for recovery, you risk having to restart the 2FA reset process from scratch. Note: do not use a disposable email address, or one that is readable by anyone such as those provided by or others maybe able to interfere with your reset process.

After requesting a reset, your wallet will become read-only, and whenever you login a warning will be displayed, showing you that the reset process is underway.

You must then wait for the grace period to expire. The period starts from the later date of a) when the reset was requested or b) the send or receive date of the last transaction in your wallet. The exact duration of the grace period will be announced with the release of our wallet upgrade, but it will be at least 12 months (one year) long.

The wallet will also allow you to dispute a reset during the grace period using the settings menu. In the event of a dispute, the reset process will be blocked and you should contact support for more information.

Once the grace period expires without dispute, the recovery email you provided will become your wallet’s email two factor authentication method. At this point you can access your coins as you normally would. We recommend then enabling additional 2FA methods and securely backing them up. You can then optionally remove the email 2FA method.

Example recovery scenarios:

Mnemonic Last received (or spent with change) Nlocktime setting Recovery
User Bob Yes 100 days ago Default 12960 (~90 days worth of blocks) Grace Period Only (As there is no nlocktime left)
User Matt Yes Today 1440 (~10 days) Grace Period + 10 days (nlocktime left)
User Frank Yes 365 days ago 144000 ( ~ 1000 days) Grace Period + (1000 – 365) days (nlocktime left)
User Jeff No N/A N/A Not possible as we don’t ever have a copy of the mnemonic.

Recovery In The Future

In the near future we will be taking advantage of a Bitcoin feature known as Check Sequence Verify/CSV.

This will allow us to:

– Make recovery processing completely trustless and atomic
– Remove the need for nlocktime files
– Remove the need for an email address for nlocktime notifications
– Have all newly generated addresses in wallets to automatically have the ability to be recovered

Once CSV support is complete and thoroughly tested by our team, we will be enabling it by default for everyone. We will provide more information as the deployment time approaches. We are very excited about the improvements to our user experience that CSV will bring!


Thanks for taking the time to read this announcement. We would like to remind users with only a single two factor method currently enabled to enable a second method as a backup. We are busy working on other new features and enhancements to the platform too, and will post about them in the near future.

As always, if you have questions or comments you can reach us at


Lawrence and the GreenAddress Team

Segregated Witness & Updates


It’s been a very busy few months for us, and certainly an exciting few months in the Bitcoin ecosystem!
We’d like to update you on what’s been happening here at GreenAddress and what’s in store in the future.

This is a long post, but we suggest you read it very carefully. As always, if you have any questions feel free to contact us at


We are happy to announce that we have grown the team with two new developers joining us to work on the platform. We should be able to work through our huge list of enhancements and updates much faster with the extra brain power on board. Welcome to the team! We look forward to implementing more features even faster going forward.


We recently moved to a new support system which makes it easier for us to track and quickly respond to support requests via our support email Although the number of support queries we get has been steadily increasing, our response time has been reduced, and we hope to improve  it even further going forward. Our FAQ at has also seen some updates to respond to the most common questions from our users.

We’d like to remind users to ensure they have at least two two-factor authentication methods enabled! If you lose access to one method you will then be able to use the other(s). If you lose two-factor access we can’t help you restore it so please be sure to back up your Google authenticator seeds and verify that the methods set up are still accessible.

We’d also like to remind users to make a backup of their mnemonics, if you lose them we cannot help you get them back.


We have supported segwit in our testnet environment for a long time now, and with segwit locked in on the main chain, we have deployed the changes needed to enable this to the main service. When you next log in to your wallet you will be upgraded to segwit and offered the chance to opt-out. If you don’t see the upgrade prompt, your client is too old and you will need to update it. Once segwit is enabled on your account and you have generated at least one receive address, it will be locked in and you will no longer be able to disable it.

Segwit is fully backwards compatible with the rest of the ecosystem, you should notice no differences with segwit enabled except cheaper fees.

Our testing shows that segwit fees are around half the cost of the equivalent non-segwit transaction. Lower fees kick in once you start spending segwit inputs, so for most users it will take a few transactions before you see the full effects. As the rest of the ecosystem updates we expect block pressure to reduce which may also lower fees further.

We strongly recommend that all users upgrade their wallet apps to the latest available versions to pick up recent updates and fixes and to ensure your transaction fees are as low as possible. Also we suggest that users get into the habit of checking their fees before sending transactions. When fees are high you can often save money by delaying transactions to quieter times like late at night and the weekend.


Our previous recovery tool Gentle was getting long in the tooth and did not support segwit along with other features that we wanted to add. We are happy to announce our replacement recovery tool “garecovery” has completed internal testing and is now available at garecovery has support for segwit as well as now supporting 2of3 wallets, and can be run on testnet for users who wish to validate or experiment with the recovery process.

We plan to improve garecovery even further in the future, for example to improve the privacy impact of recovering inputs sent to the same address. We welcome your input on improvements and features you would like to see in the future.

Bitcoin Cash

We have had requests from some users to enable splitting of Bitcoin Cash from the wallet. Our statement ( on the fork was posted before the split in order to allow users to move their funds to split themselves, but unfortunately not all users did so at that time.

At GreenAddress we believe in putting the user in control of their coins, and we recognize that there is demand to withdraw bitcoin cash from the service. We investigated the options open to us and have settled upon providing API support for signing the GreenAddress side of bitcoin cash transactions for users to allow them to split manually. Developers can see the API documentation for the call vault.sign_alt_tx at for more information.

Please note that this call respects the wallets two-factor settings and will only sign with the bcash fork id replay protection mechanism, and only with keys under the user’s GreenAddress path.

We do not provide tools or support for the splitting process beyond providing the API call. In particular we will not be providing a split tool or making any changes to our wallets to support bitcoin cash at all. As there is already at least one community provided tool to split 2of3 accounts, it is now possible a tool for 2of2 will be developed too. We urge all users to be careful about third party services to split coins and remind you that maintaining the security of your mnemonics and two factor is your sole responsibility.

Users should not expect that future splits or altcoin air-drops will be supported, in line with our previous statements on contentious hard forks here:

API Examples

We have a new repository of simple python examples using the GreenAddress API to talk to the service at We will be updating the API documentation to refer to these and adding more examples as time permits.

Pricing Sources

The seizure of BTC-E has made them unavailable as a pricing source. We have updated all wallets that were using it to use BTCAVG instead. If you had a spending limit setup in fiat and were using BTC-E, we have reset your limit to zero as part of this change. If you would like to use another source, you can change this (and update your spending limits) in the settings of all of our wallets.

For our New Zealand users, we are also happy to now support Kiwi-Coin ( as an NZD pricing source in addition to Local Bitcoin.


GreenBits has recently been updated with a variety of changes including UI updates, transaction limits, improved RBF and more validation to ensure users have backed up their mnemonics and are using the correct PIN. We hope these changes will result in more users taking all of the required steps to maintain access to their coins in the event of device loss.

Our Cordova and CRX wallets have also been updated with bug fixes, improved fees and better segwit support.

Finally, we have a native iOS wallet in development which will provide a better native experience for iPhone users. We will announce more details as development progresses.

Longer Term

We are working on updating the Cordova/JavaScript clients to share more code with the rest of our code base. This should result in a faster and more smooth experience for users with new features rolling out on all our wallets simultaneously.

For system integrators, we are developing a higher level API abstraction which will handle many of the low level details such as transaction construction on behalf of users. This will make it much easier to integrate with us for users providing services backed by GreenAddress and for developers to automate wallet workflows.

We will shortly begin development work on using CSV to replace nlocktime emails. This change will allow recovery of 2of2 funds without needing to receive or store nlocktime zip files and make recovery for lost two factor much easier.

We will have more to share in the near term as things progress. For now, we hope you enjoy the new features and remind you that you can keep updated/contact us via:

– Our website at
– reddit at
– Twitter at
– Email at (PGP keys for sensitive email are at

Thanks for using GreenAddress, we appreciate your support and hope you continue to enjoy the service.

Lawrence and the GreenAddress team

Announcement regarding BIP148/BIP91 SegWit soft fork upgrade and enforcement

How is GreenAddress handling the BIP91/BIP148 soft fork?

BIP91 (see has now been activated by a large majority of miners. This means that miners are now signaling to activate Segregated Witness (also known as segwit or BIP141, see

If BIP91 is enforced by a majority of miners as expected, they will ignore blocks that are not signaling segwit. This will have the effect of activating Segregated Witness on the main Bitcoin chain.

In order to ensure that the service is not affected by any miners that do not enforce BIP91, we are now enforcing BIP91 on our service nodes. This means we are only considering blocks that signal segwit as valid. This aligns the service with the majority of miners and prevents us from processing blocks that are likely to be orphaned/reorganized out of the blockchain. This in turn should prevent our users from being misled or confused by transactions and/or confirmations that would later disappear.

Enforcing BIP91 in this manner is compatible with the User Activated Soft Fork (i.e. UASF, also known as BIP148, see As things currently stand we do not foresee any issues or long lasting split arising from BIP148 activating on August 1st.

Users of our Android app GreenBits can configure it to point to their own node to independently verify validity of confirmations.                      

Will GreenAddress support a hard fork? How can I spend coins on a hard fork chain?

As of today there hasn’t been any hard fork proposal that has gathered consensus. A hardfork is something that anyone can do at any time and it is infeasible for companies and developers to have reasonable support for proposals that are contentious. We do not currently plan to support a specific hard fork at this time.

If you wish to be able to spend coins on a chain that clones the Bitcoin ledger, we advise that you move your coins from GreenAddress to a wallet that will allow you to split your coins safely. Coins that are held in GreenAddress may not be able to be split, and transactions that occur on GreenAddress may be replayed on the forked chain. If you do not care about forked chains, or you believe a given fork will not last, then you can simply ignore the hard fork. Your coins on the main Bitcoin chain will remain valid and spendable there as usual.

Please note that we cannot provide support services for users who wish to split coins outside of GreenAddress, and we do not plan to develop split support for coins in GreenAddress wallets even if the forked chain coins should survive or rise in value.

We have a position statement on contentious forks which you can read at

What about Bitcoin Cash/Bitcoin ABC/Segwit2X support?

See the above question on hard fork support.

What about normal Segwit support? Can I create segwit transactions once it activates?

We support segwit and will enable this functionality as an opt-out option for users after it is fully activated and our testing of the features is complete. We will announce this before we enable the functionality along with instructions on how to opt-out if you wish. If you would like to test segwit integration or how our wallets work with segwit, you can use our testnet service which is already segwit enabled.


As always, if you have any questions, please feel free to contact us at

Lawrence Nahum
GreenAddress Lead
Senior Architect @ Blockstream

GreenAddress’ position on contentious forks

Dear GreenAddress users,

Recently there has been considerable discussion and speculation concerning the possibility of a contentious fork to the Bitcoin blockchain.

At this time, we remain confident such a fork will not occur. We trust that the incentives of the system continue to operate as expected and encourage participants to play by the Bitcoin consensus rules.


However, if such a situation were to unfold, GreenAddress users need not to worry. We will always provide safe wallet support  for Bitcoin under the original chain rules, as GreenAddress is server based and follows Bitcoin’s consensus rules. Users do not need to take any particular action at this time.

To better understand the principles guiding us, we wish to emphasize our vision for Bitcoin and what drives us everyday to create infrastructure that we hope can help further its adoption.

We strongly believe that the critical properties of decentralization, censorship resistance, privacy and trustlessness must not just be maintained, but enhanced further while the technology behind and around Bitcoin is scaled up to serve the whole world.

We support this technology because it enables voluntary actions and makes coercive behaviours ineffective. We think it is superior to existing alternatives because it allows us to verify rather than trust. Bitcoin uses the most work valid chain, and economic actors collectively follow rules set by the software they run. Accordingly, our focus is and will always remain to build products and advocate for solutions that put you, the user, in control.

GreenAddress does not support contentious hard forks that risk disenfranchising users, irrespective of hashing power. We believe that such an outcome would create an irreparable precedent that would severely undermine social trust in Bitcoin and potentially set it back for years to come. We will only consider proposals that demonstrate the support of the majority of users, developers and industry partners in the Bitcoin ecosystem.

We strongly favor protocol upgrades that guarantee backwards-compatibility and allow users to opt-in to new features without the threat of coercion. In that regard, soft forks are widely regarded as the most secure and reliable way to implement Bitcoin upgrades. The robustness of this method is shown by years of experience with Bitcoin itself as well as a great deal of technical analysis. We encourage you to consult the links below for further information.


We would like to take the occasion to remind that on top of normal wallet withdrawal our recovery model also always permits user Bitcoin recovery. This means that you can access  your bitcoins even independently of the service being available. For more information on GreenAddress recovery measures please see our FAQ

Additionally, our GreenBits wallet app for Android allows you to directly connect to your own full node for extra validation of the information provided by the service. We aim to roll out this extra security (and more) to all of our wallet clients in the near future.

For further reading on considerations for hard fork proposals, see  recent posts from fellow industry members, BitGo and Bitrated.

As always, if you have any questions, please feel free to contact us at

Lawrence Nahum
GreenAddress Lead
Senior Architect @ Blockstream

Announcing Blockstream’s GreenAddress acquisition

Dear GreenAddress User,

Today, we have some exciting news. We are proud to announce that we are joining forces with Blockstream, a leader in open source blockchain technology.

For the last two years we have worked hard to bring you a user friendly, innovative, and safe bitcoin wallet. We couldn’t have come this far without you. No worries! Your wallet will continue to operate, and, as always: your funds are safe by design. We are grateful for your support and feedback. From the bottom of our hearts, thank you!

Many of you know that GreenAddress was one of the first bitcoin wallets to deliver features like HD multisig, hardware wallet support, dynamic fees, and transaction replacement. Now, with the expertise, experience, and resources of Blockstream, we will continue improving GreenAddress. Our goal is to remain at the forefront of innovation and deliver new improvements to our users.

Here’s a preview of upcoming improvements we are working on: a multi-platform wallet library to enable more rapid development of all platforms, enhanced privacy and security, and of course sidechain support throughout the platform. Extending GreenAddress to work with sidechains will mean you, as a GreenAddress user, will have the ability to manage not only bitcoin, but other assets and features that are coming online over the next months and years ahead as Blockstream and other developers establish new sidechain-based networks.

You could already experience the benefits of our collaboration with Blockstream: out of it came the novel and trustless nLockTime backup feature. Many other improvements are yet to come as a product of very exciting discussions we already had! We are extremely excited to solidify this relationship and continue evolving the space to the benefit of you and all our other valued users.

If you have any questions, please feel free to reach me at


Wishing you all the best,


Why Replace by Fee is Good for Bitcoin

tldr The reason we started GreenAddress was to provide a way of third party assured, zero-conf transactions: our customers have enjoyed since the service was launched.  RBF means these transactions won’t get stuck, and their bitcoin experience will be even smoother, even in the case of massive usage spikes.  For us and our customers, there is no downside, and only upside to this change, so of course we support it!
First, what is replace by fee (RBF)?

The short answer is that RBF is a mechanism to update a transaction that is not getting confirmed by miners because its fee is too low – the idea is to increase the fee to give miners an incentive to mine it.

The idea of RBF is quite simple, yet the topic is undoubtedly controversial as it makes something unreliably unreliable (and insecure) like zero-conf transactions reliably unreliable.

We have been advocating for RBF since as early as April 2014: the first time we publicly discussed RBF was when BitUndo was announced and when Peter Todd suggested miners should implement it. The reason we support RBF is simple:  transactions are constantly getting stuck (especially as blocks get fuller and fuller) and even if you use the state of art in terms of fee estimation, predicting spikes is unreliable at best. Inevitably, unconfirmed transactions for hours or even days will occur, which is incredibly frustrating for bitcoin users.

We think RBF is inevitable and can’t be prevented, as it is not a consensus rule but a mere mining policy: miners can decide at any point in time to support RBF (just like they can decide to mine an empty block) without any need for anyone to agree. This makes accepting zero-conf an especially risky business as miners have a strong economic incentive to support RBF (increased fees!) and some have been known to take advantage of their position in the past.

RBF and vandalism?

Many have been saying that RBF (also known as Full RBF) is vandalism, as it breaks some unsupportable use cases by making them reliably unreliable. This is true to a certain extent; however, we always believed that one should always think adversarially and avoid relying on zero-conf, because if something can go wrong it inevitably will. We are also worried that perceived  tacit consent of zero-conf would lead to an increase of adoption, which once attacked could be disastrous to the Bitcoin industry as a whole.

How many types of RBF exist?

There’s three types of RBF that have been largely discussed in the last few years:

  • Full RBF (most controversial)
  • First Seen Safe RBF (bad user experience or bad privacy)
  • Opt in RBF (best of both worlds)

We already discussed Full RBF above so we’ll talk about the other two now.

First Seen Safe RBF (FSS RBF) is a way to support RBF without the  perception of vandalism: allow people to update stuck transaction, but without the ability to change or remove any of the inputs and outputs. Users are only allowed to add new inputs to increase the fee (and new outputs as necessary).

While this sounds great, in practice it is quite bad because every FSS RBF update increases the amount of coins stuck and always requires users to have multiple unspent transaction outputs (UTXOs), but a large part of users have only one (and even if they had more, they wouldn’t want to tie up more and more of them as they attempt to update a transaction fee). Unfortunately, we can’t increase the fee by decreasing the change amount as miners have no idea which output(s) are change. While users could let miners know by flagging the change this, would be an incredibly reckless idea as it would harm privacy for all participants in the space – even when RBF is not used.

Welcome Opt In RBF

Screen Shot 2015-12-09 at 10.22.11

Recently Bitcoin Core has merged Opt-in RBF, which will be part of the 0.12 release scheduled to be released in the upcoming months. What is it? It’s a way to make RBF opt in, that is, transactions will have to be flagged in order for RBF updates to work (using an unused field in transactions called nSequence). This way, recipients can instantly detect the transaction is updatable (just like they can currently detect a fee being too low for a timely confirmation).

Merchants and payment processors don’t need to make more changes that they would normally do during normal updates to things like minimum relay fee or dust amounts in order to handle opt-in RBF.

This is great right? Indeed it is, best of both worlds, yet it is still quite misunderstood. Luckily, a great FAQ has been worked on by the community, which should clarify any doubt left.

GreenAddress’ users have been enjoying third party trust instant transaction for a long time now, which has allowed people to hold their own Bitcoin. By using supported exchanges like The Rock Trading they retain the ability to trade fast without waiting for confirmation.

With RBF this is even better, as it allows to more aggressively reduce fees and have better confirmations speed guarantees.

One last important point to make is that opt in RBF doesn’t actually prevent Full RBF – miners can still decide to adopt Full RBF, so people should be very careful when accepting zero-conf regardless. The practice should never be encouraged.

Phasing Out Third party trust

In the long term assurance based on third party trust is not great because you are trusting someone and it is possible for that trust to be broken, willingly or not. Lightning is posing to be the superior mechanism for instant confirmation without the need to trust anyone. We intend to support Lightning in the future and believe that RBF will be extremely important for maintaining the trustlessness of Lightning (as you need to be able to update the fee for transactions timing out from lightning peers).

Scaling Bitcoin is Political

“What is the right maximum blocksize?”

This question is impossible to answer. There is no “right” blocksize, and everyone will have to lobby for their vision of the network.

However, in order to actually persuade anyone of your position, you need to enumerate your end goals and take a critical look at what this will mean for the decentralized nature of the network. This post delves into why this is such a tough problem, and why naive scaling is not a silver bullet even under optimistic conditions. Scaling Bitcoin in this way is a game of getting things “just right”: not too cold, and not too hot.

Bitcoin Today (Too cold!)

There is no argument that the 1MB block size was arbitrarily chosen and painfully small. Originally this was instituted to prevent DoS attacks against the network. The roughly 3.5 transactions per second this allows means that we have a total capacity of 110 million transactions per year, with a blockchain growth cap of 52.56GB a year.

Depicted: Bitcoin network versus VISA

This means that if we only count on-chain transactions as “Bitcoin”, 1.6% of people on planet earth could make a single transaction a year. If we stick to a Lightning Network-style payment channel setup, this means that 0.8% of humanity could get hub-and-spoke payment channels each year in today’s blocks. Even this relegates the Bitcoin network as a settlement network for banks and large financial players.

On the other hand, running a full node today is utterly trivial with a modern computer and internet connection, and SPV nodes appear to be well provisioned on less than 6,500 listening full nodes. Anyone who chooses to do so can run a full node and enjoy the full security of the network. As computing technology advances, it is quite likely that a 1MB cap could be trivially run on a budget smartphone. If you are an interested banker at least.

C’mon, Just Scale It! (Too hot!)

To most, 1MB forever is too small to really hit any sort of network effect they desire. If we want to improve this, why don’t we just increase the blocksize and scale it up until we really make an impact?

Let’s say we just want all people on planet earth to be able to make two transactions a year on-chain. That would require roughly 126MB blocks, with a theoretical maximum blockchain growth of 6.7TB a year. Scaling it even further, it gets apparent that running a full node will become a serious affair. If we want all humans to be able to make two transactions a day on-chain for paying bills, groceries, and coffee, we come to the massive blocksize of nearly 46GB. Running a full archive node will take 2.4PB of storage per year.

Even if we trimmed the low-hanging fruit to improve node performance and stuck with the first scaling scenario, no longer would running a node be a trivial exercise, but one that would take a serious amount of effort and resources maintain. There is clearly a trade-off on ability to interact directly with the blockchain via transactions and the ability to participate in the validation of the network itself. Most importantly, growing the block size too fast could result in catastrophic centralization of the network, resulting in a few stakeholders counterfeiting and controlling policy at will.

Network Health Today

Bitcoin the network is not as decentralized as we would like.

It is uncommon for even Bitcoin enthusiasts to run a full node, when they understand the security shortcomings of SPV and thin wallets. Some of the most popular wallets in the space are hosted, poorly-reviewed javascript web-wallets that promise you they aren’t lying to you about what the code contains, as well as about the state of the blockchain itself. Anyone who is not running a full node will naturally find it easier to simply increase the blocksize than those who are bearing the actual cost of bandwidth and storage. It’s fortunate that today’s small block sizes mean that even in this environment, SPV nodes are being serviced and an enthusiast can start up a full node just because they feel like doing so on a old laptop.

More worryingly, Bitcoin businesses that need wallet services are being publicly encouraged by unauthenticated blockchain indexing services to not run a full node. If we can’t even convince organizations that need the security protection the most  to run full nodes when the blockchain is quite small, this casts doubt on the viability of expansive changes to the protocol.

The mining industry seems equally as dire. A vast majority of pooled miners hand over their entire hashing “vote” to the control of the pool itself, or simply throw their bits to cloud mining operators who are more likely than not some form of Ponzi.

Changing these behaviors will mostly require education and time rather than with the blocksize cap, but it’s important to note that it is not very conservative to stress the network’s security assumptions when all other measurements are pointing to centralization issues.

Stakeholders and Blocksize Caps

Much of the urgency in this debate seems to be over the natural state of the network in the long-term. There appear to be 3 factions, with slight overlap in membership between adjacent groups.

Catastrophic Coalition: This group contends that once max block size is hit consistently, it will essentially be viewed as a Denial of Service attack, blocking out cheap transactions, making transactions time out of the network’s collective mempool, and inherently damage Bitcoin’s reputation. The public will point and laugh at the puny 3.5 transactions per second rate, and people will either flock to altcoins who have not hit such a cap, or simply traditional payment systems. Bitcoin will have permanently missed the opportunity to replace VISA. This event is to be avoided at all costs.

Experimenters: This group is really quite curious what is going to happen when the 1MB blocksize cap is hit. They view Bitcoin as an experiment, and are partial to the idea that “hitting the max block size will have to happen eventually, so why not now?” Many of these are also interested in finding out how many business models and security assumptions were being made in the absence of block inclusion competition. Often these folks are looking forward to some type of replace-by-fee to be rolled out to create a real functioning fee market in contrast to today’s relatively ham-fisted software that just fails if you shoot too low in fee. Hitting the block limit would spur development of such software.

Scarce Resourcists: This group believes that Bitcoin, in it’s natural state, will be up against the block size limit. They argue a limit will be necessary to both fund the network security by auctioning a scarce resource(paper), and will be a consequence of the desire to keep the network decentralized. They believe that simply “scaling up” is a dangerous exercise, and in their heart of hearts an ultimately futile attempt to displace traditional payment systems. Instead development should be focused on tackling problems that they believe Bitcoin can actually solve using solutions such as payment channels and off-chain crypto-audited banks.

After looking at these groups, we can now see why pre-emptively forking for the future is probably not going to gain consensus any time soon. This pragmatic and ideological divide is not going to be gapped by an excited blog post, but through time, experimentation, experience, politicking, and a dash of humility. Proposing block increases based off of future technological advancement are dead on arrival; increases, if and when they happen, will be reactionary events. Failure to take the time to gain consensus before making bold, imminent-sounding pronouncements will only further delay changes that are deemed necessary by the factions.

Just Right?

The blockchain, much like democracy, is a MAD-style suicide pact; a never-ending game of chicken. Each user that derives some utility from the current network wants the thing they like amplified even if that is to the detriment of some other users. Each user can vote for their opinion in various ways, with a permanent blockchain forking being most likely the wrong solution.

With this in mind, we can look for common ground while looking forward. Building layers on top of Bitcoin such as hub-and-spoke payment channels, and audit-able crypto-banks can be started today to relieve a lot of this pressure. Some type of replace-by-fee has to be developed to make fee adjustments easier and safer than now. These enhancements will be required at whatever blocksize is deemed safe in the future. Perhaps someday we can scale Bitcoin enough that everyone can have at least some access to the blockchain through naive scaling or newer ideas such as treechains. Until then we should focus on what is probable and safe today, and less on guesses about tomorrow’s technical advances.

Gregory Sanders, Bitcoin enthusiast –

Previous Post:

GreenBits, the all new snappy Android Bitcoin Wallet with multisig and hardware wallets support


GreenAddress and its team are happy to announce the availability of GreenBits in the Android Play and F-Droid open source stores.
Screenshot_2015-01-22-15-49-00What is GreenBits?
A new, open source, snappy Android Bitcoin Wallet combining the improved security provided by multisignature and hardware wallets to enhance both security and user experience.
Based on BitcoinJ, the app supports all hardware wallets currently available including the Ledger Nano and HW.1 as well as Satoshilabs’ TREZOR and clones such as BWALLET.

The app supports the following functionality:

  • Hardware wallet support: Ledger’s Nano and Satoshilabs’ TREZOR (and clones)
  • Payment protocol aka BIP70 via clickable links, QrCode or NFC
  • HD/BIP32: deterministic and doesn’t reuse Bitcoin addresses
  • 4 or more digits PIN (with server assisted strong 256 bit AES random key) to protect against brute force attacks while providing a smooth user experience Screenshot_2015-01-22-16-02-44
  • 2of2 and 2of3 sub accounts to separate funds
  • Instant confirmation with supported parties, ideal for recipient double spend protection
  • All bitcoin denominations (BTC, mBTC, uBTC _and_ Bits)
  • Spending Limits in BTC or fiat terms
  • 4 different kinds of 2FA authentication (SMS, Email, OTP and robot call)
  • Sweeping paper wallets
  • The large majority of price sources in various currencies
  • Early support for Proton, Ledger’s NFC Bitcoin Wallet prototype


The app is available for both MainNet and TestNet, some functionality currently requires use of the  GreenAddress desktop app to be used (for instance enabling/disabling 2FA, Limits, initializing hardware wallets, etc).

Some have asked why we have a new app and what will happen to the old Android app we have.

While the old app provided a great amount of functionality we came to the conclusion that having a native Android app provides a better user experience and generally faster payments.

We will keep both for the time being as GreenBits becomes more robust and supports all features GreenAddress has.



Feedback as usual is greatly appreciated!


The Rock Trading exchange implements instant transaction confirmation and safer customer deposit with GreenAddress

therockDigital currencies exchange The Rock Trading, established in 2007 and trading Bitcoin since June 2011,  announced a partnership with GreenAddress, a leading multisig provider that aims to make Bitcoin storage and transactions easier, safer and faster.

The Rock Trading now allows funds to be instantly credited when deposited from a GreenAddress wallet, and instantly  withdrawn.

The Rock Trading co-founder and CTO Davide Barbieri explained that the new features are designed to reduce friction for traders and people looking to speed up Bitcoin transactions processing while improving transactions and storage security:

“We’re pleased to be the first european exchange to support both multisignature and instant confirmation. Our users will be able to store their bitcoin in the most secure wallet, while instant confirmation let them being in control of Bitcoin funds until the last moment. It’s another step toward exchange trust.”


Lawrence Nahum, co-founder & CEO of GreenAddress said:


“Traders are feeling that while Bitcoin is superior to the legacy banking it still takes around 30 minutes to move funds from one exchange to another. This makes it harder to take advantage of arbitrage opportunities and thus bring liquidity. With our multisig-based instant confirmation people can be confident they are the only ones in control while still retaining the convenience of not having to wait for bitcoin transaction confirmations – and we have an API that provides just that to developers too!”

Nahum revealed that more exchanges, payment processors, ATMs, etc will come onboard featuring instant confirmation.

Both Nahum and Barbieri pointed out how implementing instant confirmation greatly reduces friction, allowing for a massive competitive advantage in the ecosystem.

About The Rock Trading Ltd

Born in 2007, The Rock Trading is a maltese exchange focused on digital currencies. It was one of the first exchange to make trading available with Bitcoin, in June 2011. Since May 2013 it is also a Ripple gateway.

About GreenAddressIT Ltd

Born in 2013, GreenAddress is a leading Bitcoin platform offering the industry’s first and most advanced multi-signature API and multiplatform wallet focused on reducing friction and increasing security and ease of use in storing and transacting Bitcoin.