1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id DCF27C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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" <dave@dtrt.org>
To: Eric Voskuil <eric@voskuil.org>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <8656E5B3-EDC7-4C00-93AB-C61AC6C22563@voskuil.org>
References: <dkAxjJIFndwa9WN8Hgrp92I3l3IH0SGRhheMntDfaaDjGTOOnv0s8zIivWE0yiHhh9ty0TQ_IUvkg9Zrs2KFjdSoH1_DrvCymhxA9hF-6Ko=@protonmail.com>
<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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
