242 lines
12 KiB
Markdown
242 lines
12 KiB
Markdown
BSIP: 0008
|
|
Title: Privacy (STEALTH) Mode
|
|
Authors: Daniel Larimer <Dan@cryptonomex.com>
|
|
Fabian Schuh <Fabian@BitShares.eu>
|
|
Status: Draft
|
|
Type: Protocol
|
|
Created: 2015-12-16
|
|
Discussion: <https://github.com/cryptonomex/graphene/issues/452>
|
|
<https://bitsharestalk.org/index.php/topic,20104.0.html>
|
|
<https://bitsharestalk.org/index.php/topic,20499.0.html>
|
|
Worker: 1.14.18
|
|
|
|
# Abstract
|
|
|
|
Privacy Mode Transfers (a.k.a. Stealth Transfers) are used to maintain user
|
|
privacy. This feature helps set BitShares apart from most other crypto
|
|
currencies and offers tremendous value to the users who are most interested in
|
|
privacy, liberty, and freedom.
|
|
|
|
In practise they combine the techniques of *blinding signatures* to hide the
|
|
amount of a transfer and *stealth addresses* (similar to TITAN in BitShares 1)
|
|
to hide involved parties.
|
|
|
|
# Specifications
|
|
|
|
This proposal involves creating a new front-end feature on the account page in
|
|
the web wallet to allow users to enter the *privacy mode*. Here, users will be
|
|
able to create *private accounts* which are labeled private keys. They will
|
|
also be able to manage *private contacts* which are labeled public keys. Neither
|
|
private accounts nor private contacts are tracked on the blockchain since those
|
|
keys are not used directly. Instead, each transaction will derive a
|
|
transaction-specific address from the private contact's public key. A off-chain
|
|
memo helps the receiver identify the deposit and derive the corresponding
|
|
transaction-specific private key from the private account.
|
|
|
|
Users will be able to monitor their private balances and take the following
|
|
actions:
|
|
|
|
* Transfer from public account to their own private balance
|
|
* Transfer from one of their private accounts to one of their private contacts
|
|
* Transfer from one of their private accounts to any public account
|
|
* Register a new account using a private balance.
|
|
* Receive a private transfer from a 3rd party given a transfer receipt.
|
|
|
|
These features are already available on the blockchain level using *address
|
|
authorities* and *key authorities* and indicating that a transaction to that
|
|
account has to be made in private.
|
|
|
|
## GUI Mockup
|
|
|
|
The goal of this proposal is to have a front end developed (or integrated into an
|
|
existing web wallet) that allows ordinary people to use the privacy mode without
|
|
further knowledge about the underlying technology. Thus, a proposal for the user
|
|
interface has been drafted and is attached to this proposal as
|
|
[pdf](bsip-0008/gui-mockup.pdf).
|
|
|
|
[slide 1](bsip-0008/gui-mockup-0.png) [slide 2](bsip-0008/gui-mockup-1.png) [slide 3](bsip-0008/gui-mockup-2.png)
|
|
[slide 4](bsip-0008/gui-mockup-3.png) [slide 5](bsip-0008/gui-mockup-4.png) [slide 6](bsip-0008/gui-mockup-5.png)
|
|
[slide 7](bsip-0008/gui-mockup-6.png) [slide 8](bsip-0008/gui-mockup-7.png) [slide 9](bsip-0008/gui-mockup-8.png)
|
|
|
|
This draft has been designed with user experience in mind but may be improved if
|
|
it serves its purpose.
|
|
|
|
# Implementation Aspects
|
|
|
|
## Backup Considerations
|
|
|
|
Because private transfers are not recoverable from blockchain data alone,
|
|
backups of your wallet after receiving a new private transfer are *required*.
|
|
|
|
## Javascript Implementation
|
|
|
|
This proposal will require the use of a JavaScript library to perform the
|
|
necessary crypto operations in the web wallet (see [1]).
|
|
|
|
# Funding
|
|
|
|
BitSharestalk.org forum user `onceuponatime` has proposed to fund the
|
|
development and implementation of this feature in full as a private investor and
|
|
at zero cost to BitShares shareholders.
|
|
|
|
## Contract between `onceuponatime` and Cryptonomex:
|
|
|
|
The purpose of this contract is to develop a Privacy Mode feature, Privacy Mode
|
|
fee accumulation account, Maintenance Account, Initialization Package, and GUI
|
|
interface for BitShares scoped for a firm fixed price of $45K. The following
|
|
requirements apply:
|
|
|
|
1. The Privacy Mode feature shall be implemented as proposed in
|
|
https://github.com/cryptonomex/graphene/issues/452 (as amended).
|
|
2. It shall provide the following fee based services:
|
|
* Transfer from public account to their own private balance
|
|
* Transfer from one of their private accounts to one of their private contacts
|
|
* Transfer from one of their private accounts to any public account
|
|
* Register a new account using a private balance.
|
|
* Receive a private transfer from a 3rd party given a transfer receipt.
|
|
3. Each of these services shall charge a fee initially set at 3x the standard
|
|
transfer fee, but which may be adjusted from time to time by the owner(s) of
|
|
the Privacy Mode's management account (see [BSIP-0008](bsip-0008.md))
|
|
4. Fees shall be automatically distributed by the blockchain to the following
|
|
accounts:
|
|
* 20% to the BitShares network.
|
|
* 20% to a Maintenance Account.
|
|
* 60% to holder(s) of the Privacy Mode Fees accumulation account
|
|
5. The Maintenance Account shall be controlled by five specified manager
|
|
accounts in a 3 of 5 multisig configuration. These managers will control
|
|
the allocation of this fund to future maintenance and upgrade tasks.
|
|
6. The Initialization Package shall modify the blockchain to make the Privacy
|
|
Mode feature available to users.
|
|
7. The Initialization Package shall make provision for the creation of
|
|
generic Fee Based Assets (FBA) and set the fee for such
|
|
8. A GUI shall be provided in the Web and Light wallets to allow
|
|
ordinary users to easily use the Privacy Mode features.
|
|
9. Documentation of the Privacy Mode feature and Maintenance and Fee
|
|
Accumulation account shall be provided on the appropriate reference web
|
|
sites.
|
|
10. Resulting software patch to the Graphene library shall have the same
|
|
license as the rest of Graphene subject to the condition that the results
|
|
of the Initialization package and fee distribution mechanisms are not
|
|
modified.
|
|
|
|
# Management Account
|
|
|
|
The STEALTH asset will be issued by the "management account" (see
|
|
[BSIP-0007](bsip-0007.md)) for this feature (as created by the initialization
|
|
package). `Onceuponatime` will be the initial owner of the issued asset (not the
|
|
issuer). This management account will have 3-of-5 multi-signature authority
|
|
assigned to the 5 *largest* STEALTH holders weighted proportional to stake and
|
|
will have the power to set the fee.
|
|
|
|
# Roadmap
|
|
|
|
* Feedback and discussion of this thread: *December 8 to December 10, 2015*
|
|
* Presentation of an amended Cryptonomex Worker Proposal: *Dec 11, 2015*
|
|
This worker proposal should include Milestones of what is intended to be
|
|
accomplished by the end of week 1, week 2, week 3, week 4 and week 5 so that
|
|
the Community can follow progress in the github.
|
|
* Voting for Worker Proposal: *Dec 11 to January 1, 2016*
|
|
* onceuponatime forwards $45,000 to Cryptonomex: *Jan.2, 2016*
|
|
* Cryptonomex does the development and testing of the feature: *(4 to 6 weeks)*
|
|
* Hard fork for implementation of the feature: *Monday Feb, 15th*
|
|
|
|
# Worker Proposal
|
|
|
|
The worker proposal `1.14.18` is dedicated to poll shareholders about their
|
|
willingness to implement the Privacy Mode feature in a hard fork. It serves the
|
|
private investor as an indicator whether shareholders would appreciate his
|
|
investment and agree to upgrade the protocol accordingly.
|
|
|
|
Since the implementation is funded by a private investor, the worker only pays
|
|
approx. $300.
|
|
|
|
# Discussion
|
|
|
|
For the best user experience this proposal is best combined with proposal for
|
|
*hosted wallets* (to be defined).
|
|
|
|
## No Participation in Referral Program
|
|
|
|
The referral program does not play with Privacy mode transfers (because it is
|
|
private, we don't know who the parties are or who referred them). This means
|
|
that even if the fee were the same as the basic transfer, on average the
|
|
lifetime member would be paying 5x more a Private Transfer than a Public
|
|
Transfer. If you charge 3x the basic transfer fee, then life time members will
|
|
pay 15x more for a Private transfer than a Public transfer.
|
|
|
|
Percentage based fees are not possible with Private Transfers either because the
|
|
amount being transferred is *private*!
|
|
|
|
## Worker as Poll
|
|
|
|
When the project is complete, the new software will be presented to the
|
|
witnesses as an opportunity to hard fork by switching to running the new
|
|
package/software. At that time witnesses will face a choice:
|
|
|
|
1. Honor the proposal at the time the decision to spend the private investor's money was made, or
|
|
2. Honor the proposal at the time the product is delivered (if it has changed in the mean time).
|
|
|
|
Acting against the wishes of Vote 2 could get them fired if enough people
|
|
disagree with them keeping the implied commitment of Vote 1.
|
|
|
|
Acting against the wishes of Vote 1 means that BitShares gets a reputation for
|
|
reneging on a prior vote upon which an entrepreneur has relied.
|
|
|
|
This means that even if some voters have changed their minds about this proposal
|
|
by installation time, they might *not* decide to fire otherwise faithful
|
|
witnesses for deciding to obey Vote 1 in order to preserve BitShares' reputation
|
|
in future deals.
|
|
|
|
Considering the participation rate in the worker poll: those who do not care
|
|
enough to vote are ignored in the decision making process as it is supposed to
|
|
be.
|
|
|
|
## Privacy Mode not Most Pressingly Needed
|
|
|
|
The argument was raised that the Privacy Mode as proposed here is not the
|
|
feature most pressingly needed for BitShares right now.
|
|
|
|
## Confidential Transfers already available in the CLI-Wallet
|
|
|
|
The privacy mode is already documented and available for use in the console-line
|
|
wallet client at almost the same fee as non-private transfers (December 2015).
|
|
However, since these transfers cannot participate in the Referral Program (see
|
|
above), all fees are paid to the BitShares network. This proposal, shall it be
|
|
implemented, splits the fee for private transactions 20%/80% (similar to regular
|
|
transfers with the referral program) and hands out 20% of the fee to the
|
|
BitShares network. The other 80% are given to the maintenance account and
|
|
holders of the FBA. As a result, for BitShares shareholders to keep their 20%
|
|
transaction fee, the other 80% need to be paid by the customer. However, the fee
|
|
for this type of transaction is only increased to 3x and not the required 5x.
|
|
The assumptions are that the increase in volume for this particular transaction
|
|
type and the additional customers compensate for this loss.
|
|
|
|
# Summary for Shareholders
|
|
|
|
The idea of this proposal is to increase the use of BitShares by adding an
|
|
option for improved privacy for BitShares customers. This features comes at
|
|
almost no cost to the shareholders (see below) since it is funded by a private
|
|
investor. Customers using this feature will initially need to pay 3x the basic
|
|
transfer fee for the improved privacy. The revenue from this is split as
|
|
follows: 20% go to the BitShares shareholders as refunded BTS (refunded to the
|
|
reserve pool and as such removed from available supply), 20% go to a maintenance
|
|
account that will fund future development and updates for this feature and is
|
|
controlled by several individuals. The other 60% go to holders of a special
|
|
asset that will be created during a protocol upgrade and issued to the private
|
|
investor to compensate for his investment.
|
|
|
|
A hidden cost for BitShares shareholders is that in order to keep 20% of the
|
|
transaction fees, the fee has to be 5x the basic transfer fee but is only
|
|
increased by 3x. Even though this fee is a variable defined by the maintenance
|
|
account and thus can be changed, the authors of this BSIP see a good compromise
|
|
between attracting new users and generating a higher revenue stream by
|
|
relatively low fees.
|
|
|
|
# Copyright
|
|
|
|
This document is placed in the public domain.
|
|
|
|
# See Also
|
|
|
|
* [1] https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo
|