[QT] Remove SendToSelf, and break down its payouts #10007

1. 
   NicolasDorier commented at 7:28 am on March 16, 2017: contributor

   Alternative to #9985 following @luke-jr suggestion. I think it looks great.

   The rational is that pay to yourself is mostly done by third party tool, like tumbler bit and joinmarket using watch-only addresses to track payments.

   I aggregate all the inputs into one entry with debit. If their is only one input, the description of the line is taken from its address. And one entry per output with credit.

   As you can see in this example, you can follow where the coins flow from the escrow, to the redeem (timeout) or offer.

   Before:

   After:

2. [QT] Remove SendToSelf, and break down its payouts 14d4549856
3. fanquake added the label GUI on Mar 16, 2017
4. 
   jonasschnelli commented at 8:57 am on March 16, 2017: contributor

   Nice. Concept ACK.
5. 
   luke-jr commented at 9:18 am on March 16, 2017: member

   If their is only one input, the description of the line is taken from its address.

   Uh, concept NACK this part. Inputs don’t have addresses… Not sure what to do for a description when we only have some of the inputs, but this isn’t it.

6. 
   NicolasDorier commented at 9:48 am on March 16, 2017: contributor

   @luke-jr maybe you have a better way to reach my objective, which I think is reasonable use case.

   Take a look at this scenario:

   

   If Alice manage to pay 1.0 Tumbler by the Client Fullfill transaction here is what I would like to see in the wallet:

   0Tumbler  [1.0]
   1Offer       [-1.0]
   2Offer       [1.0]
   3Escrow    [-1.0]
   4Escrow    [1.0]
   5(n/a)        [-1.0] 
   

   As you can see, it would be possible to follow the coins.

   What about I just put (n/a) if the lone input has no label ? Would it suit you ?

   In a coinjoin tumbling session we can kind of do the same for following a coins through the different mixes.

7. 
   luke-jr commented at 9:53 am on March 16, 2017: member

   We don’t even support labels for inputs (nor would it make sense to, since they are considered fungible). Labels shown are always for the outputs only.

   (I have no idea how to interpret your image, or what you’re trying to do there.)

8. 
   NicolasDorier commented at 9:55 am on March 16, 2017: contributor

   Ah. These are transaction with top of the line being the conditions the input solved. And bottom the output.

   The goal is to follow you coin as it goes through a serie of transaction as part of a larger process. (In the lightning case it will be easier to see channel creation and closing for example)

9. 
   NicolasDorier commented at 9:58 am on March 16, 2017: contributor

   In the screenshot of the PR you see several tumbling session where alice put the coin into escrow, but timeout and get the coin back through redeem.
10. 
    luke-jr commented at 10:04 am on March 16, 2017: member

    I don’t see that there’s any possible confusion over a case with one input and one output: if they’re both ours, we display the transaction as a send (with label from the output address), and also a receive (again, with label from the output address). Fairly straight-forward there. If there are merely more outputs, each one is a “send”.

    The confusion comes in when you only control a subset of the inputs. This isn’t particular to send-to-self, though: even if you don’t get any of the outputs, it’s still confusing. How do we handle that right now? Seems logical to keep the same behaviour in this PR - if that behaviour isn’t sane, another PR can change it…

11. 
    NicolasDorier commented at 10:30 am on March 16, 2017: contributor

    If you only control a subset of the inputs, then the case of this PR is not reached because fAllFromMe is false.
12. 
    luke-jr commented at 10:33 am on March 16, 2017: member

    Well, then at least this case is straightforward: Show each output as a “send” with the output’s label unless it’s considered change. :)
13. 
    NicolasDorier commented at 10:34 am on March 16, 2017: contributor

    @luke-jr it is what I am doing already.
14. 
    NicolasDorier commented at 2:53 am on June 12, 2017: contributor

    Closing, I ended up making NTumbleBit its own CLI commands for querying the state. Bitcoin QT is useless for showing any layer 2 information without this commit.
15. NicolasDorier closed this on Jun 12, 2017

    ---

16. 
    laanwj commented at 2:09 pm on June 12, 2017: member

    Sorry to hear you couldn’t get agreement on this.
17. 
    NicolasDorier commented at 2:40 am on June 13, 2017: contributor

    @laanwj I think this should be discussed at a more fundamental level: Does Bitcoin Core should consider at all the need of layer 2 users?

    The conflict point was that the notion of “input address” should be non existent in layer 1. But it makes perfect sense for layer 2. Which beg the question of: Does bitcoin core QT should solely focus on layer 1?

    But the payment-to-self, which is very used for layer 2, is actually not useful at all for layer 1. This PR was attempting to make it useful at least for layer 2.

18. 
    sipa commented at 2:54 am on June 13, 2017: member

    @NicolasDorier In the above when referring to Bitcoin Core, you mean its built-in wallet?

    I believe the built-in wallet is very inadequate for building any serious layer on top, and you’ll want a specialized wallet anyway.

    That’s not to say we should or shouldn’t cater to that use case; just that currently, I don’t see how you’d use it without very serious performance issues at least.

19. 
    NicolasDorier commented at 3:03 am on June 13, 2017: contributor

    yes, I mean specifically Bitcoin-QT wallet user interface in this case.
20. DrahtBot locked this on Sep 8, 2021

Contributors
NicolasDorier jonasschnelli luke-jr laanwj sipa

Labels
GUI