diff --git a/README.md b/README.md index faeb593..6397bcc 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/bsip-0007.md b/bsip-0007.md index 7b6fd04..416a7e1 100644 --- a/bsip-0007.md +++ b/bsip-0007.md @@ -1,161 +1,110 @@ BSIP: 0007 - Title: Privacy (STEALTH) Mode - Authors: Daniel Larimer + Title: Fee Backed Assets + Authors: Danial Larimer + Stan Larimer Fabian Schuh Status: Draft Type: Protocol Created: 2015-12-16 - Discussion: - - - Worker: tbd + Discussion: + 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/ diff --git a/bsip-0008.md b/bsip-0008.md index e20fa1b..1215d6e 100644 --- a/bsip-0008.md +++ b/bsip-0008.md @@ -1,110 +1,161 @@ BSIP: 0008 - Title: Fee Backed Assets - Authors: Danial Larimer - Stan Larimer + Title: Privacy (STEALTH) Mode + Authors: Daniel Larimer Fabian Schuh Status: Draft Type: Protocol Created: 2015-12-16 - Discussion: - Worker: not applicable + Discussion: + + + 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 diff --git a/bsip-0007/gui-mockup-0.png b/bsip-0008/gui-mockup-0.png similarity index 100% rename from bsip-0007/gui-mockup-0.png rename to bsip-0008/gui-mockup-0.png diff --git a/bsip-0007/gui-mockup-1.png b/bsip-0008/gui-mockup-1.png similarity index 100% rename from bsip-0007/gui-mockup-1.png rename to bsip-0008/gui-mockup-1.png diff --git a/bsip-0007/gui-mockup-2.png b/bsip-0008/gui-mockup-2.png similarity index 100% rename from bsip-0007/gui-mockup-2.png rename to bsip-0008/gui-mockup-2.png diff --git a/bsip-0007/gui-mockup-3.png b/bsip-0008/gui-mockup-3.png similarity index 100% rename from bsip-0007/gui-mockup-3.png rename to bsip-0008/gui-mockup-3.png diff --git a/bsip-0007/gui-mockup-4.png b/bsip-0008/gui-mockup-4.png similarity index 100% rename from bsip-0007/gui-mockup-4.png rename to bsip-0008/gui-mockup-4.png diff --git a/bsip-0007/gui-mockup-5.png b/bsip-0008/gui-mockup-5.png similarity index 100% rename from bsip-0007/gui-mockup-5.png rename to bsip-0008/gui-mockup-5.png diff --git a/bsip-0007/gui-mockup-6.png b/bsip-0008/gui-mockup-6.png similarity index 100% rename from bsip-0007/gui-mockup-6.png rename to bsip-0008/gui-mockup-6.png diff --git a/bsip-0007/gui-mockup-7.png b/bsip-0008/gui-mockup-7.png similarity index 100% rename from bsip-0007/gui-mockup-7.png rename to bsip-0008/gui-mockup-7.png diff --git a/bsip-0007/gui-mockup-8.png b/bsip-0008/gui-mockup-8.png similarity index 100% rename from bsip-0007/gui-mockup-8.png rename to bsip-0008/gui-mockup-8.png diff --git a/bsip-0007/gui-mockup.pdf b/bsip-0008/gui-mockup.pdf similarity index 100% rename from bsip-0007/gui-mockup.pdf rename to bsip-0008/gui-mockup.pdf