rhavar at protonmail.com [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-21 📝 Original message:I'm not really sure the ...
📅 Original date posted:2019-03-21
📝 Original message:I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:
>
> - If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.
>
> What do you think?
>
> Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190321/a8697048/attachment-0001.html>;
📝 Original message:I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:
>
> - If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.
>
> What do you think?
>
> Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190321/a8697048/attachment-0001.html>;