search

btcpayserver / btcpayserver-docker

Docker resources for hosting BTCPayServer easily
MIT License
581 stars 357 forks source link

Can't use new LND/RTL Channel Backup functionality #179

Closed maltokyo closed 4 years ago

maltokyo commented 5 years ago

LND and RTL now allow the backups of all channels, and in BTCPay Server it even looks like it works out of the box in RTL (it tells that backups are on and "verified", a false sense of security).

I asked here whether the mnemonic is required to use channel backups and recover from them, and the answer is yes. https://github.com/lightningnetwork/lnd/issues/3371#issuecomment-518237883

But, as here, we can't use this (without hacks) on BTCPay server - any chances to have backups available by default? https://github.com/btcpayserver/btcpayserver-docker/issues/167

Kukks commented 5 years ago

We have no way to migrate existing deployments in a sane and humane way and LND won't help even though there is access to the private key that is generated from the seed( and is equivalent enough to be a replacement). It will require a lot of hacking, hassle and non-fun code in go

maltokyo commented 5 years ago

At least then you should disable the “backup” screens in RTL.. super false sense of security.

pavlenex commented 5 years ago

That's an issue for RTL repo. I disagree it's "super-false" sense of security, upon deploying LN in BTCPay, we have a gigantic warning about backups.

maltokyo commented 5 years ago

OK, thank you for your reply. For me, I know the risk now, so I am fine. But if I didn't read all your docs (most people) I would assume that backups were enabled with a recent upgrade, and feel "safe".

Roasbeef commented 5 years ago

We have no way to migrate existing deployments in a sane and humane way and LND won't help even though there is access to the private key that is generated from the seed( and is equivalent enough to be a replacement).

It's not that we won't help. It's that from the very beginning we've informed y'all that users MUST have access to their seed. BTCPay is putting users at risk by not storing, nor presenting the seed to the end user. I've talked with Dorier several times about safe ways to implement this, however afaict, y'all have chosen not to do so.

A similar case applies to the usage of pruned nodes, which aren't fully supported.

All of this can easily be resolved with the following steps:

  1. BTCPay starts to store the user's seed externally in it's database, encrypted even, or prompt the user to provide a passphrase for their seed.
  2. BTCPay asks users to migrate to the new version, and publicly states that on-chain funds (for lnd), in the current format, as well as channels (you can use SCBs) are not able to be recovered in the case of a disaster.
  3. BTCPay deprecates the old format

If this project cares about the safety of their users, then once again, I strongly recommend that y'all carry out the step outlined above. I will make my self available to answer any questions, and help with communication so we can ensure the the funds of users using BTCPay are safu.

But if I didn't read all your docs (most people) I would assume that backups were enabled with a recent upgrade, and feel "safe".

This is an excellent point! BTCPay hides critical safety information from the end user. Most users using the system today likely aren't aware of it. This should be an explicit part of on boarding.

It will require a lot of hacking, hassle and non-fun code in go

There is no Go involved in the steps I outlined above.

maltokyo commented 5 years ago

@NicolasDorier , your view? I love your project. Don't get me wrong. It’s how I got into lightning! But I do feel the above needs addressing. But I won’t add anymore funds on BTCPayServer for now than I’m prepared to lose if my hard drive crashes.

NicolasDorier commented 5 years ago

We spoke several time on it, the problem is that we don't have an easy way to migrate our user without locking them out of their funds when they update, which is not acceptable.

