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

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

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...]

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)

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)

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)

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)

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 (https://bitcointalk.org/index.php?topic=208187.0), 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 (https://bitcointalk.org/index.php?topic=208187.msg2216060#msg2216060) in the thread I linked to. Maybe they can be of use to you.

-Michael

Quote from: mberg2007 on May 22, 2013, 07:32:11 PM

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

Quote from: phillipsjk on May 23, 2013, 04:11:44 PM

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)

Quote from: usscfounder on May 23, 2013, 04:32:33 PM

Quote from: phillipsjk on May 23, 2013, 04:11:44 PM

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.

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)

Quote from: usscfounder on May 23, 2013, 05:44:20 PM

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

Quote from: monsterer on May 23, 2013, 07:52:37 PM

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.

Quote from: sor.rge on May 23, 2013, 08:43:18 PM

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.

Quote

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.

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

Quote from: usscfounder on May 17, 2013, 04:18:46 PM

Quote from: usscfounder on May 17, 2013, 03:53:48 PM

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

Quote

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)

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)

Quote from: usscfounder on May 24, 2013, 03:40:05 PM

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

Quote from: turtle83 on May 24, 2013, 05:06:14 PM

Quote from: usscfounder on May 20, 2013, 01:50:22 PM

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.

Quote from: usscfounder on May 24, 2013, 06:57:48 PM

Quote from: turtle83 on May 24, 2013, 05:06:14 PM

Quote from: usscfounder on May 20, 2013, 01:50:22 PM

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...

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.

Quote

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

Quote

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.)

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.

Quote from: mberg2007 on May 25, 2013, 06:34:54 PM

Quote from: usscfounder on May 23, 2013, 03:46:57 PM

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...

What do you think about something like this? SPKI/SDSI:

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

I am looking at this because it doesn't use a CA plus there are some other customizations I can make.

From Wikipedia:

Quote

SPKI/SDSI does not define a role for a commercial Certificate Authority (CA). In fact, one premise behind SPKI is that a commercial CA serves no useful purpose.[1] As a result of that, SPKI/SDSI is deployed primarily in closed solutions and in demonstration projects of academic interest. Another side-effect of this design element is that it is difficult to monetize SPKI/SDSI by itself. It can be a component of some other product, but there is no business case for developing SPKI/SDSI tools and services except as part of some other product.

http://en.wikipedia.org/wiki/SPKI

http://tools.ietf.org/html/rfc2692

http://tools.ietf.org/html/rfc2693

Another feature I like about SDSI:

http://tools.ietf.org/html/rfc2693

Quote

2.8 Fully Qualified SDSI Names

SDSI local names are of great value to their definer. Each local
name maps to one or more public keys and therefore to the
corresponding keyholder(s). Through SDSI's name chaining, these
local names become useful potentially to the whole world. [See
section 2.6.2 for an example of SDSI name chaining.]

To a computer system making use of these names, the name string is
not enough. One must identify the name space in which that byte
string is defined. That name space can be identified globally by a
public key.

It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI
name occurs within a certificate, then the public key of the issuer
is the identifier of the name space in which that name is defined.

Ellison, et al. Experimental [Page 11]

RFC 2693 SPKI Certificate Theory September 1999

However, if a SDSI name is ever to occur outside of a certificate,
the name space within which it is defined must be identified. This
gives rise to the Fully Qualified SDSI Name. That name is a public
key followed by one or more names relative to that key. If there are
two or more names, then the string of names is a SDSI name chain.
For example,

(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)

is a fully qualified SDSI name, using the SHA-1 hash of a public key
as the global identifier defining the name space and anchoring this
name string.

I GOT IT!

Ok. Where do I start?

Last night I was thinking and meditation about how to secure the whole system to answer Michael question in the previous posts.

I really could not come up with a good way to secure the system. So I did what I did the night I came up with the BTA solution.

I prayed.

Afterward the answers came. Three answers actually.

The first answer was:

Quote

You don't understand the question. Look at it again

Ok. So I tried to remember Michaels post:

Quote from: mberg2007 on May 25, 2013, 06:34:54 PM

Quote from: usscfounder on May 23, 2013, 03:46:57 PM

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

Then I understood what he was actually asking. So I am going to rephrase the question:

Quote

What do you do to mitigate the worst case scenario?

