path: root/1b/07aec076409b3d607f559c10045761fc7e1fbe

Return-Path: <kravets@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4C7287A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Sep 2017 08:06:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDEB2E7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Sep 2017 08:06:13 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id f199so74506wme.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 08 Sep 2017 01:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=r/GovQN55os/ml1ferUJWu4uO0ClpPQgE4AldAQhrHY=;
	b=iZqlsZL0Ck7pjnJ9eoM3qBiBdT2khGR4JZNc9s1/oiW33h6EfCljmwLjPHOsXNHLQL
	5pJAuUEtvlbSJ9/7+9/GyQqihG/Tc1/OPz3N9FpSyIJFFYr2b20VW4XWSZLz2c3Cnma2
	serfKTl6p3O7h1YdnE3tM3NAgLP8BflkHzyUDtkSQW05/EIpg+e3zezSaOadnOBiXcJm
	17jmm+ajWNmbM3qT42rb11tL5fcV6V2nI40zfuWAQdwtkZ9+1odRSjwaJ2/hEghQHsx8
	7ocLQyGjQ2mUHQUTPKdb+KTyZNBuy+mIRpVaCgFHfKhm2IwRTM6895cEbp5jP5lgnNZh
	yTVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=r/GovQN55os/ml1ferUJWu4uO0ClpPQgE4AldAQhrHY=;
	b=Gyr6Gl20SCg8chhPUawykLBkEak4qrUde/5DXTg3T5cdLWg65xVz4Q+KnFpQ+CE+LT
	9NQFs+IpvDBMJyIQEYC6TLleOwCo3XFmvUvb6Ihu4tfVFJXVDugd/v//b0ArY+AyuZdg
	LZwPdOhkA5HYR1qtyVyUrPAaoSTeFuJtF/3EgMEj9Wbodd1zVNw7P/HS1qwgn4j7OpLu
	IeK74sG0vXv7Uqs24qUuEuKEIEua5966kMUN86EH0SJxmZY3Y7bnhQwJmiUnBNXUgILc
	NhcCNwcfTkDq8GhoeOFPx7iNkrDob+ZVJ+f12fkXC8VQU4Ybwcaz4Sbg5UZxOXdkDyj1
	QHFw==
X-Gm-Message-State: AHPjjUgL5LVQPrK2z0sI7Dx1dsFQa3mQDmzZPotdQngWlPtUCcEYHEhT
	/yDNZGcPqFqhecnf1Kl6b5njD6g6otJJ
X-Google-Smtp-Source: AOwi7QCZ4cFhXfykrwoUorGuOuDRWfiK6ljM2eWA4Q2QtXA38I1jine8AVw0p8udXkIlPsip3O9UqevgukAFXmjS55U=
X-Received: by 10.28.74.89 with SMTP id x86mr983397wma.57.1504857971791; Fri,
	08 Sep 2017 01:06:11 -0700 (PDT)
MIME-Version: 1.0
References: <a72b52aa-10b5-d256-280b-a72cac3bf92d@token21.com>
In-Reply-To: <a72b52aa-10b5-d256-280b-a72cac3bf92d@token21.com>
From: Alex Kravets <kravets@gmail.com>
Date: Fri, 08 Sep 2017 08:06:01 +0000
Message-ID: <CALMbsiJ5_YWfyFcEV19mvKUFazAbrbe0ZABO2PsCvfbu4zv6KA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
	Luca Venturini <luca@token21.com>
Content-Type: multipart/alternative; boundary="001a114e2a38d89e910558a90c35"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM 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: Fri, 08 Sep 2017 15:07:57 +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: Fri, 08 Sep 2017 08:06:19 -0000

--001a114e2a38d89e910558a90c35
Content-Type: text/plain; charset="UTF-8"

Hi Luca,

Bravissimo!

Please allow me to encourage your to follow the BIP workflow as specified
here
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_workflow

BIP Editor freely allocates BIP numberss, however that does not constitute
approval but allows for much easier discussion of and communication about
the proposal.

Good luck !


