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
|
Return-Path: <luca@token21.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EC5C1A7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2017 18:32:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from r2d2.yepa.com (r2d2.yepa.com [54.229.249.165])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 47762480
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2017 18:32:20 +0000 (UTC)
Received: from mago.yepa.com (ec2-54-171-199-73.eu-west-1.compute.amazonaws.com
[54.171.199.73] (may be forged)) (authenticated bits=0)
by r2d2.yepa.com (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id
v86IWHNP002366
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
verify=NOT) for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2017 18:32:19 GMT
Received: from [192.168.43.157] ([94.164.229.50]) (authenticated bits=0)
by mago.yepa.com (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id
v86IW5wY019653 for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2017 20:32:12 +0200
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <a72b52aa-10b5-d256-280b-a72cac3bf92d@token21.com>
<E76332FD-4B67-49F2-9E36-8EE66D490193@droplister.com>
From: Luca Venturini <luca@token21.com>
Organization: Token 21 Inc.
Message-ID: <31863284-d944-b90c-8e62-7d4f38d39476@token21.com>
Date: Wed, 6 Sep 2017 20:32:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <E76332FD-4B67-49F2-9E36-8EE66D490193@droplister.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 06 Sep 2017 18:48:09 +0000
Subject: Re: [bitcoin-dev] [BIP Proposal] Token Protocol Specification
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, 06 Sep 2017 18:32:22 -0000
Hi Dan,
thank you for your feedback. Let me clarify that the plausible
deniability is a property of the protocol. If this will become a BIP,
and will be approved, there will be wallets that will manage tokens. In
the meantime, and in the future, it is important that a person with a
legacy bitcoin wallet can hold, issue and transfer bitcoins without
disclose that there are tokens involved. Tokens are contained in Bitcoin
transactions without any modification.
Vanity addresses are on option. They are not mandatory. In situations
where plausible deniability is a concern they will, probably, not be used.
Sending to someone 0.23000012 bitcoin is really easy. You don't need any
form of math and you are sending exactly 12 tokens from your wallet.
Sometimes it is suspect, but sending 0.03423122 in order to send 23122
tokens does not seem suspect to me. The large majority of the
transactions have strange numbers like this one.
In the document, when I say "wallet" I mean every single bitcoin wallet
that you can use today to hold bitcoins. The base of the plausible
deniability is that there is no "special" wallet involved. Maybe there
will be special wallets to manage tokens, but they are not mandatory.
The consolidation is needed only when using wallets that do not allow
coin selection.
The state of the tokens is fully contained in the bitcoin blockchain.
There is no need for verification nodes, nor for any other software.
Maybe you already issued some tokens using this protocol and I cannot
know it. Unless you disclose it.
There is no "special" need to create small outputs. In order to send a
transaction containing tokens, you need to send a bitcoin transaction.
The bitcoin value will be transfered along with the token value. If you
issue tokens with a token offering transactions (aka ICO), the value of
the bitcoin transferred to you is exactly the price of the tokens, so
there is no "extra" bitcoin value involved.
I'm sorry if the example of the corporation is not clear. The idea was
only that Alice receives from the shareholders the bitcoin value, in
order to use that same value to give back the tokens. There is no
interest. As I wrote, people got equity for "time, money, furniture,
knowledge". I could simply write that Alice sends small outputs without
receiving the underlying bitcoin value beforehand.
I agree that memorable names are great to social scalability. This is
why you can use a vanity address or only the first part of the vanity
address to identify a token type.
Cheers,
Luca
On 09/06/2017 07:24 PM, Dan Anderson wrote:
> Hi Luca,
>
> Here are some comments...
>
> 1. This is clever, but it has a lot of "gotchas" that I think will work against its ability to scale socially. Especially, when you suggest that following the rules by memory/manually gains users the most advantage in terms of deniability.
>
> 2. The plausible deniability of this protocol is suspect as it would seem fairy apparent to a third party that it was being used. Vanity addresses, satoshis adding to tidy amounts, frequent "consolidation". Especially, when you make a mistake and perform actions to try again.
>
> 3. In your docs, when you say "wallet" do you mean a single Bitcoin address or do you mean an HD wallet? I become confused while reading. Address vs same wallet vs other wallet.
>
> 4. It's not clear to me how this protocol does not need verification nodes or some kind of node software to compute state.
>
> 5. I don't think it's a given that this design will cause less UTXOs. I could see people creating many small outputs as a result of trying to get the right amount of signal satoshis.
>
> 6. In your example of a corporation, it seems like people got equity for free. Why do they need to send 1 BTC at all, if they just get it back, plus interest?
>
> 7. I wouldn't underestimate the value of memorable names for social scalability.
>
> I will keep thinking about it, as the ICO portion is something I have been looking for ideas on and I have similar reservations about existing token protocols, so I hope these comments help you.
>
> ---------------------------------
> Dan Anderson
>
|
