More on VAT


The Swedish Supreme Administrative Court in the Case No. 7101-13 resolved to submit a preliminary ruling under Article 267 TFEU on the interpretation of Article 135.1 of the Directive 2006/112/EC on VAT taxation on bitcoin.

The question raised in a case in which advance ruling sought by a person who intends to carry on business through a switching operation with the virtual currency bitcoin to “fiat” currency.

The Supreme Administrative Court raised the following questions:

  1. Does the exchange of virtual currency with “fiat” currency constitute a supply of service under VAT Directive?
  2. Should the answer to the above be yes, are the exchange transactions of bitcoins exempt from VAT under Article 135.1 of VAT Directive?

The Court of Justice of the European Union received the reference on 02.06.2014 and assigned to it the number C-264/14.

In light of that, we deem it necessary to briefly summarize the history of…

View original post 1,094 more words


A great and insightful view into Bitcoin & VAT by Stefano Capaccioli


The Swedish Supreme Administrative Court in the Case No. 7101-13 resolved to submit a preliminary ruling under Article 267 TFEU on the interpretation of Article 135.1 of the Directive 2006/112/EC on VAT taxation on bitcoin.
The question raised in a case in which advance ruling sought by a person who intends to carry on business through a switching operation with the virtual currency bitcoin to “fiat” currency.
The Supreme Administrative Court raised the following questions:
1. Does the exchange of virtual currency with “fiat” currency constitute a supply of service under VAT Directive?
2. Should the answer to the above be yes, are the exchange transactions of bitcoins exempt from VAT under Article 135.1 of VAT Directive?
The Court of Justice of the European Union received the preliminary ruling on 02.06.2014 and assigned to it the number C-264/14.
In light of that, we deem necessary to briefly summarize the history…

View original post 1,046 more words

A debit card for your GreenAddress Wallet


Like many of you, I try to use Bitcoin to pay for goods and services whenever possible. The good news is that this is gradually getting easier! A quick peek at coinmap will show you that more shops are accepting Bitcoin every day. However there will always be some shops that won’t accept our hard-earned Bitcoins 😦

For these situations, where the shop accepts major cards, we are working on something we think you will find useful – A debit card from one of the major players, associated with your GreenAddress Bitcoin Wallet.

The card will be transparent, not requiring pre-loading or manually exchanging money at any point. Here’s how it will work:

When you use the card to pay, the point of sale system authorizes the card payment with the card network as usual.

When the authorization request hits the issuers network, the issuer routes it to GreenAddress, and we forward a mobile/phone notification to you. The notification confirms that you are happy to pay the fiat amount X to the shop, at a cost to you of Y bitcoins including any fees involved.

Card_reader_segfaultOnce you accept, your coins are sent securely and instantly to the issuer, and the issuer accepts the fiat transaction with the shop.

If you reject then we notify the issuer and the transaction is rejected as unauthorized. You can then try again or pay in some other way, just as with a regular debit card.

Pretty cool, huh? Now, I’m sure some of you are asking whether this requires compliance with AML or KYC regulations, how refunding will work, etc.

The short answer is that regulation depends on the country and issuer card limits(we intend to support multiple issuers where possible). Refunds will be handled in fiat – handling it in BTC has not been discussed but I can imagine it would have a huge impact on fees if it is even possible to implement.

We have other ideas in mind, such as allowing the card authorization itself to be used as two factor authentication, avoiding the need for any mobile acknowledgment step (this would make the card indistinguishable from a normal debit card).

Now, how far along are we with all this?

We have most of the technological pieces in place already, but deployment of a working service is months away if not more. We are in discussions with more than one issuer (covering EU and Asia) but nothing is firm yet. We want to shake things up a bit and get some feedback on interest, e.g. how much and in which countries. This will allow us to focus on issuers where we can demonstrate clear benefits for all sides, and push for faster service roll-out.

So, let us know what you think! Please comment here or on reddit or alternatively send us an email at

Update: the pictures are not representative of what will be the actual offering, those are just images marked for reuse in wikimedia.  So far we are talking Chip and PIN and I doubt there will be any other offering.



Sidechains, Treechains, the TL;DR

??????????????????????????????????????????????????????????????????????This document is aimed at technical readers and is simply a brief explanation of sidechains and treechains as far as I understand them, based on public information.  Both are obviously still in very preliminary development, but this document is just to introduce the broad concepts, and their consequences. Some people have been asking for something like this, might as well see if this helps.

