profile
viewpoint
Klaus klauslovgreen evershift online http://evershift.com Buy low, sell high. Don't trust. Verify.

klauslovgreen/bips 0

Bitcoin Improvement Proposals

klauslovgreen/bitcoin 0

Bitcoin Core integration/staging tree

klauslovgreen/bitcoin.github.io 0

Stuff about bitcoin

klauslovgreen/BlueWallet 0

Bitcoin thin client for iOS & Android. Built with React Native

klauslovgreen/breadwallet 0

breadwallet - bitcoin wallet

klauslovgreen/lnbook 0

Mastering the Lightning Network (LN)

klauslovgreen/sphinx-relay 0

Node.js wrapper for communication between sphinx client and lightning node.

created repositoryapoelstra/filterscreen

created time in 10 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 type RemoteDaemonConfig struct { 	// MacaroonDir is the directory that contains all the macaroon files 	// required for the remote connection. 	MacaroonDir string `long:"macaroondir" description:"The directory containing all lnd macaroons to use for the remote connection."`+	+	// CustomMacaroonPath is the path to the custom macaroon that should be+	// used instead of needing to specify the macaroon directory that+	// contains all of lnd's macaroons. The custom macaroon MUST have all+	// permissions that all the subservers use, otherwise permission errors+	// will occur.+	CustomMacaroonPath string `long:"custommacaroonpath" description:"The path to the custom macaroon to use. Cannot be specified at the same time as macaroondir. The custom macaroon must contain ALL permissions required for all subservers to work, otherwise permission errors will occur."`

Oh, my bad. I missed that on my end. Looks good 👍

guggero

comment created time in 11 hours

issue openedlnbook/lnbook

Introducing math Terminology and unifying Terms like Network / Graph

Channel graph section in gossip introduces graphs on the fly. Is that the place? I assume we need graphs at various other places.

Also I understand that in lnd there is an object called channel graph and I understand its semantics. Similarly I wonder what are the semantics of "the Lightnig network". One could easily argue that the network of payment channels is the lightning network. We seem to define it as a p2p communication protocol on top of bitcoin. Reading the gossip chapter it feels like the p2p network is "the lightning network". I understand the discussion is somewhat academic but where I am coming from it makes sense to have clear definitions.

created time in 11 hours

push eventlnbook/lnbook

Rene Pickhardt

commit sha 634b9208699ed50723d00e9932b92b98aa5caffd

completed missing sentence

view details

push time in 11 hours

issue openedlnbook/lnbook

Editorial: extend the introduction to the gossip protocol chapter with more motivation

Which part needs editing? https://github.com/lnbook/lnbook/blob/develop/gossip.asciidoc

What editing does this need? Introduction

How does it currently read? It assumes everyone has a clear picture in mind why the channel graph needs to be synced with peers

How should it read? we should refer to the routing chapter and emphasize on the fact that the channel graph was a choice by the developers with respect to our transport layer and sourced based onion routing. Consider there where routing proposals (like ant routing) that would not have needed a gossip protocol as they would have discovered a path even if all channels where unpublished or the competitor raiden didn't need a gossip network because channels carry more on chain footprint c.f.: https://bitcoin.stackexchange.com/questions/85264/why-did-the-lightning-network-implement-a-gossip-protocol

created time in 11 hours

pull request commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

I fixed the sampleData.ts with a temporary commit. Will remove that once we've tagged the final lnd v0.12.0-beta version.

guggero

comment created time in 11 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 type RemoteDaemonConfig struct { 	// MacaroonDir is the directory that contains all the macaroon files 	// required for the remote connection. 	MacaroonDir string `long:"macaroondir" description:"The directory containing all lnd macaroons to use for the remote connection."`+	+	// CustomMacaroonPath is the path to the custom macaroon that should be+	// used instead of needing to specify the macaroon directory that+	// contains all of lnd's macaroons. The custom macaroon MUST have all+	// permissions that all the subservers use, otherwise permission errors+	// will occur.+	CustomMacaroonPath string `long:"custommacaroonpath" description:"The path to the custom macaroon to use. Cannot be specified at the same time as macaroondir. The custom macaroon must contain ALL permissions required for all subservers to work, otherwise permission errors will occur."`

Yes, I did update the docs. Or did I overlook anything?

guggero

comment created time in 11 hours

push eventlightninglabs/lightning-terminal

Oliver Gugger

commit sha fed5f3e7ba9669e3790f86c4b198670efdb5924e

mod+terminal: update to latest compatible versions

view details

Oliver Gugger

commit sha 135dbdab0d2d592b3c425b85d9465b68889d4910

terminal: block until lnd is unlocked

view details

Oliver Gugger

commit sha bc3ea2c04a27c27f2e7b0255aa39e2699b3024f5

multi: only use admin mac or allow single mac With the new lndclient version we can specify a single, custom macaroon. We use the admin macaroon as the custom macaroon in the remote connection case which removes the need to copy all subserver macaroons to the host where LiT is running. Users baking custom non-admin macaroons can also specify that directly with a new configuration option.

view details

Oliver Gugger

commit sha 422321516f4cc0df39eed727a49032d04052ce36

TEMPORARY-REMOVE-WHEN-FINAL-LND-IS-READY

view details

push time in 11 hours

push eventlnbook/lnbook

Fichte42

commit sha de78a4710ec2a33f3869dad2d50eaf5bc08df876

Add Muun refs #528

view details

Fichte42

commit sha 5079219077ea8e1129c2b88b23f5b36a8b4ca315

Fixed Keystore

view details

Andreas M. Antonopoulos

commit sha d29012d12f2364c4144a6a214075271ca7eef152

Merge pull request #586 from Fichte42/issue_528 Add Muun

view details

push time in 12 hours

PR merged lnbook/lnbook

Add Muun

refs #528

+1 -0

1 comment

1 changed file

Fichte42

pr closed time in 12 hours

pull request commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

I agree that the RPC compile check will fail, but the build is also failing on the "typescript compile" step because the frontend code is not updated for v0.12 protos. This also breaks my local docker build because the frontend won't build successfully.

Can you either remove the proto update or update the sampleData.ts file to fix the frontend build?

guggero

comment created time in 12 hours

issue commentlnbook/lnbook

Editorial: Add muun wallet

Ok, fixed it.

klauslovgreen

comment created time in 13 hours

pull request commentlnbook/lnbook

Add Muun

Muun is not custodial.

Fichte42

comment created time in 13 hours

issue commentlnbook/lnbook

Editorial: Add muun wallet

Characterizing Muun as custodial because of the availability of turbo channels is incorrect and misleading, in my opinion. We should not change it. It is a non-custodial or self-custodial wallet.

klauslovgreen

comment created time in 13 hours

issue commentlnbook/lnbook

Editorial: Add muun wallet

The website states "Muun is a self-custodial wallet for bitcoin and lightning", but for the time being i added it as "Custodial" because of https://blog.muun.com/turbo-channels/

It really depends on your preferences. When transactions require the use of turbo channels, there is a limited window of time where you trust Muun. Specifically, during that window of time, you trust Muun will not execute a - very public![1] - double-spend attack. If you are not okay with this, you should disable turbo channels.

klauslovgreen

comment created time in 13 hours

pull request commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

The new RPC compile check prevents us from using an old version. Perhaps we need a way to override that. Or I can update the testdata, should be straightforward.

The check will fail until we reference the final version of lnd anyway since it tries to download it from an URL without the rc tag.

guggero

comment created time in 13 hours

PR opened lnbook/lnbook

Add Muun

refs #528

+1 -0

0 comment

1 changed file

pr created time in 13 hours

pull request commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

Your latest rebase includes an updated lnd proto which breaks the CI build. The new proto requires an update to the frontend Typescript types. I think it's fine to keep the old proto in this PR as I will update it separately.

guggero

comment created time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 type RemoteDaemonConfig struct { 	// MacaroonDir is the directory that contains all the macaroon files 	// required for the remote connection. 	MacaroonDir string `long:"macaroondir" description:"The directory containing all lnd macaroons to use for the remote connection."`+	+	// CustomMacaroonPath is the path to the custom macaroon that should be+	// used instead of needing to specify the macaroon directory that+	// contains all of lnd's macaroons. The custom macaroon MUST have all+	// permissions that all the subservers use, otherwise permission errors+	// will occur.+	CustomMacaroonPath string `long:"custommacaroonpath" description:"The path to the custom macaroon to use. Cannot be specified at the same time as macaroondir. The custom macaroon must contain ALL permissions required for all subservers to work, otherwise permission errors will occur."`

Awesome! 🥇

Not sure if you want to do it in this PR, but we should also update the docs & examples to use macaroonpath as well.

guggero

comment created time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 type RemoteDaemonConfig struct { 	// MacaroonDir is the directory that contains all the macaroon files 	// required for the remote connection. 	MacaroonDir string `long:"macaroondir" description:"The directory containing all lnd macaroons to use for the remote connection."`+	+	// CustomMacaroonPath is the path to the custom macaroon that should be+	// used instead of needing to specify the macaroon directory that+	// contains all of lnd's macaroons. The custom macaroon MUST have all+	// permissions that all the subservers use, otherwise permission errors+	// will occur.+	CustomMacaroonPath string `long:"custommacaroonpath" description:"The path to the custom macaroon to use. Cannot be specified at the same time as macaroondir. The custom macaroon must contain ALL permissions required for all subservers to work, otherwise permission errors will occur."`

Great point. I've added a deprecation comment to the dir flag and renamed the new one to macaroonpath.

guggero

comment created time in 14 hours

push eventlightninglabs/lightning-terminal

Oliver Gugger

commit sha a388457736b37d50acf74e0e84fa90c5457e17e2

mod+terminal: update to latest compatible versions

view details

Oliver Gugger

commit sha adf9d66037199181735c365ad091627213fbea20

terminal: block until lnd is unlocked

view details

Oliver Gugger

commit sha ec35258affd5df109927e290a51abae7a482dbcd

multi: only use admin mac or allow single mac With the new lndclient version we can specify a single, custom macaroon. We use the admin macaroon as the custom macaroon in the remote connection case which removes the need to copy all subserver macaroons to the host where LiT is running. Users baking custom non-admin macaroons can also specify that directly with a new configuration option.

view details

push time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 Lightning Terminal is backwards compatible with `lnd` back to version v0.11.1-be  | LiT              | LND          | Loop        | Faraday      | Pool          | | ---------------- | ------------ | ----------- | ------------ |---------------|+| **v0.3.5-alpha** | v0.12.0-beta | v0.11.2-beta | v0.2.3-alpha | v0.4.2-alpha |

Cool 👍

guggero

comment created time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 Lightning Terminal is backwards compatible with `lnd` back to version v0.11.1-be  | LiT              | LND          | | ---------------- | ------------ |+| **v0.3.5-alpha** | v0.11.1-beta | 

Doh! I should've probably read the sentence above that wasn't visible in the diff. Ok, that makes sense.

guggero

comment created time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 Lightning Terminal is backwards compatible with `lnd` back to version v0.11.1-be  | LiT              | LND          | | ---------------- | ------------ |+| **v0.3.5-alpha** | v0.11.1-beta | 

In theory we should still be backward compatible down to v0.11.1-beta, at least for remote connections.

guggero

comment created time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 Lightning Terminal is backwards compatible with `lnd` back to version v0.11.1-be  | LiT              | LND          | Loop        | Faraday      | Pool          | | ---------------- | ------------ | ----------- | ------------ |---------------|+| **v0.3.5-alpha** | v0.12.0-beta | v0.11.2-beta | v0.2.3-alpha | v0.4.2-alpha |

I wasn't sure if the UI would be ready together with lnd v0.12. But in that case it makes sense to update to v0.4.0 in the PR that adds the UI. Going to remove this diff then.

guggero

comment created time in 14 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 Lightning Terminal is backwards compatible with `lnd` back to version v0.11.1-be  | LiT              | LND          | Loop        | Faraday      | Pool          | | ---------------- | ------------ | ----------- | ------------ |---------------|+| **v0.3.5-alpha** | v0.12.0-beta | v0.11.2-beta | v0.2.3-alpha | v0.4.2-alpha |

Why v0.3.5? AFAIK we want the next release to be v0.4.0 and include the pool ui.

guggero

comment created time in 15 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 type RemoteDaemonConfig struct { 	// MacaroonDir is the directory that contains all the macaroon files 	// required for the remote connection. 	MacaroonDir string `long:"macaroondir" description:"The directory containing all lnd macaroons to use for the remote connection."`+	+	// CustomMacaroonPath is the path to the custom macaroon that should be+	// used instead of needing to specify the macaroon directory that+	// contains all of lnd's macaroons. The custom macaroon MUST have all+	// permissions that all the subservers use, otherwise permission errors+	// will occur.+	CustomMacaroonPath string `long:"custommacaroonpath" description:"The path to the custom macaroon to use. Cannot be specified at the same time as macaroondir. The custom macaroon must contain ALL permissions required for all subservers to work, otherwise permission errors will occur."`

I like that we can now just specify the admin macaroon file instead of the full dir. I wonder if we should just deprecate macaroondir and change custommacaroonpath to macaroonpath instead of keeping both flags permanently. I believe that having custommacaroonpath adds a bit of confusion. My hunch is that everyone should just use this flag pointed at the admin macaroon. Maybe I'm misunderstanding the intention here though.

guggero

comment created time in 15 hours

Pull request review commentlightninglabs/lightning-terminal

Add lnd v0.12.0-beta compatibility, allow single macaroon

 Lightning Terminal is backwards compatible with `lnd` back to version v0.11.1-be  | LiT              | LND          | | ---------------- | ------------ |+| **v0.3.5-alpha** | v0.11.1-beta | 

Shouldn't this be v0.12.0-beta like below?

guggero

comment created time in 15 hours

PR opened lightninglabs/lightning-terminal

Reviewers
docs: multiple small fixes

Fixes #170. Fixes #171.

+107 -85

0 comment

6 changed files

pr created time in 15 hours

PR opened lightninglabs/lightning-terminal

Reviewers
Add lnd v0.12.0-beta compatibility, allow single macaroon

Depends on https://github.com/lightninglabs/pool/pull/202 and the final release of lnd v0.12.0-beta.

Adds compile time and run time compatibility with lnd v0.12.0-beta. Also pulls in the latest version of lndclient which allows us to cleanly block on startup until lnd is unlocked. We can also use a single macaroon now instead of needing to specify all subserver macaroons. Either the admin.macaroon is used if --remote.lnd.macaroondir is specified. Or a custom one (must contain all required permissions!) can be specified with --remote.lnd.custommacaroonpath.

Fixes https://github.com/lightninglabs/lightning-terminal/issues/155.

+77 -38

0 comment

7 changed files

pr created time in 15 hours

more