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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1YEgjb-00074f-7I
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 16:05:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=gmaxwell@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEgjZ-0000AI-Da
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 16:05:23 +0000
Received: by mail-we0-f175.google.com with SMTP id p10so4861810wes.6
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 08:05:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.205.163 with SMTP id lh3mr5112484wic.63.1422029110308;
Fri, 23 Jan 2015 08:05:10 -0800 (PST)
Received: by 10.27.11.170 with HTTP; Fri, 23 Jan 2015 08:05:10 -0800 (PST)
In-Reply-To: <54C267A1.8090208@gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
<54C267A1.8090208@gmail.com>
Date: Fri, 23 Jan 2015 16:05:10 +0000
Message-ID: <CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alan Reiner <etotheipi@gmail.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: 1YEgjZ-0000AI-Da
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:05:23 -0000
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> Unfortunately, it seems that there was no soft-fork way to achieve this
> 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 the
> coins had entered the wallet with some special, modified TxOut script. So
> it wouldn't work with existing coins, and would require senders to update
> their software to reshape the way they send transactions to be compatible
> 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.
I've expected this need to be addressed simply as a side effect of a
new, more efficient, checksig operator which some people have been
working on and off on but which has taken a backseat to other more
urgent issues.
On Fri, Jan 23, 2015 at 2:51 PM, slush <slush@centrum.cz> wrote:
> as hardware wallets are more widespread. I'm sitting next to TREZOR for 40
> minutes already, because it streams and validate some complex transaction.
Can you help me understand whats taking 40 minutes here? Thats a
surprisingly high number, and so I'm wondering if I'm not missing
something there.
|