With GHash is getting nearly 50% of hashing power of the network, this discussion is more timely than ever.

I’ll start with sidechains, since treechains are essentially a specific form of sidechains.

In the most general, sidechains will use “SPV Proofs” to send satoshis from the regular Bitcoin chain to the sidechain, and allows the sidechain to eventually send the satoshis back to the main chain once the owner of said coin is finished utilizing the sidechain. While in the sidechain, the main chain knows nothing of what’s happening to the coin, the sidechain is the one tracking who owns what at what time.

The side chain can basically have any rules it likes for what a valid block is, block times, etc. Typically the idea is that these chains will be merge mined with the Bitcoin network, to ensure that a reasonable amount of hashing power is protecting the sidechain network from DoS, and outright theft of coins by miners which is possible due to the limitations of the SPV proofs. It’s important to note however, that it has been suggested that the outright theft of coins by miners may be protected against using zk-SNARKs.

The pros of sidechains appear to be:

  1. You don’t need permission to start a new chain with new validation rules, block times, whatever. You could fairly trivially add Zerocash, Ethereum rules, and still have them pegged in satoshis. Also would be a great way to test out new opcodes/communication protocols for the base protocol and codebase.
  2. The sidechains would be backed by the hashing power of the Bitcoin network, so given certain conditions(detailed below) it can’t be trivially attacked.

The cons are as far as we know(not counting new zk-SNARK moon math that hasn’t been given to the public):

  1. Merge mining also means two things: There is no inherent block reward. Security will most likely be only be from transaction fees. more importantly, you need to convince the large pools to manually activate the merged mining of these chains, otherwise a 51% attack is essentially free. You also have to trust the pools aren’t faking downtime, while secretly mining the chain.
  2. Long-term it can contribute to centralization of mining, just in the same way that increasing the block size would. It would be optional to mine these sidechains yes, but if it becomes a sizeable fraction of transaction fees, the economics work in the favor of more centralization.
  3. Sending satoshis back and forth  between chains will take days, to ensure that satoshis aren’t being stolen by miners, again due to the aforementioned SPV proofs, which is something that simply can’t happen in vanilla Bitcoin. Most going back and forth will be done using atomic swaps in between users to reduce this waiting period.

I think of treechains as tighter-coupled sidechains. The difference in chain structure is larger than between sidechains and the vanilla Bitcoin protocol, so I’m tackling them in broad brush-strokes.

  1. Miners are not required to validate blocks, outside of the PoW difficulty being low enough, and being a proper hash of the block+previous block. If the block header looks legit, miners can start to build on top of this.
  2. Starting from the main Bitcoin chain, each chain will have a left and right descendant chain. This builds a binary tree of chains, hence “treechains”. Each chain level has 2^(numlevels-1) chains, doubling the number of the previous level. Each difficulty threshold is also halved. Based on the hash of the transactions, they can only be mined in in specific paths of the tree structure(starting from the first bit of the hash from the root of the tree, ‘0’ means left subtree, ‘1’ means right). Each time satoshis are spent, it will get sent to another chain in the same level based on the previous transaction’s hash(ignoring up/down movement for clarity).
    In addition, each path is merge mined, allowing miners to mine one and only one path of the tree using the same hashing work. So for example, 3 layers down, there should on average only be an 8th of the total transactions on any specific chain, as well as only an 8th of the total mining power, resulting in roughly the same block time as higher chains!
  3. The chains are linked together more strongly than sidechains to enforce a total ordering of transactions. Every time a miner gets a PoW high enough for a certain level, it “links” that block with all the blocks being mined below together. This enforces the total ordering we want. Transactions on let’s say level 16 will have a higher chance of getting orphaned, but eventually once they “percolate” up to the main chain, they are just as secure as the main chain. The linking also determines when you can spend your satoshis, meaning lower chains will take longer to spend the same outputs again compared to higher chains. To spend your satoshis from chain A to chain B at level C, the previously mined transaction’s block in A must be linked to B’s nearest common ancestor chain, with the only valid paths being forward/up the chains, not backwards.
  4. Last important thing to note about the tree structure: Parent chain always wins. If the child chain is in conflict with the parent chain(the links are inconsistent, making total ordering inconsistent), those blocks child blocks are orphaned. Therefore, re-organizations at higher chains can cause reorganizations at lower chains, but not vice versa.

And their consequences/caveats:

  1. Since miners aren’t required to validate anything outside of basic PoW, this breaks the need to beg miners for protocol changes. Granted, there will be a base BTC layer that allows things like “miner gets block reward” and “pay .0001 BTC to miner for transaction fee” to incentivize the mining, but outside of this, it allows fairly arbitrary protocols. One could even imagine paying a miner colored coins to get it included in a block, if the miner wanted equity! One thing this can’t do versus sidechains is initialize chains with arbitrary block times. However you might be able to get away with much faster block times than vanilla Bitcoin due to #2. Overall, this will let innovation at the edges happen, without having to agree on everything with Core Devs, or mining pools, or industry, etc. SPV clients won’t be possible, at least in their current form, due to SPV’s assumption that mined blocks are validated by the miners.
    Proving who owns what when will be more complicated for the client, as they can’t assume miners are validating a certain protocol. Clients will have to hold data outside of their private keys, proving to the payee that these coins exist and control them. This will be more complicated than our SPV clients we have today, but will make running a node with “full node” security tractable, as you don’t care what the contents of most blocks are, just the blocks that prove to you that you own the satoshis you own(a small sample of blocks compared to the whole tree of chains). These proofs will be “compact”, although it remains to be seen how much more compact than linear in block sizes we can get(insert zk-SNARK moon math for sublinear performance?).
  2. Combining with consequences from #1, miners will be able to mine as little or as much as they like, with only paying attention to block headers, and block payloads that again, prove to him that they’re actually being paid to mine by fees. A miner could simply keep track of all headers in the treechains, which is trivial, and solo mine 16 levels down, where their variance is 2^(-16) less than the vanilla blockchain mining, due to the sparsity of miners that far down in a branch. If a user is willing to wait a while for the ability to re-spend their outputs, they can approach a solo miner, pay a smaller fee than usual, and wait for the block to get linked higher in the tree.This opens up a true marketplace for fees, as well as allows small pools/solo miners to make a real difference when it comes to block creation. Lastly, this system appears to scale to an infinite amount of transactions, without hurting decentralization.
  3. The linking scheme ultimately means that orphan rates will be higher at lower levels, and re-spending outputs will take longer, and will be based on where the next transaction will end up in the tree structure. However, for your coffee money, it enables you to get in a block, and for the merchant to not worry too much that you’ll try and 51% attack 5 levels down as it won’t make economic sense.

In summary(TL;DR’s TL;DR):

A Sidechain, at its most general, is a loosely coupled chain that, in general, uses merged mining to protect the network. These chains are “backed” by BTC from the Bitcoin network, rather than minting their own coin and diluting scarcity. There are some questions about security guarantees versus the Bitcoin network.

A Treechain is a structure of more-tightly coupled sidechains. This structure, in theory, allows miners to mine at arbitrary variance without pooling, scaling of the system far beyond 7tps without asking permission, and other innovation at the edges, all with the same protections of the main Bitcoin network. With the huge caveat that the idea is still half-baked, has no known SPV client support, and is much more complicated than a vanilla blockchain.

Both ideas are interesting ways of tackling some of the important problems that all cryptocurrencies face. We should know more about the actual implementation of sidechains within 3 months, as the company Blockstream will be releasing a white paper and source code. Many of these ideas that aren’t published will be directly applicable to treechains, as they are kin in many ways, including how they will be rolled out initially.

I’m personally biased towards treechains in that I believe the de-coupling of miners and policy is a huge step forward, even just for new fancy opcodes without permission. It may also enable us to be free of begging MegaPool#9 not to 51% attack us, which is already happening. I for one would like to solo-mine on a USB ASIC!

Unfortunately due to its complexity and fundamental difference with Bitcoin proper, it will almost certainly take more time to flesh out and convince others that radical steps need to be taken to keep cryptocurrency decentralized. I look forward to its development.

If you have time on your hands to check out more of the details of treechains, here is Peter Todd’s initial writeup of many of the ideas:

As well as the Let’s Talk Bitcoin podcast where he goes into much of this detail: here (thanks to /u/_Mr_e)

Hope someone finds this helpful,

Greg Sanders
Contributor to’s Bitcoin Developer Guide


Peter Todd sent us the following:

FWIW there are some concerns raised re: how tree chains handles data
loss at the lowest levels; I’m not sure yet that those concerns can be
resolved. Also Adam Back raised some potential issues re: incentives in
some edge cases. Of course, you did quite correctly describe the idea as
half baked. 🙂

Amsterdam Bitcoin 2014, payment protocol, stealth addresses, coinjoin and merge avoidance

Bitcoin-2014-Conference-LogoWe are getting closer and closer to what I believe to be the most important Bitcoin conference of 2014. We are really  excited to be part of it and can’t wait to meet everyone, especially the devs but also startups and ultimately what makes Bitcoin really great and
unique – the community and the people!

At this point it looks like most of the schedule is final and we are definitely looking forward to hear the keynote speech and all the feature presentations.  These presentations now have a title, but are  not ultra detailed yet:  we are guessing to hear all sorts of things, ranging from legacy-banking bridges, insurance, regulation but also more robust storage and payment solutions with ease of use, security and privacy in mind as one main focus.

Especially regarding the security and privacy we hope to hear talks about the payment protocol (for which we just finished the implementation of the client component,  currently in a test-phase  on our testnet environment) but also stealth addresses, coinjoin and merge avoidance.

Dark-Wallet-Application-Aims-To-Provide-Better-Bitcoin-PrivacyWe would also like to congratulate with the  DarkWallet team for pulling off the first wallet that implements innovative privacy features such as coinjoin and stealth addresses. There has been a lot of discussion about all these features in the recent past, especially stealth addresses and the so called waste of disk/memory capacity due to  blockchain overbloat.

For those unfamiliar with the argument behind stealth addresses I’m going to quote an excellent comment on reddit by Chris Patia:

BIP32 allows for the creation of a Master key pair. Using the master public key you can derive an unlimited number of child public keys, the private keys for which can be derived from the master private key.

You could theoretically put your master public key on a server and dynamically generate a new address for each new payee. This way you don’t have to keep your private keys on the server.

The problem is that doesn’t work in some use cases. For example, I have a basic WordPress blog with a static tip address. I cant dynamically generate a new address for each tipper because I don’t control wordpress’s server.

I could put my master public key on my blog, but then anyone can use that to derive all my addresses and see the balance of my wallet.

The reason stealth was created was to allow me to put up a single address and receive payments to a new address each time without other people seeing my balance.

mikehearnNow, you can still have stealth addresses without using the blockchain as a mean to store the secret. But it requires communication with the party you intend to transact with, which as Mike suggests, could be easily
done with the payment protocol.

It’s really hard to say, yet, what is waste and what isn’t, especially thinking about multisig  addresses. In fact, they take additional space too – as Peter Todd said in the bitcoin-dev mailing list – and we certainly don’t consider that a waste so it will be interesting to see what happens. It seems clear the community wants and needs an peter-toddoffline way to generate addresses for third parties and using the blockchain means you don’t need to backup additional data each time (which would be required if the system used was exclusively the payment protocol without a fall back measure on the blockchain).

On the other hand, using stealth addresses this way has privacy and scalability consequences, especially for light clients.  This can be, in theory,  at least partially tackled with SPV improvements or trusted third parties. The discussion about boom filters changes and SPV seems a compromise between how many clients will know about your transactions  and how much.  Additionally,  I’m not too convinced on adding Tor to SPV to improve the privacy of thin clients. As according to the wiki it would make wallets more vulnerable to the sybil attack:

Low-latency encryption/anonymization of Bitcoin’s transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you’re connected to several of the attacker’s nodes and the attacker is watching your transmissions at your ISP.

Regarding online creation of new addresses,  there can also be third parties providing new addresses as needed. This has obviously its weaknesses as you rely on this third party being available which is certainly not always a  given but also it could provide non-user addresses if malicious.  We have this feature but we also have stealth
addresses in the road map, especially as the original specification supported multisignature (although it is my understanding that Darkwallet doesn’t current implement it).
greenaddress-donate-greenTo see in action our dynamic address  click the green link donate  button on the left hand side
or see it in action on ZealDocs.

What about coinjoin?  People have been speaking about improving the current interoperability between wallets, as all coinjoin implementation currently rely on a single centralized server,   correction, the guys at Darkwallet already have gateway channels available. One such improvement is creating a ‘federation’ of coinjoin servers but it won’t mean that the system will be really decentralized. At least in a federation system it should be easier to increase the number of parties and, because of how coinjoin works, I presume this should mean improved privacy.

What I’m actually looking forward for is a system that is fully decentralized.  I am not yet entirely sure how a system like this would work, but I wouldn’t be surprised if someone is not far from envisioning one or if one is already available and I did not have a chance to find it yet. It was pointed out to me that something is in the works.   At GreenAddress we have coinjoin or something similar in our roadmap although – obviously – if something betters becomes available we’d skip directly to that 🙂 bitcoin-payment-protocol