I would either:

  1. Remove the static channel backup feature so people are not under false sense of security.
  2. Ask them to backup their wallet file manually (I guess it has the important keys inside)
  3. If possible, allowing them to export their xpriv key (or any piece of data which represent the same info as the mnemonic under a different form), and modify our fork of LND to allow using the xpriv instead of mnemonic (I don't know if technically possible @Roasbeef might tell me)
maltokyo commented 5 years ago

I guess people would be ok with any manual "opt-in" option here, to switch it on and have everything recoverable.

You will eventually have to think of this in your project anyway right? All of the users that you are afraid of locking out, will get irate if they lose their funds anyway with hardware failure etc. Better to at least have the official well-documented option to turn backups on.

NicolasDorier commented 5 years ago

@maltokyo that might be a good idea to have an opt-in. I will think about it.

NicolasDorier commented 5 years ago

@maltokyo well the difference is that user getting reckt on lightning does not happen everyday, but if I lock people out of their funds during an update I will get 2000 people coming on the chat in panic mode where I can only help them running arcane linux command they likely don't understand, mess up, and also lose money because of that.

Most users of btcpay barely can run command line.

NicolasDorier commented 5 years ago

Feel free to work on it, normally it can work with a new docker fragment.

I may be able to make it opt-out actually by modifying our fork of LND and trying both: no seed and with seed for all install during startup.

NicolasDorier commented 5 years ago

Ok giving more thought on this the best approach is to modify our fork:

  1. Remove the "noseedbackup" setting
  2. Assume same behavior as "noseedbackup=1"
  3. When a new wallet is created, save the seed mnemonic next to the wallet.db
  4. Expose the seed mnemonic file through BTCPay.
maltokyo commented 5 years ago

@NicolasDorier - sounds awesome!!!

maltokyo commented 5 years ago

@NicolasDorier Would I have to migrate my installation to a brand new installation and start from scratch with channels etc, with your approach above?

Kukks commented 5 years ago

Start from scratch in terms of lnd since we have no migration path

On Tue, Aug 6, 2019, 17:18 maltokyo notifications@github.com wrote:

@NicolasDorier https://github.com/NicolasDorier Would I have to migrate my installation to a brand new installation and start from scratch with channels etc, with your approach above?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/btcpayserver/btcpayserver-docker/issues/179?email_source=notifications&email_token=AAN357QWUKAE6GS6CWOA77LQDGI4VA5CNFSM4IJNMOVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VPV5Y#issuecomment-518716151, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN357TTIFWQ47CLBGI3EMTQDGI4VANCNFSM4IJNMOVA .

maltokyo commented 5 years ago

So your current 2000+ (?) users will never have a way to backup unless establishing all channels from scratch? Again here some sort of path to backing up (even if it’s a manual pain in the arse) would be optimal. As long as it’s less of a pain than re-establishing all of those channels etc, people will still prefer it I think).

woutersamaey commented 5 years ago

What about new users who haven't used LND before? They don't have any funds at risk but want to start out in the best way. Should new users hold off for a little while because of what's discussed here?

woutersamaey commented 5 years ago

I have a feeling that the solution lies in making LND multi-user / multi-tenant. Maybe with docker we can run an old LND and a new LND side-by-side and have a migration path? (i.e. move funds from old to new - channels be damned, only after the user consents that is). Just brainstorming at this point. If it doesn't help, I'll shut up 🤐

Roasbeef commented 5 years ago

We spoke several time on it, the problem is that we don't have an easy way to migrate our user without locking them out of their funds when they update, which is not acceptable.

Please re-read my initial message. There is no lock out, they simply upgrade, BTCPay detects that they're on an older version, then they sweep their funds away. Simple. BTCPay needs to own this mistake and communicate this to all the users, telling them that their funds are not safe.

Remove the static channel backup feature so people are not under false sense of security.

Users that use it do not have a false sense of security. It is BTCPay that is at fault here, for not giving the user a seed to their Bitcoin wallet.

So your current 2000+ (?) users will never have a way to backup unless establishing all channels from scratch?

That's the current case. Note that I communicated this issue to the BTCPay developers several months ago, and before that, even some time last year. By waiting longer and longer to resolve this issue, they increase the number of affected users. This could have been solved over a year ago, but they chose not to.

Roasbeef commented 5 years ago

Also this isn't about users getting rekt or not. It's about Bitcoin software that doesn't give users any access to their seed at all. Very early on in the lifetime of the project I explained this. IMO, in 2019, it is negligent to ship Bitcoin software that doesn't allow users to restore their funds, and also doesn't surface this information to the user.

If the project is finally fixing this, then I am very happy, as it is long over due.

On Tue, Aug 6, 2019, 2:41 PM Wouter Samaey notifications@github.com wrote:

I have a feeling that the solution lies in making LND multi-user / multi-tenant. Maybe with docker we can run an old LND and a new LND side-by-side and have a migration path? (i.e. move funds from old to new - channels be damned, only after the user consents that is). Just brainstorming at this point. If it doesn't help, I'll shut up 🤐

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/btcpayserver/btcpayserver-docker/issues/179?email_source=notifications&email_token=AAHTWLR5K7SJJYQRH3XF3FLQDHVW3A5CNFSM4IJNMOVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3WRPPI#issuecomment-518854589, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHTWLTXIXWFAMSOXG74X5DQDHVW3ANCNFSM4IJNMOVA .

Roasbeef commented 5 years ago

Ok giving more thought on this the best approach is to modify our fork:

To achieve this, you don't need to modify the fork. When you initialize lnd, you're given the seed right there. As a result, BTCPay can show it directly to the user, or you can store it yourselves.

maltokyo commented 5 years ago

Sorry to jump in again. But is the seed needed only for the on-chain wallet? Would this work?

  1. Sweep all LND on-chain funds to another wallet to have zero on-chain funds in LND
  2. Turn back on the settings to generate the seed when creating a new wallet
  3. Use “createaddress” (or is it “newaddress”?) to make a new LND wallet
  4. Use this new wallet exclusively going forward. Would the new wallet play nicely with existing channels, funded by the old wallet?

Sorry if this is stupid. I don’t know how the lnd on-chain wallet interacts with channels, but I do see that lncli allows us to make new wallets.. so just trying to find a workaround.

Eskyee commented 5 years ago

@rockstardev brain storming session needed... here !! I agree we need to provide the best BTCPay Bitcoin & Lightning software out. here, safe n simple, Noob. ready, but Excellent team work guys. n gals xx its true, BTCPay is growing up very fast... ps Thanks @Roasbeef we need your NRG man!! x

NicolasDorier commented 5 years ago

@woutersamaey @maltokyo

So your current 2000+ (?) users will never have a way to backup unless establishing all channels from scratch?

What about new users who haven't used LND before?

For the existing users, things will continue to work, but they won't have the seed. We can publish a blog post advising them to update at their leasure with proper guidance. (Closing channels and wipeout LND directory)

For new user, they will get the seed.

@Roasbeef

they simply upgrade, BTCPay detects that they're on an older version, then they sweep their funds away.

And how do they sweep their funds if LND refuse to start in the first place? Again you misunderstand the difficulties that prevent us to provide the seed. Our users can't run command line by themselves to fix the situation, and we don't have resources to spend on this, not on support and not on UX dev to fix this specific problem.

Adding a way in BTCPay to see the seed is easy. Having to do a whole UX that stop LND, sweep funds, change the config, restart LND is an architectural change that alone would take me a month to implement. You telling me that it is my problem and I am at fault don't solve the situation: I don't have time to work on it.

My solution https://github.com/btcpayserver/btcpayserver-docker/issues/179#issuecomment-518559902 is acceptable, probably less than a day of work. Though I will not do it. (if @Kukks or @rockstardev feel motivated to work on it, go ahead) Or LND could add a noseedbackup value that solve our problem. (auto unlock + saving word seed in a file for new wallets)

Note that our change will make the official LND incompatible with BTCPay providing the seed, so people will NEED to run our fork for having the word seed in BTCPay UI. (they already do if they use the docker deploy)

Roasbeef commented 5 years ago

And how do they sweep their funds if LND refuse to start in the first place?

Why would it refuse to start? You can detect which version of lnd it is (based on the deployment) and conditionally apply the flag.

and we don't have resources to spend on this, not on support and not on UX dev to fix this specific problem.

They don't need to do anything on the command line with what I outlined. I understand the project has limited resources, but I would consider the safety of user funds to be a very high priority for any Bitcoin project that involves a wallet or keys.

Having to do a whole UX that stop LND, sweep funds, change the config, restart LND is an architectural change that alone would take me a month to implement. You telling me that it is my problem and I am at fault don't solve the situation: I don't have time to work on it.

You've known for nearly a year how big an issue this is. If you don't care about the safety of the funds that users put into the project, then I guess you should get some "SFYL" messages ready, or maybe a FAQ to explain why they lost their money, and how it could've been prevented.

The solution you outlined above IS NOT A SOLUTION. You're putting far too much burden on the user, when we expose the tools in lnd to do everything correctly. Once again, from the very start, I informed you how dangerous not giving users their back up seed was. If BTCPay fails to act on this, more than a year later, then I think that says a lot about y'all's commitment to y'all's users.

Yes, it will take some time to do this properly, but isn't it worth it to have the peace of mind that users will be able to restore their funds?

cfromknecht commented 5 years ago

Adding a way in BTCPay to see the seed is easy. Having to do a whole UX that stop LND, sweep funds, change the config, restart LND is an architectural change that alone would take me a month to implement. You telling me that it is my problem and I am at fault don't solve the situation: I don't have time to work on it.

We began the process of deprecating this mode almost a year ago, which we specifically brought to your attention in this PR. It was laid out very clearly that support for this testing feature will be removed, and since then no progress has been made on migrating existing users away from it.

At the same time, I do acknowledge that migrating existing users is more involved, but as far as I can tell there hasn't even been an attempt to ensure the safety of new users being onboarded to BTCPay. Instead, the number of potentially affected users continues to grow a year later, rather than quarantining the issue to early adopters.

Note that our change will make the official LND incompatible with BTCPay providing the seed, so people will NEED to run our fork for having the word seed in BTCPay UI. (they already do if they use the docker deploy)

We planned a long deprecation cycle instead of removing it immediately specifically to support this project and offer time to come up with a solution, fully aware of the limited resources available. If the status quo continues and nothing is done, BTCPay will have to maintain noseedbackup in their fork either way when it is ultimately removed.

TBH the fact that no progress has been made thus far makes me question whether we should continue to postpone the removal of noseedbackup on BTCPay's behalf.

NicolasDorier commented 5 years ago

Why would it refuse to start? You can detect which version of lnd it is (based on the deployment) and conditionally apply the flag.

@Roasbeef all deployments run same version of LND. If we update LND, this new version of LND is also updated, there is no way to update some part of the stack and not other without architectural change which take months. It is also a UX problem: We don't want people to update only one element of the stack specifically 1 BTCPay release force specific versions of all software on which it depends, as this is the only versions we test.

but I would consider the safety of user funds to be a very high priority for any Bitcoin project that involves a wallet or keys

Speaking of which would be nice then that you fix or remove the buggy cookie file authentication in LND. Right now if Bitcoin core reboot while LND use it and that LND use cookiefile authentication, LND does not crash but stop monitoring the chain, leaving open to steal. (though out of topic, but this one concerned me on the security of lnd)

some "SFYL" messages ready,

Yes I already do basically telling them they will lose their money and they need to be tech savvy to recover or see the documentation of the implementation they are using.

But even worse than risking a loss, is updating and getting locked out of their fund.

TBH the fact that no progress has been made thus far makes me question whether we should continue to postpone the removal of noseedbackup on BTCPay's behalf.

You can remove it if we are the only problem. We already maintain or own fork of LND for other reasons. (see my PRs that did not get merged)

My plan on https://github.com/btcpayserver/btcpayserver-docker/issues/179#issuecomment-518559902 will allow to have seed for new deployment, while not breaking current user when they update.

Roasbeef commented 5 years ago

You can even just do a new update that includes the seed, then tell old users to use RTL to close all their channels, and send those funds to a new wallet. Then create a new instance.

NicolasDorier commented 5 years ago

But the old users will update BEFORE seeing my warning. That's the problem, when they updated this is too late, their LND will not start.

Roasbeef commented 5 years ago

Yes I already do basically telling them they will lose their money and they need to be tech savvy to recover or see the documentation of the implementation they are using.

As far as I've seen, this is noticeably absent from all public promotion of BTCPay.

Roasbeef commented 5 years ago

That's the problem, when they updated this is too late, their LND will not start.

Yep, then they'll complain and realize they need go back to the prior version and sweep their funds. There's no way around this, you need to communicate to users the current state of the safety of their funds.

NicolasDorier commented 5 years ago

image

This is on the config page

NicolasDorier commented 5 years ago

Yep, then they'll complain and realize they need go back to the prior version and sweep their funds.

  1. there is no way to downgrade without command line
  2. I don't want them flooding the chat in panic mode all at once
  3. It would require that I make sure that things can be downgradable, if BTCPay make DB changes this is not possible
woutersamaey commented 5 years ago

Some ideas that may help:

