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

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

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
6 participants
@NicolasDorier
Copy link
Member

NicolasDorier commented Mar 16, 2017

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

After:
capture

@jonasschnelli

This comment has been minimized.

Copy link
Member

jonasschnelli commented Mar 16, 2017

Nice.
Concept ACK.

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Mar 16, 2017

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.

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Mar 16, 2017

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

TB

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.

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Mar 16, 2017

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

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Mar 16, 2017

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)

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Mar 16, 2017

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.

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Mar 16, 2017

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

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Mar 16, 2017

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

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Mar 16, 2017

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

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Mar 16, 2017

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

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Jun 12, 2017

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.

@laanwj

This comment has been minimized.

Copy link
Member

laanwj commented Jun 12, 2017

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

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Jun 13, 2017

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

@sipa

This comment has been minimized.

Copy link
Member

sipa commented Jun 13, 2017

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

@NicolasDorier

This comment has been minimized.

Copy link
Member Author

NicolasDorier commented Jun 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.