<blockquote>
  <p>In particular, is there a way to make it so that it is impossible to know if a transaction signed with a password is correct unless its part of a mined block? This way, even if your password only requires 1,000,000 tries to crack, the attacker needs to mine 1,000,000 blocks to bruteforce the password?</p>
</blockquote>

<p>I'm not aware of any cryptographic constructions that would let you do that. The closest thing I can think of is increasing the number of iterations of the password derivation function so that the amount of work required is similar to the amount of work required for creating a block.</p>

<blockquote>
  <p>Although it is tempting to say that blocks with invalid passwords are invalid (so our malicious miner doesn't even get to keep what he mined), this would put honest miners at risk of receiving invalid transactions and losing their mined coins. Therefore, invalid transactions would just have to be ignored.</p>
</blockquote>

<p>That doesn't completely fix things, though. If someone on the network is trying to bruteforce a password by submitting lots of transactions, the miner is going to see a thousand invalid transactions for each valid one. This means that the honest miners almost never earn fees for their block, and that legitimate transactions almost never go through.</p>

<hr>

<p>You've got the right idea in trying to prevent an offline attack against a password, though. You should look at <a href="http://justmoon.github.io/pakdf/" rel="nofollow">Peer Assisted Key Derivation</a>.</p>

CC BY-SA 3.0
2016-05-08T14:28:48.823Z
Do you have any ideas on changes to the protocol to prevent people using honest nodes the brute force passwords? (Maybe small proof of work to submit transactions?)
Christopher King
CC BY-SA 3.0
2016-05-08T15:07:29.707Z
@PyRulez Yeah, you could do that. I'm not sure it'd be enough, though.
Nick ODell
CC BY-SA 3.0
2016-05-18T01:32:07.087Z
Oh, I think I know what you could do. You make it based on keys like normal, but you can *change* the key of an address using a password. To do so, you need to pay a fee from a working account (so you'll need someone who hasn't lost their private key to help you, or make a new account and get some coins), but this fee would be on the order of a transaction fee. That is still enough to defeat brute force, but shouldn't make losing your keys too much of a burden (for long term secure storage, you could reasonably burn your key and recover it later).
Christopher King
CC BY-SA 3.0
2016-05-18T01:32:44.463Z
Of course, that doesn't solve the main problem of *how* you make the password checking blockchain based, but its a start.
Christopher King
CC BY-SA 3.0
2016-05-08T14:18:26.060Z
2016-05-08T14:18:26.060Z
Nick ODell
<p>Bitcoin is key based. Although it is possible to <a href="https://en.wikipedia.org/wiki/PBKDF2" rel="nofollow">convert a password into a key</a>, publishing the public key makes it vulnerable to brute force. Currently, passwords are used with Bitcoin, but only to protect keys (if the key is lost, your money is lost. Publishing the key in a public place is bad idea because brute force.) Is there a way to you can use passwords, but make checking the password require mining a block?</p>

<p>In particular, is there a way to make it so that it is impossible to know if a transaction signed with a password is correct <em>unless its part of a mined block</em>? This way, even if your password only requires 1,000,000 tries to crack, the attacker needs to mine 1,000,000 blocks to bruteforce the password?</p>

<ul>
<li>In particular, once they have mined a block, if you change the password, the proof of work becomes invalid, and you need to generate a new one before you can check the new password.</li>
<li>Although it is tempting to say that blocks with invalid passwords are invalid (so our malicious miner doesn't even get to keep what he mined), this would put honest miners at risk of receiving invalid transactions and losing their mined coins. Therefore, invalid transactions would just have to be ignored.</li>
<li>Users could change their password by simply creating a new account and transferring their funds to that.</li>
</ul>

<p>Is this possible? Does any cryptocurrency currently do this?</p>

<passphrase>
Can you have a password based cryptocurrency?
Christopher King
# Can you have a password based cryptocurrency?

(Asked by: username_0 on 2016-05-07)

Bitcoin is key based. Although it is possible to [convert a password into a key](https://en.wikipedia.org/wiki/PBKDF2), publishing the public key makes it vulnerable to brute force. Currently, passwords are used with Bitcoin, but only to protect keys (if the key is lost, your money is lost. Publishing the key in a public place is bad idea because brute force.) Is there a way to you can use passwords, but make checking the password require mining a block?

In particular, is there a way to make it so that it is impossible to know if a transaction signed with a password is correct *unless its part of a mined block*? This way, even if your password only requires 1,000,000 tries to crack, the attacker needs to mine 1,000,000 blocks to bruteforce the password?

* In particular, once they have mined a block, if you change the password, the proof of work becomes invalid, and you need to generate a new one before you can check the new password.
* Although it is tempting to say that blocks with invalid passwords are invalid (so our malicious miner doesn't even get to keep what he mined), this would put honest miners at risk of receiving invalid transactions and losing their mined coins. Therefore, invalid transactions would just have to be ignored.
* Users could change their password by simply creating a new account and transferring their funds to that.

Is this possible? Does any cryptocurrency currently do this?

**Tags:** passphrase


---

## 1 answers

### Answer by username_1 on 2016-05-08. Score: 3

> In particular, is there a way to make it so that it is impossible to know if a transaction signed with a password is correct unless its part of a mined block? This way, even if your password only requires 1,000,000 tries to crack, the attacker needs to mine 1,000,000 blocks to bruteforce the password?

I'm not aware of any cryptographic constructions that would let you do that. The closest thing I can think of is increasing the number of iterations of the password derivation function so that the amount of work required is similar to the amount of work required for creating a block.

> Although it is tempting to say that blocks with invalid passwords are invalid (so our malicious miner doesn't even get to keep what he mined), this would put honest miners at risk of receiving invalid transactions and losing their mined coins. Therefore, invalid transactions would just have to be ignored.

That doesn't completely fix things, though. If someone on the network is trying to bruteforce a password by submitting lots of transactions, the miner is going to see a thousand invalid transactions for each valid one. This means that the honest miners almost never earn fees for their block, and that legitimate transactions almost never go through.

---

You've got the right idea in trying to prevent an offline attack against a password, though. You should look at [Peer Assisted Key Derivation](http://justmoon.github.io/pakdf/).

> **Comments:**
> **username_0**: Do you have any ideas on changes to the protocol to prevent people using honest nodes the brute force passwords? (Maybe small proof of work to submit transactions?)  
> **username_1**: @PyRulez Yeah, you could do that. I'm not sure it'd be enough, though.  
> **username_0**: Oh, I think I know what you could do. You make it based on keys like normal, but you can *change* the key of an address using a password. To do so, you need to pay a fee from a working account (so you'll need someone who hasn't lost their private key to help you, or make a new account and get some coins), but this fee would be on the order of a transaction fee. That is still enough to defeat brute force, but shouldn't make losing your keys too much of a burden (for long term secure storage, you could reasonably burn your key and recover it later).  
> **username_0**: Of course, that doesn't solve the main problem of *how* you make the password checking blockchain based, but its a start.  

---

