Oh, I see. Sorry if I came across a bit aggressive.
In hindsight, thanks for the advice - although I didn't notice, so I couldn't heed it.
Next time, please, advise cashing out at 19k.
Anticipated thanks.

About tether - I agree with Torque, it's going to be an issue sooner or later. I wish those audits were properly carried through, situation found regular, and details published. That would be superbullish.

By your words, I assume you're not a bitcoiner.

A few questions arise instantly.

- What are you if not a bitcoiner? Bcasher? Fiater?

- What are you doing here if not a bitcoiner? General trolling? Nuisance training?

We do appreciate your help, ztay. But politeness apart, next time just hodl, will you?

11k broken. First sign of life or a passing illusion?

I was hoping not to have to install special instrumentation like wireshark. Well, when I get to that I'll do what I have to.
BTW, 8333 is for bitcoind. LN uses a different port (can't recall right now).

Honestly, I don't know which solution has eventually been adopted in this first version of the LN, but already in 2016 the proposed method was significantly better than the naive SAN technique you hint at.

https://steemit.com/bitcoin/@emabfuri/bitfury-bitcoin-routing-lightning-network-solution

Here's a relevant excerpt.

So, it's not an initially low TTL that gets conservatively increased as I had wildly imagined, but not so far off either: closer nodes are exhaustively enumerated, while a small set of distant nodes is selected pseudorandomly.

There is a more detailed pdf paper floating around. If you study it, a summary will be well received. I don't have the time or energy right now. If I get either or both, I'd rather actually test how LN works for me, with my own node.

http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf

Inb4 Fyookball - not to mean you would stoop that low, but just in case ;-)
https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800
It's mostly BS with truth mixed in  - the most dangerous form of BS.

Relax, Bob. It's actually $9800. We've seen it happen already, might still happen again on one of the next, weakening, shakes, if only because they start shaking from a lower level.

Another shake of the tree, while the bears still have some breath left.

Currently: you and yourself. You must hurry and do it within a week. Can you switch on your LN node once a week until it syncs your own channels only?
Outsourcing to to others, uh, well, hm, we're still working on it  

However, as usage increases, IF (and it's a big IF) this kind of cheat should become popular (which I don't think, being too risky because it implies you do have a stake in the channel - you're not just stealing someone else's coins), then I'm sure several such services will appear, as the marginal cost of running a patrol service alongside your own LN node is so low as to be negligible. Like buying a cheap lottery ticket. Find a thief, grab some coin. Why not? Let me engage in a flight of fantasy: future LN clients for desktop machines will have patrolling functions included, and there will be a switch NOT to run a patrol service. Working as a part-time guardian will be the default.

These are the bad posts, jbreher.  

I will post some data, but don't hold your breath. I'll need some free time to install the thing - starting with Docker - and some more to figure out how to measure LN's bandwitdh tax unbundled from bitcoind's base requirements. Got any suggestions?

Now we get to the "bad boy" part.
That's incorrect. Nobody yet knows how to do decentralized permissionless anonymous OPTIMAL path route discovery. Heuristic methods with stored forward tables do work reasonably well. Several mesh-like networks work, without a single tear about being suboptimal.

EDIT: not sure, but optimality (or substantial improvements on route length) could be achieved by permissioning just the network-shaping, route discovery functions. Permissions could be earned by showing reliability and revoked for rogue nodes that systematically misreport.

Of course - the clueless developers! D'oh, what an unforgivable oversight! The system they implemented is doomed. They chose the SAN (Spam All Network) algorithm for both route discovery and node state update. They slept during their networking lessons, or was it calculus? So they failed to notice that bandwidth grows quadratically with the number of nodes. This way, it's almost as bad as if one increased the block size. But who would ever think of that?

Out of sarcasm: I'll never believe the protocol broadcasts data mindlessly. On TOR transport, link capacity is precious and doesn't get flooded with irrelevant data. I've never studied the matter in detail, but as an informed guess, I'd go for something like neighborhood broadcasting with empirical discovery of TTL (max distance for broadcasting, initially conservatively low). Once you've found a route that works, you keep it until it stops working - or TOR signals it's time to change circuit. Randomized timing etc. are all nice options to obfuscate things a little more and make network analysis harder.

Those are the good posts, jbreher. 

And gives said counterpart the chance to have their whole assets on that channel forfeited by you if anyone snitches on them within a week. I wouldn't try that.

By the way, the phrase you wrote and I underlined could be read as meaning that there are several counterparts per channel. There are only two actors for each channel: yourself and the other end (counterpart).

A friend whose opinion I highly value also has lots of praise for Synology. However, when he saw my units he fell in love with the HP and got one little later. I'm sure they make good products, but they have proprietary software, and that's a show stopper for me.

I had troublesome experiences with soft RAID under Linux (it was Suse at the time, not Ubuntu). On the other hand, zfs treated me very well. 3 hardware disk failures got recovered without a single glitch.

I have one of those, too. Definitely like it a lot. Going to get myself another for media files later this year. It keeps a decent temperature even in hot weather, which can't be said of some of my custom rigs. The remote management is quite nice indeed. Only drawback I've found: it's really slow to boot, but if you don't take it down daily you will barely notice. By the way, my unit runs FreeBSD/zfs. With timed snapshots and whatnots, I feel safe.

I would suggest a dedicated NAS with zfs (FreeBSD). Mostly like RAID, only better.
A dedicated ethernet cable between server and NAS would provide adequate disk bandwidth. Or, likely, you could actually manage to run bitcoind and lightningd on the NAS itself. As for the form factor, there are dedicated cabinets that accommodate 1-12 disks, with little leftover space except for the motherboard.

Hello vroom, I'd like some help.

After some thought, I'd like to try installing lightningd along my already running bitcoind. Which means, I would like to avoid building one more copy/instance of bitcoind inside the Docker container. This probably means no private network between bitcoind and lightningd, but plain old loopback or similar.

Do you think it can be done? Any caveats, gotchas, likely pitfalls etc?

My lowest limit buy is still unfilled, but if 10k breaks down it might go through.
As soon as the stock market opens, I'm gonna eat a moderate loss on some underperforming stock and try to get myself some more cheap coins.

Well, cloud isn't mentioned explicitly, but Digital Ocean is.
I'll try the homespun solution, install docker and all.
Thanks vroom!

I do, at least qualitatively.

In Alice's absence, some malicious counterparty (say, Bob) might try to cheat by broadcasting a previous channel state to undo his latest spend. However, if Alice - or anyone else, for that matter - notices and broadcasts the legitimate, later state as signed by both Alice and Bob, cheater Bob loses everything and the whole channel amount is forfeited to Alice. So you either have to stay online or hire some bounty hunter to patrol the network while you're away. Of course, the hunter gets a piece of the cake.

The deadline for catching such cheating is one week. I believe a bounty hunter market will arise, with aggressive price competition. In principle, it should be possible to hire a multitude of hunters. The first to out the perp wins. No single hunter needs to be online 24/7, as long as there are enough of them (including Alice herself).