[ANN] USSC Crypto-P2P-Server | Decentralized P2P Exchange & Application

[usscfounder]

Also I didn't understand why banks need multiple wallet.dat files for the same type of coin.

Let's see. How do I explain this?

The system should set a static amount of wallet.dat files per wallet bank. This has advantages such as portability (moving the wallet files to other P2P servers in the case of seizure or DDoS attacks) among other advantages.

Also virtual servers are going to be like brand names or website names. "Home-Virtual-Server-002" will be "Home-Virtual-Server-002" forever on the P2P network. It MUST be that way.

If you have an account on Home-Virtual-Server-002 its like banking at Chase or Citibank. There are Citibank branches everywhere but only one Citibank Corporation.  The wallet banks should be named after the Home-virtual-server to whom they belong for easy identification purposes:  wallet.hvs-002.bank-001 (hvs-002 is short for "Home-Virtual-Server-002". The P2P network admin would see that this particular wallet belonged to Home-Virtual-Server-002.

Another reason for multiple wallet files is that you don't want authorities being able to map user accounts to wallet files. It makes it harder to seize. When you evenly distribute the coin across the wallet files its like RAID 5 striping but for cryptocurrency instead of hard-drives. It keeps everything consolidated to the Home-Virtual-Server. The P2P transactions can be done through the P2P BTA exchange orderbook. Home-Vitual-Server-002 can then send the coins to wherever BTA orderbook says they need to go.

 

[usscfounder]

P2P BTA (Bus.Train.Airplane) Order Book Design and Configuration Suggestions

Orderbook Order Types:

1. POS Payment Request

2. POS Escrow Request

3. Sell Order

4. Buy Order

5. User to User Payment/Request/Invoice

6. User to User/POS (Point of Sale) Escrow Payment/Request/Invoice:

See this thread here:  https://bitcointalk.org/index.php?topic=208327.0

How about an p2p escrow ledger with a Point of Sale Passcode.

For example lets say I am on my way to Walmart.

1. I tell my altcoin client to reserve 20 coins for walmarts use with a time limit of 24 hours.
2. I then reserve the amount using walmarts public key to reserve the amount in my wallet.
3. the altcoin network will remove the coins from my wallet and put them in escrow.
4. the coins cannot be sent to anyone or spent by anyone who does not have walmarts private key.
5. I goto walmart and spend 10 coins.
6. Walmart altcoin client sees that there is a reserve amount of 20 coins with walmarts public key signature.
7. Walmart then receives 10 coins from the reserve and using its private key releases the rest of the coins back into my wallet freeing up the remaining 10 coins for me to spend.

This is just an idea on how to speed up transactions.

Let me know what you think.  

You can also incorporate a passcode into step 2. that way if Walmart is part of a group of retailers sharing the same private key then I can keep a larger amount in p2p escrow for use with multiple retailers. the only retailers that could take money out would be those that I am present in with my passcode ready.

The system could also be used for e-bay and the postal delivery service:

1. a seller on e-bay want to sell you a mining rig for 100 altcoins
1. e-bay seller gives you his public key
2. You reserve into escrow 100 altcoins using the public keys of the e-bay seller, e-bay, and UPS delivery service. The altcoin client removes the 100 altcoins from your wallet and puts them into the cloud secured by the public keys of the e-bay seller, e-bay, and the UPS delivery service.
3. Upon completion of the sale ebay signs the transaction with their private key.
4. Upon delivery and inspection of the mining rig the UPS delivery man signs the transaction with his private key.
5. When all the transaction has been signed by all of the private keys (matching the public keys already incorporated into the transaction) the 100 altcoins are transferred to the e-bay seller.

anyone else have input?

[UPDATE] I created and announced a project post for this idea here:
https://bitcointalk.org/index.php?topic=208393.0

The above solution could also be used like a giftcard. Simply by using the merchants public key you can load coins to be used at that merchant or group of merchants using parent and sub-keys.

A merchant would not have to do confirmations at all because they could look directly into their key-wallet and see the funds are already there before you even arrive at the location. They would not be able to spend the funds without your pass-code.

1. Bob sends Alice 100 coins using Alice's public key. Altcoin client removes 100 coins from Bob's wallet. Altcoin client sets 24 hour time limit on transaction. Passcode must be entered into transaction before time limit or funds get returned. Altcoin client sends coins to the Cloud secured by Alice's public key. Bob cannot retrieve funds until after time limit expires.
2. Alice receives coins in key wallet and verifies coins with private key.
3. Alice cannot spend coins without bobs pass-code.
4. Bob meets Alice in person and inspects merchandise.
5. Bob sees merchandise is good and gives Alice pass-code to unlock coins.
6. If merchandise is bad Bob does not give Alice pass-code and the funds are returned to Bob's wallet when the 24 hour time limit expires.  

7.

8.

(MORE TO COME IN A FEW MINUTES)

[usscfounder]

(BTA Order Book Continued:)

7. Service Confirmation

8. Service Confirmation (delivery)

9. User Message

10. User Confirmation

11. POS (Point of Sale) Confirmation

12. Warrantee Contract

13. Insurance Contract

14. Insurance Payment/Request/Invoice

15. Auto Payment

16. Auto Payment Contract/Confirmation

17. Payroll Transaction (Scheduled Auto Payment)

18. Time Tracking (Employee Clock-In/Out)

19. Time Tracking (Legal Work Start/Stop)

20. Help Desk (Open/Close Ticket)

21. etc...


BTA can be used for a whole host of things besides exchanging cryptocurrency[/b

(MORE TO COME IN A FEW MINUTES)]

[usscfounder]

Example BTA Transactions

Bob sends Alice 10 coins

1. Bob's p2p client application (or web interface) requests home-virtual-server-001 (Bob's home account server) to send Alice 10 bitcoins.

2. home-virtual-server-001 (on physical p2p-server-001) submits order to queue then sends pickup notification to p2p network.

3. Physical p2p-server-002 listener service receives pickup notification and forwards to P2P Application Stack (on the same server).

4. The application stacked BTA-virtual-server-002 (on physical p2p-server-002 (separate physical p2p server for security purposes)) receives the request for pickup from the listener service and then adds home-virtual-server-001 to pickup route list.

5. BTA-virtual-server-002 then routes through the p2p network picking up all of the orders from the home-virtual-servers in the pickup route list. Bob's request is picked up as well.

6. BTA-virtual-server-002 adds bob's request to the BTA Tier-I exchange database for processing.



(KEEP REFRESHING... WILL BE FINISHED IN A FEW MINUTES)

[Hydroponica]

So, is this like, an offshore bank account, for BTC?

[usscfounder]

So, is this like, an offshore bank account, for BTC?

A offshore p2p virtual bank account for BTC

[usscfounder]

Example BTA Transactions

Bob sends Alice 10 coins

1. Bob's p2p client application (or web interface) requests home-virtual-server-001 (Bob's home account server) to send Alice 10 bitcoins.

2. home-virtual-server-001 (on physical p2p-server-001) submits order to queue then sends pickup notification to p2p network.

3. Physical p2p-server-002 listener service receives pickup notification and forwards to P2P Application Stack (on the same server).

4. The application stacked BTA-virtual-server-002 (on physical p2p-server-002 (separate physical p2p server for security purposes)) receives the request for pickup from the listener service and then adds home-virtual-server-001 to pickup route list.

5. BTA-virtual-server-002 then routes through the p2p network picking up all of the orders from the home-virtual-servers in the pickup route list. Bob's request is picked up as well.

6. BTA-virtual-server-002 adds bob's request to the BTA Tier-I exchange database for processing.



(KEEP REFRESHING... WILL BE FINISHED IN A FEW MINUTES)

(Continuing...)

7. BTA Tier-I exchange service (on physical p2p-server-002) sees Bob's request to send Alice 10 coins to her personal wallet address. BTA Tier-I exchange service drafts confirmation request (from Bob to send Alice 10 coins to her personal wallet address).

8. The BTA Tier-I exchange service sends the confirmation request to the p2p application stack.

9. BTA-virtual-server-002 receives the request for confirmation (Bob's) from the application stack. But security rules prohibit any BTA-virtual-server from directly executing request from the same physical server. So BTA-virtual-server-002 sends confirmation request to queue and broadcasts to the p2p network for utility pickup.

10. BTA-virtual-server-003 (on physical p2p-server-003) receives utility pickup request from it's listener service and adds BTA-virtual-server-002 to it's own pickup route list.

11. BTA-virtual-server-003 routes through the p2p network and picks up the utility request from BTA-virtual-server-002.  Because this is a utility request there is no need to add the request to the Tier-I exchange database.

12. BTA-virtual-server-003 then starts to process the utility request and add home-virtual-server-001 (Bob's home server) to its own drop-off route list.

13. BTA-virtual-server-003 then routes through the p2p network and adds the confirmation request to home-virtual-server-001 receive queue

14. home-virtual-server-001 retrieves the confirmation request from its own receive queue and forwards to Bob's client.

15. Bob receives on screen the confirmation request to send Alice 10 coins. Bob then confirms the request.

16. home-server-001 then

(CHECK BACK LATER TODAY FOR THE REST... SEE YA!)  

[turtle83]

The system should be coded to run on an LAMP server using PHP and MySQL only. Perl can be used to facilitate server side scripts and systems commands as well.

n00b! Neither scalable nor secure... just n00b friendly...

[usscfounder]

The system should be coded to run on an LAMP server using PHP and MySQL only. Perl can be used to facilitate server side scripts and systems commands as well.

n00b! Neither scalable nor secure... just n00b friendly...

Its a p2p network. What do you mean scalable?

This is an overall design for you to code however you want.  If it is not secure it will be your own fault.

I assure you I am not a newbie. Stop being a troll and come up with a better solution... if you can.

I recommended MySql to demonstrate the ease in which this system could be made. You can use any database that you would like. That's up to you. The choice is yours.

What OS would you recommend? Windows?


It is obvious that you either didn't read all of my posts, or your a newbie with no experience whatsoever.

[usscfounder]

The greatest part of security for this p2p network will be in the interactions between the servers. In order to hack the system multiple servers would have to be compromised.

9. BTA-virtual-server-002 receives the request for confirmation (Bob's) from the application stack. But security rules prohibit any BTA-virtual-server from directly executing request from the same physical server. So BTA-virtual-server-002 sends confirmation request to queue and broadcasts to the p2p network for utility pickup.

If your worried about the wallet banks you can put them on separate secure wallet-virtual-servers that will process the actual cryptocurrency transactions.

There are a number of ways you can make this network more secure. This design is to show the feasibility of a p2p decentralized exchange.

[turtle83]

The system should be coded to run on an LAMP server using PHP and MySQL only. Perl can be used to facilitate server side scripts and systems commands as well.

n00b! Neither scalable nor secure... just n00b friendly...

Its a p2p network. What do you mean scalable?

This is an overall design for you to code however you want.  If it is not secure it will be your own fault.

I assure you I am not a newbie. Stop being a troll and come up with a better solution... if you can.

I recommended MySql to demonstrate the ease in which this system could be made. You can use any database that you would like. That's up to you. The choice is yours.

What OS would you recommend? Windows?


It is obvious that you either didn't read all of my posts, or your a newbie with no experience whatsoever.

I wasn't referring to the OS. My comment was for "using PHP and MySQL only" . Anyone that has any experience, wouldn't touch something as important as an exchange with php and mysql.

Both PHP and mysql are bloated "one size fits all solutions" with loads of bugs and vulnerabilities. The only reason to use them is to get something deployed quick without much concern of performance or security.  And then you expect other people to be able to run them in a secure manner?

Anything thats not compiled into a binary is not a good fit for something that needs to be secure.

[usscfounder]

Its obvious that you did not read all of the post.

Go back and read about the multi-teir BTA

Its a decentralized exchange.

What that means is that even if you were somehow able to hack one of the tier-I BTA-virtual-servers you would only affect a very very small percent of all the users on the exchange. Its decentralized!

This design is designed to be resistant to seizure and DDoS attacks. Theft is mitigated through the use of multi-server interactions. (You might find out if you let me finish my example).

What would you propose for a decentralized exchange? Ripple?

I worked at four banks and at a Internet Data Center.  Most of the platforms I supported had systems that were not "compiled into binary". What planet do you live on?

[turtle83]

All the best with your project.

[usscfounder]

(Continuing...)

7. BTA Tier-I exchange service (on physical p2p-server-002) sees Bob's request to send Alice 10 coins to her personal wallet address. BTA Tier-I exchange service drafts confirmation request (from Bob to send Alice 10 coins to her personal wallet address).

8. The BTA Tier-I exchange service sends the confirmation request to the p2p application stack.

9. BTA-virtual-server-002 receives the request for confirmation (Bob's) from the application stack. But security rules prohibit any BTA-virtual-server from directly executing request from the same physical server. So BTA-virtual-server-002 sends confirmation request to queue and broadcasts to the p2p network for utility pickup.

10. BTA-virtual-server-003 (on physical p2p-server-003) receives utility pickup request from it's listener service and adds BTA-virtual-server-002 to it's own pickup route list.

11. BTA-virtual-server-003 routes through the p2p network and picks up the utility request from BTA-virtual-server-002.  Because this is a utility request there is no need to add the request to the Tier-I exchange database.

12. BTA-virtual-server-003 then starts to process the utility request and add home-virtual-server-001 (Bob's home server) to its own drop-off route list.

13. BTA-virtual-server-003 then routes through the p2p network and adds the confirmation request to home-virtual-server-001 receive queue

14. home-virtual-server-001 retrieves the confirmation request from its own receive queue and forwards to Bob's client.

15. Bob receives on screen the confirmation request to send Alice 10 coins. Bob then confirms the request.

16. home-server-001 then

(CHECK BACK LATER TODAY FOR THE REST... SEE YA!)  

16. home-virtual-server-001 (on physical p2p-server-001) then submits the confirmation-reply to it own send-queue while broadcasting pickup notification to p2p network.

17. Whatever Tier-I BTA-virtual-server that is available on the network will pickup the confirmation-reply and route it back to BTA-virtual-server-002 (this could be BTA-virtual-server-003 or some other BTA-virtual-server. What is important is that all transactions require the interaction of more than one BTA-virtual-server in order to complete)

(REFRESH THIS PAGE... I WILL UPDATE IN A FEW MINUTES)

[usscfounder]

16. home-virtual-server-001 (on physical p2p-server-001) then submits the confirmation-reply to it own send-queue while broadcasting pickup notification to p2p network.

17. Whatever Tier-I BTA-virtual-server that is available on the network will pickup the confirmation-reply and route it back to BTA-virtual-server-002 (this could be BTA-virtual-server-003 or some other BTA-virtual-server. What is important is that all transactions require the interaction of more than one BTA-virtual-server in order to complete)

18. BTA-virtual-server-002 retrieves the confirmation-reply from the receive queue and forwards it back to the BTA Tier-I exchange service on the same physical server.

19. The BTA Tier-I exchange service (on physical p2p-server-002)...

20.



(I WILL FINISH TOMORROW... CHECK BACK. THANKS TO EVERYONE FOR THE SUPPORT.)

[mberg2007]

You use certificates and keys to secure the server nodes. A rogue node could not transact with any of the P2P server nodes.

But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?

I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.

-Michael

[usscfounder]

Hey, I am looking for a community collaboration here.

I will be honest. I have an extensive background in enterprise applications, Storage Area Networks, enterprise networking, enterprise etc...

I could build this whole system right now without writing a single line of compiled code.

Just using Linux, Apache, MySQL, pHp, (LAMP), WAMP, bitcoin, bittorrent, and a host of Linux tools (ssh, cron, bash, etc..).  


It wouldn't be pretty; but it would work.

Would it be secure? not very.

But I guarantee you that it would work.


Yes I was a firewall admin (checkpoint, cisco, netscreen, fortinet, etc...) so I know that security is a non-issue. There are ways to secure the transactions.

Going forward I will try to include some suggestions on security in my updates.

I am looking for you guys to pipe in with suggestions and other stuff too. I don't want to do this all by myself.

[usscfounder]

You use certificates and keys to secure the server nodes. A rogue node could not transact with any of the P2P server nodes.

But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?

I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.

-Michael

Let me come up with a good security implementation for this. I will put my brain to work to see if I can come up with an original security scheme.

I have been looking at some sort of original SPKI/SDSI (Simple Public Key Infrastructure / Simple Distributed Security Infrastructure) type implementation, along with some other schemes I am looking into as well.

SPKI/SDSI Link:  http://csrc.nist.gov/groups/ST/key_mgmt/documents/Sept2012_Presentations/LAMBERT_CKMW2012.pdf

Give me some time...

[MikeyVeez]

This looks awesome wish you the best, can't help any as i can't code anything.

[usscfounder]

This looks awesome wish you the best, can't help any as i can't code anything.

That's fine. Whatever you can do would be appreciated. We all need to work together to help come up with a solution.