Bitcoin Forum
July 01, 2024, 02:04:39 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Embedded currency RFC  (Read 612 times)
Mattasher (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile WWW
March 14, 2014, 04:04:41 PM
 #1

Hey all! I’m working on a project that needs an embedded currency to help allocate resources within the system. The goal is to allow participants to demonstrate proof-of-stake, yet at the same time I’d like to make ownership and transfers maximally anonymous. Here’s my proposal, your feedback welcome! If you happen to be near Toronto on March 25th and want to be involved with the initial development meetup, send me a PM for more info.

Project name: Puffball.io
Internal currency: Mycelium
Smallest unit: Spore

Rules:
1. A fixed number of spores will be generated at the beginning. There is no mining.

2. Every spore has its own blackchain record, maintained separately.

3. All transactions happen atomically; to trade 10 spores to someone else, you would sign over each spore to this other person.

4. By requirement, every spore must be signed over to a new key every X minutes (called a “period”, this length of time could change over time and get shorter as the system becomes busier. These periods are numbered sequentially).

5. If a spore isn’t “tumbled” during a period, it is considered dead and removed from the system.

6. To transfer ownership of a spore, the owner uses their private key to sign a message that encodes the public key of the new owner with the private key of the current owner, as well as some additional information (described below). To tumble a coin to themself, the owner generates their own new private-public key pair, and signs the spore over to this new address.
Ownership of each spore is invisible to everyone except the current owner, and the owner from the immediate previous period. The public key itself could be hidden (to third-parties) and instead some token could be used that proved the validity of the ownership transfer without revealing either party’s public keys.

7. (Possible) Each tumble could have a space for a fixed length message, encrypted with the public key of the new owner. To maintain overall system privacy, every transaction would have to include this field and it would have to be of a fixed length (it could be sent with the initial character “!” plus noise if no meaning is intended).

8. To make up for dead spores, and to encourage spore ownership, some fraction of the spores would be allowed to split every period, based on some unpredictable criteria that depends on the state of (a subset of) the system. When a spore splits, the private key for that spore signs over ownership twice, to two different public keys, and announces both tumbles to the network. If this method of spore growth proves technically difficult, then all (living) spores could split at pre-determined periods (for example, during a period that’s a power of number m).

9. In addition to the public address of the new owner, the tumble also encodes the current period number and a Bloom filter that includes every spore that was both alive during the previous period and that meets some randomly generated criteria (for example, its token shares the first N digits with a hash that is derived in an unpredictable way from the state of the system).
This requirement is intended to prevent a spore from trying to “catch up” after not broadcasting new keys for several periods. Before including an external spore’s identity in its Bloom filter, a spore needs to verify that it was included in those Bloom filters which should have included it during the previous period. Otherwise this spore itself is considered “dead” by the system. Spores would also be responsible to exclude other spores in if those spores split when they shouldn’t have (the equivalent of a double spend).
This method of consensus introduces weaknesses, see below.

10. To prove that a particular user controlled a certain number of spores, they could announce in advance some function of the public token for those spores during a future period. To prove ownership with a higher level of anonymity, users could announce what digits would be in a sparsely populated Bloom filter of all the spores. Here there would be a tradeoff between anonymity and the certainty that a proof of stake isn’t faked. However, for a large number of spores in the system and a high claim of ownership, figuring out exactly which spores were included could require an extremely high number of calculations.

Key advantages
1. High anonymity: Even if you knew ownership of every coin during a particular period, it’s possible that none of this information will be correct by the next period.

2. Zero transaction costs. Each spore has to broadcast its information to others, and include information from other spores, to avoid being killed. As such, everyone with an interest in the system is required to maintain it. Spore tumbling could be outsourced, but this would either have to be to a trusted third party, or there would have to be ways to provide tumbling services with enough information to continue keeping a spore alive, but not enough to steal it.

3. Transparency of market size. Because untumbled spores are removed, there are no zombie spored or lost wallets.

4. All resources go directly into maintaining the network. There are no difficult proof-of-work puzzles to be solved.


Weaknesses
1. A disruption to the network could cause major problems, as a the validation of each tumble relies on the ability to “see” the current state of many of the other spores.

2. Because an individual owner of spores has a vested interest in reducing the number of spores that they don’t control (to corner the market), they have an incentive to claim other spores are dead even when they are still alive. But because taking this action will likely cause this spore itself to be flagged as dead, that serves as a disincentive. However, if enough spores “went rogue” and began broadcasting incorrect information, this could have a cascading effect throughout the population of otherwise honest spores, as some percentage of them incorrectly trust the information of rogue spores.

3. For maximum anonymity, each period X should be as short as possible. Additionally, each period should include a sub-period during which no new tumbles are announced, to give a chance for each spore to include all the new information in it’s calculation, and to share with other spores their own new information. However, the shorter the period, the faster this communication needs to occur, and the more likely that a network failure could result in disruptions.

4. Spores cannot change hands at a rate greater than the length of a period.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!