some of the protocols don't require trusted servers, but the picture you paint as the user locking you out is simply not true. I believe you offer a good service, but if users choose you under the impression of having sole access to the server/ram/disk/... it's just wrong, and that's what you are saying.
sure, just run bitcoind on another system/line....
alternatively I used the wrong word here π meant to talk about consumer grade dsl lines with changing IP addresses etc, which is very common where I internet.
vps offer hardly any secrets from the provider. the ram is dumpable, the diskspace can be cloned on the press of a button, and network traffic is 100% visible (okay, tls here, but keys are known to hoster)
I'm all for self hosting, and a vps is a great start, but I can hardly imagine how you want to deliver on your promises. #opsec
what could possibly go wrong π€£
even better: don't subscribe. 2nd best: unsubscribe
running 170-250 channels on my CLN since years. I tend to it twice a year, reopen channels, update CLN etc.
I run a reverse proxy on my dial up connection at home, dyndns does exist.
the earnings a meager, but I honestly never calculated then. between FC and regular on chain fees.
but I can understand if people throw the towel. but then, we are still early in the game, things should get easier - and this is already happening.
Has anybody noticed that we now have "screen recordings" in our reproducibility tests? As another project is sharing "video proof" of reproducibility, we were asked to also do so but it felt kind of pointless to produce GBs of data for every reproducibility test. We did however start playing around with console recordings that are somewhat more optimized as they record the ASCII on the screen and not every pixel. Resulting files are much more manageable but for example, running the compile script for the Electrum for Android app resulted in 72MB of output. As we test a lot, this is a lot to add in a single day.
Does anybody care about screen recordings? Can we throw them at some nostr relay instead of our git repo, with some expiry date in three months, so that interested users can grab it while it's hot? Any other ideas?
Currently the tiniest ascii cast is the one for the Schildbach "Bitcoin Wallet": https://walletscrutiny.com/android/de.schildbach.wallet/
screen recordings sound pointless to me. either it builds reproducible or it doesn't. videos change nothing, videos proof nothing. ASCII replays proof even less π
Sorry, but Email
Now it's distributed at most.
Nice read:
https://blog.lopp.net/death-of-decentralized-email/
By nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp
just watched the presentation... lopp says there are gatekeepers, specifically those who manage IP addresses and domain registrars. I guess this can be argued, but this leaves hardly any decentralized system left. certainly Bitcoin core asks me what IP to bind to, and somehow fetches a list of IPs to connect to, too.
I manage and managed email infrastructure for many companies, certainly not the amount of daily emails lopp claims, but still a broad spectrum of different servers and plenty of traffic. i have never experienced emails being accepted and discarded on purpose by any mail system. the fast majority of mail that won't make it into the recipients inbox is usually blocked before even the body of the mail is transmitted or even the recipient was specified (DNSBL), thus leaving the matter to the sending email server. the consequences of false positives (legit mail being hell banned) would be grave, logs would show that the email in fact was delivered and it would be clear whom to blame for any legal consequences in most jurisdictions. I just googled those terms and also could not find anything about hell banning in smtp.
sure, the cost of running your own mail server is not zero, you need an IP and a domain and you need to invest some days from time to time to keep up with the development, configuring DKIM, which wasn't required before, but now many servers will reject unsigned messages etc., but that's just progress happening, it's not excluding anyone.
dynamically assigned IPs, unusually in dial-up scenarios are a real problem, I will admit that. but for me that's all that sticks from this presentation.
honestly, I had this pain in like 2007.... today I'm updating kennel up and down no problem. weird.
can you show me in this doll where the kernel touched you?
I don't disagree, but also try running old usb2rs232 converters on windows. they all need a specific driver and those might not be available for windows 10/11/whatever. just plug them on Linux and it just works. true for many device types
not sure, but at least #LND supports a proper database backend, too? #CLN does, but with no official migration options, just some scripts by fiatjef which might or might not be maintained...
#CLN has #SCB, redundant databases (just specify a second sqlite file) and a proper backup plugin that replicates every DB change. so I'd say yes.
while backup is preferable, there is also #SCB. which sucks, but is clearly better than having nothing
I mean sure, why not. but if you decide very little risk by zero benefit.... wait that's not even legal π
anywho, I'm all for learning, experimenting and#reckless lightning π₯³ the risk I'm taking with my node is in no relation to the benefit, too I fear.
But why would you do that? What's the purpose of having 100% your-sided channels and not spending? To me it sounds like just putting some #bitcoin at risk :-)
If you run #CLN there are plenty of proper #backup solutions - on LND I guess you just have to copy everything during migration.
Just make sure to never start the old hardware again :D
sounds like you ran #LND, where peer availability is important in case you need to recover your funds via #SCB π
I thought we need changes to #bitcoin to make #eltoo work in #lightning, like SIGHASH_NOINPUT or similar? Also what is APO, Google doesn't help me. I guess it's the answer to my first question π
also mesh central does a good job there.. but sadly all foss solutions fail to give customer friendly windows support (which is my primary use case) as the windows clients are not signed and thus throw warnings at the user. I guess one could fix that by acquiring a proper certificate and building the package on your own.. I did not find any good documentation on that :(
