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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <allen.piscitello@gmail.com>) id 1YiZAC-0000fc-9J
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 02:04:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174;
envelope-from=allen.piscitello@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YiZA7-0007ll-OG
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 02:04:20 +0000
Received: by widdi4 with SMTP id di4so176366822wid.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 Apr 2015 19:04:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.92.65 with SMTP id ck1mr567001wib.78.1429149849748; Wed,
15 Apr 2015 19:04:09 -0700 (PDT)
Received: by 10.28.30.19 with HTTP; Wed, 15 Apr 2015 19:04:09 -0700 (PDT)
In-Reply-To: <552EF785.7000207@sky-ip.org>
References: <552EF785.7000207@sky-ip.org>
Date: Wed, 15 Apr 2015 21:04:09 -0500
Message-ID: <CAJfRnm6E=huM6GYnmjqF2Wjwcp_79axktwu8+tTriF+rx8Oi8Q@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=f46d043c80762009e90513cde14a
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
(allen.piscitello[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: 1YiZA7-0007ll-OG
Cc: bitcoin-development <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 02:04:20 -0000
--f46d043c80762009e90513cde14a
Content-Type: text/plain; charset=UTF-8
If I had a time locked signed transaction where I threw away the key, this
would potentially invalidate my transaction.
What is the point of such a rule?
On Wed, Apr 15, 2015 at 6:43 PM, s7r <s7r@sky-ip.org> wrote:
> Hi,
>
> Would it be wise to add a consensus rule like the one we have for blocks,
>
> (if > 75% from last 1000 blocks are version 'n' mark version 'n' as
> standard for blocks and if > 95% from the last 1000 blocks are version
> 'n' mark previous block versions as invalid)
>
> 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.
>
> At this moment, the standard in consensus is v1, but nothing is enforced
> in the network related to transaction versions.
>
> Regarding BIP62, as it can be read here [0] it is said that it requires
> v2 transactions. It is also said that transaction version 2 will be
> skipped and jump directly to v3, for an even version for transactions
> and blocks (?). Might as well add the rule for invalidating previous
> transaction versions if the majority updates - could this break anything
> or affect functionality in any way?
>
> BIP62 adds a newer transaction version which is optional and does not
> mark previous v1 as non-standard or invalid. This means bitcoin core
> will treat both v1 and v2/v3 transactions as standard and relay/mine
> them with the same priority, regardless of the tx version?
>
>
> Thanks.
>
> [0]
>
> https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d043c80762009e90513cde14a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If I had a time locked signed transaction where I threw aw=
ay the key, this would potentially invalidate my transaction.<div><br></div=
><div>What is the point of such a rule?</div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Wed, Apr 15, 2015 at 6:43 PM, s7r <spa=
n dir=3D"ltr"><<a href=3D"mailto:s7r@sky-ip.org" target=3D"_blank">s7r@s=
ky-ip.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Would it be wise to add a consensus rule like the one we have for blocks,<b=
r>
<br>
(if > 75% from last 1000 blocks are version 'n' mark version =
9;n' as<br>
standard for blocks and if > 95% from the last 1000 blocks are version<b=
r>
'n' mark previous block versions as invalid)<br>
<br>
but for transaction versions? In simple terms, if > 75% from all the<br>
transactions in the latest 1000 blocks are version 'n', mark all<br=
>
previous transaction versions as non-standard and if > 95% from all the<=
br>
transactions in the latest 1000 blocks are version 'n' mark all pre=
vious<br>
transaction versions as invalid.<br>
<br>
At this moment, the standard in consensus is v1, but nothing is enforced<br=
>
in the network related to transaction versions.<br>
<br>
Regarding BIP62, as it can be read here [0] it is said that it requires<br>
v2 transactions. It is also said that transaction version 2 will be<br>
skipped and jump directly to v3, for an even version for transactions<br>
and blocks (?). Might as well add the rule for invalidating previous<br>
transaction versions if the majority updates - could this break anything<br=
>
or affect functionality in any way?<br>
<br>
BIP62 adds a newer transaction version which is optional and does not<br>
mark previous v1 as non-standard or invalid. This means bitcoin core<br>
will treat both v1 and v2/v3 transactions as standard and relay/mine<br>
them with the same priority, regardless of the tx version?<br>
<br>
<br>
Thanks.<br>
<br>
[0]<br>
<a href=3D"https://bitcoin.stackexchange.com/questions/35904/how-much-of-bi=
p-62-dealing-with-malleability-has-been-implemented" target=3D"_blank">http=
s://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-wi=
th-malleability-has-been-implemented</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT<br>
Develop your own process in accordance with the BPMN 2 standard<br>
Learn Process modeling best practices with Bonita BPM through live exercise=
s<br>
<a href=3D"http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-=
" target=3D"_blank">http://www.bonitasoft.com/be-part-of-it/events/bpm-camp=
-virtual-</a> event?utm_<br>
source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaig=
n=3DVA_SF<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>
--f46d043c80762009e90513cde14a--
|
