Re: [bitcoin-dev] [BIP Proposal] Token Protocol Specification

[Luca Venturini <luca@token21.com>]

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
>