* [bitcoin-dev] New BIP: Private Payments
@ 2022-07-30 9:24 Alfred Hodler
2022-07-30 13:41 ` Ruben Somsen
0 siblings, 1 reply; 3+ messages in thread
From: Alfred Hodler @ 2022-07-30 9:24 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi,
We propose a new BIP that facilitates more private two-party transactions. This is a strict improvement upon BIP47, with increased privacy and better future-proofing.
The contents may be found here:
https://github.com/alfred-hodler/bips/blob/bip-alfredhodler-private-payments/bip-alfredhodler-privatepayments.mediawiki
We hope to collect feedback and be assigned with a BIP number. A reference implementation will be published once the BIP is deemed viable.
Alfred
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] New BIP: Private Payments
2022-07-30 9:24 [bitcoin-dev] New BIP: Private Payments Alfred Hodler
@ 2022-07-30 13:41 ` Ruben Somsen
2022-08-01 11:38 ` Alfred Hodler
0 siblings, 1 reply; 3+ messages in thread
From: Ruben Somsen @ 2022-07-30 13:41 UTC (permalink / raw)
To: Alfred Hodler, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]
Hi Alfred,
Thanks for all the effort.
Note that in the previous thread I mentioned[0] that this proposal
introduces a scanning requirement in order to detect incoming notifications
(complicating light client implementation). I recommend that you put this
information in the BIP, as this is an important downside that readers
should be aware of.
I'm also now realizing that your proposal is actually *very* similar to the
BIP47 protocol improvement suggestions that were made in Prague:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae
As far as I can tell, the one difference is that you added an extra ECDH
calculation to hide the recipient payment code. Uncoincidentally, this is
also exactly what causes the downside of having a scanning requirement, and
it seems the only benefit you get in return is that you don't have to
outsource the notification (as is the case in the Prague protocol) and can
broadcast it yourself instead. I'm personally unsure whether this is a net
improvement, but that is certainly open to debate. I'd say it's worth
having this discussion prior to finalizing the BIP, as otherwise it could
potentially result in yet another incompatible standard further down the
line.
Considering the similarity, perhaps you could consider crediting the
participants of the Prague discussion (namely Alekos Filini, Martin
Habovštiak, and myself). And I imagine Silent Payments[1] may have served
as an inspiration as well. I also recommend taking another look at the
"Allowing collisions" paragraph from the Prague discussion, as it can
potentially shave off up to 28 bytes.
I hope you find this feedback reasonable and it doesn't discourage you.
There's way too much work to be done on Bitcoin, so I'm happy to see you
are actively putting in the effort to move things forward. Working out the
details such as how to handle address formats is also very much
appreciated. Keep it up.
Cheers,
Ruben
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020607.html
[1] https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8
On Sat, Jul 30, 2022 at 1:59 PM Alfred Hodler via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi,
>
> We propose a new BIP that facilitates more private two-party transactions.
> This is a strict improvement upon BIP47, with increased privacy and better
> future-proofing.
>
> The contents may be found here:
>
> https://github.com/alfred-hodler/bips/blob/bip-alfredhodler-private-payments/bip-alfredhodler-privatepayments.mediawiki
>
> We hope to collect feedback and be assigned with a BIP number. A reference
> implementation will be published once the BIP is deemed viable.
>
> Alfred
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4160 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] New BIP: Private Payments
2022-07-30 13:41 ` Ruben Somsen
@ 2022-08-01 11:38 ` Alfred Hodler
0 siblings, 0 replies; 3+ messages in thread
From: Alfred Hodler @ 2022-08-01 11:38 UTC (permalink / raw)
To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
Hi Ruben,
I have incorporated your feedback. Using only the first four bytes of the notification code is a very valuable suggestion, so thank you for that. I have added you as a co-author.
In regards to hiding the recipient in the notification, the purpose is not only to allow Alice to send a notification herself, but also to break the link between the notifier (be that Alice or a third-party service) and Bob. Not doing so would reintroduce the same problem we have with BIP47 and unique per-recipient notification addresses -- namely that of social graph building. The tradeoff, as you noticed, is that light clients have to rely on some kind of OP_RETURN indexing service. I personally consider any inconvenience (to developers, as end users never see this) stemming from that to be acceptable because:
1) it reduces the amount of social metadata on the blockchain
2) notification services might otherwise be pressured into censoring certain recipients
3) it allows wallets to decide the level of outsourcing they are comfortable with
4) adversaries monitoring notifications might see a lot of notifications to someone and use that information to mount an attack
Thanks for all the feedback.
Alfred
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-08-01 11:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-30 9:24 [bitcoin-dev] New BIP: Private Payments Alfred Hodler
2022-07-30 13:41 ` Ruben Somsen
2022-08-01 11:38 ` Alfred Hodler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox