summaryrefslogtreecommitdiff
path: root/63/38ae3d206226c5f295e5469d9592f2256e583f
blob: 3248242eb640f184c6c0e22a84635a352bd296e8 (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
110
111
112
113
114
115
116
117
118
119
120
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 <etotheipi@gmail.com>) id 1YEh55-0008Rk-6J
	for bitcoin-development@lists.sourceforge.net;
	Fri, 23 Jan 2015 16:27:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.46 as permitted sender)
	client-ip=209.85.192.46; envelope-from=etotheipi@gmail.com;
	helo=mail-qg0-f46.google.com; 
Received: from mail-qg0-f46.google.com ([209.85.192.46])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YEh54-0001gj-8K
	for bitcoin-development@lists.sourceforge.net;
	Fri, 23 Jan 2015 16:27:35 +0000
Received: by mail-qg0-f46.google.com with SMTP id i50so6754761qgf.5
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 23 Jan 2015 08:27:28 -0800 (PST)
X-Received: by 10.140.98.2 with SMTP id n2mr14880357qge.62.1422030448357;
	Fri, 23 Jan 2015 08:27:28 -0800 (PST)
Received: from [192.168.1.28] (c-69-143-204-74.hsd1.md.comcast.net.
	[69.143.204.74])
	by mx.google.com with ESMTPSA id 107sm1867735qgf.21.2015.01.23.08.27.27
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 23 Jan 2015 08:27:27 -0800 (PST)
Message-ID: <54C2766F.6030200@gmail.com>
Date: Fri, 23 Jan 2015 11:27:27 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>	<54C267A1.8090208@gmail.com>
	<CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
In-Reply-To: <CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.2 (-)
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
	(etotheipi[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
	0.4 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YEh54-0001gj-8K
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
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, 23 Jan 2015 16:27:35 -0000


On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi@gmail.com> wrot=
e:
>> Unfortunately, it seems that there was no soft-fork way to achieve thi=
s
>> benefit, at least not one that had favorable properties.  Most of the
>> soft-fork variations of it required the coins being spent to have been=

>> originated in a special way.  In other words, it would only work if th=
e
>> coins had entered the wallet with some special, modified TxOut script.=
  So
>> it wouldn't work with existing coins, and would require senders to upd=
ate
>> their software to reshape the way they send transactions to be compati=
ble
>> with our goals.
> I think this is unreasonable. There is a straight-forward soft-fork
> approach which is safe (e.g. no risk of invalidating existing
> transactions). Yes, it means that you need to use newly created
> addresses to get coins that use the new signature type... but thats
> only the case for people who want the new capability. This is
> massively preferable to expecting _every_ _other_ user of the system
> (including miners, full nodes, etc.) to replace their software with an
> incompatible new version just to accommodate your transactions, for
> which they may care nothing about and which would otherwise not have
> any urgent need to change.
>
>


As far as I'm concerned, anything that requires the coins to originate
in the wallet with some special form is a non-starter.  The new SIGHASH
type allows you to sign transactions with *any* coins already in your
wallet, and imposes no requirements on anyone paying your cold wallet to
be compatible with your signer.=20

Any proposals that require coin origination features means that 100% of
people paying you need to "be nice" and send you coins with this special
structure.  You can't spend old coins that were sent before this
proposal was implemented, and if anyone sends you coins without
respecting the new structure, then your signing devices need the
full-complexity routines to accommodate, which defeats the entire purpose=
=2E

I am happy to entertain other ideas that achieve our goals here, but I'm
fairly confident that the new SIGHASH type is the only way that would
allow devices like Trezor to truly simplify their design (and still work
securely on 100% of funds contained by the wallet).