On Wed, Sep 6, 2017 at 9:08 AM Luca Venturini via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> I would like to propose a standard protocol to manage tokens on top of
> the Bitcoin blockchain.
>
> The full text is enclosed and can be found here:
>
> https://github.com/token21/token-protocol-specification
>
> Any feedback will be appreciated.
>
> Luca Venturini
>
> ---
>
> Abstract
> ========
> This document describes a protocol to manage digital assets (tokens) on
> top of the bitcoin blockchain. The protocol enables a semantic layer
> that permits reading the bitcoin transactions as operations related to
> tokens.
>
> The protocol allows a new level of plausible deniability, while
> permitting statefull public auditability on each issued token. It allows
> both the user and the issuer to deny that an existing bitcoin
> transaction between the two is actually a token transaction, or a new
> token issuance. While both the token sender and the token issuer cannot
> deny to have sent bitcoins, nobody can prove the transaction was related
> to a digital asset. On top of that, to guarantee plausible deniability,
> tokens can be issued, sent, and received using any existing bitcoin
> client software.
>
> There is no need to have a wallet exclusively dedicated to manage the
> tokens. With a few simple precautions by the user, tokens can be managed
> using any existing Bitcoin wallet, while it is used for normal bitcoin
> transactions as well.
>
> Since it is possible to infinitely split a token in parts, there is no
> definition of the number of decimals of token generated and transferred.
> The number of tokens is always an integer.
>
> Every operation of the protocol is performed with Bitcoin transactions,
> without the use of OP_RETURN and without any form of pollution of the
> blockchain, or of the UTXO set.
>
> The protocol permits atomic buy and sell transactions between tokens and
> Bitcoin, and between different types of tokens. The only operations that
> require a coin selection enabled wallet are the split and join special
> operations and the token offering issuance operations. Those are used to
> modify the token unit of measure and to receive bitcoins from third
> parties during a token offering issuance.
>
> Copyright
> =========
> This document is licensed under the 2-clause BSD license.
>
> Motivation
> ==========
> The current protocols that permit to issue tokens based on the bitcoin
> blockchain (i.e. Counterparty, Omni, Colored Coins, Coinprism, Colu) are
> flawed.
>
> The existing solutions usually need dedicated wallets and/or
> verification nodes. Usually, a "pivot" currency is involved and atomic
> transactions are not permitted unless they use the pivot currency. Those
> protocols pollute the blockchain (30% or more) and in some cases they do
> not accept P2SH scripts. Since the use of a dedicated wallet is
> required, the users cannot plausibly deny they have got tokens.
> Plausible deniability on the issuer side is not available either. None
> of these protocols permits infinite division of the tokens, so usually
> the number of decimals has to be specified at issuance time. The
> automatic token offering issuance is not enabled as well.
>
> Rationale
> =========
> Let's take an example from the real world, a yacht. We write on the
> yacht's license that the owner is any person that can show a one dollar
> bill having the serial number F82119977F. Thus the one dollar bill can
> be exchanged between owners with extreme simplicity and full plausible
> deniability. The US government will guarantee that there is no other
> person having the same dollar bill.
>
> The protocol permits managing a token in the same way. The underlying
> Bitcoin protocol will guarantee against double spending.
>
> Features:
>
>   - Easy of use. Tokens can be managed using any wallet. Even if the
> wallet has no coin selection feature.
>   - Plausible Deniability by the issuer. The issuer can generate a new
> type of token and nobody analyzing the blockchain will understand that
> the transaction is issuing a token. Even if a token is known, the issuer
> can issue other tokens. Since a single output contains a large number of
> different token types, the issuer is actually generating different types
> of tokens every time she sends a new Bitcoin transaction to the network.
>   - Plausible Deniability by the user (no use of tokens at all, or use
> of a different token type). A transaction that sends tokens from Alice
> to Bob is a normal transaction. Nobody can understand that this
> transaction is moving tokens unless they explicitly know which
> transaction is the token issuance. In fact a single address contains a
> large number of token types, and the use of tokens itself can be denied.
>   - Accountability. Everybody can see the state of the distribution of a
> type of token.
>   - Tunnel mode (confidentiality by issuer and user versus a third
> party). Alice can send tokens to Bob and ask him to give the tokens to
> Charlie, without telling to Bob what is the type of the token given.
> Alice can disclose this information in the future, if she wants.
>   - It is possible to perform open or closed issuances. While an open
> issuance permits to continue the issuance of tokens in the future,
> closed issuance guarantees that no other token of the same type will
> ever be issued.
>   - The power to continue the issuance of an open token can be sent to
> another address, using a transaction. Once the power to continue the
> issuance is sent to someone, the former issuer cannot issue any more
> tokens.
>   - The power to continue the issuance has the same features of
> plausible deniability of the possess of a token.
>   - Since a token type is uniquely identified by a transaction hash, or,
> in some cases, by a Bitcoin address, a user can prove to be the issuer
> by signing a message using the Bitcoin protocol.
>   - Future proof. Tokens can move following P2PKH, P2SH, P2SH-P2WPKH
> outputs or any other type of script
>   - Blockchain pollution of the protocol transactions is almost zero.
> There is no OP_RETURN involved, nor any other type of "fake" addresses
> that pollute the UTXO database.
>   - The protocol is based on the Bitcoin blockchain, but, with small
> changes, can be considered blockchain agnostic.
>   - Atomic transactions between tokens and Bitcoin are possible.
>   - Atomic transactions between different types of tokens are possible.
>   - Tokens of different types can be held by the same address and by the
> same output.
>   - Tokens can be divided indefintely, thus having any number of decimals.
>   - Tokens can be issued automatically on the receiving of bitcoins.
> This operation performs a token offering issuance (also known as Initial
> Coin Offering).
>
> Introduction
> ============
>
> Where are the tokens?
> ---------------------
> As with bitcoins, tokens are contained in unspent Bitcoin outputs. In
> some cases, defined below, the last five digits of the satoshi value
> sent to the output represent the number of tokens contained in the output.
>
> When an output is spent, the tokens contained in the output are fully
> spent in the same transaction. There are no tokens outside of the tokens
> contained in the UTXO database.
>
> Token issuance
> --------------
> The large majority of bitcoin transactions can be semantically seen as
> token issuances. There are two types of token issuances: closed and
> opened. A closed token issuance guarantees that no other token of the
> same type will ever be issued.
>
> Issuance chains
> ---------------
> An open issuance gives to one, or more, of its output the power to
> continue the issuance of tokens of the same type. We define such a power
> as Power of Continuation (POC). The transaction that will spend the
> output appointed with the POC will be a continuation of the same
> issuance chain.
>
> Every transaction of the chain will issue the same type of token. On top
> of that, every transaction that is part of the chain, can also be seen
> as as issuance of tokens of its, new, type. A chain will be closed by a
> transaction having more than one output and the first output with five
> zeros as the last five digits of the satoshis value. No other
> transactions can send tokens of the same type after the close of the
> issuance.
>
> Token names
> -----------
> A token type can have multiple names. The default name is the hash of
> the first transaction that issued the token.
>
> i.e: 68330b6ab26e44f9c3e515f04d15ffe6547f29e60b809a47e50d9abf59045c1e
>
> As alternative names, a token type can be named after the bitcoin
> address of one of the outputs of the transaction that first issued the
> token, provided the fact that the address has never been used before in
> the blockchain.
>
> Note: it is better to use one of the alternate names in cases when
> transaction malleability is a concern.
>
> Vanity token names
> ------------------
> A token can be identified using only the first characters of the Bitcoin
> address, as alternate name defined above, if the characters are
> different from every previous Bitcoin address seen in the blockchain. An
> example is provided below.
>
> Tokens can coexist
> -------------------
> Token of different types can coexist in a single output while remaining
> of different types. Thus a bitcoin address (actually an output of the
> UTXO database) can hold tokens of different types. Every Bitcoin address
> contains a lot of types of tokens, so that a user usually does not know
> all the type of tokens contained in an address.
>
> A single transaction can send a type of token to some of the outputs
> while sending another type of token to a different set of its outputs.
> Tokens are never burned or deleted.
>
> Use the protocol
> ================
> This section explains a basic use case. In all the examples provided, we
> do not consider the fee. We assume that there is another input, not
> listed, that pays the transaction fee.
>
> Alice, Bob, Charlie, and Daniel decides that they want to start a new
> company. Each of them will give to the new company some time, money,
> furniture, knowledge. They decide everyone contributed to the company
> with a percentage of value as follows: Alice - 40%, Bob - 12%, Charlie -
> 34% and Daniel - 14%. They decide that the shares of the new company can
> be freely resold to others and that they will accept that the annual
> meeting will consent vote through messages signed using the Bitcoin
> protocol by the owners of the shares.
>
> Issue tokens
> ------------
> Alice asks Bob, Charlie, and Daniel to send her 1 Bitcoin each. She asks
> each of them to give her a bitcoin address where they want to receive
> back the bitcoins along with the tokens.
>
> She asks Charlie to generate a vanity address that has never been used
> before of type 1CompanyXWXjLgud9jxwxm34u.... Since there has been a
> previous address in the blockchain having 1Companx as the first
> characters, but this is the first address seen in the blockchain that
> has 1Company as the first characters, they will call the token with the
> name 1Company. This step is optional.
>
> Then she sends, from her wallet, a transaction having the following
> outputs:
>
>   - 1.00000040 to an address controlled by Alice
>   - 1.00000012 to an address controlled by Bob
>   - 1.00000034 to the vanity address 1CompanyXWXjLgud9jxwxm34u...
> controlled by Charlie
>   - 1.00000014 to an address controlled by Daniel
>   - 3.45322112 is the change generated by Alice's wallet
>
> This transaction gives 40, 12, 34, 14 tokens to each one. The newly
> generated token type can be named after the transaction hash, or after
> the vanity address (optional), or after one of the addresses of the
> persons involved, provided that the address has never been used before.
>
> The issuance is still open. Since they do not want to issue more shares,
> they decide to close the issuance (on the other side, they could decide
> to leave the issuance open and to hold the issuing key somewhere, or to
> have a multisignature address and to give the keys to the directors of
> the company). In order to close the issuance, Alice generates the
> following transaction that sends bitcoins from her wallet to addresses
> of her same wallet, using the change output of the previous transaction
> as an input:
>
>   - 0.45000000 to an address of her wallet
>   - 3.00322112 change generated by the wallet
>
> This closes the issuance.
>
> Send tokens
> --------------
> After some while, Bob decides to give some shares of the company to his
> husband Giacomo. He generates a new transaction spending the output of
> the issuance transaction:
>
>   - 0.03400008 to Giacomo
>   - 0.96600004 change generated by Bob's wallet
>
> This transaction gives to Giacomo 8 shares of the company.
>
> Atomic transactions
> -------------------
> Daniel wants to sell 3 of his 14 shares to Frank. They negotiate a price
> of 0.00323200 bitcoin per share. This is a total of 0.00969600 bitcoin
> to buy the three shares. They do not know each other very well, so they
> decide to make an atomic transaction that will give 0.00969600 bitcoins
> to Daniel and 3 shares to Frank. Daniel set an input of the new
> transaction with his issuance transaction output. Frank put in another
> input of 1.23242454 bitcoins from his wallet. The outputs of the
> transaction are as follows:
>
>   - 0.22400003 to an address controlled by Frank (this gives the 3
> shares to Frank)
>   - 0.23200000 to an address controlled by Daniel (this is part of the
> payment to Daniel)
>   - 0.77769614 to an address controlled by Daniel (this can be
> considered the change of the original issuance output of 1.00000014)
>   - 0.99872851 to an address controlled by Frank (change to Frank)
>
> Daniel sent to the inputs of the transaction 1.00000014 bitcoins and
> receives back 1.00969614. This gives to Daniel the 0.00969600 paid by
> Frank. On the other side, Frank sends 1.23242454 as an input of the
> transaction and receives back 1.22272854 bitcoins, thus paying exactly
> the 0.00969600 that needs to be paid to Daniel. This transaction sends 3
> tokens from Daniel to Frank. Another 11 tokens are the tokens that are
> given as a change to Daniel, along with 0.23200000 bitcoins.
>
> Specification
> =============
>
> Definitions
> -----------
> In order to evaluate a transaction, the outputs are sorted by the
> satoshis value. Once sorted, we define a "cut" output the first output
> having five zeros as the last five digits of the satoshi value (satoshis
> modulo 10^5 == 0). In the following, "first", "second", "last" are all
> referred to the sorted outputs.
>
> We define as "signal" of an output the value of satoshis of the output
> modulo 10^5. This is the last five digits of the value, as expressed in
> satoshis.
>
> Despite not mandatory, we sometimes call "c", or "change", the output
> having the biggest value in Satoshi. This is the last output, as sorted
> above. Such behavior follows the "Guidelines" section, explained below.
>
> We use n=0 related to a sequence a1, ..., an, to indicate that there are
> no elements in the sequence.
>
> Issuance of a token
> -------------------
> A transaction that has only one output, or has the first output that is
> a cut, issues no token. Every other Bitcoin transaction is an issuance
> of tokens of the type of the transaction.
>
> When a issuance is open, Power of Continuation (POC), will be given to
> an output that will be spent in a transaction that continues the
> issuance of the same type of tokens.
>
> As for the protocol behavior, we divide the structure of the sorted
> outputs of a bitcoin transaction in the following groups. For each
> group, a description of the behavior of the protocol is provided.
>
>   - a1, ..., an, cut(POC), z1(POC), ... zm(POC), b1, ..., bl, with n>0,
> m>=0, m+l>0
>       * zi are outputs signaling zero. They are optional.
>       * This is an open issuance. It generates the number of tokens
> signaled by the outputs before the cut: a1, ..., an. Every output of
> that set receives a number of tokens as signaled by the output satoshis'
> value.
>       * The cut output, and every other output zi, signaling zero, that
> is directly after the cut, receive the POC. This means that the
> transactions that will spend the POC will be a continuation of this
> issuance and a continuation of every issuance that gave the POC to the
> this transaction.
>   - cut, b1, ..., bm with m>0 (a cut alone is a case of the fourth type)
>       * This is a particular case of the first group, having n=0 and
> m=0. This transaction *closes the issuance forever*. Every token's chain
> that ends into this transaction is closed as well.
>       * It generates no tokens and there are no other outputs that can
> continue the issuance in the future.
>       * If b1 or b2 have a signal of zero and m>2, this is a token
> offering issuance transaction. It will be described in a following section.
>   - a1, ..., an, c(POC) with n>0
>       * This is an open issuance. It generates the number of tokens that
> are signaled in a1, ..., an. The last output c will not receive tokens.
>       * The last output c will receive the POC. A following transaction
> that spends the output c is an issuance transaction of the same type of
> token.
>       * The fact that c is a cut (or not) does not modify the behavior
> of the transactions of this group
>   - c(POC) (single output, also seen as the previous one, with n=0)
>       * This transaction generates no tokens at all.
>       * The output c receives the POC. Thus a following transaction that
> spends the output c is an issuance transaction of the same type of token.
>
> Notes on token issuances
> ------------------------
> The number of tokens generated by an issuance transaction is always the
> sum of the signals of all the outputs, excluding the last one and the
> outputs that are listed after a cut. Thus the number of tokens sent to
> each output, that receives tokens, is always the number signaled by the
> output.
>
> Who has the power to generate other tokens of the same issuance (POC):
>
>   - If there is no cut, the issuance is open and the transaction that
> will spend the last (biggest) output can continue to generate token of
> the same type.
>   - If there is a cut, in a position different than the first, the
> issuance is open. The cut output will be the input of a following
> transaction that issues more tokens of the same issuance chain. The
> following transaction can close tha chain, or can be an open issuance,
> thus having another output that will continue the generation chain.
>
> In order to close forever the issuance of tokens, the transaction should
> have a cut as the first output and have more than one output.
>
> Transfer of tokens
> ------------------
> Every bitcoin transaction spends all the tokens' content of the inputs
> and sends them to the outputs. Some of the outputs receive the number of
> tokens exactly stated in the last five digits of the satoshis sent (the
> signal), in a way similar to an issuance transaction.
>
> A transaction can be seen as having one of the three following shapes
> (ai means an output that is not a cut, bi and c are outputs that can be
> cut):
>
>   - a1, ..., an, cut, b1, ..., bm, c (transactions with a cut) (n=0 is
> described here)
>       * No output (bi) after a cut receives tokens.
>       * Tokens will be assigned to outputs a1, ..., an trying to follow
> the signal as follows:
>           - If there are enough tokens, the tokens signaled by the first
> output are assigned to that output.
>           - If there are still remaining tokens, the tokens are sent to
> the following output based on the signal.
>           - This continues until there is a cut or the tokens signaled
> by an output are more than the remaining tokens. In these cases:
>               * If there is a cut, it receives all the remaining tokens.
>               * If there is an output receiving more tokens than the
> remaining tokens (we define it a "remaining error"), the output receives
> no token at all. No other output will receive tokens after this and all
> the remaining tokens will be sent to the last output c (thus, if there
> is a cut in the transaction, the algorithm "jumps" the cut).
>               * If there is a "remaining error" and the transaction is a
> special transaction as defined in the next section, and the number of
> tokens in input is exactly the same of the two types (big and small)
> that are the result of a previous split or join special transaction, the
> "remaining error" output gets one of the smallest tokens involved. This
> will be better explained in the following section about "special
> transactions".
>       * If the first output is a cut, and the transaction is not a
> special one as defined below in the document, the last output (c)
> receives all the tokens
>   - a1, ..., an, c (ai is not a cut, for every i; c can be a cut)
>       * The tokens are assigned to a1, ..., an as described in the
> previous group.
>       * The last output c receives all the remaining tokens. This
> behavior is not modified by the fact that the last output is a cut.
>   - c (single output transaction, also seen as the previous one, with n=0)
>       * The output receives all the tokens received from the inputs
>
> Transactions receiving both the POC of an issuance and some tokens of
> the same issuance
>
> ---------------------------------------------------------------------------------------
> The protocol is designed such that a transaction of an issuance chain
> never issue new tokens to an output, that receives the POC of the same
> type of token. But two different inputs can give to a transaction both
> some tokens and the POC of the same type of token. In this case, there
> is a double role for the transaction that is both a continuation of the
> issuance and a transfer transaction sending tokens of the same type.
>
> In this case, the tokens will be allocated as defined in the following
> four different shapes of transaction:
>
>   - a1, ..., an, cut, b1, ..., bm, c (transaction with a cut)
>       * The generated tokens are sent to the outputs a1, ..., an as
> described in the definition of an issuance of tokens
>       * All the tokens received in input of the same type of the
> issuance we are continuing will be sent to the cut output
>   - a1, ..., an, c (transaction without a cut, or with c that is a cut:
> ai is not a cut, for every i)
>       * The generated tokens are sent to the outputs a1, ..., an as
> described in the definition of an issuance of tokens transaction
>       * All the tokens received in input, of the same type of the
> issuance we are continuing, will be sent to the last output c
>   - cut, b1, ..., bm
>       * The issuance will be closed and all the tokens will be given to
> the last output bm. The behavior described in the issuance transaction
> and in the transaction sending tokens do not influence each other, in
> this case.
>       * If it is a special transaction, as defined below, there is no
> overlap between the definitions. The issuance chain is closed and the
> received tokens will be given as defined.
>   - c only
>       * The definitions of issuance transaction and transfer transaction
> can be used. The issuance will remain open and the address will receive
> all the tokens received from the inputs
>
> Since both the first and the second group of transactions are giving the
> POC to the same output that receives the tokens, the output will
> continue to carry both the tokens received and the POC. This delegates
> someone to issue new tokens and allocates some tokens from a previous
> issuance that are still not assigned.
>
> Split and join transactions
> ---------------------------
> A split or join transaction is one that has one of the following formats
> of outputs:
>
>   - cut, a1, ..., an, z, b1, ..., bm (z is an output signaling zero,
> like a cut)
>   - cut, a1, ..., an, c
>
> having the added condition that the sum of the signals of the outputs
> a1, ..., an is:
>
>   - equal to the number of tokens received in input divided by 1000 (we
> call it a join transaction), or
>   - equal to the number of tokens received in input multiplied by 1000
> (we call it a split transaction)
>
> Since the presence of these two extra conditions, the fact that a
> transaction is a join or split transaction, or it is not (hence it is a
> simple transfer transaction), depends on the number of tokens received
> in the input. A given transaction can be both split or join for some
> type of tokens, and normal for other types of tokens.
>
> Note: this is the same format that closes an issuance chain. If the
> transaction receives both POC and tokens of the same type, the
> transaction chain will be closed and the received tokens will be sent as
> described here.
>
> Note: this is also the format of a transfer transaction that assigns to
> the change c or bm, the token received in the input. But, if a
> transaction is a special one of the first two types, that behavior
> should not be considered and no tokens will be transferred to the change.
>
> The split transaction generates a new type of tokens with a value that
> is one thousandth of the value of the type of tokens received in the
> input. This new type can be mixed with tokens generated by other similar
> split transactions, based on the same original token. Split tokens have
> the same value and can be joined in the future with join transactions.
>
> The join transaction generates a new type of tokens with one thousand
> times the value of the type of tokens received in the input. This new
> type of token can coexist with tokens generated by other similar join
> transactions, based on the same original token. Joined tokens from the
> same original token, have the same value and can be split in the future
> with split transactions. Thus becoming again original tokens.
>
> In a special transaction of the second group, without "the second cut"
> z, the change is mandatory and does not receive tokens. This means that
> the number of tokens sent is summed up without the last output. If the
> number is not correct, then it is not a split or join transaction.
>
> Tokens split or joined are of a different type than their original
> source. This means that they can coexist in the same output and will
> never mix together. Thus a output having 3 big tokens and 456 tokens
> obtained by a split transaction, seems to have 3.456 tokens, but, in
> fact, has 3 tokens of a type and 456 tokens of another type (the second
> type is referred as the original type with a 0.001 unit of measure).
>
> Note: as described below, there is a procedure of separating tokens of
> different types contained in the same output. This procedure will not
> work if the two type of tokens are present in the same output in the
> same number. Thus if an output contains exactly 3.003 tokens (3 big and
> 3 small), the tokens cannot be separated anymore. This is why we
> introduced, in the transfer transaction definition, the rule that
> assigns in this case one single token of the smallest type to the
> "remaining error" output.
>
> Token offering issuance transactions
> ------------------------------------
> A token offering issuance transaction is a transaction having one of the
> following formats (z is an output signaling zero, like a cut; r and s
> are outputs that signal a value greater than zero; the group of outputs
> (t1, t2, z) is optional; t1 or t2 can signal zero, but not both):
>
>   - cut, z, r, (t1, t2, z,) a1, ..., an, c
>       * price of tokens are predefined
>   - cut, s, z, (t1, t2, z,) a1, ..., an, c
>       * price of tokens are not predefined
>
> The tokens will be assigned to one of the outputs of every transaction
> that sends bitcoin to the address of the outputs r or s, as follows:
>   - if the sending transaction has only two outputs (r, c), (c, r), (s,
> c) or (c, s), the "other" output c receives the tokens.
>   - if the sending transaction has more than two outputs, the last
> (biggest) output that is not the one sending bitcoins to r or s, will
> receive the tokens.
>   - if the sending transaction has only one output, the generated tokens
> will be assigned to the output r or s itself. This can be considered as
> a donation: it generates tokens, but the tokens remain in the
> availability of the issuer.
>   - since the number of token emitted is always an integer, the
> remaining satoshis are not considered in the number of tokens issued and
> are sent to the issuer without any token generation.
>
> Note: this is the second place, in this document, where the bitcoin
> address of an output is used. The other place regards the alternate
> names of an issuance. Everything else in the protocol is based on
> outputs, not addresses.
>
> If the group (t1, t2, z) is present, it signals how many token will be
> issued. The total number of tokens that will be issued is the number
> signaled by t1 * 10^6 + the number signaled by t2. In any block, the
> issuance can be closed by the transaction that spends the outputs r or s.
>
> Timeline:
>   - The offer starts in the block that contains the token offering
> issuance transaction. Every transaction of the starting block receives
> tokens, without order.
>   - If there is a defined total number of tokens, the issuance will end
> when the total number of tokens has been reached.
>       * Inside the last block, the transactions are considered in the
> order they are listed. So if a transaction takes the last tokens, every
> other transaction sending bitcoins to r or s, do not receive tokens.
>   - The transaction that spends the outputs r or s ends the issuance.
> This transaction suspends the issuance even if a defined number of
> tokens was defined in the token offering issuance transaction.
>       * In case of an issuance suspeded, or ended, by a transaction
> spending r or s, every transaction of the block containing the spending
> transaction will be considered valid as a receiver of tokens.
>       * Thus, sending bitcoins to the address of the outputs r or s will
> be considered as part of the offering, only if it is included in a block
> between the block of the transaction that has r or s as an output
> (start), and the block of the transaction that spends the output r or s
> (end), inclusive.
>
> A token offering issuance transaction of the first type permits to set a
> rate, and to issue tokens every time bitcoins are received by an
> address. The rate is defined by the number signaled by the output r. One
> token will be issued for every r satoshis received.
>
> A token offering issuance transaction of the second type does not set a
> predefined rate at the start. The rate will be defined by the
> transaction that closes the issuance by spending the output s. The first
> (smallest) output of the closing transaction, or the first output after
> the cut (if a cut is present), will signal the rate. This type of token
> offering issuance, having the price defined at the end, permits to issue
> token based on parameters related to the issuance itself. This is the
> case, for example, of Dutch Auctions.
>
> Note: A token offering issuance transaction can be seen as a transfer
> transaction, that sends all the tokens that receives to the output c.
>
> Note: the type of token issued is defined by the token offering issuance
> transaction, seen as an issuance transaction. Since a token offering
> transaction is also the closure of some issuing chains, this means that
> the same token offer will issue different type of tokens. In fact, a
> different type of token will be issued for every issuance chain that
> ends with the same token offering issuance transaction. Thus a token
> type can be first issued in a controlled way (this is usually called
> pre-ICO) and then the rate can be stated, and the same type of token can
> be offered to the public (this is usually called the ICO). Since the
> token offering issuance transaction closes the issuance forever, there
> is the guarantee that no other tokens of the same type will ever be
> issued after the offer is closed. In order to offer tokens at different
> prices, multiple issuance transactions can be generated with POCs
> originating from the same issuance chain.
>
> Atomic transactions between bitcoins and tokens
> -----------------------------------------------
> Using the cut signal and software that allows full "coin selection",
> it's possible to make atomic exchange transactions. The outputs before
> the cut will determine who will receive the tokens and the following
> outputs will define the rest of the transaction. Both the changes (the
> one of the token wallet and the one of the Bitcoin wallet), should be in
> the second set (after the cut). Since the cut will receive the remaining
> tokens, it is suggested that the cut is sent to the seller of tokens.
> Using this method, the remaining tokens can be sent without involving a
> calculation of the remaining tokens. The outputs of an atomic exchange
> transaction will have the following format (seller is the token seller,
> buyer is the token buyer).
>
>   - a1: tokens sent from the seller to the buyer
>   - a2: tokens sent from the seller to the buyer
>   - cut: part of the bitcoin payment sent from buyer to seller
>   - b1: part of the bitcoin payment sent from buyer to seller (or change
> sent from seller to buyer, if the price to be paid is less than the
> value of the cut)
>   - b2: Bitcoin change sent to the token wallet
>   - b3: Bitcoin change sent to the bitcoin wallet
>
> It is impossible to make an atomic exchange transaction if the wallet in
> use does not allow coin selection.
>
> Cross token atomic transactions
> -------------------------------
> Let's say that Alice wants to sell a number x of tokens of type Ta and
> Bob wants to pay using y tokens of type Tb. Token of type Tb are of
> lesser value than the tokens of type Ta, so Bob will pay more Tb tokens
> and Alice will pay fewer Ta tokens (x < y). Let's say that the
> transaction spends an output from Alice containing BTCa bitcoins and
> *exactly* x tokens, while Bob sends to the same transaction BTCb
> bitcoins and a number z of tokens of type Tb. Since z > y, Bob will
> receive a change c in tokens of type Tb.
>
> Alice managed the previous transactions so that a fixed number x of
> tokens can be sent as the input with a number BTCa of bitcoins. Bob is
> not required do the same, because there is the cut that gives the
> remaining tokens back to Bob. In order to simplify let's say that there
> is another input giving the fee for the transaction and the Bitcoin
> assigned to each output will be calculated accordingly.
>
> The atomic transaction can be made by signaling with the first output
> the number y of tokens that Bob should pay to Alice. This output will go
> to Alice. Since y is higher than x, all the x tokens of type Ta will go
> to the change (directed to Bob), while the y tokens of type Tb will go
> to the first output. A following cut can be used to send the change to
> Bob. The addresses following the cut can be used as changes of bitcoins.
>
> The inputs of the transaction will have a content in Bitcoin and tokens
> as follows:
>
>   - Alice will spend an output having BTCa bitcoins and containing
> *exactly* x tokens of type Ta
>   - Bob will spend an output having BTCb bitcoins and containing y + c
> tokens of type Tb
>
> The outputs of the transaction will have the following form:
>
>   - Bitcoin sent: BTCa1; Signal sent: y; Directed to Alice (the output
> gets y tokens of type Tb, but does not get any token of type Ta, because
> x < y)
>   - Bitcoin sent: BTCb1; Signal sent: cut; Directed to Bob (no token of
> type Ta given, but receives c tokens of type Tb)
>   - Bitcoin sent: BTCa - BTCa1; Signal sent: not important; Directed to
> Alice (no token sent, but useful to send a change in Bitcoin to Alice,
> if needed)
>   - Bitcoin sent: BTCb - BTCb1; Signal sent: not important; Directed to
> Bob (this output gets number x tokens of type Ta)
>
> Cross token atomic transactions in the case of the same number of tokens
> to be exchanged
>
> ----------------------------------------------------------------------------------------
> The atomic transactions described above do not work if the value of
> tokens of type Ta is equal to the value of tokens of type Tb. In this
> case, there is no way of doing an atomic exchange.
>
> Let's say that we need to do a transaction between two tokens that have
> the same value: TetherA and TetherB. Let's say that Alice and Bob want
> to change 199 tokens. The atomic transaction cannot be made, but, with a
> small risk, two transactions can be made. The first will be an atomic
> transaction giving 100 tokens of type TetherA from Alice to Bob and
> receiving 99 of type TetherB back, and the second will be 99 to 100.
>
> How to separate different types of token
> ----------------------------------------
> Let's say that an output contains two different types of tokens of
> interest to the user. Is there a way to separate the tokens so that they
> can be sent to different outputs? If the tokens are exactly the same
> number, there is not. If the tokens are two different numbers: x tokens
> of type A and y tokens of type B, then the separation can be done. Since
> the "remaining error" of an output goes to the change, we can send the
> higher value of the two and have the change receive the lower. We assume
> that x < y.
>
> Let's call A1 the output that will receive A and B1 the output that will
> receive the tokens of type B.
>
> The transaction will be similar to the cross token atomic transaction:
>
>   - Signal sent: x (the output gets x tokens of type B, but does not get
> any token of type A, because x < y)
>   - Signal sent: cut (no token of type A given, but receives a change in
> token of type B if the previous signal was less than y)
>   - Other outputs
>   - Signal sent: not important (this output gets number x tokens of type A)
>
> Guidelines
> ==========
> There are some suggestions that, if followed by the user, permit
> managing tokens in a simple manner, without technical knowledge of the
> rest of the protocol, with plausible deniability. This can be done using
> any existing wallet.
>
> The guidelines described here are based on a wallet that will be
> "consolidated". This means that all the outputs of the wallet are linked
> toghether. In some cases, this behavior diminish the level of privacy of
> the user. Thus, it is advised to use a number of different wallets, in
> order to reach the desired level of privacy.
>
> Plausible deniability: how to use a wallet to manage tokens
> -----------------------------------------------------------
> Some of the protocol's operations are designed to be managed using a
> coin selection software, however, any wallet without coin selection can
> be used to generate, send, or receive tokens. The option to use any
> existing Bitcoin wallet is the base of the plausible deniability of the
> protocol. The user can send, receive and generate tokens by using any
> wallet in a way that seems a normal use of the Bitcoin protocol to
> manage bitcoins.
>
> Thus, the guidelines in this section are based on a use of a wallet by a
> user without involving any "coin selection".
>
> In order to send or generate tokens, the user needs to have, at any
> time, only one output in the wallet. Let's call it a "consolidated"
> wallet. In order to consolidate a wallet:
>
>   - Send all the bitcoins contained in the wallet to a new address of
> the same wallet
>
> If the user departs from these guidelines by mistake, he can "fix" his
> wallet and re-consolidate it without losing the tokens contained in the
> wallet. If the wallet is consolidated, it remains consolidated while
> tokens are generated or sent, and while bitcoins from the wallet are
> spent. If bitcoins or tokens are received by any address of the wallet,
> then the wallet needs to be consolidated again.
>
> Issuance of tokens
> ------------------
> In order to generate tokens:
>
>   - Consolidate the wallet if it is not already consolidated.
>   - Send a minority of the bitcoins contained in the wallet to a new
> address (outside of the wallet). The last five digits of the satoshis
> sent are the number of tokens generated.
>   - From the same wallet, other tokens can be generated by sending again
> a number of satoshis, having the last five digits that are the number of
> tokens to issue to the new address.
>   - The value of bitcoins sent should always be less than the bitcoin
> that remains in the wallet
>   - If during the process of generating tokens the wallet receives
> bitcoins, it should be consolidated again before continuing to generate
> tokens.
>   - The type (or name) of tokens will be the txid of the transaction. If
> the transaction sends bitcoin to a new, never used, address, the address
> can be used as the name of the tokens, as well.
>
> In order to give the power to generate new tokens to another person:
>
>   - Send all the Bitcoin content of the wallet to the other person, with
> a single transaction
>
> In order to close an issuance:
>
>   - To close the issuance and guarantee that no other tokens of this
> type will ever be generated again, send to another address of the same
> wallet a number of bitcoins with the last five digits of the satoshis
> that is zero. Be aware that this shouldn't be all the content of the
> wallet. If all the content of the wallet is sent to some address, the
> issuance will not be closed. Instead, this gives to the receiver the
> power to generate new tokens.
>
> Spending bitcoins and not tokens
> --------------------------------
> In order to spend bitcoins from the wallet without sending any tokens,
> the user should spend less than half of the bitcoin value contained in
> the wallet, and:
>
>   - Spend a number of satoshis where the last five digits are all zeros,
>   or
>   - Spend a number of satoshis where the last five digits are a number
> greater than the tokens that are in the wallet,
>
> Transfer of tokens
> ------------------
> In order to send tokens to another person:
>
>   - Consolidate the wallet if it is not already consolidated.
>   - Send a value less than half of the content of the wallet and having
> the number of satoshis where the last five digits are the number of
> tokens that need to be transferred,
>   or
>   - Send all the bitcoins of the wallet (even if the wallet is not
> consolidated).
>
> If the user sends all the content of the wallet to a single address (no
> change), then he's emptying the token content from the wallet, as well.
> All the tokens will go to the address and nothing will remain to the user.
>
> In order to receive tokens from other users:
>
>   - Give to the other person a Bitcoin address of the wallet and ask to
> send tokens as explained above.
>   - If the wallet was empty before of receiving tokens, then it is
> already consolidated. Instead, if the wallet already had some bitcoins,
> then the wallet needs to be consolidated before sending or generating
> tokens.
>
> Effects of the use of these guidelines
> --------------------------------------
> When using the guidelines, the number of tokens sent to the recipient is
> always stated in the last five digits of the satoshis sent. There are
> three exceptions:
>
>   - In a single output transaction, all the tokens of the wallet will be
> sent to the recipient.
>   - In a transaction where the amount of satoshis sent ends with five
> zeros, no tokens are sent.
>   - In a transaction sending more tokens than the number of tokens of
> that type held in the wallet, no tokens are sent.
>
> Technical notes
> ---------------
>   - Sending a number of bitcoins that is greater than half of the
> bitcoins contained in the wallet brings to unpredicted results.
>   - Thus, if there are not enough bitcoins to continue to operate, the
> wallet needs to be "re-charged" by sending some bitcoins to it. By doing
> so, there will be more than one UTXO in the wallet. This departs from
> "consolidated mode" and the wallet needs to be consolidated again.
>   - A consolidated wallet contains only one UTXO.
>   - Every transaction made from a consolidated wallet contains only two
> outputs: one is the address outside of the wallet, and the other is the
> change.
>   - Every transaction spends all the content of the wallet.
>
> Reference Implementation
> ========================
> A reference implementation will be included when the protocol will be
> reviewed and accepted by the community.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
Alex Kravets
@alexkravets <https://twitter.com/alexkravets>

