I have learned recently that brainwallets are not a good idea, mostly because I lurk the bitcoin reddit and I think I saw you posting about it.

Now my fear/question is: are Electrum seeds also compromised? In theory isn't it the same as brainwallets? It creates a seed and this seed contains everything. I think the new HD wallet in bitcoin core is not like that (you can't "spawn" everything with a single seed) but with electrum it seems the same idea to me than brainwallets and now im worried... (im not a coder or anything so I dont understand the details, it just seems the same to me in practice)

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.

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.

We do not have time nor resources to provide support for an OS that isend-of-life. From 0.13.0 on, Windows XP is no longer supported. Users aresuggested to upgrade to a newer version of Windows, or install an alternative OSthat 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 notreport 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.

When a newly created transaction failed to enter the mempool due tothe limits on chains of unconfirmed transactions the sending RPCcalls would return an error. The transaction would still be queuedin the wallet and, once some of the parent transactions wereconfirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattemptmempool insertion at the same time transaction rebroadcast isattempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempoolcan 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 affectbehavior, not code moves, refactors and string updates. For convenience in locatingthe code changes and accompanying discussion, both the pull request andgit merge commit are mentioned.

Just because 95% of the blocks that the miners produce doesn't mean that non-mining Bitcoin related companies and other Bitcoin users support SegWit (Note: ready to implement != support).

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.

Quote

Technically speaking, the threshold is 50.694% (or potentially less depending on luck) for activation as the miners who support SegWit could decide to ignore blocks that lack a signal of support for SegWit.

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

Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?

So that the soft fork deploys with supermajority. It will essentially have consensus when it deploys. This ensures that the new rules will be deployed and enforced by the miners. The 95% rule has been used for all previous soft forks, no reason to change that now.

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.

But then you come back to the problem of choosing the secure password, don't you?Which brings you back to the point that you need to learn about choosing secure passwords.

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.

Sorry, I didn't mean that they cannot be seized by any type of government.Mine isn't running a torture camp in Guantanamo - applying a hammer to my head would be illegal where I live. Plus then I'd most definitely forget it

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.

Also nobody is talking about the advantages of (strong) brain wallets, that are actually making them more secure than PRNG based wallets.

Besides of the two I mentioned already:- They don't rely on anyone's (publicly known) implementation of the "entropy"

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?

Quote

- 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!

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!

Quote

There is more:- They cannot be seized

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.

Quote

- They don't need to be carried

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.

Quote

- Their existence can be denied- Even if someone can prove that a brain wallet had existed at some point in time, he's still unable to prove that you have not forgotten the password

Both equally true for an encrypted non-brainwallet.

Quote

You see, in my opinion, the biggest enemy of the brain wallets should be the government.

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.

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?

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.

2. Anyone spending unconfirmed transactionsThis was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement

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.

Quote

but segwit just offloads the risk to a third party like any side-chain as was intended in the original design.

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.

Quote

None of them are peculiar to SegWit but #3 requires it.

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

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.

I would have gone for |r| and |s| personally so no explicit rejection would be required. I wasn't sure that N-s was negative for all values of N,

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

Quote

both DER encoding and ECDSA malleability are already addressed and not usable as a "malleability fix" argument for SegWit.

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.

Quote

It would be a side-chain if the changes weren't being implemented. I do indeed know nothing about LN.

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

Quote

The driver for SegWit seems to be purely LN

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.

Quote

2. It is the architecturally correct solution for outsourcing the txID generation-that's it. If you are going to do that, then make it a plugin module then it doesn't need to be in Bitcoin at all and anyone can use their own, including legacy (maybe a default module). It is a poor solution just for malleability and a straight-jacket for txID generation.

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.

But if you had to choose between submitting a 100 kb block and not submitting a block at all... You're going to submit the 100 kb block, obviously. You are still getting 12.5 BTC and are confirming a sizable number transactions.

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

Quote

When a 100 kb block is solved, 900 kb of capacity was not just lost. The miner responsible introduced 100 kb of capacity. Not 1 mb, but still a lot more than zero. Mining is all probabilistic, remember. The block could never have been solved at all, and the mempool would be 100 kb bigger as a result.

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.

Quote

Even if a block has no transactions at all other than the coinbase - which does not happen a lot nowadays except in some technical cases - the block is still improving the integrity of the block chain, giving recently confirmed transactions and blocks another confirmation, and introducing 12.5 BTC to most likely many people at once (enthusiasts like you and me). It is not by any means a waste and should not be considered unwelcome or inappropriate.

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.

my node uploads about 700MB a day .... i wouldnt call that a lot of bandwidth

You probably aren't accepting inbound connections, or are potentially in a /16 with many other nodes so you are connected to less often. About 300GB/month transfer is not atypical for a node with inbound connections.

Segwit doesn't have anything to do with lightning. Lightning is already possible without it and can't be blocked. So if you're against having actual scalablity in Bitcoin: well too bad and fuck you: you already lost the day Satoshi released the software. Similar, sidechains at least of the federated type are existing, unblockable, and undetectable. If you want to force other people to not use them? Again too bad. You can't.

BitcoinBarrel, the notice in your software has nothing to do with segwit. You're inconsistent with the network because you're not even running something that implements CSV. You should at least run 0.13.0; if you do you won't get a notice until segwit activates.