What is the worst case scenario? I will tell you what it is.

A trusted sysadmin who has gone rogue.

Let's say that Gavin or Coblee's best friend and most trusted sysadmin in the whole p2p exchange network who's name is Charles decides:

Quote

Hey, I am tired of making peanuts for salary. I got a quarter million dollars in BTC in the wallet banks of my server. I think I will just empty them and then go to Cancun.

How do you stop a sysadmin who has gone rogue and has physical access to a server?

The truth is you cant.

and that when the second answer came to me:

Quote

Remove the wallet.dat files.

Remove the wallet.dat files? If I remove the wallet.dat files from the server then how do conduct cryptocurrency transactions?

So, I though about it. Then I hit me. Like a ton of bricks.

It was genius. Plus, I could not believe that I had the answer all along. The answer was something I was already doing for my personal security.

Then I realized the answer was to use something that I call a "disposable wallet"

(I AM WRITING THIS AS YOU READ IT... CLICK REFRESH TO UPDATE THE SCREEN)

Disposable Wallet Method:

Just what is a "disposable wallet"? Its not just a wallet you use then throw away. Its way more complex than that.

A "Disposable wallet" is a one-time use wallet whose contents are in an un-redeemed state in the blockchain. Once the private key is imported into the Bitcoin client and a transaction has occured the wallet is then discarded. Any coins left over from the transaction are sent to a new "Disposable wallet" and those coins also remain in a non-redeemed state in the blockchain as well.

Disposable wallets are brain wallets that you generate using something like bitaddress.org.

If you click on the brain wallet tab of the site and enter a passphrase:

Quote

maryhadalittlelamb

the javscript will output this:

Quote

Bitcoin Address: 1Fcf6bCJWt2UGkK9fnTWnynY9dMcoA2v3v

Quote

Private Key (Wallet Import Format): 5KgCWZGaSqAFv5Fv74thJR4Gzv4KFPX13q4WidDmELnYNHoqGNf

After the wallet is generated. You can immediately send money to that address:

Bitcoin Address: 1Fcf6bCJWt2UGkK9fnTWnynY9dMcoA2v3v

If you send money to that address and do not use or import the private key into any bitcoin client then the transaction will be added to the blockchain and the coins will have a status of NOT-REDEEMED.

As long as you do not import the private key in to any Bitcoin client the status will not change.

A "Disposable wallet" is a one-time use wallet whose contents are in an un-redeemed state in the blockchain. Once the private key is imported into the Bitcoin client and a transaction has occured the wallet is then discarded. Any coins left over from the transaction are sent to a new "Disposable wallet" and those coins also remain in a non-redeemed state in the blockchain as well.

How does that help secure the p2p exchange servers from rogue admins?

The answer is simple:

After generating the private key, you split the key into multiple parts and then store them on multiple servers in the p2p network.

With this scenario, there are no wallet.dat files even stored on the server. All that is stored are partial private keys.

If a rogue admin tries to access the wallet banks all he will be able to retrieve are partial private keys.

So how do you conduct a transaction?

With something I call a "wallet-virtual-server" or "transaction-server" or "wallet-bot".

I will tell you about "wallet-bots" in the next post.

(I AM WRITING THIS WHILE YOU READ IT... CLICK REFRESH TO UPDATE THIS POST.)

Quote from: btceic on May 26, 2013, 04:22:59 PM

How about making this into an easy to install pre-configured linux/bsd distro?

Users would be able to download the ISO and run it on just about any machine.

From my near zero knowledge of linux and from what I recall with speaking about it to colleagues over the years a variant of NETBSD is the most hardened out of the box no?

The point I was making earlier when I said that I could make the whole system with just Linux tools was that; if I could do it, then it should be easier for a software developer to do it.

If you know C, C++, or php you can do it a lot better than I can. You can make it more secure as well. I was just demonstrating the ease in which it could be deployed.

Perhaps a combination of Linux and Code. That would be far more secure.

You don't have to use a SQL database. Use a flat-file dB or anything you want.

Disposable wallet method can be further secured using the following means:

1. Add a TTL (Time To Live) to the disposable wallet. Whether there is a pending transaction or not, set a TTL on the disposable wallet. This way a rogue admin would only have a limited time to try an attack to collect all of the partial key pieces from the servers in the p2p network.

