From: Luca Venturini <luca@token21•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Token Protocol Specification
Date: Wed, 6 Sep 2017 20:32:47 +0200 [thread overview]
Message-ID: <31863284-d944-b90c-8e62-7d4f38d39476@token21.com> (raw)
In-Reply-To: <E76332FD-4B67-49F2-9E36-8EE66D490193@droplister.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
>
next prev parent reply other threads:[~2017-09-06 18:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-06 15:44 Luca Venturini
[not found] ` <E76332FD-4B67-49F2-9E36-8EE66D490193@droplister.com>
2017-09-06 18:32 ` Luca Venturini [this message]
2017-09-06 18:58 ` Luke Dashjr
2017-09-06 19:25 ` Luca Venturini
2017-09-08 8:06 ` Alex Kravets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31863284-d944-b90c-8e62-7d4f38d39476@token21.com \
--to=luca@token21$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox