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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Return-Path: <joseph@lightning.network>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A0C3483
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Apr 2017 16:24:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 59603E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Apr 2017 16:24:22 +0000 (UTC)
Received: by mail-pg0-f49.google.com with SMTP id g2so10350274pge.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 09:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lightning.network; s=google;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to;
bh=DqvmZqNIYAGyf/4XOUriRuTfZeXgAlgJS4LRqMKNRG0=;
b=Nt9mcOiRWG4639Eqk6A+u9x/9JXwlTTLTTKYaW6uVs7rCI1iDOLd+5Vohk66Ytuvdh
aKytuE5/hiEMTrTPuQj3PiWFCx89PwjGRmUQbiH+0WTdvXwiKwio/CXICjbh8jyDOns7
XRTx052dKQCuqIybVtukE56MoTuJ2UG7DTECA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to;
bh=DqvmZqNIYAGyf/4XOUriRuTfZeXgAlgJS4LRqMKNRG0=;
b=tE4fLM+3Lf3dt5fejl/x3YiQaPajXroo5gTf/uEaMDR8dTfdU2gN4l4Iz7gcgGFcSB
eUqBaMawFfKKV3Ii/kCazGxSQOmYDPc7sWxJls5kKv+g/BxjooBsqbcEOCrS8l/KqZPV
S6JqDtZd3Pz2I2ny0mQsCXgv/TJX3IMvKwXEaoBqsXxYvZ4WGAmgDmR6Adv/FwrxCKLs
QokCEupSztwKQxFSyb6/zOUDNNNh8HVfCtGQ/eon2i5thtcCqZ+4ATElwVnNcybjOTWU
QJkx0VC3vO+sFjTiTaaPykZzLgbJ1rNWMwngN7DMUssJRnbEtbC6L68vZFZUQ0fxkaPs
c3Aw==
X-Gm-Message-State: AFeK/H0/h7jOUxtUEZXYKw711th3O59xlXX3ALUIXvwJBSBFnY9jebatcDqnAB2IF+BiOQ==
X-Received: by 10.99.163.72 with SMTP id v8mr31701905pgn.115.1491409461876;
Wed, 05 Apr 2017 09:24:21 -0700 (PDT)
Received: from localhost ([205.185.122.187]) by smtp.gmail.com with ESMTPSA id
11sm38378491pgf.28.2017.04.05.09.24.20
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 05 Apr 2017 09:24:20 -0700 (PDT)
Date: Wed, 5 Apr 2017 09:25:31 -0700
From: Joseph Poon <joseph@lightning.network>
To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170405162531.GA16131@lightning.network>
References: <201704041803.57409.luke@dashjr.org>
<B15790EC-B298-4F6A-BEBF-AF8C3DA74EED@xbt.hk>
<CAO3Pvs9DF6F4gDgrNPoUw5bqwb6ajDwwVP9NpcLzpZMzzgMQjw@mail.gmail.com>
<CAB3F3DvNO5G6WHeDr4qu8NWH3AWWgRN=NfGTNQ1myUZDzC1hnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB3F3DvNO5G6WHeDr4qu8NWH3AWWgRN=NfGTNQ1myUZDzC1hnQ@mail.gmail.com>
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 05 Apr 2017 16:24:23 -0000
On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote:
> I'd appreciate the authors chiming in, but I read the PASDA differently:
>
> 1) If a transaction is mined with a certain bit set, it reserves 700 bytes
> for that particular block.
> 2) In that space, 2 transactions may happen:
> a) First, a transaction penalizing the "parent" transaction for fraud by
> spending the funds immediately
> b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
> window
>
> This means during systematic flooding of closing transactions by
> Goldfinger, vigilant watchers of their channels can immediately punish the
> fraud in the same block using (a), and if they are unable to, need to find
> space within two weeks in (b).
>
> This is really in the LN weeds however, so I'll refrain from evaluating the
> efficacy of such a solution.
Yes, that is correct. I haven't had a chance to review Laolu's summary
yet, haven't had a chance to talk to him today since I was away from the
keyboard for most of the day, would have been unable to review things.
Section "b" above only allows for free riding on the first output of a
transaction with the bit set within the past 2016 blocks. It does not
allow free riding on outputs without that bit set in the transaction.
Additionally, the presumption is that the attacker fills up the
mempool with incorrect prior commitment transactions.
The attack scenario is Mallory asks everyone to open a channel with her.
Mallory only has 1 BTC. With sufficiently low tx fees, Mallory can use
that one bitcoin to open many ~1 BTC channels. All of those channels had
a prior state which Mallory had ~1 BTC, and a current state where she
has none. She broadcasts these thousands of prior states where she has
~1 BTC.
The presumption is the penalty transaction in many cases has a very
small fee, since it is already covered by the commitment.
This mitigates systemic goldfinger attacks since it is unlikely they can
get enough transactions in. Additionally the transactions waiting on the
mempool allows for many to be notified and fill up the first reserved
space. The attacker would likely be attempting to fill up the mempool
(longer block times help here with security!!!). It is presumed that
there is some small amount in reserve so there is some fee reward
covered for enforcing the penalty. This construction allows for the
amount in reserve to be significantly smaller and much more resilient
against even the largest of goldfinger attacks.
(This isn't a full mitigation, as there are certain conditions related
to miner-attacker coordination with high hashpower. Attacker-Miner
coordination is presumed to be out-of-scope, especially in relation to
51% attacks, since it's sort of a moot point, if they have the funds to
mount this attack so that it's profitable, it gets pretty close for them
to have a very significant hashpower anyway.)
I'll add a clarification to the specification on github soon. The intent
of this is to reduce the cost of setting up LN channels with funds in
reserve, with minimal code changes. Future changes which could be
desired if this is usable would be use additional tx flag bits to select
how many outputs in a transaction apply to enable a large payment of
funds pending in-flight.
--
Joseph Poon
|
