comment 0

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.


GreenAddress’ HD wallets and “sub” accounts

As of today, one problem shared across the majority of Bitcoin wallets, is that of separating and managing your funds in a simple, intuitive and immediate fashion.

Writing down different mnemonic pass-phrases, making various backups of wallet files, or worse, managing various kinds of wallets reusing keys over and over is now an unnecessary burden as with deterministic wallets you can construct any number of separates accounts from one initial seed or pass phrase.

GreenAddress, one of the most advanced Bitcoin wallet in the market, has resolved this issue by integrating in the API first and then in its wallets the ability for users to create and separate their funds in any number of accounts all part of their wallet.


A subaccount is an actual wallet parallel to the main one and controlled by the same user. It’s possible to create this kind of sub-accounts under one’s wallet, in this way enhancing both privacy and organization in bitcoin’s management, all in complete compliance with the BIP32 specification.


Subaccount are indeed all mathematically determined from the same mnemonic phrase. And while for GreenAddress this means implementing various Bitcoin Improvement Proposal (BIPs), on the user side  it means better usability and better privacy, without compromising security. The whole multi-signature architecture implemented by GreenAddress is unchanged: the wallet provider cannot “disappear” with the funds and no malicious attacker can take control of it without explicit authorization, including two factor authentication.



The great advantage of using deterministic accounts is crystal clear in the previous screenshot: it’s possible to separate funds based on use, this way avoiding confusions, and thus manage all transactions and accounts without the need to continuously log in and out, or to copy and pastes mnemonics, or still worse: to backup wallet files with the risk of overwriting and lose access to the funds.

A subaccount will never mix the funds it contains with another
: we are talking about separated and independent “sub” wallets, each one derived from mathematical algorithms with different variables and each one with an exclusive set of Bitcoin address for sending, receiving for all purposes. The access to all these subaccount, anyway, is granted by the same mnemonic key (or the same Bitcoin hardware wallet).



To view an account other than the main one, to check on  incoming and outcoming payments, or to check the transactions list, is simple: it’s possible to pick your subaccount (if any) from a dropdown.

Subaccounts are a consequence of Bitcoins’ growing adoption: with more and more people accepting it as a payment system, it naturally rises the need for more advanced kinds of control on funds.

The feature is now available for all platforms: iOS, Android, Desktop and Web.


BTChip HW.1 : Paris-based Secure Element innovators launch a tiny smartcard-based USB bitcoin hardware wallet, compatible from day one with GreenAddress

GreenAddress-recto2BTChip announced the launch of a friendly, small yet powerful USB wallet – HW.1 – a new product, designed with security and ease of use in m
ind, thus effectively providing stronger protection against theft and malware while providing a smoother user experience.

BTChip founder Nicolas Bacca explained that the card is designed to appeal to users frustrated with classic wallet security and maintenance policies:
“We’re pleased to be the first company to bring affordable banking grade security, while preserving bitcoin user centered principles. And, with GreenAddress, you are protected by both the card and by the multisig provided by the wallet. It makes it very, very easy for you to access your coins. Easier. Safer. AND Faster”

The device works especially well with multisignature as the combination of the two allows the user to ultimately verify transactions before they are finalized using 2-factor authentication.
Lawrence Nahum, cofounder & CEO of GreenAddress said:

“A combination that brings the best of two worlds: multisig and hardware wallets. I expect a lot of people to be using them. Both our Chrome app and Android app app support the HW.1 with the latter in final testing and via full USB ports or micro USB OTG adapters.”

GreenAddress is one of the most promising and innovative wallets, a leading bitcoin platform provider implementing multisig and HD (BIP0032) features, instant confirmation and has the widest support for devices.

The HW.1 offers a comprehensive open source API available on GitHub, is also compatible with the upcoming Electrum release 2.0 and can be, given large enough orders, personalized to customers liking.

 Immediately available, on special offer with two cards (one for backup) at – you can get away with two hardware wallets included shipping for as little as 20 € (25 $), payable in bitcoins.

Reported by CoinDesk

Pay to script hash stats

Since the end of 2013 a new kind of Bitcoin addresses is possible.

Instead of sending your Bitcoin to an address made of a hash of a public key you send them to an address made of a hash of a script.

This allows to shift the responsibility of supplying the conditions necessary to redeem the funds from the sender to the recipient.

P2SH has vastly improved Bitcoin security because it finally allows people to use a multisignature setup without making it incredible difficult for senders to send funds.

Our friend Antoine at has been collecting stats about P2SH transactions and as of today only 0.5451% of all bitcoins are stored in P2SH addresses.

I wanted to find out a bit more about number of transactions and volumes so we parsed the blockchain and found some interesting numbers.


This first graph shows the total number of P2SH spending transactions. It’s interesting to see that just recently the number of 2of2 transaction took over the number of 2of3.


This second graph shows how 2of2 is pretty flat compared to 2of3 in terms of volumes, that is, other than in August where we have a huge spike for 2of2.

We’re building a number of interesting statistics we’ll want to regularly publish.

If you have suggestions as to what to look for we’d like to hear it!