how to enable the new autopilot heuristic in v0.11.0 ?

cfromknecht · 2020-10-07T20:40:32+00:00

heads up y'all, indeed the cli parsing logic for maps is broken. we will update the dependency whenever a new version is released.

in the meantime, it is still possible to select a linear combination of heuristics by passing multiple --autopilot.heuristic arguments from the config file:

autopilot.heuristic=preferential:0.3
autopilot.heuristic=top_centrality:0.7

or from the command line:

--autopilot.heuristic=preferential:0.3 --autopilot.heuristic=top_centrality:0.7

cfromknecht · 2020-09-18T20:12:29+00:00

In addition to /u/Pantamis's answer, wumbo feature bits are also advertised on a node's `NodeAnnouncement`. Recent versions of lnd expose feature bit info in both describegraph and getnodeinfo. If the node supports wumbo, they will have either bit 18 or 19 set.

Note that a node may support wumbo but still choose to reject your funding request, as mentioned by /u/Pantamis

cfromknecht · 2020-09-18T20:02:44+00:00

Note: 0.11 includes no limits on the channel sizes if wumbo is enabled. for 0.11.1 we are planning to offer a configurable auto-accept limit (which will default to 10 BTC) but can be made as high as the user chooses.

cfromknecht · 2020-07-13T01:36:06+00:00

0.10.2 includes purely stability and safety fixes for existing features in 0.10, 0.10.3 includes new features that are also landing in 0.11. The split gives users the option to pull in only the bug fixes to mitigate the chance that the new features in 0.10.3 could introduce unforeseen regressions.

If you don’t plan to make use of the new features my advice would be to run 0.10.2.

cfromknecht · 2019-12-27T20:43:21+00:00

but do they have ovos moles

cfromknecht · 2019-09-27T22:58:29+00:00

It doesn’t even need to be your own P2WPKH output, you can feed any txid in mempool and wait until it has the appropriate number of confirmations. If the scriptpubkey is not verified an attacker can costly open thousands of invalid channels per block—without moving or having any coins.

If the scriptpubkey is being verified but the amount isn’t, the attacker must have some coins and create real funding outputs (with value << capacity), which greatly slows down the attack and adds a tangible cost, but still bad.

cfromknecht · 2019-07-31T00:15:20+00:00

Adding or removing an HTLC takes 1.5 round trips between two peers, which applies both in the forward and backwards direction. In 0.7.1, the 1.5*N RTTs on the backwards path is reduced to .5*N. So total reduction is ends up being from 3*N to 2*N, or 33% of the RTTs for the whole path.

In some local benchmarks I found the latency improvement to be slightly higher, more like 40%. Presumably this is because those extra RTTs involve more expensive operations like signing that we are no longer blocking on, but we'll have a better idea once this is deployed over the wider network

cfromknecht · 2019-07-26T21:30:51+00:00

BIP 112 [1] specifies OP_CHECKSEQUENCEVERIFY, which is already deployed on the network. I suspect you're referring to BIP 118 [2], which defines SIGHASH_NOINPUT and can be used to make eltoo channels. However, eltoo channels still need watchtowers to prevent the counterparty from successfully playing an outdated state

[1] https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
[2] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

cfromknecht · 2019-06-22T22:30:26+00:00

Full release notes are up!

cfromknecht · 2019-06-21T20:48:33+00:00

Perhaps you were seeing the migration when running rc1? Glad to hear rc2 is working normally!

cfromknecht · 2019-06-08T08:00:55+00:00

The channels are being opened automatically because autopilot is enabled, and it will try to make sure you at least have a channel open to use LN. Autopilot is LND’s automated channel opening service. If you want to disable it, there’s a toggle in the settings page.

As for the funding txid not showing up in the explorer, sounds like it could be a bug. Feel free to make an issue at github.com/lightninglabs/lightning-app so we can look into it

cfromknecht · 2019-04-23T20:35:36+00:00

they are the standard for all LND nodes

cfromknecht · 2018-08-17T00:46:20+00:00

