...
 
Commits (2)
......@@ -2,6 +2,28 @@
Crowdfunding a suite with the goal of hosting an exclusive party.
There will be a tokens issued which represent access rights to the party.
### App Structure
This is supposed to be a demo of the #D protocol which is very distributed in nature but since we don't have time to do it right and this is only a proof of concept app there will be some centralized aspects.
There will be two main chunks of code to write the web client and the server/well known identities/reliable peers.
#### Server
The server will keep track of client ids and help peers find each other. This will be done using [libp2p webrtc star](https://github.com/libp2p/js-libp2p-webrtc-star) we will probably be able to use ipfs's public star server but it doesn't look too hard to run.
The server will be running a js-ipfs daemon and serving the Web client code via an IPFS gateway.
This will allow people to verify that the code they downloaded is the code we programmed in the wallets.
Other than keeping track of peers, serving static files, and running an IPFS daemon, the server doesn't do much, there maybe some state syncronization needed on top of IPFS which is needed to get peers who were offline up to speed with changes.
#### Web Clients
The web clients will run their own IPFS node which will communicate to other peers directly over webRTC.
To ensure reliability they should have the affinity to the server's IPFS daemon as it will be a well known host to all peers.
The web clients will generate their own key pairs and mnemonic for back up key.
All of the crypto will be done client side.
All the data will be stored in the user's browser's localStorage so it will be mostly limited to text and other small bits of data since it is capped at 5MB by browsers.
### Incentive Structure
All access rights will be exclusive to the investors who actually put money to toward the initial room reservation.
This access gives them the right to the bedrooms at all times.
......
# Block Header Format
### Version 1 header
Since this is the first app to be built on top of #D we get to claim the Version 1 block format
Bytes | Name| Value | Description
---|---|---|---
4|Version| 0x00000001| We're number one!
34|Previous Block Header Hash|0x56XXXXXXX...| We are using the double sha-256 algorithm used in Bitcoin as this is the most accurate "truth sensor" available as it is most widely deployed and very easy to calculate the cost of a hash. We prefix it with 0x56 according to [IPFS's multihash](https://github.com/multiformats/multihash/blob/master/hashtable.csv)
72|Id Signature | char[72]| We will be using ECDSA, it has larger base of supported software and libraries to make it easier to put this alpha web client together, . If someone wants to implement Schnorr signatures I'm okay with that as well.
34|Merkle Root of Current Block| 0x0562XXXXXXXX....| This is a multihash formated IPFS hash which is compatible with CIDv0 and forward compatible with CIDv1
8|time|uint64| This will be the closest approximate time the device has locally, this should be as close as possible to the time when it is hashed. If it is too far in the future or past other clients should reject it.
4|nounce| uint32| Nounce used for proof of work, if 0s proof of work cost wouldn't be calculated.
\ No newline at end of file
## Functional Description
### Protocol Implementation level
- [ ] produce valid block headers
- [ ] simple recovery blocks, pubkey1 replaced by pubkey2 broadcasts pubkey3
- [ ] stores data in a content addressed way
- [ ] messaging to other peers
- [ ] peer to peer messaging
### Peer Discovery
- [ ] Well known peer that is a reliable node which will have the peerlist, webrtc maybe. Probably need another daemon that runs the #D client on top of IPFS
### User capabilities
Some of these overlap technically, some of the overlap is to highlight what should be simple to do in the UI
- [ ] sign arbitrary data onto their chain, limited by local storage and UI, hackers can hack though and do what they want
- [ ] trade access token
- [ ] set handle for identity
- [ ] broadcast their desire to be in the party
- [ ] see bids for entry
- [ ] place bid for entry
- [ ] attest to taking door money
- [ ] issue tokens
\ No newline at end of file
### Invitee Story: A Song of Crypto and Coins
Alice is an attendee to Defcon wandering about the con she finds a brightly colored Bitcoin branded tyvek wallet.
Out of curiousity she grabs it, opens it.
Inside she finds a business card designed to look like a ticket with instructions for redemption on the back.
Instructions which tell her to scan the NFC tag embedded in the wallet.
Scanning the wallet takes them to https://bitEvangel.org/CCP?sk=SECRET_KEY.
This page will give a longer decription of what they need to do to get into the party.
Probably something to the gist of:
> Congrats, you figured out how to read an NFC tag.
> Assuming you are the first one to scan this tag you will recieve a cryptographic token granting you access to the CryptoCoin Party(CCP).
> If you are not the first you can always trade someone for a token.
> Clicking on the link below will take you to the alpha web client for the hashD ID protocol, you will be asked to add some entropy to generate your public key pair.
> After that step is complete if you have a secret key it will be broadcast on the hashD network and you'll recieve a token good for entry into the party signed over to your ID.
> If you don't have a key you'll now have a hashD ID which allow you to recieve tokens if you trade for them.
Alice clicks the link under the description which takes her to a ccp.hashd.in?sk=SECRET_KEY subdomain.
This page serves up the alpha javascript client.
Since this is the first time Alice has been to the site she sees a text field asking Alice to put in entropy.
After entering some random text and clicking generate keys, the keys are genreated locally.
The first is saved to the localStorage of the device.
The second is turned into a 12 word mnemonic and displayed with a message saying that her identity is saved on this device and if it is comprmised, lost or stolen she can login with the 12 words displayed.
Alice then clicks the continue button.
The screen then loads another prompt with two choices which say ask her if she'd like to confirm her 12 word seed or live on the edge and continue.
Either she confirms or continues, confirm she re-enters the seed then continues to the main app screen.
Since Alice created her identity with a secret that hasn't been seen before
the page redirects to which shows a minimal user interface that allows Alice to interact with the HashD Network.
The interface shows a tab with labeled blocks and pending.
The blocks tab will show a list of block which can be expanded to show what data they contain.
The first block shows that she attested to her public key and a hash of her backup public key.
Since she was the first one the web app has seen with that secret key it also automatically creates a new block and broadcasts.
This block contains the secret key.
The pending tab contains a list of messages sent to the identity which she has option to accept and add them to her chain.
Alice sees a Crypto Coin Party Access Token issued by CCP.
She clicks accept which clears her pending tab and adds a new block to her #D chain.
### Web Client Requirements
- [ ] Create public private key pairs
- [ ] Verify signatures and blocks
- [ ] Verify data in merkle trees
- [ ] Broadcast block headers
- [ ] share block data via IPFS daemon that runs in the client
- [ ] store information using the localStorage browser api
- [ ] connect to other clients via webRTC
- [ ] Usable interface
\ No newline at end of file