I think a few of us already have one that we use, but it would be nice to have an "official" one for our use, but also for our users.

Simple request. Can we get a llm stop command to shutdown llmd?

We should show the max batch chain fee a trader can end up paying when submitting an order on the CLI.

In the past for lnd we had an issue where a user would try to send coins, but then needed to pay for fees, so they'd have to subtract an amount then try again, over and over again. We eventually add the --sweepall option in SendCoins to address this. We should add a similar flag for pool accounts deposit that lets the user deposit all their coins (from the lnd wallet) into poold.

We should give users an option to renew an account that's about to expire, or has already expired.

We should do real fee estimation client side.

• deposits
• withdrawal
• real fee estimation
• bumping

Would be good to show only active orders in pool o l and only active accounts in pool a l I think 😉

The Install section should note what lnd version is required, how to connect to a remote lnd node (if supported), etc. Currently, Go is the only prerequisite listed.

Similar to lightninglabs/loop#181.

Currently, the llm auction snapshot RPC returns only the latest batch. In order to get a list of past batches for the last 24 hours, my app would need to make 144 RPC requests.

I'd like to be able to make one RPC request to return a list of batches over a specific time period or number of blocks. It would also be nice to be able to do some sort of paging, so that my app can continue making additional requests to go further back in time. I do not have any strong opinions on how this is implemented (blocks vs timestamps vs start_index/limit). Whatever is easiest to implement is cool with me.

I have logs for a failed channel creation (I can send full logs in a private message).

PEER= private key of peer (always the same peer)

in chronological order

poold: [INF] FNDG: Batch(xxx): opening channels for 1 matched orders
poold: [INF] FNDG: Registering funding shim for Order(type=Ask, amt=x BTC, nonce=xx
lnd: [ERR] RPCS: unable to open channel to NodeKey(PEER): peer PEER is not inline
lnd: [ERR] RPCS: [/lnrpc.Lightning/OpenChannel]: peer PEER is not online
poold: [ERR] FNDG: unable to read chan open update event from node PEER, going to reject channel: rpc error: code = Unknown desc = peer PEER is not online
lnd: [INF] SRVR: New inbound connection from IP_OF_PEER
lnd: [INF] SRVR: Finalizing connection to PEER@IP_OF_PEER
lnd: [ERR] RPCS: [/lnrpc.Lightning/SubscribePeerEvents]: rpc error: code = Internal desc = transport: transport: the stream is done or WriteHeader was already called

It looks like channel creation would have succeeded if the connection from PEER would have come earlier.

When receiving a pending batch from the aucioneer, the batch transaction is missing witness data, since it is not yet signed.
Regardless, we store it as the account's LatestTx:

Since this transaction is not signed, it can lead to issues when the trader tries to republish if during its operation. This is done in several places throughout the state machine.

In particular I noticed this leading to flakes during integration tests, that could easily be triggered by making the auctioneer delay publication of the (signed) batch transaction by a second. In that case an account that was closed by the batch transaction would end up in StatePendingClosed, would republish the unsigned transaction, and error out.

Potential fixes:

• Don't store unsigned transactions (this would mean all batch transactions)
• Ignore the error on publication
• Store metadata about the transaction to know whether it is valid or not (or just inspect it before publishing)

I'm running LLM via LiT on regtest. I can reproducibly cause llmd to crash by calling the CloseAccount GRPC method with an invalid CloseAccountRequest. If I make the request with only the trader_key field set, and do not set output_with_fee or outputs, then llmd will crash with the error below. We should probably handle this with a validation error instead.

2020-08-27 05:31:52.919 [INF] LITD: Handling gRPC request: /clmrpc.Trader/CloseAccount
2020-08-27 05:31:52.920 [INF] RPCS: Closing acct=03754f9fb412ceb7ae224f3ebff082138f4b5704b430690534f285996403f12b6b
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xf27e2c]

goroutine 10166 [running]:
github.com/lightninglabs/llm/account.(*Manager).CloseAccount(0xc00122e180, 0x1cf8180, 0xc00406a870, 0xc003ec5f20, 0x0, 0x0, 0x131, 0x20, 0x8, 0xd1127b7a674505da)
      /go/pkg/mod/github.com/lightninglabs/[email protected]/account/manager.go:1048 +0x11c
