Topic: [ANN] USSC Crypto-P2P-Server | Decentralized P2P Exchange & Application - page 3. (Read 4851 times)

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.


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.

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.

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

(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!)  

A offshore p2p virtual bank account for BTC

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

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)

(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)]

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.

 

There are way to mitigate this. Let's get real here. You HAVE to trust someone.

You and I use keys everyday and we know absolutely nothing about the maintainers of those keys. Do you trust the server admin at your banking institution where you perform your SSL online transactions?

The purpose of the P2P network is to stop government shutdowns/seizures and ddos attacks.

You still have to trust the P2P key admin ("mayor" of the P2P network) not to steal your money (but I am working on a way to make it really difficult for him to do so).

Server admins should have no way to defraud you or steal your coins. Only the "Mayor" of the P2P network would have the power to do so. Most likey the "Mayor" would be a well know person like Gavin or Coblee.  If they use the keys to steal everyone's money then you have my permission to hunt them down.

The trust model could be reputation based. A site like Wikileaks stake their operation on public trust. If no one trusted Wikileaks then would anyone read the reports that they edit and release? Maybe, but I don't believe so.

Is there some risk? Yes, but no more than that which already exists in the current model of secure online transactions.

It should also be possible to code into the system a way to remove your account to another P2P network.

 

Like I said in another post, converting fiat is not a technical problem, it is a political problem. At the risk of changing the subject of this thread we need to let the Libertarian revolution continue on to deal with those issues.

DDos attacks don't work against the 1 million+ MoneyGram and Western Union locations that could be used to upload money to the P2P network or Fiat converting sites. Fiat conversions are a political problem. Period.

Still the one who manages the key is the weak point. He could lose them, or abuse the power. It suffers from the same problem as any centralized trust-based system. We have already seen cases when exchanges proved not trustworthy, they lose or steal their clients' funds regularly, because there's no legal persecution and they don't care much.

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

For me, the difficult part in an exchange is exchanging Fiat for crypto. This appears to only address trading crypto for other types of crypto with the role of exchanging fiat still left to legacy, centralised exchanges (albeit now connected to this P2P network) such as MtGox.

These centralised exchanges are still just as likely to be ddosed and so you have exactly the same problem you always did. Unless I'm missing something?

Cheers, Paul.

Attack and DDOS escrow agreements built into the exchange could also be made between Wikileaks and Anonymous in the cases of wallet-bank transfers.

The "city" could also trust its citizens. The server could offload work to clients to perform some P2P tasks as well helping to secure and further decentralize the network.  All keys however would be under control of the trusted "mayor".

This can only work as there would have to be multiple network "cities" in the case one network "city" was attacked or compromised. Users could still function using other trusted cities. Users also should be able to move their accounts from one network "city" to another (even under attack).

Home-virtual-servers should not only have the ability to move from one P2P server to another. They should be able to move accounts as well (in the case of a ddos attack against a server because of a particular user).

The home-virtual-server could start moving accounts to other random home-virtual-servers.

If the virtual-server under attack is unable to function because of the attack then another P2P server monitoring the attack could deactivate the home-virtual-server and reallocate the accounts on the attacked home-virtual-server to other virtual-servers for mitigation purposes. It should be possible to move the accounts to other trusted P2P networks as well.

For example: If under attack Wikileaks P2P exchange network could start moving virtual-home-server accounts and wallet-banks to Anonymous P2P exchange network and vice-versa.

(MORE TO COME LATER)

Did you read the whole entry?  It is a P2P Server that uses an application stack. Users do not have access to the wallet files.

The users use accounts on the server. When you access gmail or yahoo mail do you have access to their internal processes?

It's a client-server model (but could be programmed to be web-based - i.e wordpress, cms, etc...). Ideally The users would have accounts on the servers.

If a user and his friends downloaded the server portion of the open source software then he could start his own P2P exchange network.  He would have to generate/import his own certificates and keys to make sure that rogue servers from other users don't talk to his network. And he would have to secure the LAMP server to make sure none of the users accounts on his server would have access to his wallet banks.

If he wanted to connect to and interact with other trusted P2P networks then he would have to implement a P2P "bridge-server-node" which I will write about later. A bridge-server-node would allow other fiat converting sites (like btc-e, mtgox) to exchange fiat for cryptocurrency. Those sites would have to be trusted and and have certificates and keys implemented to transact with the P2P network.

Do you honestly believe that users would create accounts and send money to a P2P network with no trust model built in? Even bitcoin can only trust other bitcoin clients. Bitcoin clients do not talk to Litecoin clients. They only trust bitcoin. Similarly the P2P network you setup would only trust those that are part of your P2P network.

For example wikileaks could start a P2P exchange network that users all over the world could use. The people that setup accounts and send money would trust the founder of wikileaks with their money. But Wikileaks could have a bridge-server-node setup to transact with the P2P network that Piratebay has setup or Anonymous, or perhaps Mega's

Do you understand now?  

If I use the analogy about the city bus that I posted earlier then think of the city buses as servers and the drivers of those buses as keys. The only ones who could drive the buses would be those who were given keys by the city.

If anyone else tried to drive one of their buses, they would not be able to simply because they do not have the keys to the bus.

If they tried to use their own bus and go from bus stop to bus stop trying to pick up people none of the people would get on their bus because most people know what a city bus looks like (city logo, etc..) plus the police would pull them over if they tried to.

Each P2P network would be its own self contained city. The people of that city would trust the mayor and city council of that city. In addition, the city could transact with other cities that they trusted (if they chose to do so). The citizens of that city could choose to transact with other cities that they trusted as well.

I hope this help everyone to understand. I apologize for not being clearer.

(MORE TO COME LATER)

The wallet files are internally encrypted where? The use of the term "P2P" (Peer to peer) implies that all nodes (users) have access to the database.

If the users (who are also servers) do not have access to the wallet files, why are they stored at all?

What are you talking about? Its a P2P application stack. You don't let the users have access to the wallet files.