Rename 0008->0007 and 0007->0008

This commit is contained in:
Fabian Schuh 2015-12-17 10:09:48 +01:00
parent afe59cbf28
commit 3d676c8a02
13 changed files with 206 additions and 206 deletions

View file

@ -18,5 +18,5 @@ Number | Title | Owner | Type
[4](bsip-0004.md) | Distribute Market Fees on Core Asset to Referral Program | Danial Larimer | Protocol | Draft
[5](bsip-0005.md) | Expiring Votes for Witnesses | Danial Larimer | Protocol | Draft
[6](bsip-0006.md) | Market Maker Incentivization | Danial Larimer | Protocol | Draft
[7](bsip-0007.md) | Privacy (STEALTH) Mode | Danial Larimer | Protocol | Draft
[8](bsip-0008.md) | Fee Backed Assets (FBA) | Danial Larimer | Protocol | Draft
[7](bsip-0007.md) | Fee Backed Assets (FBA) | Danial Larimer | Protocol | Draft
[8](bsip-0008.md) | Privacy (STEALTH) Mode | Danial Larimer | Protocol | Draft

View file

@ -1,161 +1,110 @@
BSIP: 0007
Title: Privacy (STEALTH) Mode
Authors: Daniel Larimer <Dan@cryptonomex.com>
Title: Fee Backed Assets
Authors: Danial Larimer <Dan@cryptonomex.com>
Stan Larimer <Stan@cryptonomex.com>
Fabian Schuh <Fabian@BitShares.org>
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: tbd
Discussion: <https://bitsharestalk.org/index.php/topic,20286.0.html>
Worker: not applicable
# 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.
We're all familiar with counterparty free Market Pegged Assets (MPA) and issuer
backed User Issued Assets (UIA). Theoretically, there could be a third type: Fee
Backed Assets (FBA).
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.
Hence we propose to develop a feature for *Market based innovation*: if people
can profit from successful features in the form of fees then it definitely helps
BitShares become more adaptable over time. More importantly it promotes
innovation.
# Specifications
# Motivation
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.
A developer installs a new function that charges fees for its service and pays
those fees to holders of a UIA she creates for that purpose.
Users will be able to monitor their private balances and take the following
actions:
She naturally starts out as the owner of those revenue producing assets.
* 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.
She is free to sell them since each one is a revenue generating counterparty
free asset backed solely by the blockchain.
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.
Since they have no counterparty, they are not a security. They are simply
capital equipment, like selling a mining machine.
## GUI Mockup
This new kind of digital asset trades like any of the others but has fascinating
new properties.
The goal of this proposal is to have a frontend 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-0007/gui-mockup.pdf).
There could be a new asset for every new revenue generating feature in the whole
ecosystem. Developers recoup their costs by selling (or pre-selling) these
revenue generating software devices (or keeping them to earn the revenue they
produce.)
[slide 1](bsip-0007/gui-mockup-0.png) [slide 2](bsip-0007/gui-mockup-1.png) [slide 3](bsip-0007/gui-mockup-2.png)
[slide 4](bsip-0007/gui-mockup-3.png) [slide 5](bsip-0007/gui-mockup-4.png) [slide 6](bsip-0007/gui-mockup-5.png)
[slide 7](bsip-0007/gui-mockup-6.png) [slide 8](bsip-0007/gui-mockup-7.png) [slide 9](bsip-0007/gui-mockup-8.png)
# Examples
This draft has been designed with user experience in mind but may be improved if
it serves its purpose.
## Taxi Rental
# Implementation Aspects
Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages. Sell the
cabs to the network in exchange for a set of tickets good for rental minutes on
a cab. Resell/trade those tickets on the open market. This way, anyone can
rent time on any of the limited supply of "cabs" and earn fees for performing
delivery services.
## Backup Considerations
The TAXI FPA could represent all available minutes on a network-owned fleet of
robotic taxi cabs. Buy up as many minutes of their time as you want and you have
your own revenue generating business with no counter parties.
Because private transfers are not recoverable from blockchain data alone,
backups of your wallet after receiving a new private transfer are *required*.
## Project/Feature Funding
## Javascript Implementation
In the case of [BSIP-0008](bsip-0008.md), the project development can be funded
by a PRIVACY FPA that gets their owners a cut of fees produced by transactions
using that feature in the future.
This proposal will require the use of a JavaScript library to perform the
necessary crypto operations in the web wallet (see [1]).
# Regulatory issues
# Funding
Much consultation with Cryptonomex and with several prominent and trusted
members of the BitShares community has lead me to some preliminary conclusions
as to how a "Privacy Mode" feature could best be implemented and used in a
safe and timely fashion and at no risk to the BitShares Community.
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.
One of the first and thorniest problems we tackled is the nasty fact of
*Regulatory Risk*. There exists a vocal contingent of people who want very much
that an FBA (fee based asset) be created to fund this feature upgrade to the
BitShares blockchain. They want that everyone be thus enabled an opportunity to
participate in the fee stream originating from future use of the feature by
purchasing shares of a `STEALTH` asset.
## Contract between `onceuponatime` and Cryptonomex:
The conundrum is that whoever creates the FBA and offers it to the public as a
means of participation in a fee-based income stream faces a risk of coming under
regulatory scrutiny if the project is a success (e.g. Satoshi Dice) or even if
it is not a success (through some disgruntled investor complaining to a
regulatory authority). For a more in depth look in to Regulatory Risk please see
[1,2].
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:
If something falls within the definition of a *security* under applicable law,
it will be governed by extensive rules and regulations that can be quite complex
and expensive to comply with. And subject the issuer to a large fine/other
penalties if not complied with!
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 OpenLedger 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.
Once the "Privacy Mode" feature has been implemented and is available on the
blockchain (but not before), it will be possible for future investor and
entrepreneurs to create FBAs and crowd fund new features by having a *Private
Mode account* ([BSIP-0008](bsip-0008.md)), issue the FBA from an *unknown*
jurisdiction that is presumably not subject to securities concerns.
# Management Account
The STEALTH asset will be issued by the "management account" (see
[BSIP-0008](bsip-0008.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.
A FBA asset (such as the [STEALTH asset](bsip-0008.md)) will be issued by a
"management account" for that particular feature as part of a hard fork. The
initial share holders of the FBA asset have to be defined upon the hard fork.
The management account will have a Multi-Signature authority assigned to the `X`
largest share holders of that account 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*
# 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*!
All FBA require a protocol upgrade (read: hard fork) to create the management
account.
# Copyright
@ -163,4 +112,5 @@ This document is placed in the public domain.
# See Also
* [1] https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo
* [1] https://bitsharestalk.org/index.php/topic,20499.msg264752.html#msg264752
* [2] http://www.cuttingedgecapital.com/what-is-a-security-and-why-does-it-matter/

View file

@ -1,110 +1,161 @@
BSIP: 0008
Title: Fee Backed Assets
Authors: Danial Larimer <Dan@cryptonomex.com>
Stan Larimer <Stan@cryptonomex.com>
Title: Privacy (STEALTH) Mode
Authors: Daniel Larimer <Dan@cryptonomex.com>
Fabian Schuh <Fabian@BitShares.org>
Status: Draft
Type: Protocol
Created: 2015-12-16
Discussion: <https://bitsharestalk.org/index.php/topic,20286.0.html>
Worker: not applicable
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: tbd
# Abstract
We're all familiar with counterparty free Market Pegged Assets (MPA) and issuer
backed User Issued Assets (UIA). Theoretically, there could be a third type: Fee
Backed Assets (FBA).
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.
Hence we propose to develop a feature for *Market based innovation*: if people
can profit from successful features in the form of fees then it definitely helps
BitShares become more adaptable over time. More importantly it promotes
innovation.
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.
# Motivation
# Specifications
A developer installs a new function that charges fees for its service and pays
those fees to holders of a UIA she creates for that purpose.
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.
She naturally starts out as the owner of those revenue producing assets.
Users will be able to monitor their private balances and take the following
actions:
She is free to sell them since each one is a revenue generating counterparty
free asset backed solely by the blockchain.
* 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.
Since they have no counterparty, they are not a security. They are simply
capital equipment, like selling a mining machine.
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.
This new kind of digital asset trades like any of the others but has fascinating
new properties.
## GUI Mockup
There could be a new asset for every new revenue generating feature in the whole
ecosystem. Developers recoup their costs by selling (or pre-selling) these
revenue generating software devices (or keeping them to earn the revenue they
produce.)
The goal of this proposal is to have a frontend 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).
# Examples
[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)
## Taxi Rental
This draft has been designed with user experience in mind but may be improved if
it serves its purpose.
Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages. Sell the
cabs to the network in exchange for a set of tickets good for rental minutes on
a cab. Resell/trade those tickets on the open market. This way, anyone can
rent time on any of the limited supply of "cabs" and earn fees for performing
delivery services.
# Implementation Aspects
The TAXI FPA could represent all available minutes on a network-owned fleet of
robotic taxi cabs. Buy up as many minutes of their time as you want and you have
your own revenue generating business with no counter parties.
## Backup Considerations
## Project/Feature Funding
Because private transfers are not recoverable from blockchain data alone,
backups of your wallet after receiving a new private transfer are *required*.
In the case of [BSIP-0007](bsip-0007.md), the project development can be funded
by a PRIVACY FPA that gets their owners a cut of fees produced by transactions
using that feature in the future.
## Javascript Implementation
# Regulatory issues
This proposal will require the use of a JavaScript library to perform the
necessary crypto operations in the web wallet (see [1]).
Much consultation with Cryptonomex and with several prominent and trusted
members of the BitShares community has lead me to some preliminary conclusions
as to how a "Privacy Mode" feature could best be implemented and used in a
safe and timely fashion and at no risk to the BitShares Community.
# Funding
One of the first and thorniest problems we tackled is the nasty fact of
*Regulatory Risk*. There exists a vocal contingent of people who want very much
that an FBA (fee based asset) be created to fund this feature upgrade to the
BitShares blockchain. They want that everyone be thus enabled an opportunity to
participate in the fee stream originating from future use of the feature by
purchasing shares of a `STEALTH` asset.
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.
The conundrum is that whoever creates the FBA and offers it to the public as a
means of participation in a fee-based income stream faces a risk of coming under
regulatory scrutiny if the project is a success (e.g. Satoshi Dice) or even if
it is not a success (through some disgruntled investor complaining to a
regulatory authority). For a more in depth look in to Regulatory Risk please see
[1,2].
## Contract between `onceuponatime` and Cryptonomex:
If something falls within the definition of a *security* under applicable law,
it will be governed by extensive rules and regulations that can be quite complex
and expensive to comply with. And subject the issuer to a large fine/other
penalties if not complied with!
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:
Once the "Privacy Mode" feature has been implemented and is available on the
blockchain (but not before), it will be possible for future investor and
entrepreneurs to create FBAs and crowd fund new features by having a *Private
Mode account* ([BSIP-0007](bsip-0007.md)), issue the FBA from an *unknown*
jurisdiction that is presumably not subject to securities concerns.
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 OpenLedger 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
A FBA asset (such as the [STEALTH asset](bsip-0007.md)) will be issued by a
"management account" for that particular feature as part of a hard fork. The
initial share holders of the FBA asset have to be defined upon the hard fork.
The management account will have a Multi-Signature authority assigned to the `X`
largest share holders of that account weighted proportional to stake and will
have the power to set the fee.
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.
All FBA require a protocol upgrade (read: hard fork) to create the management
account.
# 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*
# 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*!
# Copyright
@ -112,5 +163,4 @@ This document is placed in the public domain.
# See Also
* [1] https://bitsharestalk.org/index.php/topic,20499.msg264752.html#msg264752
* [2] http://www.cuttingedgecapital.com/what-is-a-security-and-why-does-it-matter/
* [1] https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo

View file

Before

Width:  |  Height:  |  Size: 50 KiB

After

Width:  |  Height:  |  Size: 50 KiB

View file

Before

Width:  |  Height:  |  Size: 65 KiB

After

Width:  |  Height:  |  Size: 65 KiB

View file

Before

Width:  |  Height:  |  Size: 70 KiB

After

Width:  |  Height:  |  Size: 70 KiB

View file

Before

Width:  |  Height:  |  Size: 64 KiB

After

Width:  |  Height:  |  Size: 64 KiB

View file

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 60 KiB

View file

Before

Width:  |  Height:  |  Size: 92 KiB

After

Width:  |  Height:  |  Size: 92 KiB

View file

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 44 KiB

View file

Before

Width:  |  Height:  |  Size: 109 KiB

After

Width:  |  Height:  |  Size: 109 KiB

View file

Before

Width:  |  Height:  |  Size: 123 KiB

After

Width:  |  Height:  |  Size: 123 KiB