github.com/lightninglabs/llm.(*rpcServer).CloseAccount(0xc001588b40, 0x1cf8180, 0xc00406a870, 0xc003c97950, 0x0, 0x0, 0x0)
      /go/pkg/mod/github.com/lightninglabs/[email protected]/rpcserver.go:872 +0x4a0
github.com/lightninglabs/llm/clmrpc._Trader_CloseAccount_Handler.func1(0x1cf8180, 0xc00406a870, 0x15071e0, 0xc003c97950, 0x0, 0x0, 0x10, 0xc00006b180)
      /go/pkg/mod/github.com/lightninglabs/[email protected]/clmrpc/trader.pb.go:2422 +0x86
github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1(0x1cf8180, 0xc00406a870, 0x15071e0, 0xc003c97950, 0x153d920, 0xc0045b2301, 0xc003660a80, 0xc0018039f8)
      /go/pkg/mod/github.com/grpc-ecosystem/[email protected]/chain.go:31 +0x114
github.com/lightningnetwork/lnd.errorLogUnaryServerInterceptor.func1(0x1cf8180, 0xc00406a870, 0x15071e0, 0xc003c97950, 0xc003ec5b20, 0xc003c97a40, 0xc003ec5c20, 0xc000010590, 0xc0045b2360, 0xc003c97a40)
      /go/pkg/mod/github.com/lightningnetwork/[email protected]/log.go:179 +0x81
github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1(0x1cf8180, 0xc00406a870, 0x15071e0, 0xc003c97950, 0x1, 0x1, 0x0, 0x0)
      /go/pkg/mod/github.com/grpc-ecosystem/[email protected]/chain.go:34 +0x9c
github.com/lightningnetwork/lnd/macaroons.(*Service).UnaryServerInterceptor.func1(0x1cf8180, 0xc00406a870, 0x15071e0, 0xc003c97950, 0xc003ec5b20, 0xc003c97a40, 0xc00110d100, 0x0, 0xc001803ae8, 0x40e808)
      /go/pkg/mod/github.com/lightningnetwork/[email protected]/macaroons/service.go:124 +0x150
github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1(0x1cf8180, 0xc00406a870, 0x15071e0, 0xc003c97950, 0xc003ec5b20, 0xc003ec5b40, 0xc003796b58, 0x5a6198, 0x14ad680, 0xc00406a870)
      /go/pkg/mod/github.com/grpc-ecosystem/[email protected]/chain.go:39 +0x155
github.com/lightninglabs/llm/clmrpc._Trader_CloseAccount_Handler(0x1581d20, 0xc0002f0120, 0x1cf8180, 0xc00406a870, 0xc00452a4e0, 0xc00038d050, 0x1cf8180, 0xc00406a870, 0xc00440f5f0, 0x23)
      /go/pkg/mod/github.com/lightninglabs/[email protected]/clmrpc/trader.pb.go:2424 +0x14b
google.golang.org/grpc.(*Server).processUnaryRPC(0xc00106c000, 0x1d0a860, 0xc000321200, 0xc00110d100, 0xc000505560, 0x2799648, 0xc0042f3f80, 0x0, 0x0)
      /go/pkg/mod/google.golang.org/[email protected]/server.go:1082 +0x4fd
google.golang.org/grpc.(*Server).handleStream(0xc00106c000, 0x1d0a860, 0xc000321200, 0xc00110d100, 0xc0042f3f80)
      /go/pkg/mod/google.golang.org/[email protected]/server.go:1405 +0xd25
google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc0000c92d0, 0xc00106c000, 0x1d0a860, 0xc000321200, 0xc00110d100)
      /go/pkg/mod/google.golang.org/[email protected]/server.go:746 +0xbb
created by google.golang.org/grpc.(*Server).serveStreams.func1
      /go/pkg/mod/google.golang.org/[email protected]/server.go:744 +0xa1

I'm running litd version 0.3, when I try to create an account I get this error

$ pool --rpcserver localhost:3004 accounts new --amt 1200000 --expiry_blocks 8064 --conf_target 144
[pool] unable to estimate on-chain fees: rpc error: code = Unknown desc = error estimating total on-chain fee: rpc error: code = Unknown desc = insufficient funds available to construct transaction

I've noticed that my on-chain balance is actualy unconfirmed, maybe is related to the issue? I can't see an option to spend unconfirmed output.

I'm not able to start pool server with the following command

./poold --debuglevel=debug

2020-11-03 17:30:45.136 [INF] LLMD: Version: 0.3.2-alpha commit=
2020-11-03 17:30:45.136 [INF] LNDC: Creating lnd connection to localhost:10009
2020-11-03 17:30:45.147 [INF] LNDC: Connected to lnd
2020-11-03 17:30:45.453 [INF] LNDC: lnd version: v0.11.1-beta, build tags 'autopilotrpc,signrpc,walletrpc,chainrpc,invoicesrpc,watchtowerrpc'
2020-11-03 17:30:45.455 [INF] LNDC: Using network mainnet
2020-11-03 17:30:45.455 [INF] LNDC: Waiting for lnd to be fully synced to its chain backend, this might take a while
2020-11-03 17:30:45.591 [INF] LNDC: lnd is now fully synced to its chain backend
2020-11-03 17:30:46.082 [INF] LLMD: Auction server address: pool.lightning.finance:12010
2020-11-03 17:30:46.091 [INF] CLDB: Checking for schema update: latest_version=1, db_version=1
2020-11-03 17:30:46.092 [INF] RPCS: Starting trader server
2020-11-03 17:30:46.242 [INF] RPCS: Connected to lnd XXX with pubkey XXXXXXXXXXXXXXXXXXXXXXXX
2020-11-03 17:30:46.250 [INF] AUCT: Shutting down auctioneer client
2020-11-03 17:30:46.250 [DBG] LNDC: Closing lnd connection
2020-11-03 17:30:46.250 [DBG] LNDC: Wait for client to finish
2020-11-03 17:30:46.250 [DBG] LNDC: Wait for chain notifier to finish
2020-11-03 17:30:46.251 [DBG] LNDC: Wait for invoices to finish
2020-11-03 17:30:46.251 [DBG] LNDC: Lnd services finished
2020-11-03 17:30:46.251 [DBG] LNDC: Lnd services finished
unable to start server: unable to receive first block notification: rpc error: code = Unknown desc = verification failed: signature mismatch after caveat verification

When creating an account using ordered flags (llm accounts new [command options] amt expiry), it's not clear if expiry is expiry_height or expiry_blocks. After testing, I see that it is expiry_height, but that's not immediately obvious from the help displayed.

Minor nit, I think it would be better to have expiry_blocks as the ordered flag. I'm more likely to remember that 1008 blocks is around one week and multiply from there pretty easily in my head. With expiry_height, I have to first go find the current block height, then do that same math to add onto it. I'm lazy, so help me save a few seconds.

Over time, we have plans to being to decouple the roles of the capital provider from the routing node that actually allocates the capital on the network. In addition to this, a use case we want to support is a wallet author remotely purchasing channels for their user base. We can enable both of these features by extending the configuration of poold to allow it to connect to a set of lnd nodes.

These nodes would only be used to open channels, with lmd getting its funds from a single backing lnd node. In order to implement this feature, we'll need to further abstract channel funding and channel shim creation, and also come up with a sane configuration format to specify the set of lnd nodes. The upcoming lnd feature to allow custom macarons based on URIs can be used to make this feature safer, by ensuring the capital provider only has the ability to open channels and register funding shims.

Copied over from a tester on the other repo:

If I

Enter an order for a non-144-multiple min_duration
Enter an order below 1 unit

I only get the error AFTER I confirm. I expect the order-submit command to reject my invalid order before asking me to confirm. Now it gives me the error after I type "yes"

I believe that my non-Tor poold instance is crashing when attempting to match with a Tor node. Here are the logs:

2020-09-25 16:36:22.613 [TRC] AUCT: Received msg=&poolrpc.ServerAuctionMessage{Msg:(*poolrpc.ServerAuctionMessage_Prepare)(0xc000010048), XXX_NoUnkeyedLiteral:struct {}{}, XXX_unrecognized:[]uint8(nil), XXX_sizecache:0}, err=<nil> from server
2020-09-25 16:36:22.613 [DBG] RPCS: Received message from the server: prepare:<matched_orders:<key:"517fb7836fdf273627b08432e6dfe3e31b40eb8eec357c7b898b4956a94bbeaf" value:<matched_asks:<ask:<details:<trader_key:"\003\000\325\337 \177N\305K\242\n\037\017\325\347]\020\321g{\260\226\232}\246sl\370gMb\263R" rate_fixed:1157 amt:100000 order_nonce:"Ki\034\020wa\302\333_\252\324\243VW&h/\027\374\316\330Mm\024\323\276\237G\317\266\3055" order_sig:"0D\002 v\376T\017]\000\364(f\223z\375\"K*\321^\247\216\222\377\323\257\254\315\014\321}<\302\203\317\002 x\333\034\025\311x\037\024x/>}\2052\360\264\375\302\261\313#\356\333>\026If\006\3634\300N" multi_sig_key:"\002\302\336aa6s\204Z\334\032\264\226R\370\020r?o\001Wx\351d\367\022\321\305\242\234l\215\004" node_pub:"\003\346\221\370\037\010\305o\250v\314N\365\311\350\267'\275h,\363V\005\276%\324\206\007\250\002R`S" node_addr:<network:"tcp" addr:"ug6wkjdnp5fq2iiyakjn7uewn2eyghpqyapzkgvh7hbsq6acmxtt6lqd.onion:9735" > max_batch_fee_rate_sat_per_kw:22500 > max_duration_blocks:4320 > units_filled:1 > > > clearing_price_rate:2976 charged_accounts:<ending_balance:17832660 outpoint_index:2 trader_key:"\002\235\360ik^\010\262\245\2656\200+\361\346\276\375e\327\277i\223\332\007\223\353\"\003/\261_\325:" > execution_fee:<base_fee:1 fee_rate:1000 > batch_transaction:"\002\000\000\000\003\367\205\np\352Q\267H\253E_\264IQ\256HJ\334k\313\006\261\336\231T\367\260\3070?\351*\002\000\000\000\000\000\000\000\000:tt\305\034\361\374\362V\347'\306\274\315FMU\317\375\340\343{\263\033&\367\227\253\351P\3473\001\000\000\000\000\000\000\000\000r\300S\372\"\027u\004\340\023i\207\277\327\214\306p\214\3045\337\022^!\005\214\306\337!\220\362\207\006\000\000\000\000\000\000\000\000\004\240\206\001\000\000\000\000\000\"\000 \331\225\246#\211\243\371y\370[ \003\354\212\357\255j/P\035(\217\014,\330\356\337M\267\323cx\350\346\016\000\000\000\000\000\"\000 X3\370\236\361=9\210\344@[\231\351d\014\351\320\312\274R\226kw\271/\255\021n\302@n\376\324\032\020\001\000\000\000\000\"\000 \024q\177\315\216\030hJ\016\361\343\224:-A\000\342~\207\203\300\302\305\362fR\201\302\364R}\240t\036\310\001\000\000\000\000\"\000 \265d\262\302\222\265\0231\214\316\354\272\024/\2232\236\010S\350\246\276\321\225\211`\3618O\244v\203\000\000\000\000" fee_rate_sat_per_kw:12690 batch_id:"\003\312\274\204\271P\233\002`\224\337\311\307O\226&\226\276\246\271'\014Zu\017\326\303\237\250@\353\316\211" > 
2020-09-25 16:36:22.614 [TRC] RPCS: Received prepare msg from server, batch_id=03cabc84b9509b026094dfc9c74f962696bea6b9270c5a750fd6c39fa840ebce89: (*poolrpc.ServerAuctionMessage_Prepare)(0xc000010048)({
 Prepare: (*poolrpc.OrderMatchPrepare)(0xc00001d720)(matched_orders:<key:"517fb7836fdf273627b08432e6dfe3e31b40eb8eec357c7b898b4956a94bbeaf" value:<matched_asks:<ask:<details:<trader_key:"\003\000\325\337 \177N\305K\242\n\037\017\325\347]\020\321g{\260\226\232}\246sl\370gMb\263R" rate_fixed:1157 amt:100000 order_nonce:"Ki\034\020wa\302\333_\252\324\243VW&h/\027\374\316\330Mm\024\323\276\237G\317\266\3055" order_sig:"0D\002 v\376T\017]\000\364(f\223z\375\"K*\321^\247\216\222\377\323\257\254\315\014\321}<\302\203\317\002 x\333\034\025\311x\037\024x/>}\2052\360\264\375\302\261\313#\356\333>\026If\006\3634\300N" multi_sig_key:"\002\302\336aa6s\204Z\334\032\264\226R\370\020r?o\001Wx\351d\367\022\321\305\242\234l\215\004" node_pub:"\003\346\221\370\037\010\305o\250v\314N\365\311\350\267'\275h,\363V\005\276%\324\206\007\250\002R`S" node_addr:<network:"tcp" addr:"ug6wkjdnp5fq2iiyakjn7uewn2eyghpqyapzkgvh7hbsq6acmxtt6lqd.onion:9735" > max_batch_fee_rate_sat_per_kw:22500 > max_duration_blocks:4320 > units_filled:1 > > > clearing_price_rate:2976 charged_accounts:<ending_balance:17832660 outpoint_index:2 trader_key:"\002\235\360ik^\010\262\245\2656\200+\361\346\276\375e\327\277i\223\332\007\223\353\"\003/\261_\325:" > execution_fee:<base_fee:1 fee_rate:1000 > batch_transaction:"\002\000\000\000\003\367\205\np\352Q\267H\253E_\264IQ\256HJ\334k\313\006\261\336\231T\367\260\3070?\351*\002\000\000\000\000\000\000\000\000:tt\305\034\361\374\362V\347'\306\274\315FMU\317\375\340\343{\263\033&\367\227\253\351P\3473\001\000\000\000\000\000\000\000\000r\300S\372\"\027u\004\340\023i\207\277\327\214\306p\214\3045\337\022^!\005\214\306\337!\220\362\207\006\000\000\000\000\000\000\000\000\004\240\206\001\000\000\000\000\000\"\000 \331\225\246#\211\243\371y\370[ \003\354\212\357\255j/P\035(\217\014,\330\356\337M\267\323cx\350\346\016\000\000\000\000\000\"\000 X3\370\236\361=9\210\344@[\231\351d\014\351\320\312\274R\226kw\271/\255\021n\302@n\376\324\032\020\001\000\000\000\000\"\000 \024q\177\315\216\030hJ\016\361\343\224:-A\000\342~\207\203\300\302\305\362fR\201\302\364R}\240t\036\310\001\000\000\000\000\"\000 \265d\262\302\222\265\0231\214\316\354\272\024/\2232\236\010S\350\246\276\321\225\211`\3618O\244v\203\000\000\000\000" fee_rate_sat_per_kw:12690 batch_id:"\003\312\274\204\271P\233\002`\224\337\311\307O\226&\226\276\246\271'\014Zu\017\326\303\237\250@\353\316\211" )
})

2020-09-25 16:36:22.619 [ERR] LLMD: unable to parse batch: %v error parsing matched order: error parsing server ask: unable to parse node addr: lookup ug6wkjdnp5fq2iiyakjn7uewn2eyghpqyapzkgvh7hbsq6acmxtt6lqd.onion: no such host
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xd4b8ca]

goroutine 57 [running]:
github.com/lightninglabs/pool/order.(*Batch).CancelPendingFundingShims(0x0, 0x13cd160, 0xc000010208, 0xc0007f3c60, 0x0, 0x0)
	/home/ubuntu/go/src/github.com/lightninglabs/pool/order/batch.go:195 +0x3a
github.com/lightninglabs/pool.(*rpcServer).sendRejectBatch(0xc00014e3f0, 0x0, 0x13943a0, 0xc000042970, 0x2, 0x2)
	/home/ubuntu/go/src/github.com/lightninglabs/pool/rpcserver.go:1305 +0x8c
github.com/lightninglabs/pool.(*rpcServer).handleServerMessage(0xc00014e3f0, 0xc0006b66c0, 0x24, 0xc00064e070)
	/home/ubuntu/go/src/github.com/lightninglabs/pool/rpcserver.go:371 +0x8f5
github.com/lightninglabs/pool.(*rpcServer).serverHandler(0xc00014e3f0, 0xc0002ba4e0, 0xc00007a4e0)
	/home/ubuntu/go/src/github.com/lightninglabs/pool/rpcserver.go:300 +0x261
created by github.com/lightninglabs/pool.(*rpcServer).Start
	/home/ubuntu/go/src/github.com/lightninglabs/pool/rpcserver.go:207 +0x9ab

and my lnd.conf

[Application Options]
# Allow push payments
accept-keysend=1

# Public network name
alias=tehGentry

# Allow gift routes
allow-circular-route=1

# Public hex color
color=#00c300

# Log levels
debuglevel=CNCT=debug,HSWC=debug

# Public P2P IP
externalip=52.15.160.165

# Set the maximum amount of commit fees in a channel
max-channel-fee-allocation=1.0

# Set the max timeout blocks of a payment
max-cltv-expiry=5000

# Pending channel limit
maxpendingchannels=10

# Min inbound channel limit
minchansize=100000

# gRPC socket binding
rpclisten=0.0.0.0:10009

# REST socket binding
restlisten=0.0.0.0:8080

# Avoid slow startup time
sync-freelist=1

# Avoid high startup overhead
stagger-initial-reconnect=1

# TLS certificate IP
tlsextraip=52.15.160.165

[Bitcoin]
# Turn on Bitcoin mode
bitcoin.active=1

# Set the channel confs to wait for channels
bitcoin.defaultchanconfs=2

# Forward fee rate in parts per million
bitcoin.feerate=1000

# Set bitcoin.testnet=1 or bitcoin.mainnet=1 as appropriate
bitcoin.mainnet=1

# Set the lower bound for HTLCs
bitcoin.minhtlc=1

# Set backing node, bitcoin.node=neutrino or bitcoin.node=bitcoind
bitcoin.node=bitcoind

[bitcoind]
# Set the password to what the auth script said
bitcoind.rpcpass=bvf0_3yzmdRHzHwtGkOoKeo5CsIBnqjq0GHxeOxe2_Q=

# Set the username
bitcoind.rpcuser=bitcoinrpc

# Set the ZMQ listeners
bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333

[protocol]
# Enable large channels support
protocol.wumbo-channels=1

[routerrpc]
# Make sure that LND is the binary release or built with the routerrpc tag

# Set default chance of a hop success
routerrpc.apriorihopprob=0.5

# Start to ignore nodes if they return many failures (set to 1 to turn off)
routerrpc.aprioriweight=0.75

# Set minimum desired savings of trying a cheaper path
routerrpc.attemptcost=10

# Set the number of historical routing records
routerrpc.maxmchistory=10000

# Set the min confidence in a path worth trying
routerrpc.minrtprob=0.005

# Set the time to forget past routing failures
routerrpc.penaltyhalflife=6h0m0s

[routing]
# Set validation of channels off: only if using Neutrino
#routing.assumechanvalid=1

[tor]
# Enable Tor if using
#tor.active=1
#tor.v3=1

Upon startup, got: "unable to start server: unable to obtain macaroons: open /home//.lnd/data/chain/bitcoin/testnet/invoices.macaroon: no such file or directory"

I believe this may be because llm is looking for invoice.macaroon rather than invoices.macaroon?

I nuked one of our staging servers earlier today, and when I tried to boot up my poold to manual sweep the account after expiry, it just hung as it wasn't able to connect to the server. We should eliminate this assumption, as even if the server isn't reachable for a period of time for w/e reason, users should still be able to interact w/ their local poold daemon.

Hi,

I tried to set up a configuration file for use within a Docker container. However, despite telling poold that it should contact the LND daemon at lnd:10009 it still attempts to connect on localhost:

bash-5.0# mount |grep pool
/dev/sda2 on /root/.pool type ext4 (rw,relatime)
bash-5.0# ls -la /root/.pool/mainnet/
total 12
drwxrwxr-x    2 1000     1000          4096 Nov  7 07:47 .
drwxrwxr-x    5 1000     1000          4096 Nov  7 07:45 ..
-rw-rw-r--    1 1000     1000           210 Nov  7 07:42 pool.conf
bash-5.0# cat /root/.pool/mainnet/pool.conf
# Application Options
network=mainnet
rpclisten=localhost:12010
restlisten=localhost:8281

# LND options
lnd.host=lnd:10009
lnd.macaroondir=/root/.lnd/data/chain/bitcoin/mainnet
lnd.tlspath=/root/.lnd/tls.cert
bash-5.0# poold
2020-11-07 07:50:15.918 [INF] LLMD: Version: 0.3.2-alpha commit=
2020-11-07 07:50:15.918 [INF] LNDC: Creating lnd connection to localhost:10009
2020-11-07 07:50:15.919 [INF] LNDC: Connected to lnd
unable to start server: lnd compatibility check failed: unable to get info for lnd node: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:10009: connect: connection refused"