--001a114e2a38d89e910558a90c35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Luca,</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Bravissimo!</div><div dir=3D"auto"><br></div><div dir=3D"auto">Please al=
low me to encourage your to follow the BIP workflow as specified here=C2=A0=
<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#B=
IP_workflow">https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki=
#BIP_workflow</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">BIP Ed=
itor freely allocates BIP numberss, however that does not constitute approv=
al but allows for much easier discussion of and communication about the pro=
posal.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Good luck !</div>=
<div dir=3D"auto"><br></div><div><br><div class=3D"gmail_quote"><div>On Wed=
, Sep 6, 2017 at 9:08 AM Luca Venturini via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br=
>
<br>
I would like to propose a standard protocol to manage tokens on top of<br>
the Bitcoin blockchain.<br>
<br>
The full text is enclosed and can be found here:<br>
<br>
<a href=3D"https://github.com/token21/token-protocol-specification" rel=3D"=
noreferrer" target=3D"_blank">https://github.com/token21/token-protocol-spe=
cification</a><br>
<br>
Any feedback will be appreciated.<br>
<br>
Luca Venturini<br>
<br>
---<br>
<br>
Abstract<br>
=3D=3D=3D=3D=3D=3D=3D=3D<br>
This document describes a protocol to manage digital assets (tokens) on<br>
top of the bitcoin blockchain. The protocol enables a semantic layer<br>
that permits reading the bitcoin transactions as operations related to<br>
tokens.<br>
<br>
The protocol allows a new level of plausible deniability, while<br>
permitting statefull public auditability on each issued token. It allows<br=
>
both the user and the issuer to deny that an existing bitcoin<br>
transaction between the two is actually a token transaction, or a new<br>
token issuance. While both the token sender and the token issuer cannot<br>
deny to have sent bitcoins, nobody can prove the transaction was related<br=
>
to a digital asset. On top of that, to guarantee plausible deniability,<br>
tokens can be issued, sent, and received using any existing bitcoin<br>
client software.<br>
<br>
There is no need to have a wallet exclusively dedicated to manage the<br>
tokens. With a few simple precautions by the user, tokens can be managed<br=
>
using any existing Bitcoin wallet, while it is used for normal bitcoin<br>
transactions as well.<br>
<br>
Since it is possible to infinitely split a token in parts, there is no<br>
definition of the number of decimals of token generated and transferred.<br=
>
The number of tokens is always an integer.<br>
<br>
Every operation of the protocol is performed with Bitcoin transactions,<br>
without the use of OP_RETURN and without any form of pollution of the<br>
blockchain, or of the UTXO set.<br>
<br>
The protocol permits atomic buy and sell transactions between tokens and<br=
>
Bitcoin, and between different types of tokens. The only operations that<br=
>
require a coin selection enabled wallet are the split and join special<br>
operations and the token offering issuance operations. Those are used to<br=
>
modify the token unit of measure and to receive bitcoins from third<br>
parties during a token offering issuance.<br>
<br>
Copyright<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
This document is licensed under the 2-clause BSD license.<br>
<br>
Motivation<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
The current protocols that permit to issue tokens based on the bitcoin<br>
blockchain (i.e. Counterparty, Omni, Colored Coins, Coinprism, Colu) are<br=
>
flawed.<br>
<br>
The existing solutions usually need dedicated wallets and/or<br>
verification nodes. Usually, a &quot;pivot&quot; currency is involved and a=
tomic<br>
transactions are not permitted unless they use the pivot currency. Those<br=
>
protocols pollute the blockchain (30% or more) and in some cases they do<br=
>
not accept P2SH scripts. Since the use of a dedicated wallet is<br>
required, the users cannot plausibly deny they have got tokens.<br>
Plausible deniability on the issuer side is not available either. None<br>
of these protocols permits infinite division of the tokens, so usually<br>
the number of decimals has to be specified at issuance time. The<br>
automatic token offering issuance is not enabled as well.<br>
<br>
Rationale<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
Let&#39;s take an example from the real world, a yacht. We write on the<br>
yacht&#39;s license that the owner is any person that can show a one dollar=
<br>
bill having the serial number F82119977F. Thus the one dollar bill can<br>
be exchanged between owners with extreme simplicity and full plausible<br>
deniability. The US government will guarantee that there is no other<br>
person having the same dollar bill.<br>
<br>
The protocol permits managing a token in the same way. The underlying<br>
Bitcoin protocol will guarantee against double spending.<br>
<br>
Features:<br>
<br>
=C2=A0 - Easy of use. Tokens can be managed using any wallet. Even if the<b=
r>
wallet has no coin selection feature.<br>
=C2=A0 - Plausible Deniability by the issuer. The issuer can generate a new=
<br>
type of token and nobody analyzing the blockchain will understand that<br>
the transaction is issuing a token. Even if a token is known, the issuer<br=
>
can issue other tokens. Since a single output contains a large number of<br=
>
different token types, the issuer is actually generating different types<br=
>
of tokens every time she sends a new Bitcoin transaction to the network.<br=
>
=C2=A0 - Plausible Deniability by the user (no use of tokens at all, or use=
<br>
of a different token type). A transaction that sends tokens from Alice<br>
to Bob is a normal transaction. Nobody can understand that this<br>
transaction is moving tokens unless they explicitly know which<br>
transaction is the token issuance. In fact a single address contains a<br>
large number of token types, and the use of tokens itself can be denied.<br=
>
=C2=A0 - Accountability. Everybody can see the state of the distribution of=
 a<br>
