From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EF94BC0051 for ; Tue, 6 Oct 2020 04:11:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id D787986508 for ; Tue, 6 Oct 2020 04:11:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9t0pUIum3SM for ; Tue, 6 Oct 2020 04:11:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by whitealder.osuosl.org (Postfix) with ESMTPS id EC900864FB for ; Tue, 6 Oct 2020 04:11:03 +0000 (UTC) Date: Tue, 06 Oct 2020 04:10:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1601957461; bh=iF+bUYwOyBhoWqO3IeNDjWBUV7tanGJjWxNAazEWUFk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=en9iXeL536Iu6QMnRZOUUKRhr/CmmO3jB1b+A3067N52EIJqF7OIEYUXm3QGE7cW+ a1rB7+sjPo/1QD8NGreYZOM9PavYdBs+vYFKFTpZb7/pzeGT3al9eJZrCiP5deQQwg lI2MJNIetvRZW1fQ0WCNK0CezEFizwmIxNcD1hZI= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <-9eIH0M9XOXDIGvFaSHljGrkKfd_N7q9POTV4wzobjSGljNwE3snOP2-jPE4Nh1IPovo8tTuQz_nSqgpLWI2hrD5_UGonfn-sjNo7oIbVXU=@protonmail.com> References: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion> <-9eIH0M9XOXDIGvFaSHljGrkKfd_N7q9POTV4wzobjSGljNwE3snOP2-jPE4Nh1IPovo8tTuQz_nSqgpLWI2hrD5_UGonfn-sjNo7oIbVXU=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy 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: Tue, 06 Oct 2020 04:11:06 -0000 Good morning Mr. Lee, and list, > I can then look at the gossiped channels and see the size of the channel = between the cut-throat company and the other employee, and from there, gues= s that this is the bi-weekly salary of that employee. This can be made an argument against always publishing all channels, so let= me propose something. The key identifying information in an invoice is the routehint and the node= ID itself. There are already many competing proposals by which short-channel-ids in ro= utehints can be obscured. They are primarily proposed for unpublished channels, but nothing in those = proposals prevents them from being used for published channels. The destination node ID is never explicitly put in the onion, only implied = by the short-channel-id in order to save space. However, the destination node ID *is* used to encrypt the final hop in the = onion. So the receiver node can keep around a small number of throwaway keypairs (= or get those by HD) and use a throwaway to sign the invoice, and when it is= unable to decode by its normal node ID, try using one of the throwaway key= pairs. With both of the above, what remains is the feerate settings in the invoice= . If the company node gives different feerates per channel, it is still possi= ble to identify which channel is *actually* referred to in the invoice. What the receiver node can do would be to give a small random increase in f= eerate, which basically overpays the company node, but obscures as well *wh= ich* channel is actually in the invoice. Regards, ZmnSCPxj