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

[usscfounder]

USSC Litecoin-P2P-Server - A Decentralized P2P Client-Server Application & Exchange For Fast Transactions That Utilize Any Cryptocurrency

Application Features:

1. Directly and internally handles wallet.dat files and the Bitcoin/Litecoin protocol.

2. Completely separate database for user accounts with decentralized replication of virtual-server to other P2P servers.

3. Utilizes banks of wallet.dat files partial wallet private keys that are not mapped to any specific user account. Evenly distributes coins to internal banks of wallet.dat files partial wallet private keys. (SEE POSTS BELOW IN DISPOSABLE WALLET SECTION)

4. End-user client software accounts are assigned to specific virtual-server allowing transactions speeds comparable to a centralized system like Visa, MasterCard, and Pay-Pal.

5. End-user accounts and wallet.dat banks are replicated to other P2P servers.

6. P2P server network monitors each other for online or offline status. Virtualization server replication to replicate virtual servers across network in the event of physical server seizure or DDOS attack [virtual servers house wallet.dat banks].

7. Double spend attacks are mitigated by denying end-users access to wallet.dat files or banks. [Wallet.dat files are internally encrypted].

8. Uses Bitcoin/Litecoin protocol as a lower level protocol like web-browser applications use the transport layer in the OSI model stack.

9. Uses Bitcoin/Litecoin client and wallet.dat files as lower level application.

10. Eliminates need for confirmations by end-user clients and web-server or web based services.

11. No need for end-user to keep wallet.dat files on local computer or phone. Account is in the P2P cloud.

12. Account cannot be frozen or seized by anyone - even the server operator.

13. No changes to the existing Bitcoin/Litecoin network or protocol. Utilizes existing Litecoin network and protocol.

14. End-user application plug-in to existing Bitcoin/Litecoin client.

15. Government cannot track nor trace nor freeze your funds.

16. Funds cannot be traced.