type of token.<br>
=C2=A0 - Tunnel mode (confidentiality by issuer and user versus a third<br>
party). Alice can send tokens to Bob and ask him to give the tokens to<br>
Charlie, without telling to Bob what is the type of the token given.<br>
Alice can disclose this information in the future, if she wants.<br>
=C2=A0 - It is possible to perform open or closed issuances. While an open<=
br>
issuance permits to continue the issuance of tokens in the future,<br>
closed issuance guarantees that no other token of the same type will<br>
ever be issued.<br>
=C2=A0 - The power to continue the issuance of an open token can be sent to=
<br>
another address, using a transaction. Once the power to continue the<br>
issuance is sent to someone, the former issuer cannot issue any more tokens=
.<br>
=C2=A0 - The power to continue the issuance has the same features of<br>
plausible deniability of the possess of a token.<br>
=C2=A0 - Since a token type is uniquely identified by a transaction hash, o=
r,<br>
in some cases, by a Bitcoin address, a user can prove to be the issuer<br>
by signing a message using the Bitcoin protocol.<br>
=C2=A0 - Future proof. Tokens can move following P2PKH, P2SH, P2SH-P2WPKH<b=
r>
outputs or any other type of script<br>
=C2=A0 - Blockchain pollution of the protocol transactions is almost zero.<=
br>
There is no OP_RETURN involved, nor any other type of &quot;fake&quot; addr=
esses<br>
that pollute the UTXO database.<br>
=C2=A0 - The protocol is based on the Bitcoin blockchain, but, with small<b=
r>
changes, can be considered blockchain agnostic.<br>
=C2=A0 - Atomic transactions between tokens and Bitcoin are possible.<br>
=C2=A0 - Atomic transactions between different types of tokens are possible=
.<br>
=C2=A0 - Tokens of different types can be held by the same address and by t=
he<br>
same output.<br>
=C2=A0 - Tokens can be divided indefintely, thus having any number of decim=
als.<br>
=C2=A0 - Tokens can be issued automatically on the receiving of bitcoins.<b=
r>
This operation performs a token offering issuance (also known as Initial<br=
>
Coin Offering).<br>
<br>
Introduction<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Where are the tokens?<br>
---------------------<br>
As with bitcoins, tokens are contained in unspent Bitcoin outputs. In<br>
some cases, defined below, the last five digits of the satoshi value<br>
sent to the output represent the number of tokens contained in the output.<=
br>
<br>
When an output is spent, the tokens contained in the output are fully<br>
spent in the same transaction. There are no tokens outside of the tokens<br=
>
contained in the UTXO database.<br>
<br>
Token issuance<br>
--------------<br>
The large majority of bitcoin transactions can be semantically seen as<br>
token issuances. There are two types of token issuances: closed and<br>
opened. A closed token issuance guarantees that no other token of the<br>
same type will ever be issued.<br>
<br>
Issuance chains<br>
---------------<br>
An open issuance gives to one, or more, of its output the power to<br>
continue the issuance of tokens of the same type. We define such a power<br=
>
as Power of Continuation (POC). The transaction that will spend the<br>
output appointed with the POC will be a continuation of the same<br>
issuance chain.<br>
<br>
Every transaction of the chain will issue the same type of token. On top<br=
>
of that, every transaction that is part of the chain, can also be seen<br>
as as issuance of tokens of its, new, type. A chain will be closed by a<br>
transaction having more than one output and the first output with five<br>
zeros as the last five digits of the satoshis value. No other<br>
transactions can send tokens of the same type after the close of the<br>
issuance.<br>
<br>
Token names<br>
-----------<br>
A token type can have multiple names. The default name is the hash of<br>
the first transaction that issued the token.<br>
<br>
i.e: 68330b6ab26e44f9c3e515f04d15ffe6547f29e60b809a47e50d9abf59045c1e<br>
<br>
As alternative names, a token type can be named after the bitcoin<br>
address of one of the outputs of the transaction that first issued the<br>
token, provided the fact that the address has never been used before in<br>
the blockchain.<br>
<br>
Note: it is better to use one of the alternate names in cases when<br>
transaction malleability is a concern.<br>
<br>
Vanity token names<br>
------------------<br>
A token can be identified using only the first characters of the Bitcoin<br=
>
address, as alternate name defined above, if the characters are<br>
different from every previous Bitcoin address seen in the blockchain. An<br=
>
example is provided below.<br>
<br>
Tokens can coexist<br>
-------------------<br>
Token of different types can coexist in a single output while remaining<br>
of different types. Thus a bitcoin address (actually an output of the<br>
UTXO database) can hold tokens of different types. Every Bitcoin address<br=
>
contains a lot of types of tokens, so that a user usually does not know<br>
all the type of tokens contained in an address.<br>
<br>
A single transaction can send a type of token to some of the outputs<br>
while sending another type of token to a different set of its outputs.<br>
Tokens are never burned or deleted.<br>
<br>
Use the protocol<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
This section explains a basic use case. In all the examples provided, we<br=
>
do not consider the fee. We assume that there is another input, not<br>
listed, that pays the transaction fee.<br>
<br>
Alice, Bob, Charlie, and Daniel decides that they want to start a new<br>
company. Each of them will give to the new company some time, money,<br>
furniture, knowledge. They decide everyone contributed to the company<br>
with a percentage of value as follows: Alice - 40%, Bob - 12%, Charlie -<br=
>
34% and Daniel - 14%. They decide that the shares of the new company can<br=
>
be freely resold to others and that they will accept that the annual<br>
meeting will consent vote through messages signed using the Bitcoin<br>
protocol by the owners of the shares.<br>
<br>
Issue tokens<br>
------------<br>
Alice asks Bob, Charlie, and Daniel to send her 1 Bitcoin each. She asks<br=
>
each of them to give her a bitcoin address where they want to receive<br>
back the bitcoins along with the tokens.<br>
<br>
She asks Charlie to generate a vanity address that has never been used<br>
before of type 1CompanyXWXjLgud9jxwxm34u.... Since there has been a<br>
previous address in the blockchain having 1Companx as the first<br>
characters, but this is the first address seen in the blockchain that<br>
has 1Company as the first characters, they will call the token with the<br>
name 1Company. This step is optional.<br>
<br>
Then she sends, from her wallet, a transaction having the following outputs=
:<br>
<br>
=C2=A0 - 1.00000040 to an address controlled by Alice<br>
=C2=A0 - 1.00000012 to an address controlled by Bob<br>
=C2=A0 - 1.00000034 to the vanity address 1CompanyXWXjLgud9jxwxm34u...<br>
controlled by Charlie<br>
=C2=A0 - 1.00000014 to an address controlled by Daniel<br>
=C2=A0 - 3.45322112 is the change generated by Alice&#39;s wallet<br>
<br>
This transaction gives 40, 12, 34, 14 tokens to each one. The newly<br>
generated token type can be named after the transaction hash, or after<br>
the vanity address (optional), or after one of the addresses of the<br>
persons involved, provided that the address has never been used before.<br>
<br>
The issuance is still open. Since they do not want to issue more shares,<br=
>
they decide to close the issuance (on the other side, they could decide<br>
to leave the issuance open and to hold the issuing key somewhere, or to<br>
have a multisignature address and to give the keys to the directors of<br>
the company). In order to close the issuance, Alice generates the<br>
following transaction that sends bitcoins from her wallet to addresses<br>
of her same wallet, using the change output of the previous transaction<br>
as an input:<br>
<br>
=C2=A0 - 0.45000000 to an address of her wallet<br>
=C2=A0 - 3.00322112 change generated by the wallet<br>
<br>
This closes the issuance.<br>
<br>
Send tokens<br>
--------------<br>
After some while, Bob decides to give some shares of the company to his<br>
husband Giacomo. He generates a new transaction spending the output of<br>
the issuance transaction:<br>
<br>
=C2=A0 - 0.03400008 to Giacomo<br>
=C2=A0 - 0.96600004 change generated by Bob&#39;s wallet<br>
<br>
This transaction gives to Giacomo 8 shares of the company.<br>
<br>
Atomic transactions<br>
-------------------<br>
Daniel wants to sell 3 of his 14 shares to Frank. They negotiate a price<br=
>
of 0.00323200 bitcoin per share. This is a total of 0.00969600 bitcoin<br>
to buy the three shares. They do not know each other very well, so they<br>
decide to make an atomic transaction that will give 0.00969600 bitcoins<br>
to Daniel and 3 shares to Frank. Daniel set an input of the new<br>
transaction with his issuance transaction output. Frank put in another<br>
input of 1.23242454 bitcoins from his wallet. The outputs of the<br>
transaction are as follows:<br>
<br>
=C2=A0 - 0.22400003 to an address controlled by Frank (this gives the 3<br>
shares to Frank)<br>
=C2=A0 - 0.23200000 to an address controlled by Daniel (this is part of the=
<br>
payment to Daniel)<br>
=C2=A0 - 0.77769614 to an address controlled by Daniel (this can be<br>
considered the change of the original issuance output of 1.00000014)<br>
=C2=A0 - 0.99872851 to an address controlled by Frank (change to Frank)<br>
<br>
Daniel sent to the inputs of the transaction 1.00000014 bitcoins and<br>
receives back 1.00969614. This gives to Daniel the 0.00969600 paid by<br>
Frank. On the other side, Frank sends 1.23242454 as an input of the<br>
transaction and receives back 1.22272854 bitcoins, thus paying exactly<br>
the 0.00969600 that needs to be paid to Daniel. This transaction sends 3<br=
>
tokens from Daniel to Frank. Another 11 tokens are the tokens that are<br>
given as a change to Daniel, along with 0.23200000 bitcoins.<br>
<br>
Specification<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Definitions<br>
-----------<br>
In order to evaluate a transaction, the outputs are sorted by the<br>
satoshis value. Once sorted, we define a &quot;cut&quot; output the first o=
utput<br>
having five zeros as the last five digits of the satoshi value (satoshis<br=
>
modulo 10^5 =3D=3D 0). In the following, &quot;first&quot;, &quot;second&qu=
ot;, &quot;last&quot; are all<br>
referred to the sorted outputs.<br>
<br>
We define as &quot;signal&quot; of an output the value of satoshis of the o=
utput<br>
modulo 10^5. This is the last five digits of the value, as expressed in<br>
satoshis.<br>
<br>
Despite not mandatory, we sometimes call &quot;c&quot;, or &quot;change&quo=
t;, the output<br>
having the biggest value in Satoshi. This is the last output, as sorted<br>
above. Such behavior follows the &quot;Guidelines&quot; section, explained =
below.<br>
<br>
We use n=3D0 related to a sequence a1, ..., an, to indicate that there are<=
br>
no elements in the sequence.<br>
<br>
Issuance of a token<br>
-------------------<br>
A transaction that has only one output, or has the first output that is<br>
a cut, issues no token. Every other Bitcoin transaction is an issuance<br>
of tokens of the type of the transaction.<br>
<br>
When a issuance is open, Power of Continuation (POC), will be given to<br>
an output that will be spent in a transaction that continues the<br>
issuance of the same type of tokens.<br>
<br>
As for the protocol behavior, we divide the structure of the sorted<br>
outputs of a bitcoin transaction in the following groups. For each<br>
group, a description of the behavior of the protocol is provided.<br>
<br>
=C2=A0 - a1, ..., an, cut(POC), z1(POC), ... zm(POC), b1, ..., bl, with n&g=
t;0,<br>
m&gt;=3D0, m+l&gt;0<br>
=C2=A0 =C2=A0 =C2=A0 * zi are outputs signaling zero. They are optional.<br=
>
=C2=A0 =C2=A0 =C2=A0 * This is an open issuance. It generates the number of=
 tokens<br>
signaled by the outputs before the cut: a1, ..., an. Every output of<br>
that set receives a number of tokens as signaled by the output satoshis&#39=
;<br>
value.<br>
=C2=A0 =C2=A0 =C2=A0 * The cut output, and every other output zi, signaling=
 zero, that<br>
is directly after the cut, receive the POC. This means that the<br>
transactions that will spend the POC will be a continuation of this<br>
issuance and a continuation of every issuance that gave the POC to the<br>
this transaction.<br>
=C2=A0 - cut, b1, ..., bm with m&gt;0 (a cut alone is a case of the fourth =
type)<br>
=C2=A0 =C2=A0 =C2=A0 * This is a particular case of the first group, having=
 n=3D0 and<br>
m=3D0. This transaction *closes the issuance forever*. Every token&#39;s ch=
ain<br>
that ends into this transaction is closed as well.<br>
=C2=A0 =C2=A0 =C2=A0 * It generates no tokens and there are no other output=
s that can<br>
continue the issuance in the future.<br>
=C2=A0 =C2=A0 =C2=A0 * If b1 or b2 have a signal of zero and m&gt;2, this i=
s a token<br>
offering issuance transaction. It will be described in a following section.=
<br>
=C2=A0 - a1, ..., an, c(POC) with n&gt;0<br>
=C2=A0 =C2=A0 =C2=A0 * This is an open issuance. It generates the number of=
 tokens that<br>
