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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1YxNpm-0000zD-Am
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 23:00:30 +0000
X-ACL-Warn:
Received: from mail-pd0-f182.google.com ([209.85.192.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxNph-0006xF-CQ
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 23:00:30 +0000
Received: by pdbki1 with SMTP id ki1so59340542pdb.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 May 2015 16:00:19 -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=pYSV/CrPFNhJZE5xBzybNuow9l2z5D2UNNMVYkaX/to=;
b=HdbkskNxFuawsn4LzU4Tts6/W02a3kt53fQn1dYhXITs3Ouxo56ciSxeLQPhJ/PD3S
UF2dHA/z8dF3XxKAMyUc0yI6Qlnj8kORW+AemChYN7I19onxJYeYmBo0/kDcUDjX7LxC
PUmYgP6b4JKEBsPVZO57vDTWX7pMwcYo2OeJmaZIXhQYwoAQGVib5tFOOn8YurwTKT/h
QsQrm8/NoyB0JRO5eAd+w9IFk5Sa9s40an/ENg1flw35wiy1rsxbdu3knumzBV2NVZP7
RUDBdkg8IlrxothDsThH2Lxv6RM9kLdIe8GEEp57EfSu/IfoN0mWGrVspVR2ociOGv6r
eDzQ==
X-Gm-Message-State: ALoCoQl/cyT5LmW4paPZgcCjEuHEKRKsCLxClsnHZCgLxwnHB0Lm0edF4lZqce/SiC7ImWjJfloh
X-Received: by 10.66.100.138 with SMTP id ey10mr52700273pab.110.1432681219545;
Tue, 26 May 2015 16:00:19 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
by mx.google.com with ESMTPSA id
ja1sm14078026pbc.51.2015.05.26.16.00.18
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 26 May 2015 16:00:18 -0700 (PDT)
Message-ID: <5564FAF1.1050907@thinlink.com>
Date: Tue, 26 May 2015 16:00:01 -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>
In-Reply-To: <CAAS2fgSEW9RjZ-=-XE8AkdToHjjAyzBfW6X7JjFtUbppcExbDw@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: 1YxNph-0006xF-CQ
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:00:30 -0000
On 5/26/2015 12:10 PM, Gregory Maxwell wrote:
> On Tue, May 26, 2015 at 5:54 PM, Tom Harding <tomh@thinlink.com> wrote:
>> It's not difficult to
>> imagine real-world consequences to not having contributed to the
>> transaction.
> I'm having a hard time. Can you help me understand a specific case
> where this makes a difference.
>
The bitcoin transaction is part of a real-world "deal" with unknown
connections to the other parts. New inputs combined with new or
increased outputs can be thought of as a second deal sharing the same
envelope. That's not the case if paying parties are kicked out of the
deal, and possibly don't learn about it right away.
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. Whether that's a problem depends on real-world
connections. 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.
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?
Mempool policy shouldn't help one payer make a unilateral decision to
become the sole party to a deal after various parties have seen it
broadcast.
> The inherent malleability of signatures makes it unreliable to depend
> on the signature content of a transaction until its good and buried,
> regardless.
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.
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.
|
