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
146
147
148
149
150
151
152
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1YxOUj-0003I4-DE
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 23:42:49 +0000
X-ACL-Warn:
Received: from mail-pa0-f41.google.com ([209.85.220.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxOUh-0002f1-Ja
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 23:42:49 +0000
Received: by pabru16 with SMTP id ru16so104025367pab.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 May 2015 16:42:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=2WmSgh4yeRhOFYB5tJrBVZtNrH+CkCxfxb9TeewWgGg=;
b=OblwUh+7M6UUfcmAsM9escxe4iuyH9SdHXp36PYfUin0/w4ALApf6oGkKmmYLIgH/5
T5mNHMXyVRZcMzKl4USF4hptnJIjrCdBKHA/7tbIXp2Rk7QPEqaMzADi7JYR7QsHs6SC
J5yRn73pZSNpq4uyu5woboj6IiLAXf0aB7C10L1HpGrejSzWtLrPn2p8CHsBR1LxoV67
cgEzpVRknskiMfTzv9Ykv91Jv2rv/Zm+LxGYN6DBNiD9fe86f/+97NLQR9TxoiPEZuiP
ShW7gyCdzdS0p9x670GLoJ7B3BYWGlKbJtoe2ADa6yMdwt2lCFoSbMFe9sDl3bpo+Yqf
qQVQ==
X-Gm-Message-State: ALoCoQnWIC0xAo3efH6wjMs7KGEY/AvQnWe2GfXo05vxbplOBtnkDoJ2lfycOVJwBc9ym77CwuYs
X-Received: by 10.68.138.230 with SMTP id qt6mr53940665pbb.160.1432683761756;
Tue, 26 May 2015 16:42:41 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
by mx.google.com with ESMTPSA id
po2sm14140791pbb.13.2015.05.26.16.42.40
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 26 May 2015 16:42:40 -0700 (PDT)
Message-ID: <556504DF.7060309@thinlink.com>
Date: Tue, 26 May 2015 16:42:23 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <20150526051305.GA23502@savin.petertodd.org> <5564B33D.3070107@thinlink.com> <CAAS2fgSEW9RjZ-=-XE8AkdToHjjAyzBfW6X7JjFtUbppcExbDw@mail.gmail.com> <5564FAF1.1050907@thinlink.com>
<CAAS2fgRDF-p3-4CruCXkNtV3tDTQLUx3x+Dq7WN7WnQJdBtu3A@mail.gmail.com>
In-Reply-To: <CAAS2fgRDF-p3-4CruCXkNtV3tDTQLUx3x+Dq7WN7WnQJdBtu3A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[204.58.254.99 listed in dnsbl.sorbs.net]
X-Headers-End: 1YxOUh-0002f1-Ja
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:42:49 -0000
On 5/26/2015 4:11 PM, Gregory Maxwell wrote:
> 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.
For example, you are paying for concert tickets. The deal is concert
tickets for bitcoin. Or you're buying a company with 3 other investors.
>> 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.
Miners can't update the signature on input #0 after removing input #1.
>
>> 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.
Replacement is about how difficult it is to change the tx after it is
broadcast and seen by observers.
>> 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.
Pick any one "maybe". They're only maybes because it's not realistic
for them all to happen at once.
>
>> 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.
Not without replacement, after broadcast, unless they successfully pay
twice.
>
>> 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?
In the multisig input case, each signer already accepted the possibility
of being written out. Peter Todd's proposal is in the spirit of not
willfully making unconfirmed txes less reliable. I'm suggesting that
multi-input signers should be included in the set of people for whom
they don't get less reliable.
>
>> 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?
We'd have to warn signers to multi-input txes instead of just warning
receivers.
|
