|
bob131313 (OP)
|
 |
December 18, 2013, 05:22:56 PM
Last edit: December 18, 2013, 09:33:54 PM by bob131313 |
|
Distributed Trading Application using Bitcoin block chain using a cryptographically verifiable distributed database.
Summary: Creation of a simple peer-to-peer app using a trading protocol to enable to creation of merchant/customer system that piggybacks on the Bitcoin block chain using a cryptographically verifiable distributed database.
Application consist of 3 parts:
1. Heartbeat - Internal messaging system - 2-4 addresses that the app knows the private key to to send dust transactions with encoded text into the block chain.
2. Customer interface - Customer Role has a public and private pgp key used for signing bid/ask request in the system.
3. Merchant Interface - Merchant Role has a public and private pgp key used in responding to bid/ask request in the system.
Application Workflow:
1. Program loads.
2. Person selects role they will be using the program for in the current session:
a. Browse stores -
1. Displays a list of stores showing in the app address space which includes the public signing key for each store.
2. When you enter a store it list the current items for sale at that store. If you click on bid for the item a encoded message is sent by the app to the BTC block chain to the addresses controlled by the app.
3. App reviews new transactions to the block chain to check for pgp encoded messages to your public key.
4. If encoded message is a purchase the BTC address for funding is provided and the app waits for confirms on the BTC block chain for that transaction.
b. Merchant mode.
1. Create store. Assigned PGP public/private keys. Assign store name.
2. Create inventory.
3. Check orders
a. App checks App addresses for transactions that are related to the the specific store public key.
b. App displays the store interface to accept a bid, cancel a bid, send a message.
c. App automatically checks the block chain for required number of confirms to the address specified in the order and notifies the merchant that shipping can be sent.
3. Account settings allows to the attachment of a BTC address ownership that is added to the program based on a signed verification of ownership.
4. Program heartbeat. Checks Bitcoin block chain for transactions sent between the addresses owned by the app. Checks text on transaction to see if this is a transaction related to the current user of the system.
a. Encrypted message for current user of program. Message decoded and displayed. If accepted the message is encoded with the public key of the Merchant and sent signing with the key of the user.
b. Communication can only be decoded by the person sending and receiving the message. Each Merchant shares the public pgp key. Each customer signs with the key. Same way PGP emails work.
c. Text is encoded by app and sent to the BTC block chain with by a dust transaction to the addresses owned by the app. App only sends dust back and forth and never truly spends any BTC. Confirms are not needed as long as the transaction is encoded into the block chain.
Still have lots to work out. The idea seems simple. This will be released as an Android app distributed as a unknown source apk with full source on github. Custom builds of the app would require the private keys to be set for the APP addresses used for the heartbeat, otherwise each instance of the custom build would be on their own fork.
This idea seems simple at first look. PGP used to store a distributed database on the block chain specific to addresses.
If you would like to donate to this project to help as incentive for brighter minds then mine, feel free.
BTC: 1G7Y47uDJEFNb54csAmq2Yn79EuMgX8Rya
If you have useful feedback or caveats that you think we have missed please let me know.
This is not specifically an alt, but deals with some of the things that mastercoin is proposing. This is my own solution that does not require an exit address for the blockchain. Please read it over and provide feedback. If you would like to take part please let me know.
This program will be released into the wild when done and all ownership of the specific forks will be based on the encoding addresses used in the apk build.
Please forgive the brain dump. This is an idea I have been thinking about for sometime to determine the flaws.
One of the issues I was thinking about was history. If a store is shutdown and the private key of that store is found, the entire purchase history is known so previous transactions would be able to be read. This might compromise private data, this might be resolved with the creation of a new PGP key for each day. I will be thinking on this point more.
|
|
|
|
|
|
bob131313 (OP)
|
|
December 18, 2013, 05:28:35 PM |
|
Also to be included into the app. Merchant and Customer rating system.
Haven't considered how to add a new role of Escrow. Maybe this is open as a specific type of store added to the system
|
|
|
|
|
|
bob131313 (OP)
|
|
December 18, 2013, 05:38:09 PM |
|
|
|
|
|
|
|
kr105
|
|
December 18, 2013, 06:41:47 PM |
|
One of the issues I was thinking about was history. If a store is shutdown and the private key of that store is found, the entire purchase history is known so previous transactions would be able to be read. This might compromise private data, this might be resolved with the creation of a new PGP key for each day. I will be thinking on this point more.
Why you need to keep a history on the block chain of every transaction made? Lets just make this an extension of the current p2p protocol, so all the traffic of your new proposal will be sent thru the network but not stored forever on every node. Do you need the items list of a certain store? Then ask the store for it directly over p2p. I'm selling alpaca socks and then ran out of stock of them? Then delete the item of the store instantly, I don't need to wait until my item delete request goes all over the nodes. Unless someone set a listening only node that is saving all traffic of your implementation, I don't see why finding a private key after the store is closed means a privacy issue. |
|
|
|
|
|
bob131313 (OP)
|
|
December 18, 2013, 07:21:48 PM |
|
One of the issues I was thinking about was history. If a store is shutdown and the private key of that store is found, the entire purchase history is known so previous transactions would be able to be read. This might compromise private data, this might be resolved with the creation of a new PGP key for each day. I will be thinking on this point more.
Why you need to keep a history on the block chain of every transaction made? Lets just make this an extension of the current p2p protocol, so all the traffic of your new proposal will be sent thru the network but not stored forever on every node. Do you need the items list of a certain store? Then ask the store for it directly over p2p. I'm selling alpaca socks and then ran out of stock of them? Then delete the item of the store instantly, I don't need to wait until my item delete request goes all over the nodes. Unless someone set a listening only node that is saving all traffic of your implementation, I don't see why finding a private key after the store is closed means a privacy issue. Was thinking in terms of a android device with the app installed would not always be online. If I create a store and stock it, I don't want to have the store always on the device running waiting for p2p connections. This would work if the block chain is only storing the latest update to the store. storev1 - socks added. inventory 10 storev2 - socks inventory 8 After each transaction the store data is encoded and loaded into the block chain ie datacoin style. Wondering about block chain bloat..but we will need to test the POC app with a store with 50 items or so. Hoping to have POC concept app created this next week during the holiday. |
|
|
|
|
|
bob131313 (OP)
|
|
December 18, 2013, 07:47:16 PM |
|
Check out freenet datastore technique
|
|
|
|
|
|
bob131313 (OP)
|
|
December 18, 2013, 09:58:02 PM |
|
another thing to consider as a negative of going p2p. ip leakage. my system doesn't have ip leakage, all communication is handled with api calls to major blockchain apis.
Only privacy leakage would be delivery information or things shared in the conversation.
consider ways to prevent identity leakage.
|
|
|
|
|
|
bob131313 (OP)
|
|
December 19, 2013, 04:56:59 AM |
|
hi. I started this in the alt section..I think it is a better fit here. I hope to have the poc android app made for next week. Please provide criticism and ideas
|
|
|
|
|
|
bob131313 (OP)
|
|
December 19, 2013, 05:22:52 AM |
|
|
|
|
|
|
overcoin
Newbie
 Offline
