Yep, but it might be quite a while before it gets released, officially. I was following the progress of it and the documentation is still in the progress I think. Bitcointalk over Tor is still somewhat usable, not really totally inaccessible.

Anyhow, CloudFlare actually allows for Onion routing as well. Allowing the site to be served over onion while still allowing for the site to piggyback on CloudFlare's CDN. I assume that there is a very good reason why this isn't used currently.

Live USB is an isolated environment, encrypted virtual machine with imminent disconnection from the internet doesn't qualify as being any safer than just having it connected. A lot of malwares are capable of stealing from VMs, even if it is offline. The data is just cached, RAM can still be dumped regardless. A completely isolated environment is much better in comparison and not particularly difficult with an hour of googling.

No telling if they are the ones controlling it. Someone could've simply paid them in RUB and asked them to transfer to this address.
No, it is just a normal Bitcoin address just like any other. They don't pay extra fees to use the address.

Also, vanity addresses are just like any other addresses, except for the special bunch of characters. It might have just been a coincidence with an address they generated, or they might have specifically generated that prefix.

The issue lies when you associated randomness with a uniform distribution. Contrary to popular belief, they are actually not synonymous. For Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), they are subjected to the next-bit test where you cannot predict the next few bits given the first few bits. That requirement is fulfilled by your OS's CSPRNG and thus it qualifies as being sufficiently random.

Now, back to the topic. Sure, you can reject a result where you have 12 consecutive '0's in your key, but that is extraordinarily rare and it would prob never be executed in any code that you write. Hence, there is no good reason for anyone to include test-cases which tests for this. Going by that, the definition of having entropy would then be having the results for which each character has the equal probability of being in each space (ie. non-biased). A counter-example is this:
Against these which are generated with a CSPRNG:

The former has low entropy, even though each character appears exactly once, which means that by normal standards, you would consider each character as having the equal probability to occur at least once. Yet, that is predictable. The second is generated with a CSPRNG, which is random yet there are repeated characters present. That is unpredictable. Given a large enough set, think infinity, each of the values would possibly be uniformly distributed. The mathematical model doesn't exist, there is no telling of how random something is because it is not designed to be predictable. Analysis with any results are often done with something that can be measured and thereby predictable.

There is no need to implement any algorithms to test for this. Your wallet client probably incorporates /dev/random which is a CSPRNG within your OS. random continually collected entropy from the environment and blocks if there isn't any sufficient entropy being collected. In addition, your wallet also seeds using entropy collected from other sources. Hence, trying to evaluate entropy is unnecessary and provides a false sense of security.

No. If there is a method to accurately determine the randomness of strings or cryptographic keys, we wouldn't have so much issues with CSPRNGs. We would be able to just test the entropy using algorithm. The issue is that there is no way of testing if a key is truly random, variance could skew your results to have more x characters than another for example. Even if you introduce a huge sample size, there is no telling if a bias is inherent or it is just a coincidence with variance. There are instances where the lack of CSPRNG is evident; most evidently with Bitcoin signatures but they are attacked in unique ways and are not determined using a fixed algorithm.

If you are using a reputable wallet, one of the key things that is heavily scrutinized is the CSPRNG mechanism used during seed generation. That being said, you're probably in safe hands.

As to how bad humans are at generating entropy: http://www.loper-os.org/bad-at-entropy/manmach.html.

This isn't accurate. You cannot compromise an entire network and even if you run your own node, you can't possibly convince another node to think that it is valid.

No and no. If you were to pay zero fees, you would probably violate the minimum relay fee requirement of Bitcoin nodes and that would mean that your transaction wouldn't be accepted and relayed by other nodes. If your transaction gets relayed by nodes around the network, then there is a chance that it would get confirmed. A transaction that can't be confirmed would probably not be relayed by other nodes.

There is no such thing as a "fake node input".

It practically takes seconds[1], for most personalization. I remember using my GPU to generate an address that has only lower case IIRC, and even that only took an hour or so.
It doesn't. Your vanity address can be generated locally which would expose you to just as much risk as using your wallet to generate an address. Alternatively, if you were to generate it with a third party, you can use split-key generation to keep your keys safe.

No. Unless you are trying to re-use your address or generating a new vanity address for each transaction, it definitely isn't worth. Besides, vanity addresses can't really be generated in a HD wallet, which negates the benefit of being able to back up using seeds.
You probably consume more energy gaming than generating vanity addresses.

[1] https://bitcointalk.org/index.php?topic=5322102.msg56510404#msg56510404

Nope, it is a scam.

First of all, creating Bitcoins out of thin air is not possible. Each transaction references a previous transaction output, which leads all the way up to a transaction which is generated from the block reward. It is impossible to fabricate this link in the first place. If the transaction doesn't reference a valid unspent transaction output (UTXO) of the previous transaction, then it would not be valid. Only transaction that doesn't require a UTXO would be the CoinBase transaction of blocks.

Secondly, each transaction must be spending the correct amount of Bitcoins. Total output must be less than the total inputs, with the remaining being considered as the fees. If you were to spend anything more than your inputs, then your transaction is invalid. Each transaction must also be supplied by a correct ScriptSig, which fulfills the criteria as dictated by the UTXO, a signature that corresponds to the public key of the address for example. If any of these doesn't check out, none of the nodes would accept them and they wouldn't even appear in the memory pool of your nodes and no one would be able to see them.

