This was the primary way of RBF at that time when there were plans to either get FSS-RBF or Opt-in RBF on the network. There are many different risks and hassle with FSS-RBF, namely with it being subjective to the different miners and that it provides a false sense of security with no security benefits whatsoever. It was only adopted by Discus Fish (AKA. F2Pool) and dropped shortly afterwards. RBF (Opt-in or not) does not prevent fraud or anything like that, merely making it slightly harder for the average person but doesn't make them immune.

I don't foresee it to be a problem. Users generally do update their nodes, and currently 18% of the network runs 0.23 and 50% of the network runs 0.22. The number of hops that it takes to reach a miner should still be acceptable and you shouldn't have a case where it gets stuck due to nodes stopping the propagation of the transaction. Miners are generally very well connected to a myriad of nodes. However, the main concern should be whether the miners are willing to change their policy and start accepting these kind of transactions.

Peering should be a no issue because it is usually done by recognizing the service flags of their peers. It shouldn't be too difficult to have a service flag where the node attempts to connect to another which has full-rbf enabled.

Yep, so the program didn't manage to guess that sequence of numbers and it was random (intentionally or not). Sample size can skew the results quite significantly, but I think the program can do more as well. If you were to do it over longer periods of time or take a bigger sample size, then you are more likely to tend towards the computer winning/losing. Anyways, anything above/below 50% shows a short term sequence so that is undesirable. If they took a bigger sample size or used a RNN the sequencing would actually be more obvious.

It's actually quite a simple solution and program which uses weighted average by organizing your inputs into matrices and uses it to weight and predict your next move. Hence, something like 10111000 will result in the computer giving the wrong answer every time after a few correct answers. Anyways, that's not the point, beating the algorithm isn't difficult. Having to beat the algorithm consistently without knowing what it does is more difficult for most.
 
Agreed. I still think that general users should still realize the possible risks and caveat for brainwallets.

Non-final transactions are not relayed. The locktime has to be passed for it to be accepted into a mempool.

Nope, we have seen it before. We have had a fairly huge drop >40% of the hashrate during the migration from China. That resulted in a huge sell-off as well. However, people were well aware the root cause of it and it was reasonable to expect them to be turned online again. The impact of it should be magnitudes bigger, given the larger percentage.

Economic-wise, it is fairly easy to imagine what will happen. 90% drop either means the hashrate is so centralized that some disaster took them out, which is bad by itself or that miners decided collectively to stop mining. Either of them will almost definitely result in a sharp drop in the price. The remaining miners which were still profiting at the current difficulty will shut down. This results in a >90% difficulty drop in all. Even if you were to take into account, by considering the total difficulty drop, you will still see a very significant crash in price. Miners are the backbone of the network and having 90% of them leave (ie. industry being worth tens of billions) is not a good look for Bitcoin.

Furthermore, because every Crypto is in essence tied to Bitcoin, the little (and potentially diminished) profits in merged mining doesn't warrant enough for anyone to really turn their miners on. So, I would believe that the protocol will survive and function but not the economy.

If your transaction can be seen on the network, then it should be valid by consensus rules. Even if all of the miners were running custom implementations, so long as someone is compliant with the rules, then your transaction will be mined.

There are of course ways to slow this down;
1) Having a transaction with high sigops. There was a way to exploit the sigops limit such that most mining pools prefer other transactions over yours. This makes it less desirable to mine your transaction. However, there is a sigops limit and this isn't a problem anymore.
2) Pay a lower fee, miners won't want to mine it.
3) Exploit the standardness rules across mining pools. IIRC, certain mining pool had a different standardness rule that resulted in them not wanting to mine specific transactions. I can't find the material for this but IIRC it happened before (not related to SatoshiDice censorship).

All in all, if your transaction is non-standard, it won't be mined without a miner explicitly doing so. If not, then your transaction will always be mined.

Most hardware wallets don't have NFC chips. They are only necessary for wireless transfers, AFAIK both Trezor and Ledger doesn't have it. The cards that you see are not hardware wallets, and IIRC Ledger was about to launch one but the cards weren't very useful as the chips require too much power for NFC.

NFC is just another way of transferring data, so nothing really revolutionary or surprising.

Nope, they are unprofitable. You won't see any of those hardware getting turned on until at least the current epoch has passed, and even so it depends on when the hashrate changes and if the price maintains.

Economic-wise, you will likely see the market crash as well and for a good reason. Having 90% of the hashrate turned off means that the most important economic agent has lost trust in Bitcoin and there is no reason why any of the other market actors would be interested in this. Then it becomes a cycle, where more miners turn their ASICs off, so on so forth. You would see even larger decrease in the hashrates. Bitcoin won't survive.

Be my guest: http://www.loper-os.org/bad-at-entropy/manmach.html.

Your different phrases likely already exist in the dictionary and specific permutations of it are likely to be inter-linked with real life events. Your brain works in a way by association, so you are likely to think of something that you've already seen before. It is a natural phenomenon that has been studied and proven.

Yep. Dice rolls are sufficiently random given a large enough number because even with a 256bit entropy, your decrease in entropy can still make it sufficiently difficult.

I bet that if you use a sufficiently big random number generated by a CSPRNG and insert it into Brainwallet, it would still be secure. The whole point isn't about which KDF is stronger, because they're all going to become weaker as technological advances progress. The one thing that never really changes is that 2^256 or 2^128 is a very big key space and is likely unable to be exhausted. The same cannot be said about the improvement in speeds of KDFs.

Sure. Then you are making this entire process unnecessary difficult, and there is no guarantees of security. Why? How do you know your "iterations" or n values are sufficiently high? Not like I'll publish my most optimized implementation for everyone. It's really quite stupid to have to wait minutes to generate a single address.

Nope. Your keyspace is only 65 bits, you mentioned it yourself.

Your keyspace is only that if you use a passphrase that is completely random and sufficiently big. And yes, that is the whole point of warpwallet but if the input entropy is either:
1) Predictable
2) Short
, then I've got a better shot at cracking something as opposed to the costs.


Precisely why the whole argument revolves around brainwallet. Most people simply cannot make these kinds of passphrase. You underestimate the ability of humans to not think by experiences and association. Unfortunately, the reality is often very different from what you think. Search engines are not comprehensive and they are most definitely not a dictionary.

So a passphrase with a specific pattern.

Then you introduce another risk vector; how can you create that is
1) Sufficiently long
2) Sufficiently unique
3) and also prevent yourself from getting into an incident which induces amnesia or a form of it.
It is a risk that I would very much not have to face.

Sounds like the same problem that would occur with your memory problem. I'm not going to comment further about the memory issue, because things like these are certainly doable and there really isn't a need to memorize in the first place. If you want, you can certainly do it. You definitely don't need a brilliant memory, spaced memorization is surprisingly effectively, for what its worth.

---

If you trust that you can make a passphrase with sufficient entropy, then go ahead. You won't really know if it is secure until it gets hacked anyways. I, for one am definitely not doing something like this, especially with so much money on the line.

That is kind of the problem isn't it?

Humans can't generate anything without bias. It is an inherent trait and the best that we can do is to try to approximate using known random substances. However, there is also another problem; most of the variables in nature is predictable, things like Radioactive decay with Heisenbergs Uncertainty can be approximated to be random but that isn't accessible in normal computers. That leaves us with urandom but even that isn't strictly random (random enough but still susceptible to minute interference), so you can't accurately measure entropy still.

Sure, but that doesn't prevent bruteforce from happening. Using a salt would just be a concatenation of the two components, which would prevent rainbow tables but nothing else.
I think that is well established, that KDFs like Scrypt is way better than SHA256 with brainwallet. Countering ASICs or bruteforce speedups with a parameter change doesn't do enough; you still leave tons of addresses vulnerable. Now, there is also a problem with resource scarcity in systems; if you increase the parameter far too high, you risk having certain users taking longer than normal to access their wallets.

Addressed this previously. ASICs has gone past the stage of only having a few MB of ram. If you increase it too much, you make it difficult and time consuming for certain people to get to their wallet. If your security is reliant on the algorithm rather than the keyspace, then I would urge you to reconsider and re-evaluate your risks.

Then isn't there a problem here? If there is a certain meaning to it, then it is probably not so random and that defeats the whole point of a brainwallet. So that leaves you with a single solution; using a random method to generate your passphrase. Then why bother going through brainwallet? Your mnemonic seed is far easier to memorize because there is a pre-defined word list and that you can easily construct a sentence with it.

Here: https://blog.trezor.io/how-to-memorize-a-seed-phrase-building-narratives-from-nonsense-a306e48dfb39. The entire point about these 12 words is to allow you to construct your own stanza. Also, the whole point about whether memorizing something would be effective has been discussed earlier in the thread as well.

That is not what entropy means. There is no way to measure entropy because it is the degree of randomness and for which you can't see how random something really is. Passphrases are certainly not defined by entropy; you can have the most sophisticated and random passphrase that you can think of, but so long as there is a rainbow table that contains that permutation of it, then you're no better than just using correct horse battery staple.

65 bits of entropy is not a lot.

It has been 4 years and there are tons of ASICs that has shown capabilities of implementing memory hard algorithms. A challenge like this isn't really worth the time, because you're cracking only one specific address. If we have thousands of wallet like these, then there will be incentives to improve on those programs and we'll have even faster and more efficient bruteforcing.

Brainflayer was introduced many years after the inception of brainwallet and it has shown that Brainwallet was a very weak implementation. There is no guarantee that a better and more optimized program would surface in the future given enough traction.
Sure, you can but what would be the benefit of a brainwallet as compared to a simple 12 word mnemonic that is guaranteed to be random by implementation?

The only possible benefit that I can see using these implementation is if that for some reason you are able and willing to memorize a 20 character randomly generated passphrase rather than a 12 word mnemonic.

Look at Burden Of Proof. The only real evidence is that it is both time and resource consuming but it doesn't mean someone with decent resources won't crack it or if someone uses weaker than usual passphrase.

Brainwallet schemes are by no means sophisticated. You can probably replicate the entire scheme easily, because you're just essentially using Scrypt to generate a key. All you need to do is to determine the algorithm and the parameters. They are generally quite well-studied so you probably won't have any bugs.