2. Because there are replicated virtual servers keep more than one online. I know I said earlier to keep one virtual server online and the replicated copies offline. But now I have changed my configuration and design. Keep more than three virtual servers online at a time. Split the partial keys up between the online copies, offline copies, and other semi-offline virtual servers that are not linked to that particular virtual server. for example:

NY-p2p-Server
home-virtual-server-002......online......wallet-key-home-virtual-server-002-bank-001-wallet-004.dat-segment-A-XXXXXX-A-segment-end
home-virtual-server-005......offline......wallet-key-home-virtual-server-005-bank-005-wallet-002.dat-segment-G-XXXXXX-G-segment-end
home-virtual-server-007......offline-monitored......wallet-key-home-virtual-server-003-bank-001-wallet-001.dat-segment-M-XXXXXX-M-segment-end
home-virtual-server-009......online......wallet-key-virtual-server-009-bank-003-wallet-003.dat-segment-P-XXXXXX-P-segment-end

This way a rogue admin would have to hunt the keys down outside of his home-virtual-server groups. The final key he may need may be on a home-virtual-server that he doesn't even know exists on a physical server on the other side of the globe.

3. Rotate newly generated disposable wallet partial keys among the home-virtual-servers.

4. Make sure each generated key is large enough to be split into 25 parts. Split then label each part from A through Y or B through Z.

5. NEVER KEEP MORE THAN $1000 IN ANY WHOLE DISPOSABLE WALLET. I will explain why later when I explain about wallet-servers or wallet-bots. I will also introduce you to another wallet called an insurance-wallet.

6. Set hierarchies for the wallet-bots with most handling transactions of less than $100 USD. Higher more secure wallet-bots from more trusted admins (with higher insurance fees) can handle larger amounts. Again never allow any single wallet-bot to handle more than $1000 USD. Period.

Wallet-virtual-servers - AKA wallet-bots

A wallet-virtual-server just has one purpose. That purpose is to:

1. To retrieve the wallet private key segments, assemble them, then import the whole private key into the Bitcoin/Litecoin client.
2. Conduct the transaction.
3. Generate a new disposable wallet.
4. Transfer any leftover change from the previous transaction to the new disposable wallet address (This will be an non-redeemed transaction in the blockchain).
6. Discard the old disposable wallet.
5. Redistribute the new disposable wallet private key segments among the home-virtual-servers in the p2p network.
6. wipe memory / reboot / whatever is necessary to forget the newly generated key.

Now wallet-bots have rules:

1. Wallet-bots cannot store any information.
2. Wallet-bots cannot retrieve key segments on its own.
3. Wallet-bots cannot retrieve the same key segments that it has disbursed to the p2p network.
4. Wallet-bots are designed to work in groups. A $25,000 USD transfer transaction would require 25 wallet-bots with each bot handling one transaction of $1000 USD.

Quote

Note: A rogue wallet-bot can be mitigated by setting a TTL (Time To Live) on the disposable wallet. This is set by the home-virtual-servers that hold the private key segments. When the TTL is expired a different wallet-bot will be used to generate a new address/key and transfer the holdings to the new wallet address; then reallocating the segments to different servers on the p2p network.

If a rogue bot did manage to steal coins from the network then the p2p network would immediately revoke the keys of the bot, identify the owner/admin of the bot, boot the bot from the p2p network, and the loss would be no more than $1000 USD.

An insurance bot would then activate and complete/replace the transaction of $1000 USD. The funds would come from insurance fees charged to the owners of the servers on the p2p network.

It is best to charge insurance fees to the admins on the p2p network. The admins would recoup the cost by charging transaction fees for the use of their server.

If an admin's server was used in any transaction on the p2p network, the admins could charge a transaction fee to the users involved in the transaction. This also gives admins incentive to be honest in service operations.

If you are reading this or printing this out then you might want to re-read or re-print this thread. I have made changes to the configuration and security practices. Most of the changes are on from the Disposable Wallet Section.

ALT-COIN SECURITY

USE WORTHLESS ALT COINS TO DO TRANSACTION VERIFICATION BETWEEN NODES.

All of these new alt coins being created everyday are not necessarily a bad thing. Crypto-coins and their corresponding blockchains can be used for other things besides money. Like securing transactions between P2P nodes. You can use worthless alt coins as transaction verifiers throughout the entire p2p network; and its more secure than using CA certs, pre-shared keys, or other more complicated security setups.

