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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1YxO0J-0006pC-Qs
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 23:11:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.177 as permitted sender)
client-ip=209.85.213.177; envelope-from=gmaxwell@gmail.com;
helo=mail-ig0-f177.google.com;
Received: from mail-ig0-f177.google.com ([209.85.213.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxO0I-0000BS-Tf
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 23:11:23 +0000
Received: by igbhj9 with SMTP id hj9so73230080igb.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 May 2015 16:11:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.170.219 with SMTP id g88mr21752159ioj.85.1432681877614;
Tue, 26 May 2015 16:11:17 -0700 (PDT)
Received: by 10.107.147.213 with HTTP; Tue, 26 May 2015 16:11:17 -0700 (PDT)
In-Reply-To: <5564FAF1.1050907@thinlink.com>
References: <20150526051305.GA23502@savin.petertodd.org>
<5564B33D.3070107@thinlink.com>
<CAAS2fgSEW9RjZ-=-XE8AkdToHjjAyzBfW6X7JjFtUbppcExbDw@mail.gmail.com>
<5564FAF1.1050907@thinlink.com>
Date: Tue, 26 May 2015 23:11:17 +0000
Message-ID: <CAAS2fgRDF-p3-4CruCXkNtV3tDTQLUx3x+Dq7WN7WnQJdBtu3A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1YxO0I-0000BS-Tf
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] First-Seen-Safe 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: Tue, 26 May 2015 23:11:23 -0000
On Tue, May 26, 2015 at 11:00 PM, Tom Harding <tomh@thinlink.com> wrote:
> The bitcoin transaction is part of a real-world "deal" with unknown
> connections to the other parts
I'm having a hard time parsing this. You might as well say that its
part of a weeblix for how informative it is, since you've not defined
it.
> not the case if paying parties are kicked out of the deal, and possibly
> don't learn about it right away.
The signatures of a transaction can always be changed any any time,
including by the miner, as they're not signed.
> A subset of parties to an Armory simulfunding transaction (an actual
> multi-input use case) could replace one signer's input after they broadcast
> it.
They can already do this.
> Maybe the
> receiver cares where he is paid from or is basing a subsequent decision on
> it. Maybe a new output is being added, whose presence makes the transaction
> less likely to be confirmed quickly, with that speed affecting the business.
The RBF behavior always moves in the direction of more prefered or
otherwise the node would not switch to the replacement. Petertodd
should perhaps make that more clear.
But your "maybe"s are what I was asking you to clarify. You said it
wasn't hard to imagine; so I was asking for specific clarification.
> With Kalle's Proof of Payment proposed standard, one payer in a two-input
> transaction could decide to boot the other, and claim the concert tickets
> all for himself. The fact that he pays is not the only consideration in the
> real world -- what if these are the last 2 tickets?
They can already do that.
> I'd argue that changing how an input is signed doesn't change the deal. For
> example if a different 2 of 3 multisig participants sign, those 3 people
> gave up that level of control when they created the multisig.
Then why do you not argue that changing the input set does not change
the weeblix?
Why is one case of writing out a participant different that the other
case of writing out a participant?
> Replacement is new - we have a choice what kind of warnings we need to give
> to signers of multi-input transactions. IMHO we should avoid needing a
> stronger warning than is already needed for 0-conf.
How could a _stronger_ warning be required?
|