are signaled in a1, ..., an. The last output c will not receive tokens.<br>
=C2=A0 =C2=A0 =C2=A0 * The last output c will receive the POC. A following =
transaction<br>
that spends the output c is an issuance transaction of the same type of<br>
token.<br>
=C2=A0 =C2=A0 =C2=A0 * The fact that c is a cut (or not) does not modify th=
e behavior<br>
of the transactions of this group<br>
=C2=A0 - c(POC) (single output, also seen as the previous one, with n=3D0)<=
br>
=C2=A0 =C2=A0 =C2=A0 * This transaction generates no tokens at all.<br>
=C2=A0 =C2=A0 =C2=A0 * The output c receives the POC. Thus a following tran=
saction that<br>
spends the output c is an issuance transaction of the same type of token.<b=
r>
<br>
Notes on token issuances<br>
------------------------<br>
The number of tokens generated by an issuance transaction is always the<br>
sum of the signals of all the outputs, excluding the last one and the<br>
outputs that are listed after a cut. Thus the number of tokens sent to<br>
each output, that receives tokens, is always the number signaled by the<br>
output.<br>
<br>
Who has the power to generate other tokens of the same issuance (POC):<br>
<br>
=C2=A0 - If there is no cut, the issuance is open and the transaction that<=
br>
will spend the last (biggest) output can continue to generate token of<br>
the same type.<br>
=C2=A0 - If there is a cut, in a position different than the first, the<br>
issuance is open. The cut output will be the input of a following<br>
transaction that issues more tokens of the same issuance chain. The<br>
following transaction can close tha chain, or can be an open issuance,<br>
thus having another output that will continue the generation chain.<br>
<br>
In order to close forever the issuance of tokens, the transaction should<br=
>
have a cut as the first output and have more than one output.<br>
<br>
Transfer of tokens<br>
------------------<br>
Every bitcoin transaction spends all the tokens&#39; content of the inputs<=
br>
and sends them to the outputs. Some of the outputs receive the number of<br=
>
tokens exactly stated in the last five digits of the satoshis sent (the<br>
signal), in a way similar to an issuance transaction.<br>
<br>
A transaction can be seen as having one of the three following shapes<br>
(ai means an output that is not a cut, bi and c are outputs that can be<br>
cut):<br>
<br>
=C2=A0 - a1, ..., an, cut, b1, ..., bm, c (transactions with a cut) (n=3D0 =
is<br>
described here)<br>
=C2=A0 =C2=A0 =C2=A0 * No output (bi) after a cut receives tokens.<br>
=C2=A0 =C2=A0 =C2=A0 * Tokens will be assigned to outputs a1, ..., an tryin=
g to follow<br>
the signal as follows:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - If there are enough tokens, the tokens=
 signaled by the first<br>
output are assigned to that output.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - If there are still remaining tokens, t=
he tokens are sent to<br>
the following output based on the signal.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - This continues until there is a cut or=
 the tokens signaled<br>
by an output are more than the remaining tokens. In these cases:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If there is a cut, it re=
ceives all the remaining tokens.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If there is an output re=
ceiving more tokens than the<br>
remaining tokens (we define it a &quot;remaining error&quot;), the output r=
eceives<br>
no token at all. No other output will receive tokens after this and all<br>
the remaining tokens will be sent to the last output c (thus, if there<br>
is a cut in the transaction, the algorithm &quot;jumps&quot; the cut).<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If there is a &quot;rema=
ining error&quot; and the transaction is a<br>
special transaction as defined in the next section, and the number of<br>
tokens in input is exactly the same of the two types (big and small)<br>
that are the result of a previous split or join special transaction, the<br=
>
&quot;remaining error&quot; output gets one of the smallest tokens involved=
. This<br>
will be better explained in the following section about &quot;special<br>
transactions&quot;.<br>
=C2=A0 =C2=A0 =C2=A0 * If the first output is a cut, and the transaction is=
 not a<br>
special one as defined below in the document, the last output (c)<br>
receives all the tokens<br>
=C2=A0 - a1, ..., an, c (ai is not a cut, for every i; c can be a cut)<br>
=C2=A0 =C2=A0 =C2=A0 * The tokens are assigned to a1, ..., an as described =
in the<br>
previous group.<br>
=C2=A0 =C2=A0 =C2=A0 * The last output c receives all the remaining tokens.=
 This<br>
behavior is not modified by the fact that the last output is a cut.<br>
=C2=A0 - c (single output transaction, also seen as the previous one, with =
n=3D0)<br>
=C2=A0 =C2=A0 =C2=A0 * The output receives all the tokens received from the=
 inputs<br>
<br>
Transactions receiving both the POC of an issuance and some tokens of<br>
the same issuance<br>
---------------------------------------------------------------------------=
------------<br>
The protocol is designed such that a transaction of an issuance chain<br>
never issue new tokens to an output, that receives the POC of the same<br>
type of token. But two different inputs can give to a transaction both<br>
some tokens and the POC of the same type of token. In this case, there<br>
is a double role for the transaction that is both a continuation of the<br>
issuance and a transfer transaction sending tokens of the same type.<br>
<br>
In this case, the tokens will be allocated as defined in the following<br>
four different shapes of transaction:<br>
<br>
=C2=A0 - a1, ..., an, cut, b1, ..., bm, c (transaction with a cut)<br>
=C2=A0 =C2=A0 =C2=A0 * The generated tokens are sent to the outputs a1, ...=
, an as<br>
described in the definition of an issuance of tokens<br>
=C2=A0 =C2=A0 =C2=A0 * All the tokens received in input of the same type of=
 the<br>
issuance we are continuing will be sent to the cut output<br>
=C2=A0 - a1, ..., an, c (transaction without a cut, or with c that is a cut=
:<br>
ai is not a cut, for every i)<br>
=C2=A0 =C2=A0 =C2=A0 * The generated tokens are sent to the outputs a1, ...=
, an as<br>
described in the definition of an issuance of tokens transaction<br>
=C2=A0 =C2=A0 =C2=A0 * All the tokens received in input, of the same type o=
f the<br>
issuance we are continuing, will be sent to the last output c<br>
=C2=A0 - cut, b1, ..., bm<br>
=C2=A0 =C2=A0 =C2=A0 * The issuance will be closed and all the tokens will =
be given to<br>
the last output bm. The behavior described in the issuance transaction<br>
and in the transaction sending tokens do not influence each other, in<br>
this case.<br>
=C2=A0 =C2=A0 =C2=A0 * If it is a special transaction, as defined below, th=
ere is no<br>
overlap between the definitions. The issuance chain is closed and the<br>
received tokens will be given as defined.<br>
=C2=A0 - c only<br>
=C2=A0 =C2=A0 =C2=A0 * The definitions of issuance transaction and transfer=
 transaction<br>
