Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 19012C002D for ; Fri, 1 Jul 2022 12:42:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id DAFB684689 for ; Fri, 1 Jul 2022 12:42:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DAFB684689 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=uyjZKpi1 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toQ5BjVu48zD for ; Fri, 1 Jul 2022 12:41:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1B27784619 Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1B27784619 for ; Fri, 1 Jul 2022 12:41:59 +0000 (UTC) Date: Fri, 01 Jul 2022 12:41:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1656679316; x=1656938516; bh=CFMgGU7DAL2nGcOl9lyuAJupA0BvP2kYpqbnM/BcwBY=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=uyjZKpi1AxLxk/RKGz4zQbtJVDsmYPd8desm2UOM+s/ngP8kikfbapaYV3EaDXI4H cOaV4Jl0OJnKgrb/QMYbyz4bCaH9aIihTyohErys9T90P3LoRIqitJBtgXaMOJ2l4w JhFoXyERl1zo1KyC77qfBPVKulq/mykiHvE4+uf75//MDB7MZo1vIqhBvZrxqxYqpb 1QcXNzbt9iWaEL/TH31vPBOR8VeliAzi43X4rZr3IY3s0Aa4TzSxRBi3OxK1pZZ6yX 75eIqCzqOPrigfQzgNxh+Kj/7tQ5XS756/nAzcJkWQSI44n1sEDbcaHx0nObtdHeCh 0dzGmFgrrzQIw== To: Bitcoin Protocol Discussion From: Alfred Hodler Reply-To: Alfred Hodler Message-ID: In-Reply-To: References: Feedback-ID: 44065311:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 Jul 2022 12:42:55 +0000 Subject: Re: [bitcoin-dev] [BIP proposal] Private Payments X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2022 12:42:01 -0000 Hi Clark, Thanks for your input. I agree with your proposal to use bech32 instead of base58. It looks sound = to me and as you said, the standard would benefit from more compact QR code= s. The `pay1` prefix is fairly recognizable. > I don't see how this would work, and others have pointed out that the > cost of block space is itself an anti-spam measure. I agree. > A third-party service could offer to publish OP_RETURN notification > payloads in the blockchain for a fee, paid over Lightning Network. > This completely de-links Alice's notification from her wallet, while > accepting the less-known privacy implications of a Lightning payment. > The service would remain ignorant of Bob's identity in any event. Such > a service would also be incentivized to charge market rates for the > potential privacy boost and for block space. The manner of publishing or outsourcing notifications cannot be enforced by= the standard but we can add this as a recommendation. We can also release = such a service in tandem with the BIP in order to encourage its use. The fa= ct that the service would use its own coins would be beneficial to notifier= s since they wouldn't have to engage in coin control on their end. I'm not too familiar with the innerworkings of Lightning, but it is my unde= rstanding that a message can be embedded in each payment. The message in th= is case can be the OP_RETURN payload. That way both the payment and the not= ification payload are sent out in one go. Please correct me if I'm wrong. The downside is that this isn't as censorship resistant as direct notificat= ions but that's probably not going to be a big problem in reality. If these= services ever go down, users should still be able to notify from their own= wallets. > Alternatively, the service publishes the block height along with the > notification data contained within that block. Light clients could > download relevant blocks over the p2p network and perform full > validation. This sounds better than requesting transaction data, both from the standpoi= nt of simplicity and privacy. The danger is that the service drops notifica= tions, either on purpose or by accident, eventually causing clients to miss= notifications. Two possible solutions: a) the service publishes Merkle Tre= es b) each client subscribes to more than one service. Alfred