From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id DCF27C0037 for ; Sat, 30 Dec 2023 00:37:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AC12D4049A for ; Sat, 30 Dec 2023 00:37:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AC12D4049A X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDxrzJC6XArn for ; Sat, 30 Dec 2023 00:37:19 +0000 (UTC) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 57B7F4010C for ; Sat, 30 Dec 2023 00:37:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 57B7F4010C Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id DF7F12800844; Fri, 29 Dec 2023 16:37:14 -0800 (PST) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Fri, 29 Dec 2023 16:37:14 -0800 (PST) MIME-Version: 1.0 Date: Fri, 29 Dec 2023 14:37:14 -1000 From: "David A. Harding" To: Eric Voskuil , Bitcoin Protocol Discussion In-Reply-To: <8656E5B3-EDC7-4C00-93AB-C61AC6C22563@voskuil.org> References: <8656E5B3-EDC7-4C00-93AB-C61AC6C22563@voskuil.org> User-Agent: Roundcube Webmail/1.4.15 Message-ID: <786297315b27fdecc1a21cc40ef4b993@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 6944.658f663a.66388.0 Subject: Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks 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, 30 Dec 2023 00:37:21 -0000 On 2023-12-28 08:42, Eric Voskuil via bitcoin-dev wrote: > Assuming a “sufficient fraction” of > one of several economically rational behaviors is a design flaw. The amount of effort it takes a user to pay additional miners out of band is likely to increase much faster than probability that the user's payment will confirm on time. For example, offering payment to the set of miners that controls 90% of hash rate will result in confirmation within 6 blocks 99.9999% of the time, meaning it's probably not worth putting any effort into offering payment to the other 10% of miners. If out of band payments become a significant portion of mining revenue via a mechanism that results in small miners making significantly less revenue than large miners, there will be an incentive to centralize mining even more than it is today. The more centralized mining is, the less resistant Bitcoin is to transaction censorship. We can't prevent people from paying out of band, but we can ensure that the easiest and most effective way to pay for a transaction is through in-band fees and transactions that are relayed to every miner who is interested in them. If we fail at that, I think Bitcoin losing its censorship resistance will be inevitable. LN, coinpools, and channel factories all strongly depend on Bitcoin transactions not being censored, so I don't think any security is lost by redesigning them to additionally depend on reasonably accurate in-band fee statistics. Miners mining their own transactions, accepting the occasional out-of-band fee, or having varying local transaction selection policies are situations that are easily addressed by the user of fee-dependent timelocks choosing a long window and setting the dependent feerate well below the maximum feerate they are willing to pay. -Dave