Kukks commented 5 years ago

I don't think this should warrant a major release on its own and forcing ( instead of allowing to do it on their own at the very least if we cannot find a graceful upgrade path) to close all their channels is definitely not acceptable. I would be furious if a simple version bump wiped out all my channels( and potentially funds) just because of this issue.

On Thu, Aug 8, 2019, 07:32 Wouter Samaey notifications@github.com wrote:

Some ideas that may help:

  • What if we release BTCPay as a new version 2.0 and inform users about it in this light? 1.x users will remain in the same boat.
  • If communication beforehand is an issue, we can simply release a small update now that has a simple notification system (I.e. curl a URL from the docs and if not empty, show at the top of the Admin UI). People will need to do the small upgrade to see the message, sure, but it is helpful and low effort. This also buys you time.
  • Personally I do think users have been warned more than enough and as this is experimental software. Sometimes experiments need to be restarted. It should not upset anyone if we close all their channels and move their funds to safety, but they need to re-add channels after.
  • Do we really need a full UI for this? Can’t we inform the user (and ask him some Y/N questions during the Docker deployment update script? Or are you also considering non-dockers to be an issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/btcpayserver/btcpayserver-docker/issues/179?email_source=notifications&email_token=AAN357SRFEM4PMT7X3GD7E3QDOVXLA5CNFSM4IJNMOVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD32PRRY#issuecomment-519370951, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN357TOVGMGYD57N5NSZYTQDOVXLANCNFSM4IJNMOVA .

woutersamaey commented 5 years ago

@Kukks Forcing is definitely not what we want. That’s why I suggested a different version scheme, allowing people to choose to stay or upgrade. The choice can be presented on the command line (for docker deployments), but I guess non-dockers are much harder. These were just some ideas. Will shut up now.

Kukks commented 5 years ago

@Kukks Forcing is definitely not what we want. That’s why I suggested a different version scheme, allowing people to choose to stay or upgrade. The choice can be presented on the command line (for docker deployments), but I guess non-dockers are much harder. These were just some ideas. Will shut up now. @woutersamaey you don't need to shut up haha. We're all neutral and equal in this discussion :)

maltokyo commented 5 years ago

Looks like I’d better start closing my channels and sweeping 😅. It was fun while it lasted and I learned a lot so far 👍🏻 I will implement again when I have certainty that I can really use with larger amounts and can back them up.

I really wish I could help, and while I’ve grown to consider myself a “power user” I can’t contribute in the coding part. Maybe I can help to document this upgrade?

woutersamaey commented 5 years ago

I may be able to help with the backup and rollback to a previous/specific version for docker installs. Looks like this will come in handy anyway.

NicolasDorier commented 5 years ago

@woutersamaey no need of complicated solution look my solution here:

https://github.com/btcpayserver/btcpayserver-docker/issues/179#issuecomment-518680623

This is like half a day of work without any work on btcpay side aside of reading a file and leave user to update at their leisure.

Downside is that the official LND will not work with btcpay out of the box without them doing some auto unlocking and saving the seed in a file. But that's as far as we can go.

NicolasDorier commented 5 years ago

there hasn't even been an attempt to ensure the safety of new users being onboarded to BTCPay.

But HOW, let me know HOW. There is no way to differentiate "old user" from "new user", people update all to same version at their own leisure. There is no way to run "old software" for old user and "new software" for new user. There is no way we can tell them during the update to do things either. They will push the button see things which explode and get angry.

Moreover, this would be a combinational explosion of compatibility to check.

I submitted a solution https://github.com/btcpayserver/btcpayserver-docker/issues/179#issuecomment-518680623 after @maltokyo made me think we can make it "opt-in" for old user and default for new users. It requires we do it on our own fork, but that's ok. I asked for LND a LONG time for a solution that allow me to migrate. And I told you exactly what was the problem, and this would be easy for you to figure solution out. Instead you keep pushing that "that's not how you must use LND". I don't care how you think I must use LND, I have a problem and you don't help me so until you help me to get this shit fix, this will continue to drag both of our time.

My solution is maybe half a day of work, but as always, when I make PR and suggestion this get dismissed as "not the way we do thing", so instead of arguing or wasting weeks to workaround LND, the fastest way is to fork LND and maintain our own version.