can be used. The issuance will remain open and the address will receive<br>
all the tokens received from the inputs<br>
<br>
Since both the first and the second group of transactions are giving the<br=
>
POC to the same output that receives the tokens, the output will<br>
continue to carry both the tokens received and the POC. This delegates<br>
someone to issue new tokens and allocates some tokens from a previous<br>
issuance that are still not assigned.<br>
<br>
Split and join transactions<br>
---------------------------<br>
A split or join transaction is one that has one of the following formats<br=
>
of outputs:<br>
<br>
=C2=A0 - cut, a1, ..., an, z, b1, ..., bm (z is an output signaling zero,<b=
r>
like a cut)<br>
=C2=A0 - cut, a1, ..., an, c<br>
<br>
having the added condition that the sum of the signals of the outputs<br>
a1, ..., an is:<br>
<br>
=C2=A0 - equal to the number of tokens received in input divided by 1000 (w=
e<br>
call it a join transaction), or<br>
=C2=A0 - equal to the number of tokens received in input multiplied by 1000=
<br>
(we call it a split transaction)<br>
<br>
Since the presence of these two extra conditions, the fact that a<br>
transaction is a join or split transaction, or it is not (hence it is a<br>
simple transfer transaction), depends on the number of tokens received<br>
in the input. A given transaction can be both split or join for some<br>
type of tokens, and normal for other types of tokens.<br>
<br>
Note: this is the same format that closes an issuance chain. If the<br>
transaction receives both POC and tokens of the same type, the<br>
transaction chain will be closed and the received tokens will be sent as<br=
>
described here.<br>
<br>
Note: this is also the format of a transfer transaction that assigns to<br>
the change c or bm, the token received in the input. But, if a<br>
transaction is a special one of the first two types, that behavior<br>
should not be considered and no tokens will be transferred to the change.<b=
r>
<br>
The split transaction generates a new type of tokens with a value that<br>
is one thousandth of the value of the type of tokens received in the<br>
input. This new type can be mixed with tokens generated by other similar<br=
>
split transactions, based on the same original token. Split tokens have<br>
the same value and can be joined in the future with join transactions.<br>
<br>
The join transaction generates a new type of tokens with one thousand<br>
times the value of the type of tokens received in the input. This new<br>
type of token can coexist with tokens generated by other similar join<br>
transactions, based on the same original token. Joined tokens from the<br>
same original token, have the same value and can be split in the future<br>
with split transactions. Thus becoming again original tokens.<br>
<br>
In a special transaction of the second group, without &quot;the second cut&=
quot;<br>
z, the change is mandatory and does not receive tokens. This means that<br>
the number of tokens sent is summed up without the last output. If the<br>
number is not correct, then it is not a split or join transaction.<br>
<br>
Tokens split or joined are of a different type than their original<br>
source. This means that they can coexist in the same output and will<br>
never mix together. Thus a output having 3 big tokens and 456 tokens<br>
obtained by a split transaction, seems to have 3.456 tokens, but, in<br>
fact, has 3 tokens of a type and 456 tokens of another type (the second<br>
type is referred as the original type with a 0.001 unit of measure).<br>
<br>
Note: as described below, there is a procedure of separating tokens of<br>
different types contained in the same output. This procedure will not<br>
work if the two type of tokens are present in the same output in the<br>
same number. Thus if an output contains exactly 3.003 tokens (3 big and<br>
3 small), the tokens cannot be separated anymore. This is why we<br>
introduced, in the transfer transaction definition, the rule that<br>
assigns in this case one single token of the smallest type to the<br>
&quot;remaining error&quot; output.<br>
<br>
Token offering issuance transactions<br>
------------------------------------<br>
A token offering issuance transaction is a transaction having one of the<br=
>
following formats (z is an output signaling zero, like a cut; r and s<br>
are outputs that signal a value greater than zero; the group of outputs<br>
(t1, t2, z) is optional; t1 or t2 can signal zero, but not both):<br>
<br>
=C2=A0 - cut, z, r, (t1, t2, z,) a1, ..., an, c<br>
=C2=A0 =C2=A0 =C2=A0 * price of tokens are predefined<br>
=C2=A0 - cut, s, z, (t1, t2, z,) a1, ..., an, c<br>
=C2=A0 =C2=A0 =C2=A0 * price of tokens are not predefined<br>
<br>
The tokens will be assigned to one of the outputs of every transaction<br>
that sends bitcoin to the address of the outputs r or s, as follows:<br>
=C2=A0 - if the sending transaction has only two outputs (r, c), (c, r), (s=
,<br>
c) or (c, s), the &quot;other&quot; output c receives the tokens.<br>
=C2=A0 - if the sending transaction has more than two outputs, the last<br>
(biggest) output that is not the one sending bitcoins to r or s, will<br>
receive the tokens.<br>
=C2=A0 - if the sending transaction has only one output, the generated toke=
ns<br>
will be assigned to the output r or s itself. This can be considered as<br>
a donation: it generates tokens, but the tokens remain in the<br>
availability of the issuer.<br>
=C2=A0 - since the number of token emitted is always an integer, the<br>
remaining satoshis are not considered in the number of tokens issued and<br=
>
are sent to the issuer without any token generation.<br>
<br>
Note: this is the second place, in this document, where the bitcoin<br>
address of an output is used. The other place regards the alternate<br>
names of an issuance. Everything else in the protocol is based on<br>
outputs, not addresses.<br>
<br>
If the group (t1, t2, z) is present, it signals how many token will be<br>
issued. The total number of tokens that will be issued is the number<br>
signaled by t1 * 10^6 + the number signaled by t2. In any block, the<br>
issuance can be closed by the transaction that spends the outputs r or s.<b=
r>
<br>
Timeline:<br>
=C2=A0 - The offer starts in the block that contains the token offering<br>
issuance transaction. Every transaction of the starting block receives<br>
tokens, without order.<br>
=C2=A0 - If there is a defined total number of tokens, the issuance will en=
d<br>
when the total number of tokens has been reached.<br>
=C2=A0 =C2=A0 =C2=A0 * Inside the last block, the transactions are consider=
ed in the<br>
order they are listed. So if a transaction takes the last tokens, every<br>
other transaction sending bitcoins to r or s, do not receive tokens.<br>
=C2=A0 - The transaction that spends the outputs r or s ends the issuance.<=
br>
This transaction suspends the issuance even if a defined number of<br>
tokens was defined in the token offering issuance transaction.<br>
=C2=A0 =C2=A0 =C2=A0 * In case of an issuance suspeded, or ended, by a tran=
saction<br>
spending r or s, every transaction of the block containing the spending<br>
transaction will be considered valid as a receiver of tokens.<br>
=C2=A0 =C2=A0 =C2=A0 * Thus, sending bitcoins to the address of the outputs=
 r or s will<br>
be considered as part of the offering, only if it is included in a block<br=
>
between the block of the transaction that has r or s as an output<br>
(start), and the block of the transaction that spends the output r or s<br>
(end), inclusive.<br>
<br>
A token offering issuance transaction of the first type permits to set a<br=
>
rate, and to issue tokens every time bitcoins are received by an<br>
address. The rate is defined by the number signaled by the output r. One<br=
>
token will be issued for every r satoshis received.<br>
<br>
A token offering issuance transaction of the second type does not set a<br>
predefined rate at the start. The rate will be defined by the<br>
transaction that closes the issuance by spending the output s. The first<br=
>
(smallest) output of the closing transaction, or the first output after<br>
the cut (if a cut is present), will signal the rate. This type of token<br>
offering issuance, having the price defined at the end, permits to issue<br=
>
token based on parameters related to the issuance itself. This is the<br>
case, for example, of Dutch Auctions.<br>
<br>
Note: A token offering issuance transaction can be seen as a transfer<br>
transaction, that sends all the tokens that receives to the output c.<br>
<br>
Note: the type of token issued is defined by the token offering issuance<br=
>
transaction, seen as an issuance transaction. Since a token offering<br>
transaction is also the closure of some issuing chains, this means that<br>
the same token offer will issue different type of tokens. In fact, a<br>
different type of token will be issued for every issuance chain that<br>
ends with the same token offering issuance transaction. Thus a token<br>
type can be first issued in a controlled way (this is usually called<br>
pre-ICO) and then the rate can be stated, and the same type of token can<br=
>
be offered to the public (this is usually called the ICO). Since the<br>
token offering issuance transaction closes the issuance forever, there<br>
is the guarantee that no other tokens of the same type will ever be<br>
issued after the offer is closed. In order to offer tokens at different<br>
prices, multiple issuance transactions can be generated with POCs<br>
originating from the same issuance chain.<br>
<br>
Atomic transactions between bitcoins and tokens<br>
-----------------------------------------------<br>
Using the cut signal and software that allows full &quot;coin selection&quo=
t;,<br>
it&#39;s possible to make atomic exchange transactions. The outputs before<=
br>
the cut will determine who will receive the tokens and the following<br>
outputs will define the rest of the transaction. Both the changes (the<br>
one of the token wallet and the one of the Bitcoin wallet), should be in<br=
>
the second set (after the cut). Since the cut will receive the remaining<br=
>
tokens, it is suggested that the cut is sent to the seller of tokens.<br>
Using this method, the remaining tokens can be sent without involving a<br>
calculation of the remaining tokens. The outputs of an atomic exchange<br>
transaction will have the following format (seller is the token seller,<br>
buyer is the token buyer).<br>
<br>
=C2=A0 - a1: tokens sent from the seller to the buyer<br>
=C2=A0 - a2: tokens sent from the seller to the buyer<br>
=C2=A0 - cut: part of the bitcoin payment sent from buyer to seller<br>
=C2=A0 - b1: part of the bitcoin payment sent from buyer to seller (or chan=
ge<br>
sent from seller to buyer, if the price to be paid is less than the<br>
value of the cut)<br>
=C2=A0 - b2: Bitcoin change sent to the token wallet<br>
=C2=A0 - b3: Bitcoin change sent to the bitcoin wallet<br>
<br>
It is impossible to make an atomic exchange transaction if the wallet in<br=
>
use does not allow coin selection.<br>
<br>
Cross token atomic transactions<br>
-------------------------------<br>
Let&#39;s say that Alice wants to sell a number x of tokens of type Ta and<=
br>
Bob wants to pay using y tokens of type Tb. Token of type Tb are of<br>
lesser value than the tokens of type Ta, so Bob will pay more Tb tokens<br>
and Alice will pay fewer Ta tokens (x &lt; y). Let&#39;s say that the<br>
transaction spends an output from Alice containing BTCa bitcoins and<br>
*exactly* x tokens, while Bob sends to the same transaction BTCb<br>
bitcoins and a number z of tokens of type Tb. Since z &gt; y, Bob will<br>
receive a change c in tokens of type Tb.<br>
<br>
Alice managed the previous transactions so that a fixed number x of<br>
tokens can be sent as the input with a number BTCa of bitcoins. Bob is<br>
not required do the same, because there is the cut that gives the<br>
remaining tokens back to Bob. In order to simplify let&#39;s say that there=
<br>
is another input giving the fee for the transaction and the Bitcoin<br>
assigned to each output will be calculated accordingly.<br>
<br>
The atomic transaction can be made by signaling with the first output<br>
the number y of tokens that Bob should pay to Alice. This output will go<br=
>
to Alice. Since y is higher than x, all the x tokens of type Ta will go<br>
to the change (directed to Bob), while the y tokens of type Tb will go<br>
to the first output. A following cut can be used to send the change to<br>
Bob. The addresses following the cut can be used as changes of bitcoins.<br=
>
<br>
The inputs of the transaction will have a content in Bitcoin and tokens<br>
as follows:<br>
<br>
=C2=A0 - Alice will spend an output having BTCa bitcoins and containing<br>
*exactly* x tokens of type Ta<br>
=C2=A0 - Bob will spend an output having BTCb bitcoins and containing y + c=
<br>
tokens of type Tb<br>
<br>
The outputs of the transaction will have the following form:<br>
<br>
=C2=A0 - Bitcoin sent: BTCa1; Signal sent: y; Directed to Alice (the output=
<br>
gets y tokens of type Tb, but does not get any token of type Ta, because<br=
>
x &lt; y)<br>
=C2=A0 - Bitcoin sent: BTCb1; Signal sent: cut; Directed to Bob (no token o=
f<br>
type Ta given, but receives c tokens of type Tb)<br>
=C2=A0 - Bitcoin sent: BTCa - BTCa1; Signal sent: not important; Directed t=
o<br>
Alice (no token sent, but useful to send a change in Bitcoin to Alice,<br>
if needed)<br>
=C2=A0 - Bitcoin sent: BTCb - BTCb1; Signal sent: not important; Directed t=
o<br>
Bob (this output gets number x tokens of type Ta)<br>
<br>
Cross token atomic transactions in the case of the same number of tokens<br=
>
to be exchanged<br>
---------------------------------------------------------------------------=
-------------<br>
The atomic transactions described above do not work if the value of<br>
tokens of type Ta is equal to the value of tokens of type Tb. In this<br>
case, there is no way of doing an atomic exchange.<br>
<br>
Let&#39;s say that we need to do a transaction between two tokens that have=
<br>
the same value: TetherA and TetherB. Let&#39;s say that Alice and Bob want<=
br>
to change 199 tokens. The atomic transaction cannot be made, but, with a<br=
>
small risk, two transactions can be made. The first will be an atomic<br>
transaction giving 100 tokens of type TetherA from Alice to Bob and<br>
receiving 99 of type TetherB back, and the second will be 99 to 100.<br>
<br>
How to separate different types of token<br>
----------------------------------------<br>
Let&#39;s say that an output contains two different types of tokens of<br>
interest to the user. Is there a way to separate the tokens so that they<br=
>
can be sent to different outputs? If the tokens are exactly the same<br>
number, there is not. If the tokens are two different numbers: x tokens<br>
of type A and y tokens of type B, then the separation can be done. Since<br=
>
the &quot;remaining error&quot; of an output goes to the change, we can sen=
d the<br>
higher value of the two and have the change receive the lower. We assume<br=
>
that x &lt; y.<br>
<br>
Let&#39;s call A1 the output that will receive A and B1 the output that wil=
l<br>
receive the tokens of type B.<br>
<br>
The transaction will be similar to the cross token atomic transaction:<br>
<br>
=C2=A0 - Signal sent: x (the output gets x tokens of type B, but does not g=
et<br>
any token of type A, because x &lt; y)<br>
=C2=A0 - Signal sent: cut (no token of type A given, but receives a change =
in<br>
token of type B if the previous signal was less than y)<br>
=C2=A0 - Other outputs<br>
=C2=A0 - Signal sent: not important (this output gets number x tokens of ty=
pe A)<br>
<br>
Guidelines<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
There are some suggestions that, if followed by the user, permit<br>
managing tokens in a simple manner, without technical knowledge of the<br>
rest of the protocol, with plausible deniability. This can be done using<br=
>
any existing wallet.<br>
<br>
The guidelines described here are based on a wallet that will be<br>
&quot;consolidated&quot;. This means that all the outputs of the wallet are=
 linked<br>
