From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4AB02C0051 for ; Sun, 4 Oct 2020 14:07:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 22BF120115 for ; Sun, 4 Oct 2020 14:07:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cmDT6jnzbaQ for ; Sun, 4 Oct 2020 14:07:19 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by silver.osuosl.org (Postfix) with ESMTPS id D83E620110 for ; Sun, 4 Oct 2020 14:07:18 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id k14so6663871edo.1 for ; Sun, 04 Oct 2020 07:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=tHek+Z7nGWJtCrGS/lEW+KrTXtKj1LVZOSG4l1vRfXo=; b=m0Qv1+7jixOBULwl659cmAwC78Pc7w8Z8MVwf68vZrLAd57xW1vQqIXLzmkZHTm+Cq L4lc0arUy0mDsTwXMP2tXL6E0GqL9BqX/VPaJKjMTUnlWlwzSK0q8e8U+nlQ+/bmVjOf dKuwiodKZcTSJ5bJZw/JN7J8vP2Spyhc4fc55qVVdhYmqIlcKrOG/o/jukOQwF4UKT8J tMigO/9KjQ4sDsvv0OdNHgmEcTwTQnDAVA26Aj+q28b44dxN0f6Ale1k2mXIY3UPbgnq FsNQnV2lsSrbXhlOez5JTDuB6XAYGg/OXrYg+M8lYvbst59LolHsOqci+vGMqoVYMBjO GXng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=tHek+Z7nGWJtCrGS/lEW+KrTXtKj1LVZOSG4l1vRfXo=; b=AVxY3QSwyDR1Rt1FBiEInCGcYK+jKUhqwcMXpd3rpiRLRhRQk+cXJRGSZBaU9ccCNi jhiUek7nCL7WmwBewGZHDDeEMg5eZvGAhxKaL9RgSgJmZDNyO7kxPh0GqbNK+k6kw04V 5bi61lFIj/7FSbV4MhcfBFuH3Zz++OzwfuMUGN+JA/WZ7+44XQKftl16LaKZSMmnB3Wc uBVIl86Cn/bC34hdNHO6dGexykjafa4uYJ1Po+Wdr8Tr+p/McJI3Tv1wl3+kBFsrqirm tJKffPXvRNPn9mEvojHqP+BwQZ7fWIUp5s+9asqbRESkeV7raN1NUCkce27GssrhDpZ0 PS/A== X-Gm-Message-State: AOAM531ppmziLeq36YeFphkyzJmDT75RiYMMSov9OcNrlAHn5C3apglc 47uzGe/aulfFQYxfxVQi3mV7ELYKDKTsqn3tE9zG0seU4/7eAQ== X-Google-Smtp-Source: ABdhPJzQuyj3OwoPsZmHjmYOwUuY02bZQloZxERLEkNhhUa53nTjFlZ4fTwIJTJ/1QFTD7MLSlIK0+CfqgmcaTMsJX8= X-Received: by 2002:a05:6402:d3:: with SMTP id i19mr12833897edu.320.1601820436898; Sun, 04 Oct 2020 07:07:16 -0700 (PDT) MIME-Version: 1.0 References: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion> In-Reply-To: From: Thomas Hartman Date: Sun, 4 Oct 2020 10:07:05 -0400 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 04 Oct 2020 17:49:27 +0000 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 14:07:20 -0000 "big to-network channel" nit: should this be "big from-network channel" ? thanks for this explanation. On Sat, Oct 3, 2020 at 11:45 PM ZmnSCPxj via bitcoin-dev wrote: > > 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 loc= k > > up funds. > > This is not a reasonable assumption! > > Suppose you have a new hire that you have agreed to pay 0.042BTC every 2 = weeks. > > On the *first* payday of the new hire, you *have* to have *at least* 0.04= 2BTC in your treasury, somehow. > > If not, you are unable to pay the new hire, full stop, and you are doomed= to bankruptcy and your problems will disappear soon once your cut-throat n= ew 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 c= hannel 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 em= ployee base available, otherwise you would be unable to pay at least some o= f 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 to= pology* for Lightning usage, and show that by golly, Lightning will still w= ork. > > 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-cut= ter (we will show later that without loss of generality this will still wor= k 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 t= he 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 a= nd put the money onchain. > Then you can create the new channel to your new hire and pay the promised= salary to the throat-cutter. > > Now, you have no more funds in either of your channels, the to-network bi= g channel, and the to-employee channel. > So you are not locking up any of *your* funds, only the funds of your emp= loyee. > > Now, as your business operates, you will receive money in your to-network= big channel. > The rate at which you receive money for services rendered *has to* be lar= ger than 0.042/2weeks on average, *otherwise* you are not earning enough to= pay your throat-cutter by the time of the *next* payday (much less your ot= her operating expenses, such as knife-sharpening, corpse disposal, dealing = with the families of the deceased, etc.). > If you are not earning at a high enough rate to pay your employee by the = next payday, your employee will not be paid and will solve your problems by= cutting 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 continuous= ly, the employee can now spend the funds "locked" in the to-employee channe= l, 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 p= erfectly fine, since you should, by the next payday, have earned enough, an= d 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 = less than 0.042/2weeks. > In that case, a wise business manager will reserve some funds for a rainy= day when business is a little slow, meaning you will still have some funds= you can put into your to-network big channel for other expenses, even as y= our 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 op= erational 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 = have accumulated enough money in your treasury to justify hiring yet anothe= r employee. > > By induction, this will work regardless if you have 1 employee, or 1 mill= ion. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev