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 00E80C0051 for ; Sat, 3 Oct 2020 22:25:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id E8C1B86410 for ; Sat, 3 Oct 2020 22:25:12 +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 z55aihIyietN for ; Sat, 3 Oct 2020 22:25:11 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by whitealder.osuosl.org (Postfix) with ESMTPS id 2316A85B58 for ; Sat, 3 Oct 2020 22:25:10 +0000 (UTC) Date: Sat, 03 Oct 2020 22:24:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1601763908; bh=KgbHsNqlGUwhxE/jitsA4uIZn3GdilcWWAOPv16hJv0=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=P0Fnsk0ujCSDraAlbnWwH805CCTLmhpRoKaz/poMkk1BVqkSZOmS9HMDOK5pqITNp jsPTPMozqbl1ArAYnhkvOdRuAMx1qyeXkOA8adL5s2hPiQRccwAdghQvzRoVufSjHt ftXlejtYpipgsuzWuK9nbbgBkcVdhZrnIhLzdn9Q= To: "Mr. Lee Chiffre" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion> References: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion> 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: Sat, 03 Oct 2020 22:25:13 -0000 Good morning Mr. Lee, > Lightning network is not much an option because they do not have > inbound balance to get paid. Why not? Your company can open a channel with each employee that has insufficient in= bound liquidity. The employee is incentivized to reveal their node to your company so you ca= n open a channel to them, since otherwise they would be unable to receive t= heir salary. Your alternative is as you say: openly-visible salaries and throat-cutters = who might decide to cut your throat. Let us say your company receives its income stream over Lightning. Let us say you hire a new throat-cutter, with a bi-weekly salary of 0.042 B= TC. You ask the new hire if his or her Lightning node has that capacity. If not, you take some of your onchain Lightning funds, swap out say 0.043 B= TC on Lightning Loop or Boltz Exchange or some other offchain-to-onchain sw= ap. You use those swapped onchain funds to create a fresh channel to the new hi= re. If you are onboarding by batches (which your HR is likely to want to do, so= they can give the onboarding employee seminars in groups) then you can sav= e onchain fees by using C-Lightning `multifundchannel` as well. The occasional bonus can be a bit tricky, but similarly the employee can us= e Lightning Loop or Boltz Exchange or some other alternative to free up cap= acity for the bonus (and they have an incentive to do so, as they want to g= et the bonus). Permanent raises can justify permanently increasing the size of the channel= with the employee. Even if the employee leaves your employ, that is no justification to close = the channel with her or his node. You can earn forwarding fees from his or her new employer or income source. Because of the onion routing, it is hard for you to learn what the employee= spends on, and in the future when they leave your employ, it is hard for y= ou to figure out her or his new employer. If the employee is a saver, they can accumulate their funds, thus reducing = their incoming capacity below their biweekly salary. If so, he or she can use an offchain-to-onchain swap, again, to move their = accumulated savings to onchain cold storage. This is not perfect of course, if you run multiple nodes you can try correl= ating payments by timing and amount (and prior to payment points i.e. today= , you can correlate by payment hashes). But this is still much better than the onchain situation, as you describe. Regards, ZmnSCPxj