Nice, thanks for checking that out


It'd be good if they could make a feature out of this for Trezor users (whether the Trezor 1 or the Trezor T). Force the user to choose:

• Security focused: a minimal firmware with minimal features, written in C (i.e. the trezor-mcu firmware that Trezor 1 uses today)
• Feature focused: a more flexible firmware with more features, written in C/Micro Python (i.e. the new firmware that Trezor T uses)

Downloading the firmware is something the user must do anyway when they first set up the device. Giving them that choice when they install the firmware shouldn't be too hard.

Watching only wallets have the private keys removed. Search on storage devices for .wallet files. The correct files should have the same random character string as the watching only wallets from the online computer.

It will be difficult to market the device as the most secure, if they do this.



Or someone might continue to update the older software, and also sell their own device. I'd support that company instead, if so. It'd be a shame, Trezor has been very well handled upto now, except the time when they tried to close the source code of course.

There's a certain legitimacy to that argument, but you could equally argue that Liquid is only making an oligopoly (the exchanges) more centralised, which could in the long term break any illusions that the exchanges are as independent as they would like clients to believe.



If there's a real marketplace for BTC, there's no such thing as a "correct price". Only controlled (i.e. rigged) marketplaces can claim that prices are "correct".



The other interesting idea is that you can issue tokens backed by something other than BTC. Exchanges could use that to manage fiat liquidity, and so create a stablecoin in the process. If all the exchanges depended on such a stablecoin for liquidity, the stablecoin itself would be less exposed to 1 exchange going bust (that would still rock the peg seriously, but it need not definitively kill the coin, as would happen to USDT if Bitfinex did actually go bankrupt).

Even better: if that hypothetical stablecoin could be used without using the exchanges themselves, decentralised platforms could use it too. The ultimate would be if atomic swaps between such a stable coin and BTC could happen, then individuals could trade the stablecoin with BTC freely and quickly, and the exchanges could provide the price stability for the stablecoin. In that scenario, you could actually see an improvement in the decentralisation of cryptocurrency exchange; why hold BTC with a 3rd party if you don't need to? The centralised exchanges would end up trading only the stablecoin as a result (probably why this won't happen, but things are heading in that direction one way or another anyway)

That's true.

You could do this yourself then. Setup a script that starts when you lock the screen, and times out after however long. When time out is reached, do any prerequisites, delete disk encryption headers, power off. Setting the timeout would be the difficult part, it needs to be less than the remaining battery + safety margin (so you can be sure that the script reliably completes before the battery dies). You lose alot of usability after that, it would be difficult at first to remember to unlock the device before your script wipes the disk encryption headers.

Or a more high risk strategy might be to have a panic script, in your taskbar say. That would be simpler, the panic script would begin the timeout period, or even the header wiping directly. This assumes your adversary gives you enough time to hit the panic button though, hence the high risk part.


I'm not keen on any of these solutions, it's better if taking you by surprise is a high cost to an adversary. You can do that by keeping private stuff on separate disks, without encryption headers, except when you're using them.

do. not. want.

I hope SatoshiLabs aren't planning on discontinuing development of the basic firmware, some people want a hw wallet that concentrates on security. "Feature expansion" is the road to increased attack vectors, a security compromise


Edit: apparently, SatoshiLabs will maintain security updates for the trezor-mcu firmware: https://bitcointalk.org/index.php?topic=122438.msg46772564#msg46772564

no

I think it does exist, but I would forget about it, as it wouldn't work as a defense forever. As soon as that software became commonly used, anyone who might steal your device from you will simply use a faraday cage when seizing it, that defense would be useless in that case.

My solution would be to make use of encryption headers on your removable storage. Keep anything private on removable storage, and only ever flash the encryption headers onto the storage device when you need the data. Without the encryption headers, the disk is indistinguishable to random data, so the disk appears blank to an OS or to more technical analysis. You can't be blackmailed for a password to a blank SD card.

Try installing this version of Armory 96.4 (the latest version): https://github.com/goatpig/BitcoinArmory/releases/download/v0.96.4/armory_0.96.4_amd64_gcc4.7_noasm.deb

Good to hear


Maybe a software bug? Reading up on lnd might help



Possibly the Pi. How long was the delay? And when you did 'lncli openchannel', was that to the starblocks node directly? If not, that may be one reason for the delay (BitCryptex is saying the same basic thing a different way).

One way it could slow right down is if the payment path failed multiple times, that would be pretty bad luck for a first attempt.

^^^ Right

1. Make LN connection
2. Open channel
3. Pay someone through channel

You checked that the transaction is confirmed?

Also, you might need to manually initiate the first connection, the lnd autopilot possibly doesn't do that part (but auto opens after the first connection is made).

Press Q to get the prompt back



Probably a typo in the original guide. Let Stadicus know, it would be appreciated it if that turns out to be the case.

That command just lists files in /home/bitcoin/.lnd/, 'ls' is the list command.

To create those files... either running lnd will do that (i haven't used lnd), or you could do it yourself (the command would be touch /home/bitcoin/.lnd/admin.macaroon). But it makes more sense that lnd would do it, the idea is that a macaroon file is similar to a cookie file (both are biscuits IRL, a curious metaphor IMO). Checking the documentation for lnd should tell you more (at this stage, you've probably done most of what the guide can tell you).

Nice work

Telegram (or Signal) were nowhere 2 or 3 years ago, all you've gotta do is use it with the people who are willing, and if others ask why you use Tox, tell them "more secure". Adoption will take care of itself.

I don't like Tox just for it's p2p nature, you also don't need to give someone a telephone number (it finds your message recipient in a different way). That means Tox works on a PC desktop too.

chmod doesn't give you any output if it succeeds, so don't worry about that. If you did ls -l before chmod, then again after chmod, you'd notice the file permissions change, which is chmod's purpose.



"LightNode Keys" has a space character in it, but you're not using double quotes around the nickname in the example public key string you gave. I'm not saying that's the overall problem, but it's likely a problem. Avoid putting spaces in anything that's going to get parsed by a command line tool, a space is treated like an indication that a new parameter is after the space from the perspective of parsing commands.

That sounds off.

If you've reflashed the Debian image, there's no conceivable reason that pinging the Pi works, yet SSH login won't. Either the ethernet hardware on your Pi works or it doesn't. Are you using ethernet, or wifi?


Cool. I hope you get it working, this is all good experience you're building up.

The first thing I'd do is try pinging the IP of the Pi and other devices on your home network, it sounds like the problem is to do with your router

Which user did you choose? You should probably choose "root". For that, you'll need whatever the default password is for the root user on Debian (possibly the password is literally "root", but that's a guess). Search for "default Debian root password" maybe.