profile
viewpoint
Saibato Saibato UTC: barbed wire land https://www.twitter.com/saibatoai Make me smile addr: 1CL2NFws71dPzYTxWfj5DBtQe5BjzToA6b In source we trust, in compile we frust.

Saibato/bitcoin 1

Bitcoin Core integration/staging tree

Saibato/bitcoindevlist.com 0

Support bitcoin developers so they can focus on building our future.

Saibato/bitcpaw 0

Bitcoin Peer Address Wrapper

Saibato/clboss 0

Automated C-Lightning Node Manager

Saibato/gui 0

Bitcoin Core GUI staging repository. Please do not fork unless for development reasons.

Saibato/lightning 0

c-lightning — a Lightning Network implementation in C

Saibato/lightning-rfc 0

Lightning Network Specifications

Saibato/monero 0

Monero: the secure, private, untraceable cryptocurrency

issue commentZmnSCPxj/clboss

ChannelCandidateInvestigator - how does it work ?

Sorry, had to do some reinstalls, will set up IRC again.

hosiawak

comment created time in a month

issue commentZmnSCPxj/clboss

ChannelCandidateInvestigator - how does it work ?

@ZmnSCPxj - are you available on IRC or something like that? I have some questions wrt fees and don't want to spam you with issues on GH.

hosiawak

comment created time in a month

push eventZmnSCPxj/clboss

ZmnSCPxj jxPCSnmZ

commit sha e7c388abee8a21d0bc9e3d89c057e413c6a24b55

configure.ac: post-release.

view details

push time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

Looks like the first 3 or 4 bytes for IPv6 (/24 or /32 prefix length) would be a good bin, roughly comparable to /16 on IPv4. Could not grok the bitcoind code enough to figure out what it uses.

Looks to me we can use typedef std::uint64_t IPBin; rather than invent a 128-bit number. ASNs are 32-bit anyway, and if 32 bits is enough to naively bin IPv6, that may be good enough for now.

ZmnSCPxj

comment created time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

For now, I plan to make an abstract interface to an IPBinner object:

class IPBinner {
public:
    virtual ~IPBinner() { }
    virtual
    IPBin get_bin_of(IPAddr const&) =0;
};

IPBin would be a 128-bitvector that is LessThanComparable and Hashable (so it can be used with std::map/std::set/std::unordered_map/std::unordered_set), and IPAddr would have variant types for IPv4, IPv6, and Onion. A "true" ASMAP would use the ASN for the IPBin, filling upper bits with 0s.

Until then, we can make do with a submask /16 for IPv4, some kind of submask for IPv6 (dunno, /48? /64? go dig the bitcoind code?) and maybe set a high bit somewhere in the IPBin to separate IPv4 from IPv6.

For Tor, we could do hashing of .onion addresses and extracting 1 or 2 bits so that it maps to an IPBin of 0xFFFFFFFFFFFFFFFC to 0xFFFFFFFFFFFFFFFF, so we allow up to 4 onions. The hashing would be a keyed hash to reduce the ability of targeted attacks by onion-users; we already have a keys.clboss file that we use for interacting with Boltz, we can reuse that as the key in the hash, and we even have Secp256k1::SignerIF::get_privkey_salted_hash to allow a signer holding keys.clboss to provide a keyed hash --- we hash the .onion, then hash the hash with get_privkey_salted_hash then get 2 bits from the first byte of the result. Thus as long as our keys.clboss file is private to us (it is stored right next to the hsm_secret, which has to be even more private anyway), targeted attacks would not be possible, onion-users would have to spam the .onion space, which would not be cheap on LN since LN public nodes have to commit some amount of channel space. CLBOSS also does some filtering based on how much a node has locked in channels, so an onion-using attacker would need to commit something like 50 mBTC (LOL hahahaha) in various channels to have multiple nodes it controls pass that test, so I guess that helps somewhat against the ".onions are free!" problem.

Then at some point while constructing objects we just bind a concrete IPBinner that uses submasks as desribed above for now, and we can update it later to replace the IPBinner with a true ASMAP once bitcoind has settled on how to distribute the map files and we can steal their work easily. The ASMAP concrete IPBinner would have to use the same treatment for Tor, though.

When checking a node, we would need to do a listnodes query, which returns a set of "addresses". We prefer IPv4, then IPv6, then finally Torv3 or Torv2. Then we call into the IPBinner interface we got.

ZmnSCPxj

comment created time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

https://github.com/ZmnSCPxj/clboss/issues/18#issuecomment-745229067

To me, a solution of this sort seems to make the most sense for CLBOSS ^

ZmnSCPxj

comment created time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

My understanding is that by BlueMatt it is better. From what little I understand it seems to be feasible for somebody to generate an ASMAP that is then distributed to multiple users, much like how we have a set of hardcoded nodes in ConnectFinderByHardcode.

ZmnSCPxj

comment created time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

https://bitcoincore.reviews/16702.html for reference.

