If we aren't continually filling blocks then that is a disaster.

...


Ask me again if you ever see me advocating solutions which are have resulted in lots of funds loss in practice... or selling wallet cracking tools.

The two main problems problems with brainwallets is that (1) humans created the randomness and humans are surprisingly bad at that (and, worse, can't tell how bad they are) and (2) they depend on human memory to perfectly remember a long highly random string.  Human memory is not very good at this either.

Electrum seeds, used correctly, don't have either of these problems.

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.

0.13.2 is out and here is the release announcement:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bitcoin Core version 0.13.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.13.2/>

Or by bittorrent:

  magnet:?xt=urn:btih:746697d03db3ff531158b1133bab5d1e4cef4e5a&dn=bitcoin-core-0.13.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  <https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <https://bitcoincore.org/en/list/announcements/join/>

Compatibility
==============

Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

- From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes
===============

Change to wallet handling of mempool rejection
- -----------------------------------------------

When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error.  The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).


0.13.2 Change log
=================

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### Consensus
- - #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell)
- - #9053 `5b93eee` IBD using chainwork instead of height and not using header timestamps (gmaxwell)

### RPC and other APIs
- - #8845 `1d048b9` Don't return the address of a P2SH of a P2SH (jnewbery)
- - #9041 `87fbced` keypoololdest denote Unix epoch, not GMT (s-matthew-english)
- - #9122 `f82c81b` fix getnettotals RPC description about timemillis (visvirial)
- - #9042 `5bcb05d` [rpc] ParseHash: Fail when length is not 64 (MarcoFalke)
- - #9194 `f26dab7` Add option to return non-segwit serialization via rpc (instagibbs)
- - #9347 `b711390` [0.13.2] wallet/rpc backports (MarcoFalke)
- - #9292 `c365556` Complain when unknown rpcserialversion is specified (sipa)
- - #9322 `49a612f` [qa] Don't set unknown rpcserialversion (MarcoFalke)

### Block and transaction handling
- - #8357 `ce0d817` [mempool] Fix relaypriority calculation error (maiiz)
- - #9267 `0a4aa87` [0.13 backport #9239] Disable fee estimates for a confirm target of 1 block (morcos)
- - #9196 `0c09d9f` Send tip change notification from invalidateblock (ryanofsky)

### P2P protocol and network code
- - #8995 `9ef3875` Add missing cs_main lock to ::GETBLOCKTXN processing (TheBlueMatt)
- - #9234 `94531b5` torcontrol: Explicitly request RSA1024 private key (laanwj)
- - #8637 `2cad5db` Compact Block Tweaks (rebase of #8235) (sipa)
- - #9058 `286e548` Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (ryanofsky)
- - #8865 `4c71fc4` Decouple peer-processing-logic from block-connection-logic (TheBlueMatt)
- - #9117 `6fe3981` net: don't send feefilter messages before the version handshake is complete (theuni)
- - #9188 `ca1fd75` Make orphan parent fetching ask for witnesses (gmaxwell)
- - #9052 `3a3bcbf` Use RelevantServices instead of node_network in AttemptToEvict (gmaxwell)
- - #9048 `9460771` [0.13 backport #9026] Fix handling of invalid compact blocks (sdaftuar)
- - #9357 `03b6f62` [0.13 backport #9352] Attempt reconstruction from all compact block announcements (sdaftuar)
- - #9189 `b96a8f7` Always add default_witness_commitment with GBT client support (sipa)
- - #9253 `28d0f22` Fix calculation of number of bound sockets to use (TheBlueMatt)
- - #9199 `da5a16b` Always drop the least preferred HB peer when adding a new one (gmaxwell)

### Build system
- - #9169 `d1b4da9` build: fix qt5.7 build under macOS (theuni)
- - #9326 `a0f7ece` Update for OpenSSL 1.1 API (gmaxwell)
- - #9224 `396c405` Prevent FD_SETSIZE error building on OpenBSD (ivdsangen)

### GUI
- - #8972 `6f86b53` Make warnings label selectable (jonasschnelli) (MarcoFalke)
- - #9185 `6d70a73` Fix coincontrol sort issue (jonasschnelli)
- - #9094 `5f3a12c` Use correct conversion function for boost::path datadir (laanwj)
- - #8908 `4a974b2` Update bitcoin-qt.desktop (s-matthew-english)
- - #9190 `dc46b10` Plug many memory leaks (laanwj)

### Wallet
- - #9290 `35174a0` Make RelayWalletTransaction attempt to AcceptToMemoryPool (gmaxwell)
- - #9295 `43bcfca` Bugfix: Fundrawtransaction: don't terminate when keypool is empty (jonasschnelli)
- - #9302 `f5d606e` Return txid even if ATMP fails for new transaction (sipa)
- - #9262 `fe39f26` Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs)