For high security, don't use other alt coins. Make your own customized alt coin for the same purpose. You don't have to worry about double spend attacks because you are only using it for the purpose of securing transactions for the p2p network and you are the only one with access to the coin. Make a coin that is fast and can be mined easily. Afterward, pre-mine it to the hard-limit with enough coins to support the entire network. You wont have to worry about it retaining a monetary value because its pre-mined. Don't give any coins out to anyone except server admins. It shows the users on the exchange that a server admin is validated because no one should have the coins except for server admins.

The good thing about alt-coin security is that no one will have your coin except you. As long as none of the admins don't send their coins to other people. If they do you can find out by doing an blockchain analysis. If no one has your coins except for you then that makes it much harder for a hacker to compromise the p2p network integrity.

Security-Coin Validation
Use the blockchain to verify where the security-coins came from. If a server node sent you security-coins from a wallet address of ABCDEFG1234567 to validate a specific transaction you can verify where the security-coins came from by doing a blockchain analysis. The analysis will show where the security-coins came from. If the security-coins came from an address that you do not know or is not listed in the security list you know not to perform the said transaction. It that simple. No ACLs, no certs, no keys, just alt-security-coins.

High Level Security-Coins
For sensitive servers such as high level wallet-bots use a different security-coin than that which is used by the rest of the network. Only give it out to server admins that are high level. This provides an additional layer of security within the p2p network.

Keep Track Of Every Coin
The head of the p2p network can disburse security-coins to the server admins for transaction verifications and tolls on the network. As the security-coins travel from the server admins to other nodes, you can make nodes to collect the security-coins and bring them back to you. A security-coin audit can show if any security-coins were lost and where they went and who lost them. This provides better security than other methods; in addition, if a server admin and his nodes are booted or fired from the p2p network you can blacklist his wallet address or refuse to give him more security-coins to perform transactions and pay tolls on the network.

Transaction Tolls
Transaction Tolls provide a way to control and maintain the p2p network. Certain nodes require certain security-coins and a specific amount. For example, a high level transaction involving a large sum of money might require a larger amount of security-coins before the transaction will take place. Only admins with that amount of security-coins will be able to perform the said transaction.

Security-Coin Dual Wallet Application
I recommend coding a dual-wallet application for the wallet-bots. Code the wallet application so that the Bitcoin/Litecoin wallet will not send cryptocurrency to anyone unless there is a sufficient amount of security-coins to perform the said transaction. You can hard code the security-coin amounts based on how much cryptocurrency is sent. This would make it much harder for a hacker to get the bot to send coins to an illegal wallet address.

Append the Sec-Coin Wallet Address To The Name Of The Node
Name the sever nodes on the network with their corresponding sec-coin wallet address appended so that users and end-user clients can view the sec-coin blockchain to verify that the server performing the transaction actually has sec-coins and enough of them to perform the task. If a rogue server-node spoofs a sec-coin wallet address and attempts to perform a transaction on the p2p network, the transaction will be denied because the rogue node doesn't have any or enough sec-coins to complete the transaction. Verify the transaction afterward by examining the sec-coin blockchain to see if the balance has changed. If the balance is still the same then you know a rouge server was spoofing a valid servers wallet address. When the transaction confirmation comes back to you, deny the confirmation. If you know that a sec-coin transaction costs five sec-coins and the balance has changed by four; again, deny the transaction confirmation when it arrives.

(I AM GOING TO TAKE A BREAK... BE BACK LATER)

Use a Proof Of Stake Alt-Coin
As much as I do not like "Proof of Stake" coins, I have to admit that they are better to use for sec-coins. The reason for this is because sec-coins are purposely pre-mined. What that means is that the pre-miner should be the largest stake holder.
Being a "Proof of Stake" sec-coin, any attack against the sec-coin will be far more expensive for the attacker as opposed to using a "Proof of Work" sec-coin.

Keep The Sec-Coin Secret
Once you download the open source version of this p2p software (when it is made) and are going to customize and use your sec-coin; do not release the newly customized alt-coin that you are going to use as a sec-coin. Do not release the customized source code. Do not release the software clients binaries after you have compiled them. What I am saying is, keep the sec-coin secret and confidential. This is going to be the foundation of your p2p network security. Do not announce pre-mining operations to anyone. You don't want anyone else mining your sec-coins while your pre-mining operation is going on.

