summaryrefslogtreecommitdiff
path: root/d5/8a7e95bdde099b4bea5f98b77c7f875b8f9a94
blob: 7366b272661bde1cc87bd2773c8d2d5f25960a13 (plain)
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
Return-Path: <nathanw@tutanota.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A0C3AC6A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  2 Apr 2019 16:59:31 +0000 (UTC)
X-Greylist: delayed 00:06:16 by SQLgrey-1.7.6
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8256187
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  2 Apr 2019 16:59:30 +0000 (UTC)
Received: from w2.tutanota.de (unknown [192.168.1.163])
	by w1.tutanota.de (Postfix) with ESMTP id B18EBFA01F9;
	Tue,  2 Apr 2019 16:53:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com;
	s=20161216; t=1554223991;
	bh=hA5AHtf2CoE9gJ7VMEHyNTxJbBFNkp3qSC9Bxj5x+BA=;
	h=Date:From:To:Subject:From;
	b=TzogDLNQBD4Gfj0ko+zoggjZ9qgpJlBnv7m2Ojx7mEEFp4cGmjztI8I/fr6Y3OVw7
	/E7pOx28IyJ4wdX5LBAzAXA3nEjeTgxgkrle6fFDFKbDxYVPzGuZVPgKPGuSuXAbQl
	arV9k2a/7Kz9VSxQ6G3vFyHYRSk5ReNf9vY6gNydudveHB3lM1dE6hpd/V5nRW/Hoq
	da+Pu9P163Ajm5Wo3ID69y5H/tWVzxHR9hKhfrhFtaLQQtxrFoGmLWlRZOcq+nCXXM
	nAboxlowd7Qcu70A45ff0YKYqQy1XTQmQmX3Tw/sI/Aj35+6MyulY3cx/PPDUldQIN
	bNINCQFhzXAig==
Date: Tue, 2 Apr 2019 18:53:11 +0200 (CEST)
From: <nathanw@tutanota.com>
To: <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <LbTxyE4--3-1@tutanota.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_56542_1246574562.1554223991721"
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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
X-Mailman-Approved-At: Tue, 02 Apr 2019 17:06:09 +0000
Subject: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?
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: Tue, 02 Apr 2019 16:59:31 -0000

------=_Part_56542_1246574562.1554223991721
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

To whom it may concern,

I believe a missing feature in Bitcoin is the ability to have an "integrated address", where the address resolves into a Bitcoin address, and also a transaction message or some other kind of identifier.

By having this feature we could enhance the security of exchange cold-wallet systems, by allowing them to easily receive all payments to a single address from an infinite number of customers. We would also greatly simplify the process of setting up and managing exchange cold-wallet systems, because we would eliminate the "sweeping" step required to move multiple customer deposits from a hot address into a single cold address.

Although it would be nice to have all customers deposit directly into cold addresses, this quickly becomes impractical when large amounts of customers begin to use exchange wallets as their personal web-wallet, frequently depositing and withdrawing without trading action. You end up needing to have a staff member moving funds away from cold deposit addresses as a full time job - if you wish to handle customer funds in a completely secure manner.

Thus we see that most exchanges now use the hot-deposit system, where customers deposit into a hot address that is then automatically swept into a singular cold address, by a service which holds customers private keys online. You can observe this service at work simply by making a deposit to most major exchanges (including the largest exchange Binance), as you will see the funds quickly being "swept" to their cold wallet address in a manner which heavily suggests automation by a program which possesses private keys to the address you are sending funds to. This means there is always the danger of a sophisticated hacker being able to capture private keys to customer deposit addresses (as they are clearly being held online). An integrated address would allow all exchanges using this automated hot-deposit service to easily switch to a far more secure alternative of having all customers depositing directly into their singular cold wallet address.

There are several other more minor advantages such a feature would have, including:
- Lower fees for exchanges (which could be passed onto customers), by reducing a transaction step out of the deposit-to-withdrawal flow.
- Less need for large rescans after loading huge amounts of customer addresses into client software.
- Exchanges can more easily provision deposit addresses to new customers in a secure manner, by simply generating a hex or other value, creating an integrated address from the cold wallet address, and then providing this to the customer.
- By providing a singular cold address for exchanges publicly, customers can more easily verify that no man-in-the-middle has given them an incorrect address to deposit to.
The integrated address could work by combining the Bitcoin address together with some kind of hex or other value, allowing users to choose the amount they wish to deposit themselves, but ensuring their deposits are uniquely trackable.

I'm not sure if some kind of functionality already exists in BTC, as I haven't been able to find it. If not, can I submit a proposal to implement this? This feature would be a godsend to all exchange developers if it was widely accepted.

