nullcount / rain Goto Github PK

Add a TG monitor to listener.py
It listens for user chats
First command should be /invoice 2300 memo
And it replies with an invoice code

create a listener for mempool
It watches the MB size of pending blocks
it should notify based on the last notification sent.
"mempool is growing" if 9MB larger than last notice
"mempool is shrinking" if 9MB smaller than last notice
"mempool is empty" if <3MB and last notification was >3MB

In short, we implement the same methods

get_onchain_address
send_onchain
get_lightning_invoice

• for this one, go to invoice settings, and set a custom amount in sats
  pay_invoice

operators should have a way to run some methods from the console with nice ui feedback
The first method should be Accounting.get_history() to monitor initial sync for larger nodes

https://fixedfloat.com/api

makes the most sense for htlcstreamer also useful for .history.pkl

Someone who knows Java and/or android app development can figure it out.
Can we simply send requests to an api to do wallet actions?
https://github.com/muun/apollo

some freaks believe certain sats are more valuable than others
as new UTXOs arrive, scan them for interesting sats and send to a vault

In the MVP, it should generate a new muun wallet in the app:

Send a request for current wallet balance.
If wallet balance == 0.00
goto Settings > Delete Wallet > Yes I'm sure > Continue > Create A New Wallet > Enter PIN 2x > DONE!

the strategy should look at recently failed HTLCs where the reason for failure is "not enough balance".
it should identify sink/source patterns, and average htlc amounts
it should perform liquidity operations to optimize for future htlcs

automate the process of openeing channels to Deezy, requesting close, and getting paid for moving liquidity

All endpoints are appreciated, but start with the EARN endpoints
https://docs.deezy.io/#tag/Earn

create a class Deezy in deezy.py
Create methods for each endpoint
Deezy API follows the OpenAPI standard, not sure if there's any tooling to generate the methods for you or if it's more of a Documentation thing.

This is the first step towards implementing a Deezy Auto Earn strategy see #7

https://docs.boltz.exchange/en/latest/api/

create a method which attempts to classify any node as sink or source
here are some heuristics:

• identify net payment flows by analyzing outputs from channel close transactions
• high outbound / low inbound fees indicates source, high inbound / low outbound indicates sink

The loop node gets a new IP every few hours. Looks like fun.

create a listener for sending notification when any funds arrive/leave the node
both onchain and LN
Notify channels open/close

in lnd.py the get_node_fee_report will return a corrected average in and out fee. Currently, it simply removes fees < 10_000 ppm. But it should remove outliers and/or weight the distribution to arrive at a number close to what https://amboss.space reports as their "corrected average"

if a node attempts to route an htlc for a channel that is already closed it will crash with

inchan.capacity cannot ready capacity of None

If this happens, fail silently

It should return all the pending channel open transactions
https://api.lightning.community/#pendingchannels

Even nodes with a direct channel with Muun node will pay a rooting fee when paying Muun wallet invoices.

Muun invoices have routing hints for possible private channels the node can use and their fees.

Before paying a Muun invoice in an automated way, we should decode the invoice verifying the fee is expected.

See https://lightingdecoder.com

Most strategies involve waiting for blocks. The blocks are the bottleneck. Offer an option to run strategies as a listener type. It should listen for new blocks to execute the strategy.

To use the bitcoind gRPC API in Python, you can use the grpcio and grpcio-tools packages to create a gRPC client that can communicate with the bitcoind server. You can then use the getblockchaininfo method to retrieve information about the current state of the blockchain, including the current block height.

To watch for new blocks, you can use the watchblocks method, which will return a stream of notifications whenever a new block is added to the blockchain. You can then use a Python asyncio event loop to receive these notifications and perform any actions you want, such as sending a notification or updating a database.

Here is an example of how you might use the bitcoind gRPC API in Python to watch for new blocks and receive notifications:

import asyncio
from grpc import Channel
from grpc.experimental import aio

from bitcoin.rpc.bitcoind import BitcoindServiceStub, WatchBlocksRequest
from bitcoin.rpc.bip0044 import Account
from bitcoin.wallet import Wallet

# Create the gRPC channel
channel = aio.insecure_channel('localhost:8332')

# Create the gRPC client
client = BitcoindServiceStub(channel)

# Create the asyncio event loop
loop = asyncio.get_event_loop()

# Get the current block height
response = loop.run_until_complete(client.getblockchaininfo())
current_height = response.blocks

# Set up the request to watch for new blocks
request = WatchBlocksRequest(from_block=current_height+1, to_block=-1, account=Account.EXTERNAL)

# Start watching for new blocks
async for block_notification in client.watchblocks(request):
    # Print the notification when a new block is added
    print(block_notification)

    # Perform any other actions you want here
    # ...

You can then run this script using Python 3.7 or newer, which includes support for the asyncio module.

I hope this helps! Let me know if you have any other questions.

"withdrawal" vs "withdraw", etc. its confusing to know which one to use. Also tricky to spell.

Replace every instance of withdrawal and it's variations with a synonym.

sometimes a source can close on you, set funding config for source channel and reopen if this happens

pending #30

Example of inheritance

class State:
    def transition(self, event):
        raise NotImplementedError
        
class InitialState(State):
    def transition(self, event):
        if event == "start":
            return StartedState()
        return self

local balance calculations don't add up, something is wrong with the calculation

LOOP, Boltz, Deezy and ...
PeerSwap is for direct channel peers only. LAME!
Seems there are no OSS options, yet.

Implement Atomic (reverse) submarine swaps or be a wimp and do something trustful as deezy does

Start by testing strategies.

Our test should create multiple instances of each strategy class and instead of loading data from API's, it should fill all attributes with mock data to test all the different execution flows.

just set up the structure for testing and do a simple test, will add more tests as we go.

1. modify the SinkSource class in strategy.py so that it can optionally instantiate it's attributes with data from a python dict instead of reaching out to APIs.
2. create a tests folder files for testing each strategy.
3. create a test instance of the SinkSource class and instantiate it with mock data
4. call SinkSource.ececute() and assert that the execution path is as expected

Default Playbook Vars:

• min onchain balance
• node = LND

SinkChannels

• node pubkey
• node address
• num channels
• capacity (budget)
• close ratio
• base fee
• fee ppm
• cltv delta
• mempool fee rec.
• mempool fee factor
• max sat per vbyte

SInkChannels play:

• count sink channels
• get empty sinks
• if needs a sink, try open sink channel
• try close empty sinks

SourceChannels

• node pubkey
• node address
• num channels
• capacity (budget)
• base fee
• fee ppm
• cltv delta
• loop-out provider
• loop-out amount
• loop-out backoff
• mempool fee rec.
• mempool fee factor
• max sat per vbyte

SourceChannels play:

• count source channels
• if needs a source, try open source channel
• if any source channel can loop out, try to loop out

when the exchange won't let you do it with API, use a selenium session.
Maybe use https://pypi.org/project/pyotp/ for OTP protected actions.