Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

on-chain balance (linking to deposit page) could be added to home #62

Open
yoss1x opened this issue Feb 20, 2019 · 2 comments
Open

on-chain balance (linking to deposit page) could be added to home #62

yoss1x opened this issue Feb 20, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@yoss1x
Copy link

yoss1x commented Feb 20, 2019

While full on/off chain UX is quite complex, displaying the on-chain balance somewhere (even the footer) is a good idea imo. During a Bitcoin Installfest we did, people where confused about having 0 balance while their deposit to newaddr was confirmed. Another scenario, is when a channel was closed: funds seem to be missing unless you check the on-chain outputs.

@shesek shesek added the enhancement New feature or request label Feb 25, 2019
@shesek
Copy link
Owner

shesek commented Feb 25, 2019

I'm thinking that it might make sense to combine both onchain and offchain funds on the top-right balance, as a "total funds held in this node" metric, then prominently display the onchain and offchain split separately on the homepage (below the buttons?).

The original thought behind the upper-right balance being offchain only is that it should represent the funds the user can actually spend using the send payment functionality, and that it won't make sense to lump onchain funds in until sending/receiving onchain is implemented. However:

  1. The sum of channel balances does not really represent the amount the user can spend either, because it depends on how its split between channels (though AMP will eventually improve that), which channels are currently online, and the routability/connectivity of these channels (i.e. funds on a channel with a mobile non-routing lightning node are actually not offchain-spendable at all, except for direct payments to the mobile node itself).

    And in fact, the sum of onchain utxos does not really represent the amount the user can spend either, because of onchain fees which are effected by how its split between utxos. What the user can actually spend is more around sum_of_utxos - (num_of_utxos * avg_input_size * current_feerate).

    Given the complexities of making an "how much you can spend" metric, going for "how much you have" instead seems like a reasonable choice.

  2. Now that spark has channel management and onchain deposit functionality, the onchain funds are more tightly related to the functionality that spark provides, so it makes more sense to show them, even as part of the main balance.

shesek added a commit that referenced this issue Feb 25, 2019
Instead of attempting to show an "how much you can spend" metric,
we're now showing a simpler "how much you have" metric instead.

- The balance now includes the on-chain balance (sum of utxos).

- It also includes funds held in channels with disconnected peers.

- It uses the total "msatoshi_to_us" instead of "spendable_msatoshi",
  which includes the channel reserve.

For more on the rational behind this changes, see:
#62 (comment)
@yoss1x
Copy link
Author

yoss1x commented Mar 7, 2019

I agree with preferring funds-you-have over funds-you-can-spend. In the on-chain case it's clearly the standard and for off-chain balance, counting disconnected peers and using "msatoshi_to_us" (as done in
9b500c4) seems right.

But I'm not sure that's an argument for a combined on/off-chain balance (also in 9b500c4). If the plan is to also display each balance separately as in #67, the total is maybe redundant. Three (quite long) balances might make the homepage a bit overloaded with digits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants