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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <s7r@sky-ip.org>) id 1YmA12-0004ND-Bk
for bitcoin-development@lists.sourceforge.net;
Sun, 26 Apr 2015 00:01:44 +0000
Received-SPF: neutral (sog-mx-4.v43.ch3.sourceforge.com: 162.222.225.10 is
neither permitted nor denied by domain of sky-ip.org)
client-ip=162.222.225.10; envelope-from=s7r@sky-ip.org;
helo=outbound.mailhostbox.com;
Received: from outbound.mailhostbox.com ([162.222.225.10])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YmA0i-0001CY-BC for bitcoin-development@lists.sourceforge.net;
Sun, 26 Apr 2015 00:01:44 +0000
Received: from [0.0.0.0] (tor-exit0-readme.dfri.se [171.25.193.20])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id B65DF1A122A
for <bitcoin-development@lists.sourceforge.net>;
Sun, 26 Apr 2015 00:01:14 +0000 (GMT)
Message-ID: <553C2AC6.3000109@sky-ip.org>
Date: Sun, 26 Apr 2015 03:01:10 +0300
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <552EF785.7000207@sky-ip.org> <CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com> <552FDF73.6010104@sky-ip.org> <CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.gmail.com> <CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com>
<CABHVRKS0EYV0CqKW1MVtUZC3u4KvSxMB=Uks9UrCUBQbozO9xQ@mail.gmail.com>
In-Reply-To: <CABHVRKS0EYV0CqKW1MVtUZC3u4KvSxMB=Uks9UrCUBQbozO9xQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
X-CTCH-RefID: str=0001.0A020203.553C2ACC.00BB, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1YmA0i-0001CY-BC
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: s7r@sky-ip.org
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: Sun, 26 Apr 2015 00:01:44 -0000
Thank you all for your comments. The youtube video was indeed very
educative and nice to watch.
It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying solely
on its txid.
BIP62 is good for preventing 3rd parties (non signers) to mutate txids,
but cannot do anything against 2nd parties (signers). I think we can
solve both by using NORMALIZEDTXID - wouldn't this be simpler and easier
to implement? Why are we talking about P3SH when we can just upgrade
P2SH to support additional OP codes? I saw that there have been talks
about a hard fork for increasing the block size, might as well take the
opportunity and fix this for good, by implementing BIP62, NORMALIZEDTXID
as well as BIP65. Couldn't all these be part of P2SH?
On 4/25/2015 6:40 PM, Stephen Morse wrote:
> Hi Gregory,
>=20
> In particular not covering the ID allows for transaction replay whi=
ch
> can result in monetary losses far more severe than any possible
> mishandling of malleability could result in. Byzantine attackers ca=
n
> costlessly replay your old transactions any time anyone reuses an
> address, even accidentally (which cannot be easily prevented since
> they can race).
>=20
>=20
> With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
> specify that they are to be signed without the previous UTXO's
> value/amount. This means that, at worst, replay attacks can send the
> money to the same place it was sent before (which in many cases is
> likely not be a loss of funds), and only if the amount sent to the
> reused address is the exact same as it was before. I don't think this i=
s
> worse than an attacker being able to mutate their transaction and extor=
t
> a merchant who accepts zero-conf transactions. Anyway, not signing the
> input ID wouldn't exactly be the norm, there would be a defined set of
> flags for standard use cases. Not signing the input TXID would only be
> used in specialized cases, such as setting up micropayment channels.=20
> =20
>=20
> There are no free lunches; the proposal linked to there is itself =
a
> game of wack-a-mole with assorted masking flags;=20
>=20
>=20
> I agree that it is also a bit of wac-a-mole, but the defined space of
> issues is possibly more limited here. There are only X number of things
> that can be signed/not signed in a transaction, and the 'Build your own
> nHashType' proposal enables you to fully specify which of those are
> being signed. If you don't want to get burned by not fully signing your
> transactions, then don't use the non-standard sighash flags.
>=20
> many of which we have
> no notion of if they're useful for any particular application(s);=20
>=20
>=20
> A few of the flags, indeed, may not ever be useful. But we can't predic=
t
> the future, and I think it's better to build in a more flexible solutio=
n
> now than to wish we had more flexible nHashTypes later.
>=20
> To the original point of this thread, hopefully the suggested proposal
> won't be necessary as wallets will upgrade to use version 3 transaction=
s
> and the rules associated with them over time.=20
>=20
> Best,
> Stephen
>=20
>=20
> -----------------------------------------------------------------------=
-------
> One dashboard for servers and applications across Physical-Virtual-Clou=
d=20
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insight=
s
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>=20
>=20
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
|