Thanks for your time.
Regards,

Nathan Worsley
CTO - LocalCoinSwap.Com
------=_Part_56542_1246574562.1554223991721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div style=3D"16px" text-align=3D"left">To whom it may concern,<br></div><d=
iv style=3D"16px" text-align=3D"left"><br></div><div style=3D"16px" text-al=
ign=3D"left">I believe a missing feature in Bitcoin is the ability to have =
an "integrated address", where the address resolves into a Bitcoin address,=
 and also a transaction message or some other kind of identifier.<br></div>=
<div style=3D"16px" text-align=3D"left"><br></div><div style=3D"16px" text-=
align=3D"left">By having this feature we could enhance the security of exch=
ange cold-wallet systems, by allowing them to easily receive all payments t=
o a single address from an infinite number of customers. We would also grea=
tly simplify the process of setting up and managing exchange cold-wallet sy=
stems, because we would eliminate the "sweeping" step required to move mult=
iple customer deposits from a hot address into a single cold address.<br></=
div><div style=3D"16px" text-align=3D"left"><br></div><div style=3D"16px" t=
ext-align=3D"left">Although it would be nice to have all customers deposit =
directly into cold addresses, this quickly becomes impractical when large a=
mounts of customers begin to use exchange wallets as their personal web-wal=
let, frequently depositing and withdrawing without trading action. You end =
up needing to have a staff member moving funds away from cold deposit addre=
sses as a full time job - if you wish to handle customer funds in a complet=
ely secure manner.<br></div><div style=3D"16px" text-align=3D"left"><br></d=
iv><div style=3D"16px" text-align=3D"left">Thus we see that most exchanges =
now use the hot-deposit system, where customers deposit into a hot address =
that is then automatically swept into a singular cold address, by a service=
 which holds customers private keys online. You can observe this service at=
 work simply by making a deposit to most major exchanges (including the lar=
gest exchange Binance), as you will see the funds quickly being "swept" to =
their cold wallet address in a manner which heavily suggests automation by =
a program which possesses private keys to the address you are sending funds=
 to. This means there is always the danger of a sophisticated hacker being =
able to capture private keys to customer deposit addresses (as they are cle=
arly being held online). An integrated address would allow all exchanges us=
ing this automated hot-deposit service to easily switch to a far more secur=
e alternative of having all customers depositing directly into their singul=
ar cold wallet address.<br></div><div style=3D"16px" text-align=3D"left"><b=
r></div><div style=3D"16px" text-align=3D"left">There are several other mor=
e minor advantages such a feature would have, including:<br></div><div styl=
e=3D"16px" text-align=3D"left">- Lower fees for exchanges (which could be p=
assed onto customers), by reducing a transaction step out of the deposit-to=
-withdrawal flow.<br></div><div style=3D"16px" text-align=3D"left">- Less n=
eed for large rescans after loading huge amounts of customer addresses into=
 client software.<br></div><div style=3D"16px" text-align=3D"left">- Exchan=
ges can more easily provision deposit addresses to new customers in a secur=
e manner, by simply generating a hex or other value, creating an integrated=
 address from the cold wallet address, and then providing this to the custo=
mer.<br></div><div style=3D"16px" text-align=3D"left">- By providing a sing=
ular cold address for exchanges publicly, customers can more easily verify =
that no man-in-the-middle has given them an incorrect address to deposit to=
.</div><div style=3D"16px" text-align=3D"left"><br></div><div style=3D"16px=
" text-align=3D"left">The integrated address could work by combining the Bi=
tcoin address together with some kind of hex or other value, allowing users=
 to choose the amount they wish to deposit themselves, but ensuring their d=
eposits are uniquely trackable.<br></div><div style=3D"16px" text-align=3D"=
left"><br></div><div style=3D"16px" text-align=3D"left">I'm not sure if som=
e kind of functionality already exists in BTC, as I haven't been able to fi=
nd it. If not, can I submit a proposal to implement this? This feature woul=
d be a godsend to all exchange developers if it was widely accepted.<br></d=
iv><div style=3D"16px" text-align=3D"left"><br></div><div style=3D"16px" te=
xt-align=3D"left">Thanks for your time.</div><div style=3D"16px" text-align=
=3D"left"><br></div><div style=3D"16px" text-align=3D"left">Regards,<br></d=
iv><div><br></div><div>Nathan Worsley<br></div><div style=3D"16px" text-ali=
gn=3D"left">CTO - LocalCoinSwap.Com</div>  </body>
</html>

------=_Part_56542_1246574562.1554223991721--