### Tests and QA
- - #9159 `eca9b46` Wait for specific block announcement in p2p-compactblocks (ryanofsky)
- - #9186 `dccdc3a` Fix use-after-free in scheduler tests (laanwj)
- - #9168 `3107280` Add assert_raises_message to check specific error message (mrbandrews)
- - #9191 `29435db` 0.13.2 Backports (MarcoFalke)
- - #9077 `1d4c884` Increase wallet-dump RPC timeout (ryanofsky)
- - #9098 `ecd7db5` Handle zombies and cluttered tmpdirs (MarcoFalke)
- - #8927 `387ec9d` Add script tests for FindAndDelete in pre-segwit and segwit scripts (jl2012)
- - #9200 `eebc699` bench: Fix subtle counting issue when rescaling iteration count (laanwj)

### Miscellaneous
- - #8838 `094848b` Calculate size and weight of block correctly in CreateNewBlock() (jnewbery)
- - #8920 `40169dc` Set minimum required Boost to 1.47.0 (fanquake)
- - #9251 `a710a43` Improvement of documentation of command line parameter 'whitelist' (wodry)
- - #8932 `106da69` Allow bitcoin-tx to create v2 transactions (btcdrak)
- - #8929 `12428b4` add software-properties-common (sigwo)
- - #9120 `08d1c90` bug: Missed one "return false" in recent refactoring in #9067 (UdjinM6)
- - #9067 `f85ee01` Fix exit codes (UdjinM6)
- - #9340 `fb987b3` [0.13] Update secp256k1 subtree (MarcoFalke)
- - #9229 `b172377` Remove calls to getaddrinfo_a (TheBlueMatt)

Credits
=======

Thanks to everyone who directly contributed to this release:

- - Alex Morcos
- - BtcDrak
- - Cory Fields
- - fanquake
- - Gregory Maxwell
- - Gregory Sanders
- - instagibbs
- - Ivo van der Sangen
- - jnewbery
- - Johnson Lau
- - Jonas Schnelli
- - Luke Dashjr
- - maiiz
- - MarcoFalke
- - Masahiko Hyuga
- - Matt Corallo
- - matthias
- - mrbandrews
- - Pavel Janík
- - Pieter Wuille
- - randy-waterhouse
- - Russell Yanofsky
- - S. Matthew English
- - Steven
- - Suhas Daftuar
- - UdjinM6
- - Wladimir J. van der Laan
- - wodry

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJYa2IbAAoJEHSBCwEjRsmmiQsIALbkHVVwO7nViQKH1Ub2qpD4
TplOuAP0/4vYotizuI12Gqdnu8SjPmhKwAgIXhVinE6TS4OzGNjy+6LtWGzpcpud
B1pcziZ72Mlfxdbdd1UhDMWEjoBumS9RmXMSqzTlMVlHRv4iiISzdaAROu1jHvdF
YTsnmKXB8OvcXOecxRMY9LrnpSzLALM2MYTDmYwlhhExHIA8ZqI2niky6GCfyfDi
KD7bgfIFJzlgFTpAdhQXOXtWoRV5iHqN7T29ot8Y+yIhVCRhHYXS93Z50GKbkqYV
MXsVAkpZF3qqcKYSPFjbif7faMdrMqcEiII6QhXdDTRGI/35IfuTDbWzzQlnVyY=
=ncCY
-----END PGP SIGNATURE-----

Well no one is forced to implement it; so ready to implement does suggest a small amount of support at least. FWIW, before segwit's activation was set in Bitcoin Core I reached out directly to most of the non-mining Bitcoin related companies that I could fine to specifically prompt for opposition. I received back many positive responses, none opposed, and the only negative comment was from a party that hoped activation would take longer so they would have more time to add support-- it's still possible that they don't support it,  apparently not enough to send a respond saying so. After that there was a public discussion on the bitcoin-development list and the only party that argued against it was Tom Zander.

Yep, only just over half is strictly needed if they're willing to orphan the other almost-half.

Arubi doesn't have a bitcointalk account, and saw others being blamed for their transaction and asked me to post this:

Not all-- we've increased it over time in response to prior instability and as we all learned better the implications.  BIP30 just used a 'past this time' decree. BIP16 was based on 55% and just used a time for the actual activation, and resulted in months of low levels of orphaned blocks being produced.  Satoshi used several hard cut softforks that were just triggered on blockheights.  BIP34 was the first to use 95% but it actually started enforcing the rules for a subset of blocks at 75%.

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  But we saw no reason to lower the criteria:  basically when it activates the 95% will have to be willing to potentially orphan the blocks of the 5% that remain if they happen to mine invalid blocks.   If there is some reason when the users of Bitcoin would rather have it activate at 90%  (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

So basically setting the criteria high protects the stability of the network in the common case, but never ties anyone's hands against something not activating. By default the safest thing happens, but no one can exploit this in an attack.

Because of this, the trade-offs favor a high threshold.

Ah ha, but no-- the requirements for the password security are much lower.

With a brainwallet, the moment you use it everyone in the world can begin cracking it-- in parallel with all other keys they are cracking at no extra cost.  They can also apply precomputed rainbow tables to try may of the passwords they tested in the past against it-- at low cost. They also can see the bounty attached to it.

If a wallet is encrypted it has a salt and (hopefully) an expensive KDF. The attacker cannot attack multiple files in parallel. If the whole wallet is encrypted, they don't know what their payoff will be and most importantly they can't even begin cracking until they get the file.  The security becomes multi-factor: You must have the file and the passphrase.  Theft of the file may also be noticed, giving you time to react.

So if your passphrase is a little weaker than you intended it to be-- there is likely no great harm.

Hand, not head, for that reason!   (also, hitting people in the head tends to make them unconscious and then they can't answer. Hitting them in the hand is very painful but leaves them able to talk.)

Especially if you're not worried about torture-- use encryption! it also resists seizure in just the same way-- but: it works like a salted password hash stored privately. O(N*M) work to try N passwords for M people, and to even start you must steal a copy of the private data which you have hopefully not posted in a public database.  If you want to generate it securely and _also_ attempt to memorize it, sure knock yourself out, an extra backup doesn't hurt.

Unless you never intend to sign a message they do... and they also depend on a human's easily predictable production of "entropy".

There are hundreds of millions of dollars worth of Bitcoin secured by the CSPRNG setup in Bitcoin Core. It is peer reviewed by quite a few subject matter experts. That is a pretty strong bit of auditing there, ... can you say the same for your scheme?

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!

Backups are also easy if you don't need to redo them. They are practically free:  A small USB stick costs a few dollars, paper costs cents. You can make many backups and secure them with a weak password that your family also knows and really can never be forgotten-- but attackers with a FPGA farm in china cannot crack your password protected backed up wallet!

Equally true of a pasword protected backup wallet.  And both can be seized after finding evidence of you using them in the blockchain or on your computer and then liberally applying a hammer to your non-dominant hand.

Yes, this is perhaps the one advantage-- if you are a refugee who can literally carry _nothing_ without severe risk of losing it. But even there you would be much better off with a few backups of that key securely hidden back at home in case you do forget it and do someday find yourself in a place where you can pick it up.

Both equally true for an encrypted non-brainwallet.

Brainwallets are irrelevant to the government-- they don't add any protection from the a government except in the refugee case, but they are the friend of the coin thieves -- no surprise considering they were invented by one.

You seem to have ignored my point that a brainwallet is equivalent to storing an unsalted password hash in a public database. Do you consider that incompetent security?

The advice would be to have a computer generate it randomly.  (the next best advice is to choose it with dice but it takes so many rolls to even get 128 bits, that I have found that users don't actually comply with the procedure; a treatment that the patient will not follow is not a good treatment, no matter how perfect it is if used flawlessly). Studying the result in practice isn't politics, it's science.  Developers are not magically anointed with an ability to not make these errors, they appear to be even more vulnerable: to quick to enamor themselves with fancy schemes but just as unable to really comprehend billions of attempts per second as any other human. It isn't a question of being stupid, I do not think I can securely use a brainwallet and I do not think I am stupid.

No, it's not true.

Brainwallets were literally invented by someone who was out to rip people off; no joke!

piotr_n: Errors like you talk about are what happen sometimes when technical experts given all the time in the world work on secure entropy.  What do you think will happen when you ask less technical end users to take care of it for themselves?

Predictable failure, that is what results. And, of course, if your crypto code is broken-- your security is toast anyways: your signatures will give away your key.

People _massively_ overestimate their ability to choose unguessable strings. They come up with absurd munging schemes that are easily predicted and exploited by attackers.  The result is that brainwallets cause funds loss _constantly_.

Why is it when it turns out that some website was using an unsalted hashing scheme to store their users password hashes in a private database people pull out the torches about how incompetent the web developer is-- but when people construct brainwallet software which stores the users hashed password in a PUBLIC database-- unsalted-- where every found password results in an irreversable theft of Bitcoin, some people fall over themselves to recommend it?

... because that is exactly what a brainwallet is doing:  A public key is a hash of the private key (with special homomorphic properties that makes it useful for signatures). When you use a brainwallet you are computing an unsalted password hash and sticking it in a public database along with the amount you can steal by cracking it.  Because they are unsalted, an attacker can target N users with ~O(1) effort just like any other unsalted password hash.

Again, you are showing profound confusion.  If you do not spend _your own_ unconfirmed coins you can be restricted to make only a _single_ transaction until you receive a confirmation... meaning you might easily be waiting an hour before you can make a second payment after making a first while waiting on a block.

Without the ability to spend unconfirmed transactions you cannot engage in many useful protocols like cross chain atomic swaps or coinswaps.


A bit of a wrinkle there. Tracking if a payment has been made is what I was referring to above, but that text is referring to needing code to _unfuck_ a wallet after a chain of transactions has been disrupted with malleability. I'm not aware of any wallet that does this today, not even core. It too hard to do right, compared to just fixing the malleability. The distinction is that no amount of "modular" cosmetic ID can help that, because once the transaction chain is broken, it's broken.  Previously I was responding above the kind of cosmetic issues you were discussing when you suggested that a non-normative ID could help.


You are just spouting nonsense here. Who is the third party? What risk is offloaded?  I think at this point you are literally just making things up and not even earnestly expressing your own confused views.

Lightning does not require segwit. Simply repeating it over and over again will not make it true.

An ECDSA signature itself does not prove knowledge of a discrete log.

You can pick a random message and a random signature  then compute the public key this signature,message pair would be valid for.

To accomplish this, you must-- of course-- make sure the message does not contain any commitment to the public key.

Bitcoin's signatures include a commitment to the scriptPubkey-- but nothing requires you to have the EC public key there.

This cute construction is not secure: if you'd seen that txn before confirmation you could have modified the destination and computed a new pubkey.

If you take a look at Roconnor's covenants post you'll see he uses the same kind of pubkey recovery to turn checksig into an operation for verifying a hash of the masked transaction-- which otherwise the script doesn't have access to.

You are showing an impressive level of ignorance here: N-s is _never_ negative, s is a field element.  

Malleability in Bitcoin goes far beyond just signature encoding malleability. Multistep multiparty protocols like coinswap require that the other signer in a 2 of 2 not be able to invalidate a chain (or extreme amount of additional protocol phases); this can never be accomplished with a DL signature since they inherently must have a random input, so long as the signature itself is part of the identifier. Segwit's approach to eliminating signature malleability gives a guaranteed solution to all forms that would potentially invalidate a chain of transactions.

There has only ever been one other proposal that provided an equally complete solution, but it had the downside of doubling the UTXO set size and roughly doubling the amount of transaction hashing work.


Clearly you don't-- because this statement makes no sense.


This is an rbtc talking point-- it has no basis in reality.   Segwit is largely orthogonal to lightning, and proposed long after it. The reason people keep claiming it is because segwit is above reproach and lightning is less well understood and easier to FUD.


You seem to be confused about what a txid is really used for.   From your comments it seems that you think that wallets are somehow distinguishing payments that way. That isn't the right way to distinguish a payment... Bitcoin Core doesn't, it tracks outpoints (either as inputs for conflict handling or outputs for payments).  No one cares much about the cosmetic implications of malleability, they're largely irrelevant.

Transaction IDs are an essential part of the Bitcoin consensus rules. A transaction selects the coins it will spend by specifying the transaction IDs of the transactions that created those coins.  These IDs are included under the subsequent transaction's signature.  If something happens to change a transaction's TXID then all subsequent descendant transactions are invalidated. This is what people care about.

No amount of module whatever can do anything to help that.  So what you propose would only ad a cosmetic issue that almost no one cares about ('I can't look up the txid I was expecting in a block explorer')-- and if anyone cared it would already be solved, as it's not a consensus change.

That isn't actually the choice being made here-- tiny blocks are created even when there is plenty of reasonably high fee paying backlog.

At an instant this is true, but the empty block still serves to increase the difficulty and reduce the rate of block finding in the next interval. If it happens on an ongoing basis it does reduce capacity.


Unfortunately the parties producing small blocks do so because they haven't validated the prior block. So they add only a false confirmation and erode the security of lite clients rather than contributing to security as empty blocks did in prior years before this practice became common.

Not just done in Bitcoin, but we came up with that improvement; and ripple borrowed it long after-- including the code for it. I put him on ignore after that post: There is nothing worse to deal with in this subforum than a chest-thumping altcoin promoter bragging about an altcoin being superior on the basis of code or techniques they coped from Bitcoin Core.

This article is overtly dishonest. I rebutted it on reddit. I think it's shameful that Tom is either so ignorant or so outrageously dishonest to have published such a thing.