Lastly, confirmed transactions are final and cannot be removed. You can create a transaction with a very low fee that appears in the memory pool of the nodes as an unconfirmed transaction, but they have to be periodically rebroadcasted to ensure that they stay in the mempool. They are not "fake" Bitcoins, just transactions that are unconfirmed and can eventually be confirmed.

The core of the issue is how susceptible onion addresses are to DDOS, which is arguably harder to block due to the nature of anonymity. There's some progress with trying to resolve this issues (PoW requirement, etc) , presumably due to the massive DDOS a while back.

I assume theymos doesn't want to mess with Tor for now, and sacrifice having to deal with tons of DDOS coming in from Tor at the expense of having the user jump through loops using CloudFlare.

Depends on the size of the economy. It can be quite difficult for your government to enact fiscal policies if they didn't have a large enough reserve. The currency and the need to separate them has a lot to do with economics and how countries use currency to stabilize their own economy.
Nope, tons of reasons. Bitcoin is not user-friendly at the slightest. There has been quite a lot of negative publicity surrounding Bitcoin in the recent months and that contributes to the negative perception of Crypto. In addition, governments are always trying to encourage people to use their currency as a legal tender to better enact capital controls and stuff on their own citizens.

Without the endorsement of the government, people have no reason to accept Bitcoin as a currency.

Some merchant uses MultiSig when using BTCPay servers.

There are non-custodial schemes to use 2FA as well, which has to do with MultiSig. One of the keys can be held with a third-party which only signs the transaction when the 2FA is correct. However, the third-party still requires the participation of the user when using the funds due to the MultiSig setup. As such, this becomes a scheme whereby the third-party has no sole control over the coins.

Humans are bad sources for entropy. By brainwallet's scheme, if I were to generate a key that is sufficiently long and has sufficient entropy, it would never get cracked. Note that brainflyer cracks the keys at a pretty fast speed but it is very far from exhausting the entire space of SHA256.

Hiding anything without encryption isn't the best way of doing things anyways. Even a safe can be cracked given time, and most people usually add a layer of encryption ontop of their keys before hiding behind something.

The beauty about this is that there isn't a set way of recovering or encoding your keys. It is perfectly possible for you to choose a unique obfuscation technique that doesn't raise the slightest form of suspicion and people wouldn't bother figuring out how you've encoded it. After all, art is abstract and a bunch of colours mashed together wouldn't raise any suspicion.

Yeah, its fine unless someone broadcasts it. The two signed transactions are both valid and either of them can be broadcasted at any point in time. If for some reason, you didn't manage these two transactions properly and someone else gets access to it, they can still broadcast it because they are valid.

These two transaction are valid until any of the inputs in that signed transaction gets spent.

Thanks for the clarification. Forgot that top stack is popped given that OP_IF is skipped when OP_CHECKSIG is false.

Removed the script.

Still a central point of failure, where one seed gives you more control than it should and the compromise of a single seed equals to a compromise of 3 entities and only requiring the participation of one more. Nevertheless, that is not the point as security of seeds isn't the central discussion here.


That is only if you want to use a single Multisig address without an easy way of avoiding address re-use. So yes, it can work in that case.

Generally, if you want to create a multisig system with HD seeds, then you should use multiple seeds instead of different derivation paths. IMO, no good reason to use HD seeds to just create a single address though.

Yeah, agreed. Should've caveat that it is probably not too good to mess with ScriptSig if you're inexperienced. Good to test with regtest before trying it out on mainnet with small amounts of BTC though. P2WSH/P2SH is pretty versatile in the sense that you can create redeem script with a bunch of conditions and customize it to your use case.

I don't foresee these kinds of scenarios to be prevalent enough to warrant a standard though. Going by OP's question, that is the only way this can be achieved if you're mapping 1 key -> 1 entity.

If the end goal of Bitcoin is to have everyone to understand how it functions, then it would have failed as a currency. Initial versions were made such that people who are technically adept are able to understand and develop it. However, if we want Bitcoin to be mainstream, then complicating it further would be counter intuitive and hence why it is a bad idea to further complicate things instead of simplifying.

That is kind of besides the point, since the intention of OP wasn't for one co-signer to have additional security but for the entire system to require the signature of one specific cosigner. Though, there is also a point in that, but the security being provided would be the same as n-of-m multisig, with m distinct entities.

Besides, I do agree that using separate seeds would both improve security and reduce the complexity of having to track multiple derivation paths. Wallets like Electrum already makes use of their own versioning system to reduce the chances of user error. It isn't that much more complicated to store a few more seeds anyways.

Yes, it actually is possible. I stumbled upon this a while back and thought it was a pretty nice usecase. Smaller redeem script size as well, as compared to the other solution involving a single entity holding multiple keys.

Here's the thread: https://bitcointalk.org/index.php?topic=1231148.msg12830232#msg12830232.

We simplified and expanded on it afterwards in another discussion, I was the OP IIRC. The simplified scripting would be something like



In your case, your P2SH would be:

** See pooya's reply.

Brainwallet isn't security by obscurity, because it isn't intended to be obscure. Brainwallet can work if the keys are long and random enough, with enough key stretching. Storing seeds as words isn't the failure of it, but allowing user to compromise on the entropy would be.

I would argue that it could work, provided that the security model fits the threat. There is no safe that can't be cracked with a matter of time, but if you were to hide a perfectly normal looking art piece, or an image file for that matter beside the safe, then there is no good reason why the adversary won't be trying to crack your safe instead. All is given with the fact that your adversary doesn't have prior knowledge of it.

Both the passphrase and your safe are susceptible to $5 wrench attack so there is that.