17. Anyone can run a Bitcoin/Litecoin P2P Server (it's decentralized). If the server goes offline or is seized, the virtual server, accounts, and wallet.dat files are still safe and reallocated to other P2P servers.

19. Can be used as an peer-to-peer (P2P) exchange. Can utilize other exchange sites such as btc-e and mtgox for fiat conversions.

20. Completely Open Source.


This is how to best use cryptocurrency protocols

Bitcoin and other altcoins are best suited to operate as lower level applications and should not be designed for direct end-user control or use. Like web browsers use tcp/ip for lower level operations, the Bitcoin application and protocol should operate much the same way. End-user applications and services need to be built on top of the Bitcoin protocol and application.

There is no need to write code from scratch. all of the above can do coded by combining the bittorrent protocol [for virtual server and wallet.dat bank replication] and onion router protocols [for P2P Server communication] with the existing Bitcoin/Litecoin protocol [This would make a hybrid bittorrent/onion router/Litecoin application].

I will post on here design specs but I will not code it for you.

You have my permission to use the above designs. I will not make a patent or copyright claim against you so long as you keep it open source. I do not own any patents on the above system. It came from meditation and thought.

You don't necessarily have to use the Litecoin protocol, Bitcoin or Worldcoin will work as well. But I recommend the Litecoin Protocol [fast and secure].

I have been an Active Directory admin, and MS Exchange admin, Banyan Vines Street Talk Admin, And have supported everything from X.25 to X.400 and Protocols from RIP, OSFP, BGP, etc...

If you have any questions on how to design the application, I will post answers on here. You can PM me or just post your design questions here. I will help you. If you code an application for this then please give me credit for some of the design. That is all that I ask and maybe a little donations in Litecoin [PM me for address].

Get to Coding.

Thank you.

USSCFounder  
 

[usscfounder]

Bitcoin and other altcoins are best suited to operate as lower level applications and should not be designed for direct end-user control or use. Like web browsers use tcp/ip for lower level operations, the Bitcoin application and protocol should operate much the same way. End-user applications and services need to be built on top of the Bitcoin protocol and application.


I left out:
"Should use client side passphrase and server side passphrase to give access to encrypted user account on virtual server."

The above should stop any server admin/owner from trying to hack any specific users account. Client side passphrase + server side passphrase = access key to access user account on virtual server. Using combined key, client side can access server side Db for that specific user account only. Kind of like how the truecrypt client accesses an encrypted hard drive. Nothing is stored on the users client side. Server side can be configured to use third-party authentication if necessary [i.e other website, yubi-key, etc...]

[usscfounder]

Here are some of the first design specs to help you code the above system.

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. The end user client or plug in can be coded in C if desired.


Virtual Servers
Virtual servers are just database tables that give a type of centralization to P2P servers facilitating a single point of transaction for a specific user account; thus allowing for speedy transactions that could not be otherwise obtained by conventional P2P cryptocurrency networks. Virtual servers can be configured to be reassigned to other physical servers in a few minutes in the case of ddos attacks or physical server seizure by authorities.

virtual-server-001.user.table
user-id-key                              |   coins.litecoin           |     coins.bitcoin          |     coins.namecoin
(bob) XXXuser-id-key-001XXX    |            100                   |              0                     |                 20
(alice) XXXuser-id-key-002XXX   |            0                      |            100                    |                 20




The coins can then be evenly distributed so that no one account can be linked to any specific wallet:


virtual-server-001.litecoin.wallet-bank-001.table
wallet-id                                                    |   coin-amount
wallet.vs-001.bank-001.litecoin-01.dat           |            25                  
wallet.vs-001.bank-001.litecoin-02.dat           |            25                  
wallet.vs-001.bank-001.litecoin-03.dat           |            25                  
wallet.vs-001.bank-001.litecoin-04.dat           |            25    


virtual-server-001.bitcoin.wallet-bank-001.table
wallet-id                                                    |   coin-amount
wallet.vs-001.bank-001.bitcoin-01.dat           |            25                  
wallet.vs-001.bank-001.bitcoin-02.dat           |            25                  
wallet.vs-001.bank-001.bitcoin-03.dat           |            25                  
wallet.vs-001.bank-001.bitcoin-04.dat           |            25    


virtual-server-001.namecoin.wallet-bank-001.table
wallet-id                                                       |   coin-amount
wallet.vs-001.bank-001.namecoin-01.dat           |            10                  
wallet.vs-001.bank-001.namecoin-02.dat           |            10                  
wallet.vs-001.bank-001.namecoin-03.dat           |            10                  
wallet.vs-001.bank-001.namecoin-04.dat           |            10          
 



(MORE TO COME)

[usscfounder]

Additional design specs:

virtual-server files can then be propagated to other P2P servers simply by sharing the files via bittorent to the other P2P servers:

virtual-server-001 files to be propagated to P2P network:

virtual-server-001.user.table
virtual-server-001.litecoin.wallet-bank-001.table
virtual-server-001.bitcoin.wallet-bank-001.table
virtual-server-001.namecoin.wallet-bank-001.table

wallet.vs-001.bank-001.litecoin-01.dat
wallet.vs-001.bank-001.litecoin-02.dat
wallet.vs-001.bank-001.litecoin-03.dat
wallet.vs-001.bank-001.litecoin-04.dat

wallet.vs-001.bank-001.bitcoin-01.dat
wallet.vs-001.bank-001.bitcoin-02.dat
wallet.vs-001.bank-001.bitcoin-03.dat
wallet.vs-001.bank-001.bitcoin-04.dat

wallet.vs-001.bank-001.namecoin-01.dat
wallet.vs-001.bank-001.namecoin-02.dat
wallet.vs-001.bank-001.namecoin-03.dat
wallet.vs-001.bank-001.namecoin-04.dat

It is that simple to make a virtual-server. Each P2P server would have local copies of the virtual-servers on the network but only a few would actually be online. Every virtual-server would exist in an online state only on one on three or more of the P2P servers on the network.  That means if virtual-server-001 was online in a New York P2P server, an exact copy of it on the Moscow server would be offline. In the event that the New York server was seized or ddos'ed and went offline, virtual-server-001 would then come online in Moscow.

Its a layered P2P application; one P2P application layered on top of another P2P application.

(MORE TO COME)

[usscfounder]

These update are going to start to get more and more technical. I will post daily. Check this thread daily for design updates. Feel free to ask questions.

changes in technical terminology
1. "virtual-server" will now be referred to as "home-virtual-server"


tomorrow I will post about how to make a "decentralized orderbook". I will be called an  "orderbook-virtual-server"

It will be another separate P2P application stacked on top of the "home-virtual-server".

A LAMP Server will used to house and support a P2P application stack.

P2P APPLICATION STACK
4. P2P decentralized Orderbook application - orderbook-virtual-server
3. P2P  decentralized account application - home-virtual-server
2. P2P bittorrent application
1. P2P cryptocurrency application

I will post tomorrow.

(MORE TO COME)

[usscfounder]

Decentralized Orderbook - BTA System (Bus - Train - Plane)

BTA - Bus. Train. Plane. BTA is a concept I came up with the solve the problem of a decentralized orderbook for P2P systems.

BTA is a system to move orders from Tier I exchange nodes to Tier II exchange nodes to Tier III exchange nodes according to a predetermined cycle.

BTA is a system akin to a mass-transit public transportation system.

example:
In a mass transit system you could have a bus that would route and cycle through a city with 25 bus stops, stopping at every stop to pick up people. The bus would then drop all of the people off at the last stop which for the purposes of this demonstration is the city's train station. The bus would then repeat the cycle continuously bringing more and more people to the train station.

Eventually the train would arrive to that city and pick up the people who got off the bus and are waiting at the train station. The train would then continue on and cycle through all of the cities of that particular province/state picking up people (who were dropped off by the bus) at every city train station. At the end of the train route would be an airport with a planes ready to pick people up and take them to a specific destination. The train would cycle continuously through all of the cities picking up people and dropping them off at the airport.

The people who were first on the bus and then on the train and now at the airport would then board the plane (jumbo jet if you will) and travel on the plane from the province/state they were in to a final location all the while making stops in every major province/state of that country to pick up additional people. After the plane arrived at the final location it would take off again and cycle through all the provinces/states of the country continuously picking up and dropping off people.

Now, imagine if you will a dating and match making service on one of the sides of that county that has a big convention to help people find a spouse. That service decides to utilizes the same aforementioned mass transportation system to bring people together from all over the country.

People would leave their homes and go to the bus stop. Some people would find compatible matches for themselves at the bus stop or while riding on the bus. Those people would get off the bus pay the fee and then go home with no need to go to to the convention. Those people have what they want; a spouse.

The rest of the people would continue on to the train station and get on the train. But again some people would find matches on the train and at the station; so, they too would pay the fee and go home. They have what they want; a spouse.

What remains of the people would continue on to the airport then get on the plane to go to the convention hoping to find a good match for a spouse.

A P2P BTA (Bus-Train-Airplane) exchange would operate the same way only picking up orders instead of people.

(More in a few minutes)

 

[usscfounder]

P2P BTA Application

How does it work?

In a P2P BTA system a "Bus" exchange node would cycle through and collect orders from P2P "home-server" nodes mentioned in the above posts.  "Home-server" nodes house user accounts and wallets in a P2P network.

1. The Bus exchange server node would collect orders from home-server nodes 1 through 25 (for example).

2. Matching orders (if any) are fulfilled in a mini exchange. Receipts are generated. All unfulfilled orders and receipts are then stored for pickup by an "Train" exchange node.

3. On a predetermined cycle the higher Train exchange node would pick up all of the unfulfilled orders and receipts from all four (for example) of the Bus exchange nodes in the P2P network. All matching orders are fulfilled in a medium sized exchange and more receipts are generated.  Again, All unfulfilled orders and collected receipts are then stored for pickup by an "Airplane" exchange node.

4. Finally, on a predetermined cycle the higher Airplane exchange node would pick up all of the unfulfilled orders and receipts from all four (for example) of the Train exchange nodes in the P2P network. The Airplane exchange is the highest exchange on our example P2P network. All orders would attempt to be fulfilled here. Collected receipts are used to generate reports and to display fulfilled orders.

In our example P2P network, if no orders were fulfilled by the Bus or Train exchange nodes then the Airplane exchange node would have picked up 400 orders.

(MORE TO COME LATER)

[mberg2007]

Very interesting indeed.

The only problem with the BTA approach I think is the fact that a criminal could set up a rogue bus service that would collect people and then convince individuals that they either don't need a new spouse, or supply them with a dummy that they cannot distinguish from a real human being, and then kill a random woman on the bus.

In other words, this idea is not completely secure and tamper proof in its current form.

I started a similar thread here, which is based on the concept that for person A to receive currency C from person B, without any chance of keeping C, he would have to create a transaction T for an echanged currency C2 to person B, and only the id of T could then be used as a key (somehow) to validate the original payment from B to A.

But it's a chicken-and-egg type of problem, and solving that in a way that is close to the bitcoin "blockchain" way of thinking is beyond my feeble comprehension unfortunately. There are however some good ideas in the thread I linked to. Maybe they can be of use to you.

-Michael

[phillipsjk]

USSC Litecoin-P2P-Server - A Decentralized P2P Client-Server Application & Exchange For Fast Transactions That Utilize Any Cryptocurrency

Application Features:

...

7. Double spend attacks are mitigated by denying end-users access to wallet.dat files or banks. [Wallet.dat files are internally encrypted].
.....

DRM Does not, and can never work. Assume the distributed database is public.

[usscfounder]

Very interesting indeed.

The only problem with the BTA approach I think is the fact that a criminal could set up a rogue bus service that would collect people and then convince individuals that they either don't need a new spouse, or supply them with a dummy that they cannot distinguish from a real human being, and then kill a random woman on the bus.

In other words, this idea is not completely secure and tamper proof in its current form.

I started a similar thread here, which is based on the concept that for person A to receive currency C from person B, without any chance of keeping C, he would have to create a transaction T for an echanged currency C2 to person B, and only the id of T could then be used as a key (somehow) to validate the original payment from B to A.

But it's a chicken-and-egg type of problem, and solving that in a way that is close to the bitcoin "blockchain" way of thinking is beyond my feeble comprehension unfortunately. There are however some good ideas in the thread I linked to. Maybe they can be of use to you.

-Michael

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

[usscfounder]

USSC Litecoin-P2P-Server - A Decentralized P2P Client-Server Application & Exchange For Fast Transactions That Utilize Any Cryptocurrency

Application Features:

...

7. Double spend attacks are mitigated by denying end-users access to wallet.dat files or banks. [Wallet.dat files are internally encrypted].
.....

DRM Does not, and can never work. Assume the distributed database is public.

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

[phillipsjk]

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?

[usscfounder]

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?

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)

[usscfounder]

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?

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 bridge-server-nodes are P2P as well. Just so that there is no single point of failure.

It is possible to make an end-user client or website that can access multiple P2P networks simultaneously. This would not diminish network security in the least bit. Each P2P network would remain secure.

[usscfounder]

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)

[usscfounder]

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)

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

[monsterer]

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.

[sor.rge]

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.

[usscfounder]

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.

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.

[usscfounder]

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.

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.