toghether. In some cases, this behavior diminish the level of privacy of<br=
>
the user. Thus, it is advised to use a number of different wallets, in<br>
order to reach the desired level of privacy.<br>
<br>
Plausible deniability: how to use a wallet to manage tokens<br>
-----------------------------------------------------------<br>
Some of the protocol&#39;s operations are designed to be managed using a<br=
>
coin selection software, however, any wallet without coin selection can<br>
be used to generate, send, or receive tokens. The option to use any<br>
existing Bitcoin wallet is the base of the plausible deniability of the<br>
protocol. The user can send, receive and generate tokens by using any<br>
wallet in a way that seems a normal use of the Bitcoin protocol to<br>
manage bitcoins.<br>
<br>
Thus, the guidelines in this section are based on a use of a wallet by a<br=
>
user without involving any &quot;coin selection&quot;.<br>
<br>
In order to send or generate tokens, the user needs to have, at any<br>
time, only one output in the wallet. Let&#39;s call it a &quot;consolidated=
&quot;<br>
wallet. In order to consolidate a wallet:<br>
<br>
=C2=A0 - Send all the bitcoins contained in the wallet to a new address of<=
br>
the same wallet<br>
<br>
If the user departs from these guidelines by mistake, he can &quot;fix&quot=
; his<br>
wallet and re-consolidate it without losing the tokens contained in the<br>
wallet. If the wallet is consolidated, it remains consolidated while<br>
tokens are generated or sent, and while bitcoins from the wallet are<br>
spent. If bitcoins or tokens are received by any address of the wallet,<br>
then the wallet needs to be consolidated again.<br>
<br>
Issuance of tokens<br>
------------------<br>
In order to generate tokens:<br>
<br>
=C2=A0 - Consolidate the wallet if it is not already consolidated.<br>
=C2=A0 - Send a minority of the bitcoins contained in the wallet to a new<b=
r>
address (outside of the wallet). The last five digits of the satoshis<br>
sent are the number of tokens generated.<br>
=C2=A0 - From the same wallet, other tokens can be generated by sending aga=
in<br>
a number of satoshis, having the last five digits that are the number of<br=
>
tokens to issue to the new address.<br>
=C2=A0 - The value of bitcoins sent should always be less than the bitcoin<=
br>
that remains in the wallet<br>
=C2=A0 - If during the process of generating tokens the wallet receives<br>
bitcoins, it should be consolidated again before continuing to generate<br>
tokens.<br>
=C2=A0 - The type (or name) of tokens will be the txid of the transaction. =
If<br>
the transaction sends bitcoin to a new, never used, address, the address<br=
>
can be used as the name of the tokens, as well.<br>
<br>
In order to give the power to generate new tokens to another person:<br>
<br>
=C2=A0 - Send all the Bitcoin content of the wallet to the other person, wi=
th<br>
a single transaction<br>
<br>
In order to close an issuance:<br>
<br>
=C2=A0 - To close the issuance and guarantee that no other tokens of this<b=
r>
type will ever be generated again, send to another address of the same<br>
wallet a number of bitcoins with the last five digits of the satoshis<br>
that is zero. Be aware that this shouldn&#39;t be all the content of the<br=
>
wallet. If all the content of the wallet is sent to some address, the<br>
issuance will not be closed. Instead, this gives to the receiver the<br>
power to generate new tokens.<br>
<br>
Spending bitcoins and not tokens<br>
--------------------------------<br>
In order to spend bitcoins from the wallet without sending any tokens,<br>
the user should spend less than half of the bitcoin value contained in<br>
the wallet, and:<br>
<br>
=C2=A0 - Spend a number of satoshis where the last five digits are all zero=
s,<br>
=C2=A0 or<br>
=C2=A0 - Spend a number of satoshis where the last five digits are a number=
<br>
greater than the tokens that are in the wallet,<br>
<br>
Transfer of tokens<br>
------------------<br>
In order to send tokens to another person:<br>
<br>
=C2=A0 - Consolidate the wallet if it is not already consolidated.<br>
=C2=A0 - Send a value less than half of the content of the wallet and havin=
g<br>
the number of satoshis where the last five digits are the number of<br>
tokens that need to be transferred,<br>
=C2=A0 or<br>
=C2=A0 - Send all the bitcoins of the wallet (even if the wallet is not<br>
consolidated).<br>
<br>
If the user sends all the content of the wallet to a single address (no<br>
change), then he&#39;s emptying the token content from the wallet, as well.=
<br>
All the tokens will go to the address and nothing will remain to the user.<=
br>
<br>
In order to receive tokens from other users:<br>
<br>
=C2=A0 - Give to the other person a Bitcoin address of the wallet and ask t=
o<br>
send tokens as explained above.<br>
=C2=A0 - If the wallet was empty before of receiving tokens, then it is<br>
already consolidated. Instead, if the wallet already had some bitcoins,<br>
then the wallet needs to be consolidated before sending or generating<br>
tokens.<br>
<br>
Effects of the use of these guidelines<br>
--------------------------------------<br>
When using the guidelines, the number of tokens sent to the recipient is<br=
>
always stated in the last five digits of the satoshis sent. There are<br>
three exceptions:<br>
<br>
=C2=A0 - In a single output transaction, all the tokens of the wallet will =
be<br>
sent to the recipient.<br>
=C2=A0 - In a transaction where the amount of satoshis sent ends with five<=
br>
zeros, no tokens are sent.<br>
=C2=A0 - In a transaction sending more tokens than the number of tokens of<=
br>
that type held in the wallet, no tokens are sent.<br>
<br>
Technical notes<br>
---------------<br>
=C2=A0 - Sending a number of bitcoins that is greater than half of the<br>
bitcoins contained in the wallet brings to unpredicted results.<br>
=C2=A0 - Thus, if there are not enough bitcoins to continue to operate, the=
<br>
wallet needs to be &quot;re-charged&quot; by sending some bitcoins to it. B=
y doing<br>
so, there will be more than one UTXO in the wallet. This departs from<br>
&quot;consolidated mode&quot; and the wallet needs to be consolidated again=
.<br>
=C2=A0 - A consolidated wallet contains only one UTXO.<br>
=C2=A0 - Every transaction made from a consolidated wallet contains only tw=
o<br>
outputs: one is the address outside of the wallet, and the other is the<br>
change.<br>
=C2=A0 - Every transaction spends all the content of the wallet.<br>
<br>
Reference Implementation<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br=
>
A reference implementation will be included when the protocol will be<br>
reviewed and accepted by the community.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div><div dir=3D"ltr">-- <br></div><div class=3D"gmail_=
signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><span s=
tyle=3D"font-size:small">Alex Kravets</span><br style=3D"font-size:small"><=
div style=3D"font-size:small"><a href=3D"https://twitter.com/alexkravets" s=
tyle=3D"color:rgb(17,85,204)" target=3D"_blank">@alexkravets</a></div></div=
></div></div>

--001a114e2a38d89e910558a90c35--