
Blind signatures for Bitcoin to secure BTC storage - oleganza
http://blog.oleganza.com/post/77474860538/blind-signatures-for-bitcoin-the-ultimate-solution-to
======
gesman
Adding another entity to rely on to hold funds "safe" just adds another link
to the chain that can die, disappear, change it's mind and be broken.

I personally love how Electrum wallet does it:

You may generate and regenerate wallet using only key word phrase. Keep it
safe in memory or in bank deposit box.

No backups needed. You may always regenerate wallet by keyphrase.

~~~
wes-exp
_No backups needed_

Doesn't Electrum do this by backing up your wallet to "the cloud"? Even if it
is 100% properly encrypted, I can't say that I feel good about this. Feels
like one bug away from compromising many people's wallets.

~~~
jimrandomh
No, it does not.

~~~
wes-exp
Are you sure? Why does the restore process require a server address?

[https://electrum.org/seed.html](https://electrum.org/seed.html)

The screenshot uses ecdsa.org, which seems to be just an Electrum server of
some kind.

~~~
bglusman
Pretty sure that's because Electrum doesn't download the entire blockchain but
relies on servers for most of it and only downloads a certain amount of recent
history and trusts servers for older history. And it doesn't have to be that
server, which is why app lets you change the URL, any server serving
blockchain history you trust is fine. It's using your passphrase as the one
and only seed for key generation, so it can reliably generate same private key
every time. Someone correct me if I'm mistaken on any details.

------
betterunix
The paper is very light on details. I am not even sure what security property
is being achieved here. Is it some kind of group blind signatures protocol?
Some kind of threshold system? Some kind of special-purpose multiparty
computation protocol?

~~~
oleganza
The paper only discusses blind signature algorithm: how to prepare a "blinded"
public key and then produce a matching signature, also blinded from the
signer. The primary motivation is to use such blinded public keys in the
standard Bitcoin multisignature transactions. That is, transactions, using N
public keys and requiring M signatures (M <= N). "Multiparty computation" with
"threshold system" here are provided by Bitcoin automatically, paper does not
discuss that. But it shows how such multiparty signing can be done absolutely
privately, when neither party (except for initiator and holder of funds) can
learn which transaction they allowed to spend.

~~~
betterunix
"The paper only discusses blind signature algorithm"

No, it seems to discuss something else. It starts out talking about blind
signatures, then veers off with claims like this:

"The novelty of the scheme is that unlike the original Chaum blind signature
scheme, this one does _not allow anyone to prove that the signing party signed
a particular message_ "

I am not actually sure what you are trying to say there. Does it mean that I
can only narrow down the possible signers to some group? Does it mean that the
signature key is ephemeral, yet somehow meaningful?

To put it another way, what differentiates your proposal from this:

[https://eprint.iacr.org/2011/402.pdf](https://eprint.iacr.org/2011/402.pdf)

""Multiparty computation" with "threshold system" here are provided by Bitcoin
automatically, "

What? Where? Citation needed.

~~~
JoeAltmaier
Yeah confused. If you can't tell who signed a particular message, then what
are signatures for? I thought they were for authentication, which means the
message was not modified, and, I know who sent it.

------
JacobH
A "blind signature" sounds like an odd concept.

What can be done I just thought up is adding another transport layer to
bitcoin. And breaking up and distributing the wallet's contents "sum" among
strangers into something like a checksum. Then on transactions bringing the
chunks of checksum partially back together.

How it's broken down can vary. you have to remember though, if you are buying
something for $10 all that needs to be verified is that you have $10 or more
for the next step.

~~~
oleganza
The scheme allows never holding all secret pieces in one place to make a
transaction. Otherwise, if your machine is compromised, someone can send your
money elsewhere. I don't quite understand your proposal, but it requires
having all chunks in one place to make a transaction.

------
JacobH
Something that also just came to me, instead of having one large sum on money
in one wallet. Who says it can't be distributed and broken down in max wallet
sizes of $50 or so. $50 is a common number no one should really care too much
about. So there goes your concern about being able to see wallet size. If
something costs more than $50 group multiple wallets into the transaction.

~~~
Retric
And how do you plan to realistically manage 200 such wallet's? Realistically
you would have a computer somewhere know there key's which introduces the same
inherent risk as having that computer manage a single wallet.

If you really want secure storage you print out your private key's and store
them in one or more vaults. If your even more paranoid you can encrypt the
information such that you need more than one vault to access the data, but
have some redundancy so if one storage location floods you don't lose any bit-
coins. Which is where these N of M encryption schemes become useful.

~~~
JacobH
The idea is less about losing coin, and more about concealing wallet size from
people that don't need to know about how much money is in a bitcoin wallet.

My idea is more along the lines of instead of pulling out a wad of money
you're only pulling out $50 at a time.

Me personally, I don't mind the wallet amount being public because for things
lie fundraising it keeps people honest.

~~~
hendzen
In the bitcoin world, this technique is known as "merge avoidance" \- read
about it here: [https://medium.com/bitcoin-
banter/7f95a386692f](https://medium.com/bitcoin-banter/7f95a386692f)

------
natrius
Why would you use this instead of a warp wallet?

[https://keybase.io/warp/](https://keybase.io/warp/)

~~~
oleganza
Good question. I answered it in the paper (just 8 pages) which you obviously
haven't read before asking.

Keybase is a single point of failure. Or your machine that will do KDF. M-of-N
multisig transactions are way safer because to sign a specific transaction you
never need to have all secret material at once on a single machine. If my PC
is compromised, I can still independently verify specific transaction I want
to sign and send it out to my friends to sign. All their private keys are
stored on independent machines which normally aren't compromised altogether by
the same attacker.

On specific problem with brainwallets - low entropy. One specific problem with
web apps: no code signing. Even if your SSL pubkey is pinned (which is not
supported by any browser yet), the code you receive from the server is never
remembered and pinned (like with installed apps). If their server is silently
compromised tomorrow, someone may humbly hijack keys of 1% of the users and go
undetected for quite some time.

~~~
j_s

      > which you obviously haven't read before asking
    

This blew my mind; so unkind!

~~~
oleganza
Sorry, but the question was quite disrespectful. We are presenting a high-
security solution to an important problem and the ignorant observer proposes
to use something extremely unsafe and insecure as an alternative without even
trying to understand the problem.

Here's the motivation, right on the first page:

"This can be viewed as an ultimate solution for secure storage of bitcoins as
no individual computer system can be fully trusted (e.g. even RNG may leak
information about private keys through ECDSA signatures [5]). By spreading the
trust between several independently operating computers the risk is
significantly reduced. The attacker not only has to compromise several
computers instead of just one, but beforehand they must find out which
computers are involved (which is made much harder when blind signatures are
being exchanged). Therefore the scheme enables safer Bitcoin storage on
conventional personal computers and smartphones without need for specialized
hardware or compromising privacy."

To my excuse, I only allowed myself to be a bit arrogant while providing a
respectful answer anyway. This both answers the question and signals that
something can be improved in the discussion.