*I am not saying that I will develop this p2p software that I am designing, but I imagine the developer of the software will release the code as open source (as per my request at the beginning of this thread).

Set a Hard Limit on each Sec-Coin you create
Pre-mine each set of sec-coins to the hard limit. If you set a hard limit on each set of sec-coins that you pre-mine and you mine it to the hard limit; no more coins can be made after your pre-mine operation is over. If you pre-mine one million sec-coins then make sure no more can be made afterward. Pre-mine multiple sets of sec-coins for different purposes and security levels.

Keep Track of the Sec-Coins You Pre-Mine
Keep count of the sec-coins that you have pre-mined. Since you pre-mined the sec-coins to the hard limit, you now are obligated to keep count of the coins. If you lose any sec-coins that you have pre-mined, they can potentially be used against you if a hacker gets his hands on them.

Wholly Abandon Any Set of Sec-Coins If Some Of The Coins Are Lost or Stolen
If a rogue admin sells some of the sec-coins that you made, or you somehow lost some; then you need to wholly abandon that particular set of the pre-mined coins. If you have pre-mined multiple sets of sec-coins just replace the set with another or pre-mine some more. Whatever you do, I urge you - Do not use any of the sec-coins from the set that was compromised. Dump them on the market (they may have value if your p2p exchange is popular) or throw them away. Once again I tell you: If you lose any sec-coins that you have pre-mined, they can potentially be used against you if a hacker gets his hands on them.

(CHECK BACK TOMORROW FOR MORE UPDATES... THANKS EVERYONE!)

Quote from: mberg2007 on May 29, 2013, 08:50:02 AM

Hello,

Things seem to be drifting in a direction which is pretty far away from the original goals. Users creating alt coins?

All the end user wants is some software he can run, which will facilitate a secure currency exchange without any need for a central server. That is the goal. I think you should focus on that and keep all the other good ideas for another time and another project.

-Michael

Sorry I have been away a few days. Been a little under the weather. But I am back now.

Michael,

The end-users would not have to create anything. Just install a plug-in into their bitcoin software.

You asked me in a previous post about security measures in the p2p exchange. The security coins (sec-coins) are a supplemental method keep secure the p2p network infrastructure.

The processes that I am writing about on here are background processes that the end-user does not see.

The end-user would not ever see the sec-coins. His client would perform all of the validations. All the user does is click yes or no to confirm the transactions.

Please understand that p2p networks are decentralized by nature; so, not all of the server operators are going to be honest, good hearted people. So the network must be designed to be functional while keeping a good measure of security to protect the end-user accounts.

This thread and my design are geared mostly toward software developers and system admins who would be interested in developing or deploying such a system.

Blockchain vs "Federated" p2p system.

I must admit that the system being designed on this thread is indeed a "federated" type system. Any p2p exchange is going to have to have some sort of federation in order to be successful.

What will make the system liberated are the various p2p exchanges interlinked through contract agreements enforced by protocols built into the system. As I explained in an earlier post, a group such as Anonymous could produce a p2p exchange in their name then interlink it to another group such as Kim Dotcom's Mega. Both could have connections to Fiat converting sites such as MTGOX and BTC-e. Users could choose which p2p exchange they wanted to have their account on, then be able to move that account to another p2p exchange if so desired.

Because this system is built on an application stack there is no need to "reinvent the wheel". The blockchain would still be utilized by the bitcoin/litecoin/cryptocurrency clients at the bottom of the stack.

Being a federated system the owners of the system should allow anyone to join as an admin (so they both can make money). The admin would charge a transaction fee to the end-user if his server is used in any transactions. This allows the federated system to be open to anyone interested in becoming an admin and deploying a physical server to house virtual-servers on the network.

The sec-coins would allow a measure of control over the entire p2p network. The sec-coins would only be seen by administrators on the network.

Quote from: usscfounder on May 18, 2013, 05:50:50 PM

An europian platform is launching cryptocurrency exchange named as blockchain.io. One can visit the webpage and get more information about the same. This exchange ensures quick transaction in lesser time and will work globally.

Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: usscfounder on May 18, 2013, 03:31:13 PM