An malicious actor with more than 50% of the total hashrate can NOT 'print money'


Someone with 51%+ hashrate can decide which transactions to include (also means that he can refuse to include a single one).
He also can double spent his own transactions (since he decides which TX's to include).

But he can NOT steal other peoples money or create money out of nothing.




AFAIK, pruning is NOT enabled by default.

As long as there are 'enough' full nodes which share the full historical data (probably always will be), that's not a problem at all.

Its not like an exchange can be manged using one hardware wallet which is plugged in each time you request a withdrawal.

They have a cold wallet (to store the majority of funds) and a hot wallet (to be able to properly handle withdrawal requests from clients).
Regularly the hot wallet needs to get funded again and/or additional funds need to be transferred to the cold wallet.


In most cases funds are being stolen from a hot wallet. The circumstances which lead to such a loss can vary quite heavily.




The costs are extremely inefficient and high in cases of bitcoin. But butka was refering to "bitcoin gold" which forked off from bitcoin (together with 30 more shitcoins).
Their PoW (and therefore also security) is way lower. The costs to attack such a low-quality fork are relatively small and affordable compared to bitcoin.

Enter the 'Addresses'-tab and search for the address. Or enter the console (View -> Show console) and enter:


If it returns true you are fine.
If it somehow returns false and/or you can't find your address from the watch-only wallet in your cold wallet, you somehow might have messed up when setting up your wallets.

Did you use the xpub of your cold wallet to create your watch-only wallet ?




You will be able to see them in your watch-only wallet. But you will be able to watch them only. Therefore "watch-only".




Public keys (and therefore also 'addresses') can be derived using the master public key. But to spend all the coins on these addresses, you need the corresponding master private key (stored only inside of your offline wallet).
Therefore you can safely watch your wallet and derive new addresses to receive new transactions, while to actually use or spend the coins you need to use your offline wallet.

One line can be found quite often:


Can you verify that C:\Users\Ruprecht\AppData\Roaming\Bitcoin\ is the correct core data directory ?

It seems like it doesn't exist. I guess you set a specific data directory when installing core ? You'll have to point armory towards this directory.

The easiest way would probably be to import your mycelium seed into coinomi, both follow BIP44.
But note, that you shouldn't use this seed anymore afterwards. Regard it as compromised after importing it anywhere (but keep a copy of your seed - just in case).

To restore a wallet in coinomi: "Settings > Create / Restore wallet > Restore a wallet"

Paper wallets and hardware wallets are both one of the most secured options to store your bitcoins.

Paper wallets are only suggested for long-term storage where you don't need to transact often.
Transacting with paper wallets is a pain. You need to import them to your (unsafe) computer, create the tx yourself and choose a change address (and back it up, nothing is don manually when using a paper wallet).


Hardware wallets can safely be regarded at the 'same' security level than paper wallets.
They store the private keys in an isolated environment which never leave the device.

The big advantage with hardware wallets is, that you can plug them in into online-pc's without having to worry about losing your coins.
You can transact daily, without running risk of losing your coins.

Hardware wallets are a pretty user-friendly way to securely store your coins.

There are a few tools available on the internet which decode the sheme to a standard bitcoin address.

One of these tools can be found here: https://alexk111.github.io/DeBitpay/ (Source code: https://github.com/alexk111/DeBitpay).
You will be able to derive the address the funds need to be sent to with this tool.

Then you can skip the process of sending your funds from your desktop wallet to your bitpay mobile wallet, and send it directly from your desktop wallet instead.


Note that i haven't tried this tool out and can't guarantee that it is 100% working. However, it seems to have quite good reputation and is mentioned quite frequently.

This tells you that it got rejected by the network due to your TX being dust.

How much are you trying to send ? It seems like it is just a fraction of 0.01$.

Depending on the specific amount you want to send, you'll either have to wait until the fees are at its lowest (~ 1 sat/B) or you need to use more inputs in order to create a bigger transaction (worth more than fees + minimum amount).

Usually, you shoudn't enter this command at all.
Inside of the .ssh directory, there are files which are fine to be read by non-root users (e.g. known_hosts).

All you have to protect inside of the directory are the private keys of the machine from reading and the public key from connecting clients from manipulation.


Back to your question. Usually you enter this command to move the public key of your machine you use to login into the .ssh directory of your server (the machine you want to connect to).
You just need a valid private-/public- ssh keypair on your machine used to login before executing this command.

Google authenticator is a software 2FA.
A proper (real) 2FA consists of a hardware token (similar to a hardware wallet) which shows the current code to enter.

Just because it is common to use GA as 2FA, this doesn't mean now that anything you know can be a 2 FA. This is a cheap way to realize a hardware token.


Additionally not every GA is generating time-based one-time passwords.
Besides TOTP, GA also supports HOTP (hmac-based one-time passowrds). Those are not dependent on the current time, but on a counter.





As already mentioned.. encryption and 2FA are two different things. They are not comparable and are independent from each other.

Cipher text + password simply is the cipher text + the password to decrypt. That's comparable with a lock and the key to open it. This has NOTHING to do with 2FA.





Why would you need it to be supported by electrum ?
This is kind of trivial and can be done using a seed (obviously) and a fresh linux with the basic tools.

Extending the seed and multisig are both different to using SSSS. Each has it's own purpose.
You can't compare them with each other the way you are doing it.





Or you do it yourself using basic linux command line tools and write it per hand instead of using the printer..
Writing down 40 words shouldn't be a problem..

The fact that YOU are relying on a copy, doesn't change the fact.
A seed is pure information. Something you know. Not something you have.

No one can take the seed away from you. Once you have (know) the seed, it is yours. Therefore it is something you know, not something you have.




Again, it is not really a second factor. It is just an additional part which is missing.
This is like writing down a password except for the last 2 characters. This is not something they have to steal from you.
They just have to get to that information.. Either via stealing OR through different techniques (e.g. bruteforce).

It is pure information. Something you know (again).




Of course it does. Noone said encryption is a 2FA (this wouldn't make any sense at all).




Not necessarily. A non-multisig wallet, whose seed is split via shamir's secret sharing is also a safe solution.

The EXACT same issue ? Then something is wrong with your hardware..

But most probably you do NOT have the exact same issue..

Create a new thread, explaining your problem and post your debug.log.

Without the log, no one can determine your issue (and therefore also can't give you hints to solve it).

Uhm.. what? 

How shall this be understood ?
A programming language can never provide any level of security.

The security of a project/program/whatever is determined by the way it is programmed, the used functions/checks/etc.. not the programming language..

Rather stability and performance can be determined by the programming language, but definitely not the security.

This might be possible, but is definitely NOT the recommended way.

You don't want to have the VM and the Host-OS sitting between you and your hard drive. That just increases the risk of anything going wrong.

The most convenient (and probably also best) approach would be to use a live system (bootable from USB).
This way you'll be able to directly mount the drive and copy/work on it, without multiple abstraction layers in between.


There are multiple guides available on the internet which show how to create a bootable linux USB stick.

Yes, you have to include the entire string.

Usually, after creating your keypair you simply move it to your server (your PI in this case).
This works with this command:


with PI-USERNAME being your username on the PI and 192.168.56.101 being the IP of your PI.


Afterwards you will be able to authenticate using public key cryptography, without entering your password.

Unfortunately you can't see where the address is from by simply looking at it.

The only way for you to find out where these coins are located is by checking each of your 'places' where you keep your coins.


And in future you might want to consider to move them all to one place. If you choose an offline solution (e.g. airgapped wallets or hardware wallet),
your coins will even be more secured than they could ever be when split between multiple untrustworthy and unsecure online wallets/sites accesses by your online computer.

I think you misunderstood the OP.
OP is not talking about bitcoin futures, but derivatives traded with BTC as the currency.

This wouldn't create any demand regarding BTC/USD and therefore also wouldn't help stabilizing the BTC/USD rate.


But on the other hand it would definitely increase the usability and also adoption of BTC. Overall this would be a step into the right direction, since BTC would finally be used as a real currency.
The liquidity is the biggest problem with this. But once this problem is solved, i can smell a lot of profits from the first one implementing this.

How (and why) should a country leaving the EU have an (technology- or financial-based ?) impact on bitcoin ?

I don't see a single scenario where this would have an impact. Even if there was a specific political change which would affect bitcoin, those impacts would only be temporarily.
A small country like the UK can't have a big impact on something which runs all around the world (e.g. internet, bitcoin, ...).


I would be glad to hear your point of view - why and how the brexit could impact anything regarding bitcoin.

A solution has already been found. A second layer solution called hashed timelocked contracts (HTLCs).
The most known implementation of HTLC's is the lightning network.

With the LN as a second layer, the TPS capability will heavily increase without increasing the energy consumption.


It might also be worth to mention that the whole energy consumption from the bitcoin network is just a small fraction of the energy consumption from the whole banking industry.
This 'bitcoin is killing the environment' argument is not valid at all. Especially since this assumes that the whole energy is (and will always be) from non-renewable sources. That's not an assumption one can easily make.

He wouldn't prove anything with it.
Sending the coins to a burning address would simply just make them inaccessible.

If he really would want to harm BCH, he'd probably just dump all of his coins for BTC. Not necessarily to get the money, but simply just to crash the price.

But still.. this wouldn't prove that BCH is a scam. This would just show his stance regarding BCH.


In the end i think it is very unlikely that satoshi is/are going to touch his/her/their coins (neither BTC nor any fork of BTC).
This could create some kind of panic (e.g. 'what if he dumps all his BTC too') and probably would harm the whole crypto ecosystem. And satoshi (if he/she/they is/are still alive) does know this.