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
140
141
142
143
144
145
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <justusranvier@riseup.net>) id 1Z5yO3-0001g3-7W
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:39:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129;
envelope-from=justusranvier@riseup.net; helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z5yO1-0005Vf-Lj
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:39:23 +0000
Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id B49434140E;
Fri, 19 Jun 2015 15:39:15 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: justusranvier) with ESMTPSA id 93FFB429D1
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 19 Jun 2015 15:39:15 +0000
From: justusranvier@riseup.net
To: Peter Todd <pete@petertodd.org>
In-Reply-To: <20150619151127.GA11263@savin.petertodd.org>
References: <20150619103959.GA32315@savin.petertodd.org>
<c2a392703d02e1d674a029c60deb6d94@riseup.net>
<20150619151127.GA11263@savin.petertodd.org>
Message-ID: <47d8e5c4a1d55a1763f1aade1993fece@riseup.net>
X-Sender: justusranvier@riseup.net
User-Agent: Riseup mail
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
X-Spam-Score: -2.0 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5yO1-0005Vf-Lj
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
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: Fri, 19 Jun 2015 15:39:23 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015-06-19 15:11, Peter Todd wrote:
> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
>
> Yet from the point of view of an external observer they have no idea
> why
> the transaction outputs reduced in size, nor any way of knowing if
> fraud
> did or did not occur.
If there are two transactions which spend the same inputs, and each
transaction has completely different output scripts, then this is prima
facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie
If the two transactions have identical output scripts, and one output is
reduced in value to increase the transaction fee, that has the
appearance of honest dealing. There is a possibility that the payer has
chose to under-pay their payee in order to over-pay the miner, but
that's not what a reasonable observer would assume at first glance.
Adding outputs to a transaction, while keeping all the existing outputs
exactly how they are is another way of increasing the transaction fee of
a transaction and is prima facie non-fraudulent.
Note that child-pays-for-parent has none of this ambiguity.
> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?
I haven't closely looked into the features of Bitcoin XT because I'm
hoping that it never becomes relevant. I do want to see a heterogenous
implementation network develop, but Bitcoin XT doesn't really count
since it's a derivative of the Bitcoin Core codebase.
In general, I think every signed Bitcoin transaction sent between
different parties is part of a valid, enforceable contract (using common
law definitions which predate any particular legal jurisdiction).
Handling contracts and money is Serious Business and so the decision of
how software should respond to double spends should not be made
frivolously.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1
7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG
yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ
4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A
Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ
dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m
Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH
NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7
xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE
vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u
8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl
uEW4Vcn+HxlNI/rhxBw4
=odRL
-----END PGP SIGNATURE-----
|
