Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[QT] Remove SendToSelf, and break down its payouts #10007
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.
As you can see in this example, you can follow where the coins flow from the escrow, to the redeem (timeout) or offer.
referenced this pull request
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:
If Alice manage to pay 1.0 Tumbler by the Client Fullfill transaction here is what I would like to see in the wallet:
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.
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)
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...
@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.