Nice.
Concept ACK.

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.

@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:

Tumbler  [1.0]
Offer       [-1.0]
Offer       [1.0]
Escrow    [-1.0]
Escrow    [1.0]
(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.

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.)

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)

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.

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...

If you only control a subset of the inputs, then the case of this PR is not reached because fAllFromMe is false.

Well, then at least this case is straightforward: Show each output as a "send" with the output's label unless it's considered change. :)

@luke-jr it is what I am doing already.

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.

Sorry to hear you couldn't get agreement on this.

@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.

@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.

yes, I mean specifically Bitcoin-QT wallet user interface in this case.