Last but not least, a word on merge avoidance. Generally, I think it is a great idea and a great way of improving privacy. I think wallets could be smart enough to have the right mix of efficiency and privacy
with regards to how they would split amounts by knowing what amounts you spend most often and optimize for that, so that you can have your privacy and avoid splitting bitcoin to too many (or too few) addresses.

Reusing addresses is bad, M’kay?

tl;dr Reusing bitcoin addresses has both security and privacy consequences and should be avoided, especially since services and tools that don’t reuse addresses are available and even easy to use.


locked-wallet-1First what do we mean by “address re-use”?

In general we mean sending, ever, more than one transaction to any specific bitcoin address.

Specifically what you want to do is to prevent having funds sent  to an address after any bitcoin has been spent that were addressed to that same address. Technically receiving two transaction on an address and then spending is OK but receiving, spending and receiving from an address in this order is not. The easiest thing to do is not reuse, especially since you can’t easily synchronize with parties which may pay you after you spend from an address.

Yet, a lot of people are reusing addresses over and over and over, mostly because they don’t know better and, most importantly, reusing addresses is the default option in the tool or service of their choice.

From a privacy standpoint it should be clear why this is really bad: people that have your address can see your past and future transactions and track you and also, by making yourself more identifiable you’re making it harder for everyone else to use Bitcoin privately.  Poor privacy is infectious.


If you ever pay someone that also uses a public address, like a gambling site, everyone that knows that you control that address will also be able to know you gamble, when you gamble and who you gamble with which may not be something you want people to find out or even phantom as a possibility, yet is trivial to do, as the bitcoin public ledger, the blockchain, is, duh, public.

From a security standpoint it’s not obvious why it is better to not reuse addresses but there are two/three components:

  1. Not reusing addresses can protect you from a weak random number generator or buggy ECDSA implementation (see what happened on Android with their RNG)
  2. Not reusing addresses protects you from quantum computing
  3. Not reusing addresses may prevent you to be exposed from undiscovered holes in ECDSA theory


A reasonable question/answer  about this topic is on bitcoin.stackexchange.

Historically reusing addresses has also been practiced for two main reasons:

  1. Simpler to reuse, both from user and developer implementation perspective (and most people don’t know yet about bitcoin, that this is even an issue or how to track you)
  2. Every time you ‘create’ a new address you must also create a new private key and with that comes responsibilities such as making backups of the new private keys each time a new one is created. This is no longer an issue if you use a deterministic wallet

How to solve the issue? People should be made aware of the problems associated more clearly and services and tools like Mycelium and or even Bitgo, which are relatively famous tools/services that do at least some address reuse by default , should really avoid reusing addresses before more users are harmed.

hacking-bitcoin-with-goUsers that don’t want to wait for these service or tool providers to catch up and update can use services like GreenAddress which never reuses addresses, uses a deterministic approach and provides true per-transaction two factor authentication via multisig.


Feedback is welcome!

When you can and can’t rely on 0 confirmations

The Bitcoin community has been hit with a wide range of security related news lately: first CVE-2014-0160 aka ‘Heartbleed’ , a serious vulnerability in the popular OpenSSL cryptographic software library. The Bitcoin core team has issued an update of the Bitcoin software and an alert  . We have tweeted about the vulnerability, just after we upgraded and checked our services (we recommend Saltstack to manage your servers, great especially in these situations ).

Then user espringe on Reddit announced BitUndo, a service that “can help you to revert mistaken payments” effectively allowing users to double spend their transaction back to themselves for a 10% fee to BitUndo.

One immediate community reactions was to suggest that this service could also be used to defraud merchant or bitcoin payment processors such as Bitpay  and Coinbase.

So far the service doesn’t seem to have any sufficient hashrate to be successful in double spend attempts often to be a problem however this may change as the BitUndo mining pool seems to have better incentives for miners and the situation will become worse as the block reward halves. There seems little that the network can do from a decentralized perspective to stop this from happening.

The situation appears to be much worse: Peter Todd, one of the core Bitcoin developers has submitted on reddit a post titled “Double-spending unconfirmed transactions is a lot easier than most people realise”  which shows and proves how he and anyone that tries can easily double spend with around a 50% chance. He continues, “Fact is, unconfirmed transactions aren’t safe.”  This is caused principally by the difference in how some miners perceive a low fee as dust and won’t include it (nor check for double spends) while others will happily include it. Submitting first a transaction with one of the new lower fees is what causes the problem.

This will improve as more miners move to the latest version and Peter has also proposed some patches that will allow to somewhat counterbalance this attack but ultimately any difference in the transaction that miners accept will allow some percentage of double spends and as mentioned above the incentives will change further as the block reward halves.

Solutions to this problem are various:

  • accept risk and perhaps use one of the new counterbalancing measures or wait for a number of confirmations in relation to the amount and risk in the local area/product category
  • require users to pre deposit their Bitcoins well in advance

One more thing worth mentioning is about localbitcoins , a market place for trading bitcoins locally and over the internet. User don4of4 submitted a post on Reddit  in which he advise users to empty their accounts.

There seems to be an issue with stolen bitcoins. While it is not clear yet whether the hack was on the user credentials externally to localbitcoins or whether it was on localbitcoins service itself, one thing that is clear is that a multisignature system would have prevented funds to be moved without access to the user private key.

This could be implemented directly by, or should they prefer, it could be provided with the help of a specialized third party such as that could help them concentrate on their core business and at the same time allow user funds to be locked only while in escrow and not require predepositing with

Greenaddress user’s funds are in a multisignature 2of2 P2SH between them and the server and as such both the keys from the user and GreenAddress are required to move funds. This allows us to prevent user double spend, effectively guaranteeing to receivers instant payment, even under the 0-confirmation scenario, as long as the merchant trusts us. At the same time, should we disappear for _any_ reasons, users can sleep feeling safe as we provide in advance transaction unlocking their funds in the future. could help in sending the user funds to upon user signature and two factor authentication directly in the escrow system. This would provide a signed instant confirmation proving the users funds came from a wallet in multisignature with

This would mean that users and merchants don’t have to wait to trust that funds will be received!

This mechanism could also allow exchanges to provide a competitive advantage to users both in terms of inter-exchange transfer for arbitration but also in terms of security as user funds would only be compromisable when in order or instant book, reducing the extent to which MtGoxing like scenarios can happen in the first place.

For more info on the design, see the white paper here.


Allegedly the localbitcoins issue was caused by the user reusing data across services of which some have been recently compromised and information thereof leaked. See their initial response here . Ultimately we think it doesn’t really matter who is at fault, using multisignature can help prevent this class of issues entirely and services should evolve to take advantage of improved standards.

iOS, Bitcoin and qr codes

At GreenAddress, to support the Android platform (and soon more) we use Cordova ,  a framework that allows to target multiple platforms with one code base and in theory (and in our case I believe in practice too) increase reuse and reduce rewrites.

Unfortunately, even though this would allow us to easily support iOS via an app, because of Apple policies and their history in regards to Bitcoin, it is the case that we can really only support jail broken phones on alternative markets or we can attempt to submit a version of the app to the Apple store with the send functionality removed which would really cripple its utility and it still does not guarantee our app would make it.

Qrcode scanning is almost at the core of Bitcoin payments, especially on the go.  While so far we offered support for it on Android  we did not provide any support or any other platform which we feel that especially on iOS devices limits the use of the wallet.

With some inspiration from Coinpunk QR support on iOS and the great work from the guys at,  I’m happy to announce that we now support qrcode scanning on any HTML5 enabled browser via both camera or local file ‘upload’!

Note that this functionality is also available to login into a wallet and that it includes support for all Android devices we have tested, Chrome and Safari on iOS devices 🙂

Happy scanning!

‘White paper’ and other updates

First post on our simple blog. 🙂 My name is Lawrence Nahum, I’m the founder of GreenAddress. Here’s my LinkedIn profile: I have only been interested first and then involved in Bitcoin for a bit more than the last two years, but it feels like much more than that, and the last few months, and especially the last few weeks have been so packed but great with lots of new users and amazing feedback and obviously a lot of hard work.

We started with the first deterministic Multisig 2of2 Wallet with time unlocking functionality: a wallet that at the same time sports a large array of features improving privacy, security and convenience.

We have open sourced both our clients for both Android and Desktop as well as Gentle, we then added a bunch of languages (more coming), and today have published a document that describes our design and implementation, sometimes called a ‘white paper’, at least in B2B .

If you want to read it have a look here  and please do say what you think,  we’d love to hear your feedback. If instead you want to see a quick and superficial video infographics  about GreenAddress you can find one here.

We will soon publish more information on our short-term roadmap which includes an API (check out the preview) coinjoin integration, payment protocol and more. 🙂

UPDATE: Post on Reddit with comments.