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
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 04D60E6A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 10:24:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com
[209.85.215.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 011D9149
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 10:24:57 +0000 (UTC)
Received: by mail-lf0-f53.google.com with SMTP id o89so4509081lfg.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 02:24:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding:content-language;
bh=m8HpXSoZP/GiAv+UANrnZ5tonOr5UXJ7DCYq5AX9O/U=;
b=Lq1CxY/eZSOgYYOasaxzJlATGQNka3g581/Ow9mepnAJspW7a0njO+orDSibNyIO21
viEBA4cCULpOpqhWUSPHK9LaMrf6tGh60N0WCrCpsxFrFqbNCQ+7LbgX00eoAipOE1E1
P6Aqfk8IcAWQfYmfNWMnjVC3eWGH5la5A7pSmNs6RpHkNYgu0BPlv2669jK6XtDJRCgf
rVBf7CSo7A+D4z1UXIvhfkaZ7eA7o5yW61FwTcgCVvzqElIvONBForBwdAAX6jxUPQ9T
qNBGJ9hVYNNT4pH0aCBQZ+dazTyHZQ5osuskFsHSvY1B0TSEEPtv/JbHf++KlvD3FXmt
C0uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=m8HpXSoZP/GiAv+UANrnZ5tonOr5UXJ7DCYq5AX9O/U=;
b=hmA/6vVv1sPUxdFnGx7PUVGt1olUgbMQKHGH3apDQLa+3kcgKBFNWWVYGRSQtSUwJr
dkZV3Q9sPN3X2jLDFB5HiSi+5Ln4DzyRzEa9NLFFxjlUAKiTl3fG2e4PpaS/SwzLSE5l
9V7XF6tTE0xtSy9Op0HtDlfJI3s7xpuxY3lijEdr/YC6Fef7qhTibSJMbhnnUoQZSqHB
TIX7sIREHZREc6DKt2COmso+tC8vEeLg75pefO4jMgzE29SIkvTyMmNkS9Iv+bMgqE7u
qjR+sVMX3mrsrGhvPjNC0I8mUOMGE0zv1DB+KLc9cRTZu8FV+Gq1TCSEaGxT2Zxi0Hy5
zFXg==
X-Gm-Message-State: AKwxytcUWWzFxOehi3x8wZYy3kqFIYVFbToVa8W/SQqXSUwvNZhAF7/I
I2puIFxrqiQO+xC8eMpwvO8=
X-Google-Smtp-Source: AH8x224it8Yyt6yWAxpmghTNcKQzzfVRMjQsukqaItbQZOT6/I2brEoGX6NcJWl/zCMc9kEW5fRA2A==
X-Received: by 10.46.23.205 with SMTP id 74mr166247ljx.29.1516789496237;
Wed, 24 Jan 2018 02:24:56 -0800 (PST)
Received: from ?IPv6:2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17?
([2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17])
by smtp.googlemail.com with ESMTPSA id
36sm502308lfx.13.2018.01.24.02.24.55
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 24 Jan 2018 02:24:55 -0800 (PST)
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
=?UTF-8?B?0JDRgNGC0ZHQvCDQm9C40YLQstC40L3QvtCy0LjRhw==?=
<theartlav@gmail.com>
References: <CAJRVQkBPQR3Gz3AtWFgK_Z_9vDVZvR4Ws=f+tUZ3Y0mdswuk_g@mail.gmail.com>
<CAAS2fgQmKY5206-ko9ttV4K_4aPfoWh7Jrx=XYetXLeknU30iw@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <41d8ff42-106f-45b9-cc70-507982c7336b@gmail.com>
Date: Wed, 24 Jan 2018 11:24:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CAAS2fgQmKY5206-ko9ttV4K_4aPfoWh7Jrx=XYetXLeknU30iw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: fr
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Why is deriving public key from the signature not
used in Segwit?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 10:24:59 -0000
34 bytes in fact
I have asked already the question at least twice on this list pointing
out the fact that pubkey is there now even for standard p2pkh
transactions and it was not the case some time ago
But I never got any answer regarding what motivated this change
(compared to the previous behavior) and when, so whether I am missing
something obvious, whether nobody wants to answer
Txs without pubkey are now rejected then what is the element in the code
(protocol, version, etc) that "decided" this?
Le 24/01/2018 à 05:25, Gregory Maxwell via bitcoin-dev a écrit :
> On Wed, Jan 24, 2018 at 3:50 AM, Артём Литвинович via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Greetings.
>>
>> I wanted to ask what was the rationale behind still having both public
>> key and signature in Segwit witness?
>>
>> As is known for a while, the public key can be derived from the
>> signature and a quadrant byte, a trick that is successfully used both
>> in Bitcoin message signing algorithm and in Ethereum transaction
>> signatures. The later in particular suggests that this is a perfectly
>> functional and secure alternative.
>> Leaving out the public key would have saved 33 bytes per signature,
>> which is quite a lot.
>>
>> So, the question is - was there a good reason to do it the old way
>> (security, performance, privacy, something else?), or was it something
>> that haven't been thought of/considered at the time?
> It is slow to verify, incompatible with batch validation, doesn't save
> space if hashing isn't used, and is potentially patent encumbered.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
|
