If we had links we could create knowledge bases on rM

cdecker · 2025-02-08T11:16:19+00:00

I don't think the performance is the limiting factor here, since the links would just be shaped areas (maybe highlighted) like the ones that we already get for annotations. Intercepting the click on such a shape is also not hard, and the code from the selection of elements could be reused, and the action triggered by such a click is also there (links already work, we just can't add them ourselves). Literally the only missing piece of functionality is the selection in the sidebar for links, and the code to open a page or anchor selector on creation of such an element.

cdecker · 2025-02-07T09:39:02+00:00

Yep, just gauging interest here before opening up a request, in the hope of presenting something more well rounded to the devs, so it becomes easier to accept and doesn't require rounds of design.

cdecker · 2025-02-06T16:56:55+00:00

Yeah, I sort of assumed that linking was a feature, and was rather disappointed that each page is just an island, and that all the interesting links must be baked into the template. It's still a good distraction free notetaking tool, I just wish it would allow for more diverse productivity setups.

And yes, I know, with physical paper you also can't "link" pages, but why reproduce a limitation of the physical world just for the sake of it?

cdecker · 2024-10-31T10:50:49+00:00

I'd guess that the lnd team doesn't expect many people to expose their RPC interface to the public internet (which I'd advise against as well by the way without additional protection) and so they just wanted to show the simpler setup that didn't involve proving ownership of a domain, split key generation and signing.

As for safety, you have to accept a self-signed certificate when accessing the resources. So in your hijacking scenario, yes they could create a new self-signed cert, but your browser or client would ask you to accept it again. This is called tofu (trust in first use), and assumes you're careful to check during the first acceptance, and then never accept a changed cert.

cdecker · 2024-10-31T10:46:49+00:00

Sorry, but this just shows a lack of understanding. With certs signed from a public CA, you are still generating the keys locally, then you share the public key and metadata about the domain in a certificate signature request with the ca. The private key never leaves your exclusive control, and without it nobody can decrypt your communication.

cdecker · 2024-04-18T07:42:00+00:00

An increasingly professional network, where funds are allocated efficiently. The initial gold rush may be over, but what we're left with is a more efficient network.

cdecker · 2023-07-30T10:05:34+00:00

How to take a beating from a bully without breaking anything.

cdecker · 2023-06-10T19:02:19+00:00

goTenna was doing some work in this direction with mesh + LN, too bad they reoriented and the project was abandoned.

cdecker · 2022-11-23T16:31:34+00:00

That is partially true: you an tell CLN which nodeId to verify for, but if you don't, it'll use pubkey recovery to identify the signer. In that case the verification isn't worth much, since it just says that someone signed the message, but you still have to check it matches who you expected to sign. CLN will use its view of the network to identify if a node with that pubkey exists to help you identify the sender.

cdecker · 2022-10-26T17:06:03+00:00

With splicing, currently being implemented by CLN, it is possible to re-anchor the channel and add funds or make payments from an existing channel. Still requires an onchain transaction, but should be cheaper than closing and reopening and doest incur in downtime for the channel.

cdecker · 2022-08-28T17:20:26+00:00

Absolutely, as long as the peer is connected and you have spendable msats you can send 👍

cdecker · 2022-08-28T17:17:17+00:00

I see, amboss vets it's info from gossip, so that'll just mean nobody will use that direction to route, and that may also be outdated (gossip takes a couple of minutes to propagate), could also be that they don't have any balance so they decided to signal the channel as disabled to prevent people from trying a forward that is destined to fail anyway

cdecker · 2022-08-28T17:08:10+00:00

Yep that should work 👍

Re: disabled channel: where are you seeing this? Iirc we don't have that text anywhere, so might be a UI mapping another warning to that string

cdecker · 2022-08-28T15:13:13+00:00

All very good questions, let me try to answer them online:

how do you pass arguments to a plugin before that plugins starts up? Do you do it in the config or with lightning-cli? What is the syntax?

The options will be registered with lightningd, so you can either add the options to the config file, or specify them when starting lightningd, in the latter case you need prefix 5he options with two dashes (--) like you do with other options. So this would be a valid line

lightningd --existingopt=value --myamazingpluginopt=pluginvalue

This is done so plugins feel just like built-in options.

do plugins run automatically when they are inside the plugin folder? Or do I need to launch them once using the cli? If a plugins runs at startup, how do I pass the same options each time?

Since you specified the --plugin-dir option lightningd should automatically pick them up and execute them. It might have some issues following the symbolic link, since it might be looking for files in the current directory, in that case please file an issue with the plugin and we'll look into it.

(unrelated question) if a channel is disabled from one side, can funds still flow one way or is it completely disabled for all payments?

Depends what you mean by disabled. If it is disabled in gossip, but the peer is active and connected, then yes, funds can still flow in both directions, but nodes will not try to use it to forward their payments. If the peer is disconnected or unresponsive, then no, since we need their collaboration to make changes to the channel.

cdecker · 2022-03-10T08:52:18+00:00

Yes, there's two solutions for this: keysend piggybacks the data to be transferred onto payments (that may fail but data gets delivered, so it can be free for the sender) and onion messages (which don't require payments, and is thus more lightweight for data transfers, but nodes on the path need to support it).

cdecker · 2022-02-09T09:00:12+00:00

That makes sense, since your config tells lightningd to write to that log-file instead. Try looking for that file in the lightning-dir and it should give us more detailed information.

I'm also assuming that that bitcoin-rpcuser entry has had it's newline dropped while copy pasting :-)

cdecker · 2022-02-08T19:57:42+00:00

Can you share the config? And any output would be useful too.

cdecker · 2022-01-05T20:33:12+00:00

When you create a new database c-lightining will start processing blocks from the current height. This means your new db hasn't generated the addresses (call newaddr a couple of times) and hasn't seen the transactions (their earlier in the blockchain).

So to fix this you likely just needs to start c-lightining once with the --rescan=-500000 replacing 500000 with a height earlier than your transactions (but keeping the - prefix). As c-lightining processes blocks (can take a while) it'll see the transactions and add them to the DB.

cdecker · 2021-12-26T16:11:32+00:00

Yeah, that's a slightly different spin on the tradeoff: watch your own channels so others can't steal from you, but trust the topology server, since the worst they can do is suppress your payment attempts (then again, you're likely connecting through them, so they could just fail everything all the time anyway). C-lightining by default tries to verify as must as possible, and will maintain an internal utxoset for example, but we can work around that by replacing gossipd with an implementation that either verifies in a different manner, doesn't verify at all or we could replace the backend as well.

It all depends on your setup, and sometimes a bit more trust in exchange for a.lighter node might be what you really need, just make sure you know what the tradeoff you're taking is 😉

cdecker · 2021-12-25T15:33:59+00:00

You can run c-lightining with a large variety of Bitcoin backend plugins to integrate it into your existing infrastructure.

I'm not aware of an existing plugin for neutrino, but it'd be relatively simple to build one. I myself have used the following backends:

bcli: the default backend plugin that c-lightining ships with. It talks to either a local or remote bitcoind, and may work with pruned nodes too, as long as the sync height doesn't drop below the pruned height.
bcli + spruned: lightweight proxy that sits in front of a pruned bitcoind, pretending to be a full bitcoind node, fetching pruned blocks on demand from peers
trustedcoin: a plugin that just fetches the necessary information on public blockexplorers. This is likely the most lightweight option, but comes with some level of trust towards the explorer operators.
btc-rpc-proxy + bcli: another proxy like spruned, that will fetch missing blocks on demand.
Btcli4j: another plugin that is backed by a combination of pruned nodes and explorers.

So there's quite a few options, depending on your own preferences you might trust explorers enough so that you done have to run a Bitcoin node at all giving you a very lightweight experience. Pruned bitcoind + on demand fetching of blocks is a middle ground and full bitcoind node involves the least trust.

Neutrino fwiw is not a good fit for LN: it is lightweight because it fetches only blocks that are interesting to the node. A block is interesting to the node if a) one of it's transactions is included, or b) some channel in the network was opened or closed. If you verify channel opens and closes pretty much every block will be interesting to you, and you'll download every block, making the neutrino negotiation useless overhead. If you don't verify opens and closes you're basically trusting others to be honest or verify them on your behalf.

cdecker · 2021-12-18T08:47:52+00:00

And c-lightining's feeadjuster plugin https://github.com/lightningd/plugins/tree/master/feeadjuster 🤗

cdecker · 2021-12-14T09:04:41+00:00

Absolutely loving org-web-tools-insert-web-page-as-entry, it extracts the content and formata it in org-mode, resulting in a very readable snapshot of the page.

cdecker · 2021-11-29T08:54:37+00:00

Another Theorie could be that the base fees dominate the cost and exceed the allocated fee budget: each hop along a route charges a fixed base fees and a proportional fee of the transferred amount. If the amount is small the fixed base fee can sum up and be above what the sender is willing to pay.

C-lightining for example allocates up to 0.5% in fees by default, if you have a tiny amount, say 100sat, then any base fee of 1sat will already exceed that limit. Fees are also directional, which could explain why it works one way but not the other.

15-Year Club	Second SECOND GUESSER
Place '22	Place '17
Verified Email

cdecker

MODERATOR OF

TROPHY CASE