Passing the configuration options as arguments to the binary does work. Pool is set up to be in a separate container than lnd. They're connected through a Docker network.

As titled, pool seems to use high fee rate during account creation although mempool is not very full.

-- Account Funding Details --
Amount: 0.03 BTC
Confirmation target: 6 blocks
Fee rate (estimated): 122.7 sat/vByte
Total miner fee (estimated): 0.00043913 BTC
Confirm account (yes/no):

However, in this weekend I checked other fee estimation site and it gives me:

Can I set lower sat per byte during pool account creation?

I've observed a few instances of the daemon hanging and refusing to shutdown with a CTRL-C. The way I've mostly reliably reproduced it so far is to sever the connection with the server somehow (either using something like iptables, or restart the server all together). When I looked into this issue last, it seemed to be the case that the handshake logic was stuck, and wouldn't progress, nor shutdown.

i figured it is not realy the right place for that though i wanted to learn if i could partcipate using some bitcoins i already own. But it did not work : /

closing it right away though i d more than happy to learn it somehow was fixed.

From a tester:

Adding an available_units (I think this is just a round down using -6 precision on the available_balance) value in the account list would help "thinking in units"

I'm not sure if this is the right place to ask...

I have a couple of asks in the system. Sometimes poold says: "preparing channel funding for 1 orders" and nothing happens (for >12 hours). All orders stay in state ORDER_SUBMITTED. The warning message I see is: "[WRN] ORDR: Unable to abandon channel (channel_point=blabla) ". Does something prevent my orders getting executed, is pooled talking about someone else's orders?

lncli listchannels | grep -e channel_point does not show anything

Copied over from the early tester repo:

I think adding num_confirmations (for the outpount/tx) might clarify the account state, seeing 0 confirms+pending would help for example.

Reported by a user:

2020-11-10 04:42:24.230 [INF] FNDG: Registering funding shim for Order(type=Bid, amt=N BTC, nonce=X
2020-11-10 04:42:24.237 [WRN] RPCS: Error preparing channel funding: unable to register funding shim: unable to register funding shim: rpc error: code = Unknown desc = pendingChanID(X) already has intent registered
2020-11-10 04:42:24.238 [INF] RPCS: Sending batch rejection message for batch X with code UNKNOWN and message: unable to register funding shim: unable to register funding shim: rpc error: code = Unknown desc = pendingChanID(X) already has intent registered

I'm adding an order form to Terminal and would like to display some of the same information in the UI that is presented when submitting an order from the CLI:

-- Order Details --
Bid Amount: 0.02 BTC
Bid Duration: 2016
Total Premium (paid to maker): 0.00019998 BTC
Rate Fixed: 4960
Rate Per Block: 0.000004960 (0.0004960%)
Execution Fee:  0.00002001 BTC
Max batch fee rate: 300 sat/kw
Max chain fee: 0.000039 BTC
Confirm order (yes/no):

Most of this information, I am able to calculate in the web app with relatively little code. For example, I've already implemented the code to convert from interest rate to the rate per block. The challenge I am currently facing is calculating the "Max chain fee" given the --max_batch_fee_rate. I have traced how this is done in the pool CLI. It calls EstimateTraderFee which uses constants from poolscript, lnd, and btcd to determine the bytes of this order's transaction in the batch.

I started down the path of copying all of these constants into my JS code, then realized how much needed to be duplicated. My concern is not just how much effort this would be for me, but I am also considering the usability of the GRPC API for future devs. I would image that they will also run into this same issue and need to duplicate this code in their apps. This feels a bit wasteful for consumers of the API.

With all of that said, I'd like to request the ability to fetch the same order details above as a quote without actually submitting the order. I'm imagining there would be a QuoteOrder endpoint which takes the exact same args as SubmitOrder, but the response would be something like this:

{
  "premium": "19998",
  "rate_fixed": 4960,
  "rate_per_block_pct": "0.0004960",
  "execution_fee": "2001",
  "max_batch_fee_rate": 300,
  "max_chain_fee": "3900"
}

Hi there!

I was using Lightning Pool with LiT v0.3.0, and I tried to withdraw some funds from my pool account. I got the following error: [pool] rpc error: code = Unknown desc = account must be in StateOpen to bemodified.

Meanwhile, I had some troubles with the connection to my node (I actually proxy my node onion url to localhost:10009 with socat, and make LiT connect to this last), so I restarted my node.

Now Pool seems to have taken in account the withdraw: my account outpoint and latest_txid have been updated, as well as the available_balance and value fields. The thing is that the transaction doesn't appear in any explorers, nor in my own node's, after almost two hours.

What can I do?

Let me know if you need more details.

lnd version: v0.11.1-beta
Lightning Terminal version: v0.3.0

Today pool auction leases lets a use see the set of channel leases they bought or sold. However since we don't yet auto-close leased channels after expiry (if we were the maker) users need to eye ball the expiry height and compared that against their known best height to determine if the lease is expired or not. To make things a bit easier in the CLI days, we should add either an expired field, or a new flag on the CLI that user can use to make it print out only expired leases.

As is, the only way for a user to see which channels the daemon opened is to used lncli pendingchanenls or lncli listchannels. We should add a new call, let's call it possibly: llm account assets, or llm assets, that lets a user browse their past purchased or sold channels. In addition to the channel information, this call can also be used to show a summary of the trader's yield/expenditures to date (growing the scope slightly). Minimally, for each purchased/sold channel we should list:

• the absolute expiry height of the channel (can be relative too if it hasn't confirmed yet)
• the amount paid for the channel (for bids), the amount earned by selling the channel (for asks)
• the channel size, and the channel point
• totals for yield/expenditure in the lifetime of an account

From a tester:

Has something to do with "being subscribed" it seems. Help text says it "recovers after data loss". Data loss on what side (ours?). Some docs would help :).

I think it would be useful to return the datetime of when an order was created in the llm orders list response.

With lnd 0.11, we're now able to properly execute external coin selection to craft and sign custom transactions. With this feature, we gain more control over the transaction that's ultimately broadcast. Amongst many other things, this would let us detect up -front if we don't have enough funds (including fees) to satisfy a user's new account request.

Ported over from the tester repo:

Putting in an order will give:

Max chain fee: 0.000052 BTC

Please change to

Max chain fee: 0.00005200 BTC

Makes it easier to see it's 5200 sat :)

Requested from a user on slack. They want to be able to know what the near misses were when an interval passes without a match. This may help some traders know if they're very far off, or if it's only just them on the book. This is effectively equivalent to us giving a periodic price quote every 10 minutes if no batch happens. Giving this extra information to participants effectively "leaks" the "tip" of the order book, but may end up leading to a thicker market as participants are able to make adjustments more easily.

I believe there were some complications when requesting a withdrawal with the default 0 sats amount.
Not sure about server-side on the pool but I don't see any minimum checks on the client-side.

Right now we'll try to shutdown if we reject a batch. Instead, we should clean up the lingering state so we can attempt to process another batch.

It would be great to have a streaming RPC endpoint to receive new batches when they are published and/or confirmed on the chain. The events can contain the same data as the current llm auction snapshot response.

Thanks for making pool ! I am trying it in LiT now that onchain fees are lower.

I submit an ask order but I found a weird issue with satoshis and units convertion:

$ pool --rpcserver=localhost:10009 orders submit ask 6500000 [trader key] ...
> [pool] unable to parse order params: minimum channel amount 0.0065 BTC must be a multiple of 0.001 BTC

Notice that the amount 6500000 = 6 500 000 satoshis is displayed as 0.0065 BTC, which is a mistake (it must be 0.065 BTC).

However this order is accepted and amount in BTC are correct:

$ pool --rpcserver=localhost:10009 orders submit ask 6000000
> Ask Amount: 0.06 BTC
...

Or we auto cancel the orders then proceed w/ the close.

From the tester repo:
A switch like pool o l --only-active would be very useful. I do not care too much about my cancelled orders ;)

It would be cool to allow traders to check out the current market from afar using something similar to the loop monitor call we have for loopd. This would show stuff like:

• New batches being added
• Activity with their orders
• Changes to the fee schedule

etc

This would mainly hold us over until the UI is finished.

Canceled orders still show up in llm listorders

Similar to what we have for lnd. People want to be able to shutdown poold safely to update.