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.


subaccounts_screenshot

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.

receivesub

 

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
subaccount
: 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).

send_sub

 

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 https://buy.hardwarewallet.com – 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 p2sh.info 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.

WeeklySpending

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.

WeeklyVolSpending

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!

BitLicense for non-US business – at first glance

Couldn’t agree more with Capaccioli.
The regulation is not removing uncertainty from the market, it is instead increasing it. The broad and all inclusive language used, at least at first sight, is incompatible with Bitcoin’s pseudo-anonymous and distributed nature.

BitLicense as-is does not protect consumers, but stifles innovation with unnecessary and costly burdens. Bitcoin is different from the rest of the financial system and requires some careful thought before regulations are put into place.

Finding the right boundaries and the right balance is a difficult task that requires meticulous and conservative attention.

COINLEX.

The proposed NYDFS BitLicense could impact on non-US business:

Section 200.2 Definitions
(g) New York Resident means any Person that resides, is located, has a place of business, or is conducting business in New York
(n) Virtual Currency Business Activity means the conduct of any one of the following types of activities involving New York or a New York Resident
Section 200.3 License
(a) License required. No Person shall, without a license obtained from the superintendent as provided in this Part, engage in any Virtual Currency Business Activity

The jointly analysis of these rules can impact on non-US business. The Bitcoin ecosystem consists in high pseudoanonimity and interpreting in letteral way, every business that involves NY residents, even if run abroad with no contact with NY State, requires BitLicense or find a way to avoid NY residents.
For exemple: an european exchanger could block all New York’s IP addresses, but…

View original post 67 more words

VAT & BITCOIN – ARE BITCOIN EXCHANGE TRANSACTIONS EXEMPT FROM THE VAT DIRECTIVE?

More on VAT

DELI Blog

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

VAT & BITCOIN

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

COINLEX.

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

Credit-cards

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 debit@greenaddress.it

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.

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.

Treechains:
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: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html

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 Bitcoin.org’s Bitcoin Developer Guide
gsanders87@gmail.com

EDIT:

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. 🙂