Important points:

  • Bitcoin core supports an ASMAP, but does not come bundled with one yet. Users are supposed to either create an ASMAP of their own somehow (instructions are unclear even to the reviewers) or just download from sipa, who is always 100% trustable and has never made a mistake, not even in bech32: https://github.com/sipa/asmap/demo.map
  • Bitcoin ASMAP format is based on a video codec. This means we have to reimplement or copy the Bitcoin ASMAP loading code. Copying it is somewhat difficult as it might be dependent on other Bitcoin code.
  • Tor .onions are hard to unsybil, as .onions are "free". Suggestion is to reduce the number of buckets that .onions use, which makes them very unlikely to be channeled with.

I think the raw ASMAP file requires asking your ISP for a BGP dump which, as you allude to, is possible but certainly pretty unlikely for people to do...

As #bitcoin-core-dev is logged, I presume posting logs as a snippet here is also OK (query simply asmap w/ 5 lines of context): asmap.txt. I might suggest parsing from the bottom upwards...

Perhaps asmap is overkill for this situation -- as you say, even asmap can be trivially overcome by using tor, so perhaps some simpler bucketing by IP address CIDR range might be preferable?

It would certainly help with LNBIG as they operate today; they have been kind enough to host all nodes on 46.229.xxx.xxx and 213.174.xxx.xxx from what I can roughly see. Having two connections to them would not be of great concern.

I do think asmap buckets are the most technically-correct solution that exists today, but I can't tell if the work required by the developer (and users?) of an asmap filter would be worth it if an adversary could trivially defeat it...

ZmnSCPxj

comment created time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

Here is the correct link to demo.map: https://github.com/sipa/asmap/raw/master/demo.map

I am uncertain as to what is the ultimate source of demo.map. Geolite2 database has a CC-BY-SA license, the /sipa/asmap repo has no license information, not sure whether the demo.map comes from the Geolite2 database.

Given an ASMap object that maps IP addresses to ASNs, what do we do?

So let us describe how CLBOSS decides channel creation. First, a bunch of heuristics select candidate nodes for channeling. Then the nodes go through ChannelCandidateInvestigator, which over time checks for uptime of the candidate nodes.

When we notice we have onchain funds that need to go into channels, we get the list of "good" nodes from ChannelCandidateInvestigator, which puts high-uptime, earlier-found nodes first in the list.

Currently, we prioritize assigning channels according to the order of this list. The ChannelCreator::Planner module takes this list of nodes.

What we could do instead:

  • Get ASNs of our current peers and put into a mapping from ASN to number-of-nodes-with-that-ASN.
  • Initialize an empty mapping from number-of-nodes-in-ASN to an ordered list-of-nodes.
  • For each node in the ChannelCandidateInvestigator list:
    • Get its ASN.
    • Look up the number-of-nodes-with-this-ASN (0 if not found).
    • Look up the appropriate list-of-nodes from the number-of-nodes-in-ASN.
    • Append the node to the found list-of-nodes.
    • Increment the number-of-nodes-with-this-ASN.
  • Initialize an empty ordered list-of-nodes
  • For each list-of-nodes in the number-of-nodes-in-ASN to list-of-nodes mapping:
    • Append the list-of-nodes to the current list-of-nodes.
  • Return the list-of-nodes.

The returned list-of-nodes will then prioritize nodes that do not have the same ASN as current peers or higher-ranked candidates, and de-prioritzes nodes that have the same ASN as current peers or higher-ranked candidates. This list of nodes is then what we pass to ChannelCreator::Planner.

ZmnSCPxj

comment created time in a month

created tagZmnSCPxj/clboss

tagv0.10

Automated C-Lightning Node Manager

created time in a month

release ZmnSCPxj/clboss

v0.10

released time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

https://bitcoincore.reviews/16702.html#erebus-attack for reference.

Important points:

  • Bitcoin core supports an ASMAP, but does not come bundled with one yet. Users are supposed to either create an ASMAP of their own somehow (instructions are unclear even to the reviewers) or just download from sipa, who is always 100% trustable and has never made a mistake, not even in bech32: https://github.com/sipa/asmap/demo.map
  • Bitcoin ASMAP format is based on a video codec. This means we have to reimplement or copy the Bitcoin ASMAP loading code. Copying it is somewhat difficult as it might be dependent on other Bitcoin code.
  • Tor .onions are hard to unsybil, as .onions are "free". Suggestion is to reduce the number of buckets that .onions use, which makes them very unlikely to be channeled with.
ZmnSCPxj

comment created time in a month

push eventZmnSCPxj/clboss

ZmnSCPxj jxPCSnmZ

commit sha 2fa31ece7c955a5e28f78377a09a12c81c02bb97

configure.ac: 0.10

view details

push time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

Certainly, though not quite sure how to go about it yet. Sorry for the delay in reply, things have been hectic in my non-Bitcoin activities, including a broken server whose parts I am finding difficult to find, bleah.

ZmnSCPxj

comment created time in a month

