public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alfred Hodler <alfred_hodler@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP proposal] Private Payments
Date: Tue, 28 Jun 2022 12:35:31 +0000	[thread overview]
Message-ID: <YEMOkk-YNJmfUL3J5rwpjeP47c83hDlHAvY8DaZpLN1m251di-L362zuymRWmfGY8dgzNgZDcbj_mpYwh39t7rG4T0gEhTDkF82t-sxQHpA=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjYD_sC+Hkfd=Ucf2E+6qWz7NLDHUg8sgjeS1AhGAThGXQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

Hi Ruben,

Good to see your input here.

>I agree it's not as efficient as it could be, but how big is this problem in practice? Expecting payments on more addresses doesn't seem like a huge overhead. Or are you talking about the hassle of having to support spending from all these address types?

My worry is that once the number of standard scripts becomes significant, wallets will have to watch all of them. This could create a performance hit eventually, though I don't know what that would be in practice. Maybe someone else can offer more insight. It's possible to mitigate that using a tighter gap limit. But we still have the problem of wallets not supporting certain scripts. For example, Bob's wallet may not support wrapped segwit but Alice could accidentally send funds there assuming Bob can spend them.

SP proposes to use Taproot-only (as we've been discussing elsewhere), but I still don't think it's the right solution to lock down the BIP to a single script type, for the sake of future proofing if nothing else. Having address type flags solves these issues at the expense having a couple of extra bytes.

>but it does make it rather difficult to support light clients.

That's correct. This can't take advantage of compact block filters. Doing so would require having a notification address again. The scanning scheme is lighter and a bit simpler to implement than the one proposed by SP but it still presumes a full node.

>The basic idea is that everyone publishes a single pubkey on-chain,

It even seems to me that Bob doesn't even have to publish his key on-chain unless he intends on sending funds. Only senders would have to do so, and pure recipients (if there would be any such entities) would just have to publish their codes off-chain (e.g. website donation address). The downside is that Alice now has to publish her pubkey on-chain, which creates a footprint. She's now a confirmed user of stealth addresses. She can mitigate that by publishing an ephemeral pubkey for each recipient, but this might spiral out of control fast if the standard gains wider acceptance.

>Note that this mechanism is not safe against miners, as they can pay themselves arbitrarily high fees with no downside.

Good point. Perhaps the solution is to require an OP_RETURN burn instead. I thought it's better to benefit the ecosystem by sending coins back to miners, but burning is also possible.

Alfred

[-- Attachment #2: Type: text/html, Size: 3455 bytes --]

  reply	other threads:[~2022-06-28 12:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 18:17 Alfred Hodler
2022-06-27 20:20 ` Bryan Bishop
2022-06-27 20:35   ` Ruben Somsen
2022-06-28 12:40   ` Alfred Hodler
2022-06-27 20:30 ` Ruben Somsen
2022-06-28 12:35   ` Alfred Hodler [this message]
     [not found]     ` <PS2P216MB10894F1EE83AFA648003C6339DBF9@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
2022-07-05  9:38       ` Alfred Hodler
2022-06-28 23:33   ` Peter Todd
2022-06-29 22:33 ` Clark Moody
2022-07-01 12:41   ` Alfred Hodler
2022-07-01 17:37     ` Christopher Allen
2022-07-11 10:28 ` Alfred Hodler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='YEMOkk-YNJmfUL3J5rwpjeP47c83hDlHAvY8DaZpLN1m251di-L362zuymRWmfGY8dgzNgZDcbj_mpYwh39t7rG4T0gEhTDkF82t-sxQHpA=@protonmail.com' \
    --to=alfred_hodler@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=rsomsen@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox