An Interesting Tool for creating Paper Wallets

I have written various postings now, about Bitcoin Wallets. One of the themes which I have brought up, is that the online account, of how much money has been Sent To and From a Bitcoin Address, is more important, than the offline account of it, which can therefore sometimes be reduced to only a Private Key and a Public Key. The Public Key can be converted to and from a Bitcoin Address to Send funds To, while the Private Key can be used to authorize, that funds be Sent From the same Address.

And so one subject which I also wrote about, is that if a person has the Private Key, he or she can use some existing Bitcoin Wallet apps, to Sweep that Address, thus giving the command to the network, to Send all its funds to another Address, which is online.

There is some minor discrepancy, between what I called an ‘Offline Wallet’, and what the Internet calls an “Offline Wallet”. What I was referring to by that term, would actually be called “A Wallet In Cold Storage”. What the Internet may refer to instead, is a kind of Wallet, being accessed by a program, but on a computer which is separated from the Internet by an Air Gap.

In reality, the subject of the security of Air Gap systems, is quite beyond what I am currently willing to write about. My personal guess is, that if most of us wanted that, we might be a bit too paranoid for the mundane world. There exist some organizations and even companies, who need Air Gap Systems, but then there is a whole rigamarole, of what needs to be done, for an Air Gap system actually to receive the full benefit, one hopes to gain by using them…

But, having done some reading, I have come across a tool which even everyday users could find useful, in creating an actual Paper Wallet:

Online Tool

Because all that is needed for one Bitcoin Address to exist, in principle, is a correctly-formatted set of Private and Public Keys, a tool can be useful somewhat, which only does that, and which offers to print those out as QR Codes. The above Link is a Web-page, which does this.

(Edit 10/08/2016 : Actually, I had previously posted a mistake here. As it stands, if a person transfers a Bitcoin-amount to an Address that is validly-formed, that amount will remain associated with the Address, even if no attempt is made to query the Address. This Bulletin-Board Conversation seems to state so.)

Continue reading An Interesting Tool for creating Paper Wallets

Possible Misconception: Bitcoin Wallet Singular

There is a possible misconception which people might have about how Bitcoin Wallets work, which I would say, because I had this misconception myself until only very recently. Many popular Bitcoin Wallets present themselves to the user as having one balance at one time.

Each time we receive funds, most of the time, we will want to receive those funds to a separately-created Address. And the difference between the Address and the Public Key, is mainly one in formatting of the binary data.

What many Wallets do not show the user, is that each receiving Address continues to hold its own balance. This means that when we tell such a Wallet to Send an amount of Bitcoins to another recipient, which is larger than the balance we hold on any one of our own Addresses, what our Wallet tends to try to do, is to make numerous transactions, one from each Address, all to the same recipient, until the total amount of funds has reached the amount we asked to Send.

Each of those Addresses, being a Public Key, has its own Private Key, which we must unlock across-the-board, at least until the transaction is complete. And each Private Key, therefore, only has a limited amount of Funds it can Send. Balances are not allowed to go negative.

And so what can happen to many users, is that our Wallets become fragmented, with only a small balance associated with each of our Addresses, many of which might have started out as having a larger, received balance. And sometimes, the P2P network can be reluctant to process such a transaction, because it represents a load on the network.

And so an operation that some Wallets recommend, is that if we have many small balances, eventually to transfer a larger sum, out of those balances, to a new, single receiving Address we have in our own, same Bitcoin Wallet. This incurs the transaction fee normally associated with such an operation, but the only benefit to us, is that we will have a single, larger balance afterward.

Other types of Wallets do not show us, how much of our balance is associated with each Address.


What this also means, in connection with what I wrote before, about being able to Sweep one Address, is that this ability is usually not so sweeping in practice. Since a wallet with 10 Addresses that hold balances, can also have 10 Private Keys, the program from which we might want to do the Sweeping, will need each of the Private Keys, in order to empty out a whole Wallet, for example.