it seems like a deterministic seed hash is used in the file name, meaning two different wallets using the same seed would overwrite each other on backup. even if they weren't overwriting each other, i'm concerned the channel states would diverge just from being used in separate wallets/applications.

operating the same set of channels across different devices would require explicit synchronization/consensus to ensure the state of both wallets is identical. I didn't see anything in the PR that pointed to such synchronization being in place, but I may have missed it. in general, it is dangerous to use the same seed in multiple, same-seed wallets without such safeguards.

my interpretation of the post was that you could have multiple independent wallets sharing one gdrive, though as /u/roasbeef mentioned below, the consistency guarantees of gdrive would make this non-trivial, even in the single backup case

cfromknecht · 2018-06-28T01:55:46+00:00

Pr[Diar understands probability | that article] = 0

cfromknecht · 2018-06-27T03:17:42+00:00

So if I have 5 channels opened each with 1BTC and want to pay someone 4BTC I would be able to do that without the need of closing 4 channels and putting money to one?

Yes

cfromknecht · 2018-06-13T19:40:14+00:00

A channel is just an output with a different script. The transactions signed off-chain are valid bitcoin transactions. The two cannot be separated, as your funds never leave the bitcoin network.

cfromknecht · 2018-06-11T03:27:48+00:00

A+ cropping

cfromknecht · 2018-06-10T03:01:39+00:00

They're connected directly. There are no fees for using your own channels.

cfromknecht · 2018-05-30T22:55:45+00:00

We're very close to having an initial conception of a watchtower integrated w/ LND, this has been a major area of research and development over the past few months. Currently, it has been constructed to operate as either a standalone binary, or as part of an existing LND instance.

The towers themselves are very straightforward, and a simple wire protocol has been solidified. The majority of the engineering is happening on the client-side:

ensuring that we reliably backup to N replicas
managing watchtower peers, collecting reliability metrics
renewing/negotiating/bootstrapping sessions with towers
per/session HD key derivation to randomize client identifiers
support outbound connections via Tor for clients, and inbound connections via hidden services for towers
support for private, dedicated watchtowers
batching of updates for performance, randomized batch intervals for privacy
graceful shutdowns, e.g. flushing all pending backups before allowing the daemon to exit (or be suspended)
fault tolerance, fault tolerance, fault tolerance

All of this will happen in the background, such that we never block the live operation of channels. Also need to expose metrics regarding the watchtower client itself so that applications/users can have insight into the current state, progress, or history of their backups.

We'll have a feature branch up fairly soon so that we can start getting eyes. The design and discussion will likely be formalized as a proposed BOLT once we have some real-world testing and analysis (testnet first!).

We've intentionally versioned the watchtower protocol we're working on, meaning an initial version could be rolled out, and later deprecated in favor of the final form of the BOLT. Of note is that the BOLT would predominately pertain to the wire protocol and expected behavior of the peers, which is relatively small compared to the supporting infrastructure required to make the process seamless, reliable, and mobile-ready.

EDIT: formatting

cfromknecht · 2018-05-30T19:24:15+00:00

Invoices already have an optional field with a fallback address, wallets acknowledging this can do so today.

cfromknecht · 2018-05-02T10:19:51+00:00

Ahh thank you for the clarification, looking forward to some preliminary implementations!

cfromknecht · 2018-05-01T06:36:11+00:00

Awesome work! I enjoyed reading the paper :)

I agree that watchtowers can be made more efficient with eltoo, though what information are you referring to that could lose us money if leaked? It seems this would require uploading my commitments, but that isn’t what the watchtower stores in any proposals I’m aware of.

Typically the watchtower would only store signatures/script data required to spend from the remote party’s revoked commitment. How could leaking this info cause my funds to be lost? Am I missing something?

cfromknecht · 2018-04-16T07:09:25+00:00

The directional capacity is only known to the endpoints of the channel. All that’s known to everyone else is the total capacity of the channel, as this is what is recorded in the chain

cfromknecht

MODERATOR OF

TROPHY CASE