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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1YicFf-00029d-Oy
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 05:22:11 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.179 as permitted sender)
client-ip=209.85.217.179; envelope-from=pieter.wuille@gmail.com;
helo=mail-lb0-f179.google.com;
Received: from mail-lb0-f179.google.com ([209.85.217.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YicFb-00066N-1k
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 05:22:11 +0000
Received: by lbcga7 with SMTP id ga7so50193549lbc.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 Apr 2015 22:22:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.35.230 with SMTP id l6mr3501648lbj.5.1429161720676; Wed,
15 Apr 2015 22:22:00 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Wed, 15 Apr 2015 22:22:00 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Wed, 15 Apr 2015 22:22:00 -0700 (PDT)
In-Reply-To: <552EF785.7000207@sky-ip.org>
References: <552EF785.7000207@sky-ip.org>
Date: Wed, 15 Apr 2015 22:22:00 -0700
Message-ID: <CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=001a11c37876b0081c0513d0a460
X-Spam-Score: -0.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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1YicFb-00066N-1k
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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
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: Thu, 16 Apr 2015 05:22:11 -0000
--001a11c37876b0081c0513d0a460
Content-Type: text/plain; charset=ISO-8859-1
On Apr 16, 2015 1:46 AM, "s7r" <s7r@sky-ip.org> wrote:
> but for transaction versions? In simple terms, if > 75% from all the
> transactions in the latest 1000 blocks are version 'n', mark all
> previous transaction versions as non-standard and if > 95% from all the
> transactions in the latest 1000 blocks are version 'n' mark all previous
> transaction versions as invalid.
What problem are you trying to solve?
The reason why BIP62 (as specified, it is just a draft) does not make v1
transactions invalid is because it is opt-in. The creator of a transaction
needs to agree to protect it from malleability, and this subjects him to
extra rules in the creation.
Forcing v3 transactions would require every piece of wallet software to be
changed.
--
Pieter
--001a11c37876b0081c0513d0a460
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Apr 16, 2015 1:46 AM, "s7r" <<a href=3D"mailto:s7r@sky-ip.o=
rg">s7r@sky-ip.org</a>> wrote:<br>
> but for transaction versions? In simple terms, if > 75% from all th=
e<br>
> transactions in the latest 1000 blocks are version 'n', mark a=
ll<br>
> previous transaction versions as non-standard and if > 95% from all=
the<br>
> transactions in the latest 1000 blocks are version 'n' mark al=
l previous<br>
> transaction versions as invalid.</p>
<p dir=3D"ltr">What problem are you trying to solve?</p>
<p dir=3D"ltr">The reason why BIP62 (as specified, it is just a draft) does=
not make v1 transactions invalid is because it is opt-in. The creator of a=
transaction needs to agree to protect it from malleability, and this subje=
cts him to extra rules in the creation.</p>
<p dir=3D"ltr">Forcing v3 transactions would require every piece of wallet =
software to be changed.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a11c37876b0081c0513d0a460--
|