From the security perspective, it could become a more complicated action, to steal 10 Private Keys, than it would have been simply to Steal 1 Private Key. And for off-line Wallets, this can be a limiting factor. We can only write down a limited number of Private Keys by hand, on a sheet of paper, for example.

Dirk

 

Bitcoin, more specifically

One Bitcoin Address effectively works like a Public/Private Key-Pair, except that the trapdoor function used is not RSA. Given the Public Key (aka Address), it is possible to Audit that Address, i.e. to listen for payments made to it. And, there are specific cases where a Public Key can be associated with a known identity.

For example, an Address may have been published openly, to accept donations or vending-machine payments. Because the Public Keys can be tested for equality, any additional occurrence of the same one, will be known to belong to the same identity.

Further, while the Private Key associated with an Address is needed to Send a Payment from that Address, how many BTC any Address holds is decided by the system of Peers, more than by the one Wallet. Therefore, if a third party can obtain a Private Key, he or she can use the network in order to “Sweep” that Key, which means, to order any BTC held by that Private Key Sent to some other Address. This can work without physical access to the version of the Wallet which has actually been stored on a given Computer.

What this might mean for me, if the HD of my older computer was to die, is that if additionally, I had an offline copy of its Private Keys, I could Sweep those Keys into my new Wallet, on my new computer, without having to revive the old computer necessarily.

Dirk

 

CACert has tightened its access rules.

One fact which I have sometimes blogged about, is that I am a member at CACert.org. This is a certificate authority which has been surrounded by some controversy. Its use is for members to be able to secure their servers, by obtaining an SSL certificate, i.e. obtaining an httpS:// URL, without having to pay money to do so.

What happens in the industry, is that each httpS:// URL is secured via encryption – in such a way that only the server and browser can decrypt the data – but that every Public Key used, needs to be signed by a Certificate Authority using their Private Key. There exist Certificate Authorities who charge big money for this service, to Web-masters. CACert offers this for free.

But for a variety of reasons I won’t go into here, CACert is already not included in most Web browser root certificates. In order for any signing chain to be possible, eventually the ‘top’ of the signing chain needs to be a root certificate, which is already ‘known to’ and ‘bundled with’ the browser, and which the browser automatically trusts.

A decision which a user can make however, is to add root certificates to the browser manually, and to tell the browser to trust those, at his own risk – OF perhaps having data tapped in to, which he is exchanging with the server he wants this secure connection to.

Long story short, in order for anybody to open the CACert Web page itself, which is the link I included above, the user now needs to have not only the CACert root certificate installed, but additionally needs to have their Class 3 certificate installed. Because I only had their root CA installed on some of my browsers, I recently failed to open the link, to their actual site, and spent some time troubleshooting what was causing this. They have tightened the security, with which their own site can even be accessed, always to revert back to the httpS:// version of the URL, prior to which we need to have these two certificates installed, for their page to open.

As it happens, in order for my own httpS:// URLs to open, I only need to have their root CA installed, but I cannot access their site, unless I have both CAs installed. This might sound as though convenient, but in fact is not so.

If I wanted to invite other people to access my httpS:// URLs, I would also need to invite them, to install the root CA from CACert. But in practice, the only way I can do this ethically, is to direct them to the CACert site, as above. I would never try to redistribute their root CA, myself.

And their site will not open on your browser anymore, unless you have done the research, and installed both these CAs yourself.

So this mechanism is now limited, to giving me private access, to certain parts of my own site.

But I am relieved, that CACert has not itself been hacked – so far. It was a bit hard for me to determine what the difficulty was, but it did not turn out to be any sort of hacking, of CACert.org .

Dirk

(Edit : ) What I can do in a case like this, is to suggest some http:// URL to you, such as

http://www.cacert.org/certs/root.crt

And I could tell you, to use that URL to provide access – to my site and not to CACert. But, you would have no way to trust this URL, coming from me. Doing so would be just as non-secure for you, as it would be, if I simply transferred the cert to you directly. What I can do, is suggest a WiKi page to you, which belongs to CACert.org, like so:

http://wiki.cacert.org/FAQ/BrowserClients

And then you could follow the advice given…