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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <john.dillon892@googlemail.com>) id 1UUcWF-0004ss-IA
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Apr 2013 12:40:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
designates 209.85.215.194 as permitted sender)
client-ip=209.85.215.194;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ea0-f194.google.com;
Received: from mail-ea0-f194.google.com ([209.85.215.194])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UUcWC-0008Lg-0i
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Apr 2013 12:40:23 +0000
Received: by mail-ea0-f194.google.com with SMTP id z7so78055eaf.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Apr 2013 05:40:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.15.98.141 with SMTP id bj13mr50827956eeb.29.1366720813678;
Tue, 23 Apr 2013 05:40:13 -0700 (PDT)
Received: by 10.223.197.7 with HTTP; Tue, 23 Apr 2013 05:40:13 -0700 (PDT)
In-Reply-To: <CA+CODZF_kVoKcPjPgpfnEH4PBFfLJqS7SuvsRG_DRJroo3gcLA@mail.gmail.com>
References: <CA+CODZF_kVoKcPjPgpfnEH4PBFfLJqS7SuvsRG_DRJroo3gcLA@mail.gmail.com>
Date: Tue, 23 Apr 2013 12:40:13 +0000
Message-ID: <CAPaL=UV8L59h1mQPd9H+mVSWkEuWy9wz0SvgrAU-kDOQwypxcg@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Jeremy Spilman <jeremy.spilman@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UUcWC-0008Lg-0i
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2013 12:40:23 -0000
Sorry I don't have time to reply more in depth, but I wanted to say to
Jeremy (especially) and Peter I'm very impressed to see such a good
design be created so fast that does not depend on replacement at all.
This is a great example of how often the right approach to a problem
is to accept that the easy solution will not work, and find a way to
overcome the issue, rather than trying to paper over the easy
solution's problems with insecure design. I'm reminded of Peter's work
on fidelity bonded banking to overcome Bitcoin's scalability problem,
although that needs to become real, and soon, so we can find all the
flaws in it that will only become apparent when the idea is
implemented for real.
Jeremy: There does not seem to be a PGP key listed for your email
address. Is that correct?
On Sat, Apr 20, 2013 at 8:51 PM, Jeremy Spilman
<jeremy.spilman@gmail.com> wrote:
> I was discussing this with petertodd a couple days ago and we were thinking
> the sequence I sent yesterday was usable today. I tried getting it to work
> on test-net but the final transaction closing the channel was not being
> accepted into the mempool beacause "ERROR: CTxMemPool::accept() : inputs
> already spent"
>
> But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded
> me; Test-Net implements IsStandard() to allow the non-final "refund" TX into
> the mempool, but then doesn't allow it to be replaced, Main-Net implements
> IsStandard() to *reject* non-final transactions in the first place.
>
> Therefore, this actually will work on Main-Net today, since the refund TX
> won't even be allowed into the mempool until it's final, the AP is free to
> sign and broadcast its final TX without any replacement. Of course, if the
> AP waits too long, the user can get their Refund into the mempool and the
> AP's [higher seq] version will be locked out.
>
> This may be a case where Test-Net is in a "bad" state, by allowing non-final
> TXs into the pool, but not allowing replacement, you get an intermediate
> state which neither matches Main-Net behavior, nor implements behavior which
> would ever be deployed to Main-Net as-is.
>
> The current Main-Net behavior is actually very well suited for this
> application. Any application that can be reduced to two instances of a Tx,
> namely one non-final, and one final which is updated internally between the
> parties, works very well under the current Main-Net rules.
>
> If you set the nLockTime of the refund to be several days after the
> scheduled closing time of the channel, it would be quite challenging to get
> the Refund TX into the blockchain *despite* a final broadcast TX from the
> AP. Since the vast majority of Main-Net won't even accept it, the attacker
> would have to distribute the TX to any miner who could include the AP's
> transaction in a block between now and when the refund becomes final, and
> convince them all to not include the perfectly valid, fees paid, final,
> nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of
> coordination would act substantially against the best interests of the
> miners, to say the least.
>
> This proposal still suffers from any malleability weakness, where the user's
> refund could be invalidated by a miner changing the TxID of TX1.
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
