pull down to refresh
41 sats \ 1 reply \ @aliceandthewonderland 16 Jan \ parent \ on: The Future Of Bitcoin Lending? bitcoin
imo, very negative. extremely negative. It only ends up creating massive attack surfaces, unnecessary complexity, and systemic risks that undermine the core value proposition of sound money. simple, reliable Bitcoin script is all you need for secure value transfer - anything more complex just introduces vulnerabilities.
I view Bitcoin not as a purchase, but as a way to store my energy's value outside of the corrupted fiat currency system.
when sending sats from Phoenix to Zeus with a routing hint included, Zeus is able to receive the sats. I'm not sure why thanks anyway
Have a look in your Phoenix wallet > settings > payment channels. Have a look at the Funding TX and see if it spliced out on that LN payment.
Yep, you were right, I did splice out some funds, and it led to dropping channel size. Thanks it helped me a lot to study.
If Phoenix had less inbound liquidity when LNproxy tried to forward the payment, it could have caused the transaction to get stuck. LNproxy might not have been able to fulfill the payment due to Phoenix’s reduced capacity, causing the HTLC to timeout and triggering the refund.
I exported the Phoenix wallet log from the event on Jan 10, 2025, UTC, to see whether it attempted to process the payments. The log indicates that it indeed tried to execute payments through MPP for amounts of 175,000 sats and 2 of 87,500 sats. But it appears that the LN proxy failed to complete these transactions, resulting in keep Phoenix purging incoming payments multiple times like image below, which ultimately led to the rollback of the transactions and the subsequent release of the HTLC by Strike.
Indeed it seems you are right. Not sure if this is accurate, but this is my reasonable scenario thus far.
So, the sudden drop in your inbound liquidity (from 470k to 250k sats) could have been due to Phoenix closing and reopening channels to manage fees or balance liquidity. This isn’t unusual, but it can catch you off guard if you're not expecting it.
as mentioned by @OT, I found out that I did splice out some funds to on-chain, which explains the sudden drop in inbound liquidity.
I think I wasn’t clear enough in my explanation—my apologies. When I attempted to pay sats to the Hodl invoice generated by LN Proxy through Strike, the payment didn’t go through immediately. Instead, Strike displayed the status as “payment initiated” for about 40 minutes. Concerned about the delay, I checked my Phoenix wallet and noticed that my inbound channel liquidity had suddenly dropped from 470,000 to 250,000 sats. This was why I initially thought that LN Proxy’s inability to pay my Phoenix invoice because of liquidity issue and obtain the preimage led to the Strike payment being stuck in limbo.
I use my Phoenix wallet almost daily, and I had specifically checked my inbound liquidity before generating the invoice to avoid any splice-in fees. This makes me wonder if this issue might have had nothing to do with an on-chain transaction, as there were no on-chain transactions between Strike, LN Proxy, and my Phoenix wallet.
Each side maintains the reserve as a percent of the total capacity.
It seems you’re correct—I tested it myself. With a 500k inbound channel using Voltage, it appears to set a 1% reserve of the total capacity, which amounts to 5,000 sats. I was able to successfully send sats until the outbound liquidity was reduced to 5,001 sats. However, it seems the system doesn’t allow the balance to drop below 5,000 sats, as I kept encountering insufficient balance errors.
Don’t know why Bitcoin Design explained it like reserve value will dynamically changed on local liquidity end.
Is it possible to check the current reserve value for my channels when using ThunderHub? If so, where can I find this information? If you know.
Each side maintains the reserve as a percent of the total capacity.
So it is x% of total capacity for reserve(?)
I was confused because of this Bitcoin Design
As defined in BOLT 2, the channel reserve amount dynamically trends towards 1% of the users local channel capacity.