It makes BTCPay incompatible with the official LND, but there is nothing we can do more at that point. We have limited resources, we are not a LND wallet, we integrate dozen of software in our stack, our purpose is not to design UX specific for LND, so we need to workaround that.

Roasbeef commented 5 years ago

I don't want them flooding the chat in panic mode all at once

This seems to be the main pain point on y'alls end. We can help slightly with the support, but I think it's unavoidable as it's a rather major change.

Roasbeef commented 5 years ago

There is no way to differentiate "old user" from "new user", people update all to same version at their own leisure

Is there no versioning information stored in BTCPay's database? As far as distinguishing, you can try to start lnd w/ and w/o the flag and handle that there, though this isn't very elegant.

I don't care how you think I must use LND, I have a problem and you don't help me so until you help me to get this shit fix, this will continue to drag both of our time.

This all arose due to BTCPay using a flag that we discouraged from the start (`noseedbackup). We've offered help in the form of an update path, and have given information on how to do it safely.

It makes BTCPay incompatible with the official LND, but there is nothing we can do more at that point. We have limited resources, we are not a LND wallet,

I don't think this is a good decision as it will put your fork further behind mainline lnd, which will make maintaining it more difficult for y'all, creating more work in the future for y'all.

Roasbeef commented 5 years ago

And I told you exactly what was the problem, and this would be easy for you to figure solution out.

If this is about the TLS feature, we opted to have a safe default for all/most users. AFAIK, y'all use an nginx proxy to handle TLS. This is still compatible with lnd's default TLS RPC, as the nginx proxy just need to be given lnd's cert, then it can proxy as normal, offering a Let's Encrypt cert to the regular endpoint.

Roasbeef commented 5 years ago

Assume same behavior as "noseedbackup=1"

Can you elaborate on this?

Roasbeef commented 5 years ago

We've planned to do #1 on in your list. As for the rest:

When a new wallet is created, save the seed mnemonic next to the wallet.db Expose the seed mnemonic file through BTCPay.

Why do this require making a fork of lnd? If you programmatically instantiate lnd using this call, and this call. Then there's no need to make a new fork or read from disk, as you can script this using bash, C# (gRPC), or over the REST interace. The first call gives you a seed, and the second one commits it to lnd. As a result there's no UI needed and the user is able to obtain the seed later. You may also want to generate a strong passphrase for the user's wallet unlock as well.

I understand that you went with the current model because it was easier to deploy, and also easier for the user as they didn't need any knowledge of what a seed is. However, this is the classic security vs usability tradeoff, and in this case, I think the tradeoff went in the wrong direction. Easy buttons are great, but they require you to trade of UX for security.

NicolasDorier commented 5 years ago

Can you elaborate on this?

@Roasbeef so the idea is that we will do a mode which:

  1. Does not crash on users who used lnd before this update
  2. For new users, it will save the seed inside a file next to the wallet db with the default password
  3. We will have an "auto unlock" so we don't have to create external tooling to unlock automatically the lnd wallet
  4. In BTCPay, just read the seed file (if it exists) and present it in the UX

By doing this, new users have a way to get their seed. And old users are not locked out of their funds during an update.

Roasbeef commented 5 years ago

Rather than continue to manage your own fork, wouldn't you rather follow the path I outlined above? You'd also be able to code C# (or w/e) rather than Go as well. Also having the code in place to interact w/ the WalletUnlocker gRPC server will make it easier to surface the backup/restore functionality in lnd.

As for old users, you can resolve this on the docker level:

NicolasDorier commented 5 years ago

@Roasbeef we are already maintaining our fork for other PR that you don't want to merge.

Making a health check and coding a WalletUnlocker seems more painful to us than changing the Go code. If I am correct, our change will require less then 50 lines of Go code, so that is easily maintainable.

Also, I can't use gRPC in C# as long as C# gRPC lib rely on a native binary which will break on different arch. (This should change in .NET Core 3.0 but we are far from migrating, also I don't really like introducing one dependency for only a single call)

maltokyo commented 5 years ago

Ok. So I closed all 13 channels and swept all funds out. Ready to get any updates etc that may need testing. I won’t begin again until funds are backed up properly.