created tagZmnSCPxj/clboss

tagv0.9A

Automated C-Lightning Node Manager

created time in a month

release ZmnSCPxj/clboss

v0.9A

released time in a month

issue commentZmnSCPxj/clboss

Avoid planning channels to nodes with similar IP addresses

Hey @ZmnSCPxj do you have plans to try and implement some IP (or similar) bucketing?

I closed all my channels during low on-chain fee market just to take advantage of it, but have to say that even with an "uneven" channel distribution CLBOSS just worked™ very well without any management. I didn't have that many forwards, but to be fair it was more than I had when I manually opened channels previously and I was well setup for general personal usage.

If you're not planning to implement this feature in the near future, I'll be happy to re-run latest master without bucketing and with a bit more balance and see how it gets on again...

ZmnSCPxj

comment created time in a month

push eventZmnSCPxj/clboss

ZmnSCPxj jxPCSnmZ

commit sha 46531fc8efdb5d08f60ef58e95f88f196b5c1849

Boss/Mod/FundsMover/Runner.cpp: Always finish.

view details

push time in 2 months

issue closedZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

My clboss got killed after running for a few days. The message in the log was:

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

Unfortunately I didn't have DEBUG logs enabled for clboss.

The log message prior to the error was:

lightningd: Sending 279628174msat over 7 hops to deliver 278212722msat

closed time in 2 months

hosiawak

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

Okay, let us close?

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

2 days later clboss is still running so I guess this issue is now fixed :)

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

I left it running (without using your modified version) and it got killed 2 days ago for the same reason:

2020-11-30T18:32:41.193Z INFO    plugin-clboss: FundsMover: Failed at source, cannot advance further.
2020-11-30T18:32:42.302Z INFO    plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

I'm going to compile the version you posted above and let that run for a while. Thanks.

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

I left my C-Lightning node running, but it got hit by https://github.com/ElementsProject/lightning/issues/4240 since I was using logrotate. Hmmm. Lemme run a stress-test.

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

Possible to run on testnet?

In theory it "can" run on testnet, but at much reduced functionality:

  • Normally CLBOSS will connect to nodes on the existing network. I have ways to do that for mainnet but not for testnet.
    • ConnectFinderByHardcode needs some reliably high-uptime nodes for mainnet, but not for testnet. I need to locate some high-uptime nodes for testnet (if you have a good curated list, that would be appreciated). The issue here is that since testnet coins are valueless, people are not really incentivized to keep their nodes high uptime --- they may run their nodes at high uptime for a few weeks, then shut them down completely, so the list needs to be continuously maintained and filtered by somebody to ensure it does not rot. The hardcoded list for mainnet is a lot less maintenance-heavy since people who have high-uptime mainnet nodes now have an incentive to keep them high-uptime in the future.
    • ConnectFinderByDns has DNS servers for mainnet but not for testnet. I do not know if anyone runs a DNS server for testnet nodes. In any case, it also runs into the same issue as above --- people tend to not keep their testnet nodes up, so a testnet DNS server might give long-dead testnet nodes when you query it for a list.

Other than the above, I think CLBOSS "should" work on Bitcoin Testnet. So for now, you have to manually maintain connections to the testnet network to download the gossip map.

grmkris

comment created time in 2 months

issue openedZmnSCPxj/clboss

Possible to run on testnet?

Locking 0.01 bitcoin to properly test this software is quite a lot for me and I am debating whether to use this software or not. Whoever if it would be possible to deploy this on testnet first I'd be much more comfortable deploying it on mainnet after some time...

I think the idea for this project is great and I am prepared to do the necessary changes to use this on testnet. I'd just need some pointers / instructions.

Thanks

created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

Going offline. Bye!

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

Still up, so at least the bugfix did not introduce yet another bug.... probably only question is if it actually fixes the bug.

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

Running for an hour now, seems okay.

hosiawak

comment created time in 2 months

issue commentZmnSCPxj/clboss

plugin-clboss: Killing plugin: JSON-RPC response "id"-field is not a u64

Hi @hosiawak , pushed a quick fix, hope it works. Try this package, ignore the version number for now: clboss-0.9A.tar.gz It includes fixes for both the id and the DELETE..ORDER BY issues. I have it running for like 5 minutes now (LOL).

hosiawak

comment created time in 2 months

push eventZmnSCPxj/clboss

ZmnSCPxj jxPCSnmZ

commit sha c4e737811d234f7737bc2ff4a6e7a6fbfbf6fc3c

Boss/Mod/Rpc.cpp, Boss/Mod/CommandReceiver.cpp: Do not pass JSON-RPC `id` through `double`.

view details

ZmnSCPxj jxPCSnmZ

commit sha 91f8f0b63a1ea04ef576db04fef9f57ef8ce3eeb

Boss/Mod/OnchainFeeMonitor.cpp: Avoid DELETE...ORDER BY, which might not be enabled on some SQLITE3 installs.

view details

push time in 2 months

more