Activity: 53
Merit: 0
|
|
December 19, 2013, 08:25:40 AM |
|
useful master coin implementations that can be built upon From what I understand your idea is much closer to colored coins than to master coin implementations? |
|
|
|
|
|
bob131313 (OP)
|
|
December 19, 2013, 02:26:19 PM |
|
useful master coin implementations that can be built upon From what I understand your idea is much closer to colored coins than to master coin implementations? In the sense of colored coins adding extra data to the transaction that has specific meaning. I agree that you can view the heartbeat of the program as using specific colored coins to handle the data-stream. Thank you. Writing a poc app that looks up an address on the blockchain, looks at transactions and decodes messages. |
|
|
|
|
|
bob131313 (OP)
|
|
December 19, 2013, 02:56:24 PM |
|
|
|
|
|
|
|
bob131313 (OP)
|
|
December 19, 2013, 03:28:36 PM
Last edit: December 19, 2013, 03:40:37 PM by bob131313 |
|
|
|
|
|
|
|
bob131313 (OP)
|
|
December 19, 2013, 04:09:39 PM |
|
Starting to feel like Vlad talking to myself.
Only real solution to prevent pruning etc is to use stenography and transaction values. ie send 0.00100001 - 0.00100016 representing hex of the pgp message back and forth in the program to encode the message into the chain. Which seems to be a really dumb way to go about it. Will think on it a bit more.
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”buy socks for inventoryid=1532423")
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”txidcreated for socks for inventoryid=1532423 buy sendtoaddress=“1DUHnHz5BmPF5i1WBQR1ex8g4msFn1tnVx”)
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”send payment for txidcreated for socks for inventoryid=1532423 toaddress=“1DUHnHz5BmPF5i1WBQR1ex8g4msFn1tnVx”)
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”txidcreated for socks for inventoryid=1532423 buy confirmed please send delivery data.”)
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”txidcreated deliver data=123 any street,any town,any country”)
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”txidcreated payment confirm sendtoaddress provided feedbackscore=5”)
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”txidcreated confirm received feedbackscore=5”)
cryptwithpgp(nonce,public key of sender,public key of receiver,flag#,”txidcreated closed”)
Thank you for your patience and the numerous post as I worked through the details. If you have comments or feedback please feel free.
|
|
|
|
|
|
|
|
bob131313 (OP)
|
|
December 20, 2013, 03:12:10 PM |
|
TY. Not fond of the idea of burning coins. I am looking into some ways to handle it that should work. Creating 16 addresses and using those as a translation to hex. Timing issues might be a problem. But you should be able to send a message 1. Create 16 addresses each one corresponds to a hex value a-f 0-9 2. Broadcast a transaction to each address that corresponds to the the message, including incremental value to keep order. 54657374206d657373616765 would send multi to address5 value .0001 address4 value .0002 address6 value .0003 address5 value .0004 address7 value .0005 address3 value .0006 address7 value .0007 address4 value .0008 address2 value .0009 address0 value .0010 address6 value .0011 addressd value .0012 etc.. So the message would be send to multi addresses with message relating to the order of the addresses in the multisend. This should allow coins to not be burned, but propagate on the network fast enough to be readable by the program. Need to look up multisend to verify that you can send to 1 address multiple times in a send many transaction. |
|
|
|
|
Sarchar
Member
Offline
Activity: 88
Merit: 10
|
|
December 21, 2013, 07:59:41 AM |
|
TY. Not fond of the idea of burning coins. I am looking into some ways to handle it that should work. Creating 16 addresses and using those as a translation to hex. Timing issues might be a problem. But you should be able to send a message 1. Create 16 addresses each one corresponds to a hex value a-f 0-9 2. Broadcast a transaction to each address that corresponds to the the message, including incremental value to keep order. 54657374206d657373616765 would send multi to address5 value .0001 address4 value .0002 address6 value .0003 address5 value .0004 address7 value .0005 address3 value .0006 address7 value .0007 address4 value .0008 address2 value .0009 address0 value .0010 address6 value .0011 addressd value .0012 Wow, an entire output to designate half of a byte. Have you done the math for this? A bitcoin address is 20 bytes, which means you'd need 40 outputs alone just to transmit an address this way. The approach is interesting, nonetheless. Why not just make 65536 addresses (for 0x0000-0xffff)? There's no reason why you couldn't have a database this large. It'd reduce the amount of outputs by a factor of four. Also, saving coins (from my solution) shouldn't be that much of a concern, since technically 0-satoshi outputs are valid outputs and hopefully will eventually be supported with prunable outputs. Need to look up multisend to verify that you can send to 1 address multiple times in a send many transaction.
You can. Dunno if Bitcoin-Qt will do it though. |
|
|
|
|
|
