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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C6E9B1006
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 05:14:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 21F2CEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 05:14:14 +0000 (UTC)
Received: from localhost ([::1]:32775 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>) id 1aAsnU-001D4f-VZ
for bitcoin-dev@lists.linuxfoundation.org;
Mon, 21 Dec 2015 00:14:13 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Dec 2015 00:14:12 -0500
From: jl2012 <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <537b176b25a681255eee5f6c4268ab6e@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] =?utf-8?q?A_new_payment_address_format_for_segregat?=
=?utf-8?q?ed_witness_or_not=3F?=
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Mon, 21 Dec 2015 05:14:14 -0000
On the -dev IRC I asked the same question and people seem don't like it.
I would like to further elaborate this topic and would like to consult
merchants, exchanges, wallet devs, and users for their preference
Background:
People will be able to use segregated witness in 2 forms. They either
put the witness program directly as the scriptPubKey, or hide the
witness program in a P2SH address. They are referred as "native SW" and
"SW in P2SH" respectively
Examples could be found in the draft BIP:
https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
As a tx malleability fix, native SW and SW in P2SH are equally good.
The SW in P2SH is better in terms of:
1. It allows payment from any Bitcoin reference client since version
0.6.0.
2. Slightly better privacy by obscuration since people won't know
whether it is a traditional P2SH or a SW tx before it is spent. I don't
consider this is important since the type of tx will be revealed
eventually, and is irrelevant when native SW is more popular
The SW in P2SH is worse in terms of:
1. It requires an additional push in scriptSig, which is not prunable in
transmission, and is counted as part of the core block size
2. It requires an additional HASH160 operation than native SW
3. It provides 160bit security, while native SW provides 256bit
4. Since it is less efficient, the tx fee is likely to be higher than
native SW (but still lower than non-SW tx)
---------------------------
The question: should we have a new payment address format for native SW?
The native SW address in my mind is basically same as existing P2PKH and
P2SH addresses:
BASE58(address_version|witness_program|checksum) , where checksum is the
first 4 bytes of dSHA256(address_version|witness_program)
Why not a better checksum algorithm? Reusing the existing algorithm make
the implementation much easier and safe.
Pros for native SW address:
1. Many people and services are still using BASE58 address
2. Promote the use of native SW which allows lower fee, instead of the
less efficient SW in P2SH
3. Not all wallets and services support payment protocol (BIP70)
4. Easy for wallets to implement
5. Even if a wallet wants to only implement SW in P2SH, they need a new
wallet format anyway. So there is not much exta cost to introduce a new
address format.
6. Since SW is very flexible, this is very likely to be the last address
format to define.
Cons for native SW address:
1. Addresses are bad and should not be used anymore (some arguments
could be found in BIP13)
2. Payment protocol is better
3. With SW in P2SH, it is not necessary to have a new address format
4. Depends on the length of the witness program, the address length
could be a double of the existing address
5. Old wallets won't be able to pay to a new address (but no money could
be lost this way)
------------------------------
So I'd like to suggest 2 proposals:
Proposal 1:
To define a native SW address format, while people can still use payment
protocol or SW in P2SH if the want
Proposal 2:
No new address format is defined. If people want to pay as lowest fee as
possible, they must use payment protocol. Otherwise, they may use SW in
P2SH
Since this topic is more relevant to user experience, in addition to
core devs, I would also like to consult merchants, exchanges, wallet
devs, and users for their preferences.
|
