Topic: [ANN][WHITEPAPER] Distributed Trading Application using Bitcoin block chain (Read 1716 times)

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.


You can.  Dunno if Bitcoin-Qt will do it though.

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.
 

You could potentially make use of this tool I wrote a while back:

https://bitcointalksearch.org/topic/ann-bitmsg-a-proof-of-sacrifice-distributed-messaging-layer-over-bitcoin-308483

It supports multiple-recipient AES encryption (using RSA for keys), for example.

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.

Also worth the read: https://bitcointalk.org/index.php?topic=72022.20
http://bitcoin.stackexchange.com/questions/4707/what-method-does-my-wallet-use-to-encode-messages-in-the-blockchain/4709#4709
http://garzikrants.blogspot.com/2013/04/on-bitcoin-data-spam-and-evil-data.html
https://bitcointalksearch.org/topic/why-i-believe-mastercoin-should-be-encoded-on-the-bitcoin-blockchain-298331

So far biggest argument against using the btc blockchain for this type of thing is bloat and the 1 mb limit.

Valid points relating to bitmessage.
https://bitcointalksearch.org/topic/m.607667

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.

From what I understand your idea is much closer to colored coins than to master coin implementations?

useful master coin implementations that can be built upon
https://bitcointalksearch.org/topic/m.3396794

https://bitcointalksearch.org/topic/m.3422960

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

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.

Check out freenet datastore technique

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.

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.

Review implementation of Forward secrecy
http://en.wikipedia.org/wiki/Forward_secrecy

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

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.