From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id DE7CEC0051 for ; Sun, 4 Oct 2020 03:45:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id D3D5D84CEB for ; Sun, 4 Oct 2020 03:45:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq1aap5mY8X7 for ; Sun, 4 Oct 2020 03:45:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by fraxinus.osuosl.org (Postfix) with ESMTPS id C829884C1E for ; Sun, 4 Oct 2020 03:45:27 +0000 (UTC) Date: Sun, 04 Oct 2020 03:45:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1601783124; bh=8JNYir+7VoJG8yjqKzJyuuGfBim7SOZjLXvrlCmjOHU=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=QV8mje435V3JrC2HMKocze2d3SAsm6KUPDB4pKq/H+Mzp8RuYpidaig5w/YWHrJKR 6ZickzU1BJy9BjnmCzGibgLF3Y6XWgXkfo1HCw9PonD7PzhpPsAKHoMafXggKQru2c f3tunXHUZWju8E3mJxDwu+TOk2VDL3fuP9jpm8fM= 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: Sun, 04 Oct 2020 03:45:30 -0000 Good Morning Mr. Lee, > I cannot front up funds of my own to give > them inbound balance because it would consume all of my treasury to lock > up funds. This is not a reasonable assumption! Suppose you have a new hire that you have agreed to pay 0.042BTC every 2 we= eks. On the *first* payday of the new hire, you *have* to have *at least* 0.042B= TC in your treasury, somehow. If not, you are unable to pay the new hire, full stop, and you are doomed t= o bankruptcy and your problems will disappear soon once your cut-throat new= hire cuts your throat for not paying her or him. If you *do* have at least 0.042BTC in your treasury, you *can* make the cha= nnel with the new hire and pay the salary via the new channel. At *every* payday, you need to have at least the salary of your entire empl= oyee base available, otherwise you would be unable to pay at least some of = your employees and you will quickly find yourself with your throat cut. Now, let us talk about *topology*. Let us reduce this to a pointless topology that is the *worst possible topo= logy* for Lightning usage, and show that by golly, Lightning will still wor= k. Suppose your company only has this one big channel with the network. Let us reduce your company to only having this single new hire throat-cutte= r (we will show later that without loss of generality this will still work = even if you have thousands of throat-cutters internationally). Now, as mentioned, on the first payday of your throat-cutter, you *have* to= have at least the 0.042 salary you promised. If you have been receiving payments for your throat-cutting business on the= big channel, that means the 0.042 BTC is in that single big channel. You can then use an offchain-to-onchain swap service like Boltz or Loop and= put the money onchain. Then you can create the new channel to your new hire and pay the promised s= alary to the throat-cutter. Now, you have no more funds in either of your channels, the to-network big = channel, and the to-employee channel. So you are not locking up any of *your* funds, only the funds of your emplo= yee. Now, as your business operates, you will receive money in your to-network b= ig channel. The rate at which you receive money for services rendered *has to* be large= r than 0.042/2weeks on average, *otherwise* you are not earning enough to p= ay your throat-cutter by the time of the *next* payday (much less your othe= r operating expenses, such as knife-sharpening, corpse disposal, dealing wi= th the families of the deceased, etc.). If you are not earning at a high enough rate to pay your employee by the ne= xt payday, your employee will not be paid and will solve your problems by c= utting your throat. But what that means is that the employee salary of the *previous* payday is= not locked, either! Because you are receiving funds on your big to-network channel continuously= , the employee can now spend the funds "locked" in the to-employee channel,= sending out to the rest of the network. This uses up the money you have been earning and moving the funds to the to= -employee channel, but if you are running a lucrative business, that is per= fectly fine, since you should, by the next payday, have earned enough, and = then some, to pay the employee on the next payday. Of course there will be times when business is a little slow and you get le= ss than 0.042/2weeks. In that case, a wise business manager will reserve some funds for a rainy d= ay when business is a little slow, meaning you will still have some funds y= ou can put into your to-network big channel for other expenses, even as you= r employee uses capacity there to actually spend their salary. It all balances out. You only need to keep enough in your channels to cover your continuous oper= ational expenses, and employee salaries *are* operational expenses. Suppose you now want to hire *another* throat-cutter. You would only do that if business is booming, or in other words, if you ha= ve accumulated enough money in your treasury to justify hiring yet another = employee. By induction, this will work regardless if you have 1 employee, or 1 millio= n. Regards, ZmnSCPxj