Bitcoin Forum
November 09, 2024, 07:24:13 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [ANN] P2P Decentralized Orderbook  (Read 851 times)
usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 22, 2013, 04:35:48 PM
 #1

I have designed a system for a P2P decentralized orderbook:

I have created a system for a P2P orderbook here:

https://bitcointalk.org/index.php?topic=209269.0

I figured out how to make a P2P Orderbook for a decentralized exchange:

I am updating the post daily but will add more in a few minutes:

https://bitcointalk.org/index.php?topic=209269.0





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)

 
More here in a few minutes:

https://bitcointalk.org/index.php?topic=209269.0

Here is how it works:

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




https://bitcointalk.org/index.php?topic=209269.0
usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 23, 2013, 06:55:44 PM
 #2

I have clarified my description of design to help with development:

https://bitcointalk.org/index.php?topic=209269.0
usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 24, 2013, 05:01:38 PM
 #3

New Updates!

https://bitcointalk.org/index.php?topic=209269.0


Example BTA Transactions

Bob sends Alice 10 coins

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

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

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

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

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

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



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

(Continuing...)

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

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

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

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

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

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

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

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

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

16. home-server-001 then

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

usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 25, 2013, 08:10:56 PM
 #4

New updates:

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, and a host of Linux tools (ssh, cron, bash, etc..). 

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

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.

https://bitcointalk.org/index.php?topic=209269.20
usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 26, 2013, 05:15:15 PM
 #5

New Updates:  Disposable Wallet method stops rogue admins from stealing coins in wallet banks:

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 brain wallet 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 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" I will tell you about that in the next post.



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


https://bitcointalk.org/index.php?topic=209269.0
usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 27, 2013, 03:34:46 PM
 #6

I have made some new Updates. I also introduce a new concept called security-coins to be used in place of acls and digital certificates.

https://bitcointalk.org/index.php?topic=209269.0

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 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 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 show the people 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 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 the where the coins came from by doing a blockchain analysis. The analysis will show where the coins came from. If the 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 large 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.

 






(I AM WRITING THIS AS YOU READ IT...   CLICK REFRESH TO UPDATE THE PAGE)
usscfounder (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 27, 2013, 09:50:24 PM
 #7

New Sec-Coins Thwart Hackers & Rogue Servers on p2p Exchange

More details here:

https://bitcointalk.org/index.php?topic=209269.0

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 from the Disposable Wallet Section on.


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


More details here:

https://bitcointalk.org/index.php?topic=209269.0


Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!