You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in #888, taproot asset channels will encounter premature exhaustion. While various solutions are available, many require diligence to engineer securely.
Rather the hastily develop the long-term solution, it is proposed to increase the channel funding output size to 100k sats. This will create a Lightning Network channel of sufficient size to reduce the frequency of channel exhaustion while also maintaining a measured, defensive security posture as #888 is addressed.
Improve user experience by minimizing the need for rebalancing
Strike a balance between providing a usable channel size and maintaining a defensive posture with respect to Bitcoin
Implementation TODOs
Update the channel funding logic to create an output size of 100k sats
Add validation and testing which might have changed due to the increased size
Acceptance Criteria:
A user can create/route 300 HTLCs without needing to rebalance the sats in their channel
The text was updated successfully, but these errors were encountered:
Background
As discussed in #888, taproot asset channels will encounter premature exhaustion. While various solutions are available, many require diligence to engineer securely.
Rather the hastily develop the long-term solution, it is proposed to increase the channel funding output size to 100k sats. This will create a Lightning Network channel of sufficient size to reduce the frequency of channel exhaustion while also maintaining a measured, defensive security posture as #888 is addressed.
Implementation TODOs
Acceptance Criteria:
The text was updated successfully, but these errors were encountered: