Rename 0008->0007 and 0007->0008
This commit is contained in:
Fabian Schuh
parent
afe59cbf28
commit
3d676c8a02
13 changed files with 206 additions and 206 deletions
|
|
@ -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
|
[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
|
[5](bsip-0005.md) | Expiring Votes for Witnesses | Danial Larimer | Protocol | Draft
|
||||||
[6](bsip-0006.md) | Market Maker Incentivization | 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
|
[7](bsip-0007.md) | Fee Backed Assets (FBA) | Danial Larimer | Protocol | Draft
|
||||||
[8](bsip-0008.md) | Fee Backed Assets (FBA) | Danial Larimer | Protocol | Draft
|
[8](bsip-0008.md) | Privacy (STEALTH) Mode | Danial Larimer | Protocol | Draft
|
||||||
|
|
|
||||||
204
bsip-0007.md
204
bsip-0007.md
|
|
@ -1,161 +1,110 @@
|
||||||
BSIP: 0007
|
BSIP: 0007
|
||||||
Title: Privacy (STEALTH) Mode
|
Title: Fee Backed Assets
|
||||||
Authors: Daniel Larimer <Dan@cryptonomex.com>
|
Authors: Danial Larimer <Dan@cryptonomex.com>
|
||||||
|
Stan Larimer <Stan@cryptonomex.com>
|
||||||
Fabian Schuh <Fabian@BitShares.org>
|
Fabian Schuh <Fabian@BitShares.org>
|
||||||
Status: Draft
|
Status: Draft
|
||||||
Type: Protocol
|
Type: Protocol
|
||||||
Created: 2015-12-16
|
Created: 2015-12-16
|
||||||
Discussion: <https://github.com/cryptonomex/graphene/issues/452>
|
Discussion: <https://bitsharestalk.org/index.php/topic,20286.0.html>
|
||||||
<https://bitsharestalk.org/index.php/topic,20104.0.html>
|
Worker: not applicable
|
||||||
<https://bitsharestalk.org/index.php/topic,20499.0.html>
|
|
||||||
Worker: tbd
|
|
||||||
|
|
||||||
# Abstract
|
# Abstract
|
||||||
|
|
||||||
Privacy Mode Transfers (a.k.a. Stealth Transfers) are used to maintain user
|
We're all familiar with counterparty free Market Pegged Assets (MPA) and issuer
|
||||||
privacy. This feature helps set BitShares apart from most other crypto
|
backed User Issued Assets (UIA). Theoretically, there could be a third type: Fee
|
||||||
currencies and offers tremendous value to the users who are most interested in
|
Backed Assets (FBA).
|
||||||
privacy, liberty, and freedom.
|
|
||||||
|
|
||||||
In practise they combine the techniques of *blinding signatures* to hide the
|
Hence we propose to develop a feature for *Market based innovation*: if people
|
||||||
amount of a transfer and *stealth addresses* (similar to TITAN in BitShares 1)
|
can profit from successful features in the form of fees then it definitely helps
|
||||||
to hide involved parties.
|
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
|
A developer installs a new function that charges fees for its service and pays
|
||||||
the web wallet to allow users to enter the *privacy mode*. Here, users will be
|
those fees to holders of a UIA she creates for that purpose.
|
||||||
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
|
She naturally starts out as the owner of those revenue producing assets.
|
||||||
actions:
|
|
||||||
|
|
||||||
* Transfer from public account to their own private balance
|
She is free to sell them since each one is a revenue generating counterparty
|
||||||
* Transfer from one of their private accounts to one of their private contacts
|
free asset backed solely by the blockchain.
|
||||||
* 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
|
Since they have no counterparty, they are not a security. They are simply
|
||||||
authorities* and *key authorities* and indicating that a transaction to that
|
capital equipment, like selling a mining machine.
|
||||||
account has to be made in private.
|
|
||||||
|
|
||||||
## 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
|
There could be a new asset for every new revenue generating feature in the whole
|
||||||
existing web wallet) that allows ordinary people to use the privacy mode without
|
ecosystem. Developers recoup their costs by selling (or pre-selling) these
|
||||||
further knowledge about the underlying technology. Thus, a proposal for the user
|
revenue generating software devices (or keeping them to earn the revenue they
|
||||||
interface has been drafted and is attached to this proposal as
|
produce.)
|
||||||
[pdf](bsip-0007/gui-mockup.pdf).
|
|
||||||
|
|
||||||
[slide 1](bsip-0007/gui-mockup-0.png) [slide 2](bsip-0007/gui-mockup-1.png) [slide 3](bsip-0007/gui-mockup-2.png)
|
# Examples
|
||||||
[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)
|
|
||||||
|
|
||||||
This draft has been designed with user experience in mind but may be improved if
|
## Taxi Rental
|
||||||
it serves its purpose.
|
|
||||||
|
|
||||||
# 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,
|
## Project/Feature Funding
|
||||||
backups of your wallet after receiving a new private transfer are *required*.
|
|
||||||
|
|
||||||
## 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
|
# Regulatory issues
|
||||||
necessary crypto operations in the web wallet (see [1]).
|
|
||||||
|
|
||||||
# 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
|
One of the first and thorniest problems we tackled is the nasty fact of
|
||||||
development and implementation of this feature in full as a private investor and
|
*Regulatory Risk*. There exists a vocal contingent of people who want very much
|
||||||
at zero cost to BitShares shareholders.
|
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
|
If something falls within the definition of a *security* under applicable law,
|
||||||
fee accumulation account, Maintenance Account, Initialization Package, and GUI
|
it will be governed by extensive rules and regulations that can be quite complex
|
||||||
interface for BitShares scoped for a firm fixed price of $45K. The following
|
and expensive to comply with. And subject the issuer to a large fine/other
|
||||||
requirements apply:
|
penalties if not complied with!
|
||||||
|
|
||||||
1. The Privacy Mode feature shall be implemented as proposed in
|
Once the "Privacy Mode" feature has been implemented and is available on the
|
||||||
https://github.com/cryptonomex/graphene/issues/452 (as amended).
|
blockchain (but not before), it will be possible for future investor and
|
||||||
2. It shall provide the following fee based services:
|
entrepreneurs to create FBAs and crowd fund new features by having a *Private
|
||||||
* Transfer from public account to their own private balance
|
Mode account* ([BSIP-0008](bsip-0008.md)), issue the FBA from an *unknown*
|
||||||
* Transfer from one of their private accounts to one of their private contacts
|
jurisdiction that is presumably not subject to securities concerns.
|
||||||
* 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
|
# Management Account
|
||||||
|
|
||||||
The STEALTH asset will be issued by the "management account" (see
|
A FBA asset (such as the [STEALTH asset](bsip-0008.md)) will be issued by a
|
||||||
[BSIP-0008](bsip-0008.md)) for this feature (as created by the initialization
|
"management account" for that particular feature as part of a hard fork. The
|
||||||
package). `Onceuponatime` will be the initial owner of the issued asset (not the
|
initial share holders of the FBA asset have to be defined upon the hard fork.
|
||||||
issuer). This management account will have 3-of-5 multi-signature authority
|
The management account will have a Multi-Signature authority assigned to the `X`
|
||||||
assigned to the 5 *largest* STEALTH holders weighted proportional to stake and
|
largest share holders of that account weighted proportional to stake and will
|
||||||
will have the power to set the fee.
|
have the power to set the fee.
|
||||||
|
|
||||||
# Roadmap
|
All FBA require a protocol upgrade (read: hard fork) to create the management
|
||||||
|
account.
|
||||||
* 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
|
# Copyright
|
||||||
|
|
||||||
|
|
@ -163,4 +112,5 @@ This document is placed in the public domain.
|
||||||
|
|
||||||
# See Also
|
# 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/
|
||||||
|
|
|
||||||
204
bsip-0008.md
204
bsip-0008.md
|
|
@ -1,110 +1,161 @@
|
||||||
BSIP: 0008
|
BSIP: 0008
|
||||||
Title: Fee Backed Assets
|
Title: Privacy (STEALTH) Mode
|
||||||
Authors: Danial Larimer <Dan@cryptonomex.com>
|
Authors: Daniel Larimer <Dan@cryptonomex.com>
|
||||||
Stan Larimer <Stan@cryptonomex.com>
|
|
||||||
Fabian Schuh <Fabian@BitShares.org>
|
Fabian Schuh <Fabian@BitShares.org>
|
||||||
Status: Draft
|
Status: Draft
|
||||||
Type: Protocol
|
Type: Protocol
|
||||||
Created: 2015-12-16
|
Created: 2015-12-16
|
||||||
Discussion: <https://bitsharestalk.org/index.php/topic,20286.0.html>
|
Discussion: <https://github.com/cryptonomex/graphene/issues/452>
|
||||||
Worker: not applicable
|
<https://bitsharestalk.org/index.php/topic,20104.0.html>
|
||||||
|
<https://bitsharestalk.org/index.php/topic,20499.0.html>
|
||||||
|
Worker: tbd
|
||||||
|
|
||||||
# Abstract
|
# Abstract
|
||||||
|
|
||||||
We're all familiar with counterparty free Market Pegged Assets (MPA) and issuer
|
Privacy Mode Transfers (a.k.a. Stealth Transfers) are used to maintain user
|
||||||
backed User Issued Assets (UIA). Theoretically, there could be a third type: Fee
|
privacy. This feature helps set BitShares apart from most other crypto
|
||||||
Backed Assets (FBA).
|
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
|
In practise they combine the techniques of *blinding signatures* to hide the
|
||||||
can profit from successful features in the form of fees then it definitely helps
|
amount of a transfer and *stealth addresses* (similar to TITAN in BitShares 1)
|
||||||
BitShares become more adaptable over time. More importantly it promotes
|
to hide involved parties.
|
||||||
innovation.
|
|
||||||
|
|
||||||
# Motivation
|
# Specifications
|
||||||
|
|
||||||
A developer installs a new function that charges fees for its service and pays
|
This proposal involves creating a new front-end feature on the account page in
|
||||||
those fees to holders of a UIA she creates for that purpose.
|
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
|
* Transfer from public account to their own private balance
|
||||||
free asset backed solely by the blockchain.
|
* 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
|
These features are already available on the blockchain level using *address
|
||||||
capital equipment, like selling a mining machine.
|
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
|
## GUI Mockup
|
||||||
new properties.
|
|
||||||
|
|
||||||
There could be a new asset for every new revenue generating feature in the whole
|
The goal of this proposal is to have a frontend developed (or integrated into an
|
||||||
ecosystem. Developers recoup their costs by selling (or pre-selling) these
|
existing web wallet) that allows ordinary people to use the privacy mode without
|
||||||
revenue generating software devices (or keeping them to earn the revenue they
|
further knowledge about the underlying technology. Thus, a proposal for the user
|
||||||
produce.)
|
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.
|
# Implementation Aspects
|
||||||
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.
|
|
||||||
|
|
||||||
The TAXI FPA could represent all available minutes on a network-owned fleet of
|
## Backup Considerations
|
||||||
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.
|
|
||||||
|
|
||||||
## 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
|
## Javascript Implementation
|
||||||
by a PRIVACY FPA that gets their owners a cut of fees produced by transactions
|
|
||||||
using that feature in the future.
|
|
||||||
|
|
||||||
# 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
|
# Funding
|
||||||
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.
|
|
||||||
|
|
||||||
One of the first and thorniest problems we tackled is the nasty fact of
|
BitSharestalk.org forum user `onceuponatime` has proposed to fund the
|
||||||
*Regulatory Risk*. There exists a vocal contingent of people who want very much
|
development and implementation of this feature in full as a private investor and
|
||||||
that an FBA (fee based asset) be created to fund this feature upgrade to the
|
at zero cost to BitShares shareholders.
|
||||||
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.
|
|
||||||
|
|
||||||
The conundrum is that whoever creates the FBA and offers it to the public as a
|
## Contract between `onceuponatime` and Cryptonomex:
|
||||||
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].
|
|
||||||
|
|
||||||
If something falls within the definition of a *security* under applicable law,
|
The purpose of this contract is to develop a Privacy Mode feature, Privacy Mode
|
||||||
it will be governed by extensive rules and regulations that can be quite complex
|
fee accumulation account, Maintenance Account, Initialization Package, and GUI
|
||||||
and expensive to comply with. And subject the issuer to a large fine/other
|
interface for BitShares scoped for a firm fixed price of $45K. The following
|
||||||
penalties if not complied with!
|
requirements apply:
|
||||||
|
|
||||||
Once the "Privacy Mode" feature has been implemented and is available on the
|
1. The Privacy Mode feature shall be implemented as proposed in
|
||||||
blockchain (but not before), it will be possible for future investor and
|
https://github.com/cryptonomex/graphene/issues/452 (as amended).
|
||||||
entrepreneurs to create FBAs and crowd fund new features by having a *Private
|
2. It shall provide the following fee based services:
|
||||||
Mode account* ([BSIP-0007](bsip-0007.md)), issue the FBA from an *unknown*
|
* Transfer from public account to their own private balance
|
||||||
jurisdiction that is presumably not subject to securities concerns.
|
* 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
|
# Management Account
|
||||||
|
|
||||||
A FBA asset (such as the [STEALTH asset](bsip-0007.md)) will be issued by a
|
The STEALTH asset will be issued by the "management account" (see
|
||||||
"management account" for that particular feature as part of a hard fork. The
|
[BSIP-0007](bsip-0007.md)) for this feature (as created by the initialization
|
||||||
initial share holders of the FBA asset have to be defined upon the hard fork.
|
package). `Onceuponatime` will be the initial owner of the issued asset (not the
|
||||||
The management account will have a Multi-Signature authority assigned to the `X`
|
issuer). This management account will have 3-of-5 multi-signature authority
|
||||||
largest share holders of that account weighted proportional to stake and will
|
assigned to the 5 *largest* STEALTH holders weighted proportional to stake and
|
||||||
have the power to set the fee.
|
will have the power to set the fee.
|
||||||
|
|
||||||
All FBA require a protocol upgrade (read: hard fork) to create the management
|
# Roadmap
|
||||||
account.
|
|
||||||
|
* 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
|
# Copyright
|
||||||
|
|
||||||
|
|
@ -112,5 +163,4 @@ This document is placed in the public domain.
|
||||||
|
|
||||||
# See Also
|
# See Also
|
||||||
|
|
||||||
* [1] https://bitsharestalk.org/index.php/topic,20499.msg264752.html#msg264752
|
* [1] https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo
|
||||||
* [2] http://www.cuttingedgecapital.com/what-is-a-security-and-why-does-it-matter/
|
|
||||||
|
|
|
||||||
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 70 KiB After Width: | Height: | Size: 70 KiB |
|
Before Width: | Height: | Size: 64 KiB After Width: | Height: | Size: 64 KiB |
|
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 60 KiB |
|
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 109 KiB After Width: | Height: | Size: 109 KiB |
|
Before Width: | Height: | Size: 123 KiB After Width: | Height: | Size: 123 KiB |
Loading…
Reference in a new issue