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

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

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

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

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)

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)

 

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)

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)

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)

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

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