You can use those private keys, if your funds are in there.

You cannot get your mnemonic from your private key. Your mnemonic goes through a one-way function to generate the keys. You cannot reverse the private keys to get your master private keys, your seeds or your mnemonic.
It has to be in the same order, but you can unscramble it. If you have 24 words and you've jumbled them up, then there are only 24! number of possible permutations and lesser after you factor in the checksum. There are ways to unscramble and get the entire mnemonic in the correct order so long as you know at least one of the address.

Don't think the checksum actually narrows it down too much, so yeah. It can be done, but it probably won't be possible.

After the initial brainflayer fiasco, the original brainwallet was shut down. There were variations of it such as brainwallet.io and warpwallet which both uses Scrypt and salt to enhance the security. It wouldn't go as far as to say that they are uncrackable; given sufficient resources and common enough phrases and passphrase it can be crackable. The most infallible method is really to just use BIP39 or similar mnemonic systems.

There are ways to crack them and tools to do so. Just that they are significantly slower (and more expensive) than single round SHA256.

That is wishful thinking. Bitcoin isn't designed to provide privacy, though the nature of it does provide some privacy.

The reality is that majority of the Bitcoin users actually doesn't care about privacy. Even if you do, there is nothing much you can actually do. Regulations, as it stands currently is sufficient and palatable for most Bitcoin users because there is no such thing as going dark or leave no actual digital trace in the internet. This is moreso with Bitcoin, perhaps you can get more privacy with privacy coins, but that is it. People who cares about privacy wouldn't really be using Bitcoin when there are alternatives.

These policies (AML/KYC) as it stands act as a relatively okay deterrent against illegal activities provided that sufficient screening is done. I'm all for a suitable compromise with government policies and this "intrusion" of privacy, because after all, if you're using an exchange then you probably don't care about privacy. I'd very much rather have the government reaching this compromise and the middle ground rather than clamping down hard on crypto because they cannot fulfill the basic social obligations and these illicit activities start running rampant.

Not exactly. Adding a salt is not enough if your algorithm is naturally fast and weak; reaching your specific permutation would likely just be a matter of time (albeit longer, but still easier than other algorithms because hashing SHA256 is not really that difficult). Regardless, that is not what I'm advocating for and while it does make for a difference in the difficulty, it does not, by any means make it expensive or impossible to crack.

Instead, what I'm advocating for is to use Brainwallet with a resource intensive KDF and salted. Doing this gives you the best chances; it is far, far slower to crack if it is memory-hard and it makes more sense to go through dictionary or known wordlists in that case with common salt permutations. When compared to the original brainwallet, the choice would be a no-brainer.

I think that it is still important to acknowledge that the brainwallet implementation was inherently flawed with a fairly weak KDF that resulted in an extremely fast bruteforce and balance checking which resulted in very efficient and effective implementations like Brainflyer to exist. Which accounts for this impression that brainwallet simply doesn't work.

However, more recent implementations uses a far slower and intensive algorithm which limits the effectiveness of the bruteforce as it would require either high memory intensity or resources. In addition, salt is mandatory in most implementations which makes for an additional round of protection. Fact is, while such algorithms cannot beat the entropy of your OS, you'll still have a fairly decent security as any attempts would be far more than a generic bruteforce but they would also have to take into account the salt, which is personalized and unique. Caveat being both your phrases as well as your salt has to be unique and sophisticated enough.

No. Humans are naturally not good at creating complex and secure passphrase. More often than not, you end up creating addresses with poor entropy. If you need an easy way to remember the passphrase, then you can just use a wallet with a mnemonic. The generation of mnemonic is secure with a good entropy.

Interesting to note that there is a caveat tied to this, when mining pools directly reward the miners using the coinbase transactions. These transactions have a threshold of 100 confirmations, so you can only spend the inputs from these transactions after the 100 confirmation, which is actually fairly long. A more direct method would be to send it to their own address before distributing it afterwards. The good thing is that they can include their own transaction in a subsequent block that they mine.

That is also why most exchanges don't recognize these deposits automatically. Most mining pools credits their miners after 6 confirmations and uses the older "generation transaction" to payout instead of having their miners wait for additional 100 confirmations.

It will. The password will work so long as the file is uncorrupted, no matter where you decrypt it.

I would be more comfortable with using the seed as a backup method. It would definitely work and there is no reason why backing up the file would be better than it, unless you need the labels and stuff like that. I would probably avoid exposing the seed so much as well.

If you're looking for a method, just make sure the wallet file is unencrypted (with the encrypted keys) then extract the encrypted seeds. Afterwards, just use OpenSSL or similar utility and decrypt it with AES-256-CBC.

That would be an inefficient market allocation. In a logical and perfect scenario, each miner mines at the optimum MPB/MPC and that is the market equilibrium.

This makes it such that a smaller change actually makes it more rational for a miner to either scrap and sell it or to turn it off. The phenomenon which the miner actually finds it more efficient to mine at a specific point in time would then be a market failure due to the time lag or lack of perfect information. Hence, in essence the market logic would still apply, but it gets more skewed in the real world.