Oh, dear. Please do not use brainwallets! Brainwallets are
insecure. AVOID.I call brainwallets
“wallets for the brainless”; but you needn’t take my word for it:
I think it's amusing that the two people in this thread loudly trumpeting brainwallets are someone who says they have a fetish for cracking passwords and someone who has posted extensively about wallet cracking and tried to sell scam wallet cracking tools.
This fits right in with the fact that person who popularized the idea and created brainwallet.org was cracking these kinds of keys and complaining about how few he was finding online before creating the site.
Food for thought.
It is highly NOT RECOMMENDED to use brainwallets. Humans are a horrendously low source of entropy. There are multiple research papers and programs that show that brainwallets are horribly insecure and easily cracked as what you think is a strong password probably is not a strong password.
BIP 38 paper wallets will not be particularly helpful here. It only protects against someone stealing your paper wallet and trying to get the keys. BIP 38 does not protect against someone just guessing the password you used to create your brainwallet.
Generally, my assumption is that when an otherwise intelligent person advocates for brainwallets, it's because they are hoping that foolish people with weak passphrases will store significant sums of bitcoin that they can later steal.
If you want to personally use a brainwallet. Go ahead. None of us are stopping you. However, if you are going to advocate for them, then foolish people will read what you write and will lose money.
Not only that: Long-term storage of funds inside your head is more likely than you think to lead to funds being literally
forgotten—and thus lost forever, if somebody else doesn’t helpfully steal them.
- They don't require backups
Human memory is very fallible. We often just don't remember what we don't remember so we don't often realize how bad it is. A fever, blow to the head, or other illness can easily kill single memories even of things you used frequently-- a brain wallet is the hardest kind to remember: to be secure it must be unusually random, and you should not be using it frequently (if you use it frequently, you will end up leaking it somehow) and being almost right is not good enough!
Native Segwit Addresses aren't supported by the wallets Joe and Bill Gator use.
This is something I am looking to remedy for future rounds.
I'm open to suggestions, but I'm thinking I will probably just use my Electrum wallet for Native SegWit addresses. I believe I can transfer from Core to Electrum, so that's probably what I'll do so that we don't discourage SegWit usage. I suppose I don't even need to transfer it over to Electrum, could just send it directly from Core to the Native SegWit addresses of participants. It's something I'm perfectly willing and happy to do for participants. I just had a bit of a brain hiccup when it came time to send the winnings at the end of last round, because I was in quite a rush and didn't have time to consider the solutions.
There are no Nested SegWit wallets/clients that offer compatibility with Native SegWit addresses that I know of; is there such a thing currently? There might be technical complications that I'm failing to consider that make this impossible for now.
I would have suggested Electrum, but now I’m confused. If you run Core, then what is the problem? Core v0.16 has full Segwit support, including in the GUI. It can send to both native (BIP173/Bech32) and P2SH-nested Segwit addresses, as well as generating both types of addresses for receiving.
Bitcoin Core version 0.16.0 is now available from:
https://bitcoincore.org/bin/bitcoin-core-0.16.0[...]
### Segwit Wallet
Bitcoin Core 0.16.0 introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.
[...]
### BIP173 (Bech32) Address support ("bc1..." addresses)
Full support for native segwit addresses (BIP173 / Bech32) has now been added.
This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these
addresses (including as default new addresses, see above).
A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with `-addresstype=bech32` it is checked by default. When launched with `-addresstype=legacy` it is unchecked and disabled.
