summaryrefslogtreecommitdiff
path: root/84/74f45d14895a2a358759baedb16e82a65670ca
blob: 059523ad3d1109a7e848b366c6c1ac9d691d726f (plain)
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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E70C58CC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  5 Nov 2015 15:27:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42D1F187
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  5 Nov 2015 15:27:39 +0000 (UTC)
Received: by wmeg8 with SMTP id g8so16579599wme.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 05 Nov 2015 07:27:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jtimon_cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BTl2QuJU2zCdf+lvud2o1OakTZCPhK8SVEMTU0ED+BI=;
	b=shYxE1uaXq1z4sminLcDjUZfq8P6+1zr18EduentDWrnZBsHPF0qD6oWvc85F0y1GW
	YN7PDYrt5/UndVasJsg0hFMimXpiy7ElRKiupY3UYZClLInmlZ0yXduyUTuz5scdUHP8
	7JsZ2UniZ4wNlw2U2uoDMD+CANGebGAdpDTJCf+h87HgDwHyJrYNBhAMWcZpH6IshJL0
	b4EfCalYGczLGY4Z4td0TKnk+EJdmSf7jlHn3AswvS7FhF0pfsom+sW3pRrgo+2G0PuX
	bbjHosfYPYRw38yD+eG6/FctKQyJveQYBYpTrCiTQJXTNumwT7qLwcpHZtlKHSgwyinf
	LV+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=BTl2QuJU2zCdf+lvud2o1OakTZCPhK8SVEMTU0ED+BI=;
	b=NlpJwuU2fZaJIP3z+pJ6VGpeWkixw+rJaWHPKGhPSXiWGdh0r72BYDuvKQNqZajR//
	900vm3ylN7yu5JY0lMhSOCrVAL5jyDpA+YRhfdQu9u8s3QYwKSYxXK90go6aBXN4fWBs
	SiLoUlwtT4uQL8sDG/agno9IVEHa2/CwQwjW6fvZ6GV+u8Zh1Wx0N0HqnajR8kYmeGPK
	6geDxyo5Elx8kRW9d54mfqrQujTRWTQVUHq+4tNdUgWbKUGy8OWE/YiG+YHUngzpJ4NO
	Qt2NZytXT/adhaSmTb3VNZ1PbiLmLd9Z31bcTpILqgHHiCrpFCtRB2UKIXo2WDcBoWSm
	q5gA==
X-Gm-Message-State: ALoCoQmQ5N0gIJPQSfPa48NzBE6R8wYNoFGfIG+LirbzlJK98oFmi3LUTNdVKkpIe/apezWv3ZHN
MIME-Version: 1.0
X-Received: by 10.28.146.146 with SMTP id u140mr4230601wmd.85.1446737257903;
	Thu, 05 Nov 2015 07:27:37 -0800 (PST)
Received: by 10.194.204.195 with HTTP; Thu, 5 Nov 2015 07:27:37 -0800 (PST)
In-Reply-To: <201511032201.21047.luke@dashjr.org>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201511032048.18680.luke@dashjr.org>
	<CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
	<201511032201.21047.luke@dashjr.org>
Date: Thu, 5 Nov 2015 16:27:37 +0100
Message-ID: <CABm2gDpNXGZ7yevFoN9k5nx7wBZX86cH0vJs38DyL+PtEPLHxw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 05 Nov 2015 15:44:28 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 15:27:40 -0000

On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
>> So this is indeed a form of desired malleability we will likely not be able
>> to fix. I'd argue that this goes more into the direction of double-spending
>> than a form of malleability, and is mostly out of scope for this BIP. As
>> the abstract mentions this BIP attempts to eliminate damage incurred by
>> malleability in the third party modification scenario and in the multisig
>> scenario, with the added benefit of enabling transaction templating. If we
>> can get the segregated witnesses approach working all the better, we don't
>> even have the penalty of increased UTXO size. The problem of singlesig
>> users doublespending their outputs to update transactions remains a problem
>> even then.
>
> I don't know what you're trying to say here. Double spending to the same
> destination(s) and malleability are literally the same thing. Things affected
> by malleability are still just as broken even with this BIP - whether it is
> triggered by a third-party or not is not very relevant.

I think this is just a terminology confusion.
There's conflicting spends of the same outputs (aka unconfirmed
double-spends), and there's signature malleability which Segregated
Witnesses solves.
If we want to define malleability as signature malleability +
conflicting spends, then that's fine.
But it seems Christian is mostly interested in signature malleability,
which is what SW can solve.
In fact, creating conflicting spends is sometimes useful for some
contracts (ie to cancel the contract when that's supposed to be
allowed).
Maybe it is "incorrect" that people use "malleability" when they're
specifically talking about "signature malleability", but I think that
in this case it's clear that we're talking about transactions having
an id that cannot be changed just by signing with a different nonce
(what SW provides).

Please, Christian, correct me if you mean something else.