|
A solution I am looking at is a type of automated hierarchical key generation. I want to remove the human element as much as possible. I will give the "mayor" of the city power over they top level nodes. But everything else from there would be automated by the nodes according to hierarchy. I will explain later.
|
|
|
|
This looks awesome wish you the best, can't help any as i can't code anything.
That's fine. Whatever you can do would be appreciated. We all need to work together to help come up with a solution. |
|
|
|
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.pdfGive me some time... |
|
|
|
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 |
|
|
|
|
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 Wikipedia: MintChip is a digital currency concept that enables digital transactions backed by the Government of Canada and denominated in a variety of currencies. Can anyone verify if the U.S dollar is one of those currencies? If it is then there is the solution to all of the liquidity problems the cryptocurrency community is facing. I don't know if they mean other (foreign) currencies or just the Canadian denominations? |
|
|
|
|
Can MintChip Be Used To Do Fiat Conversions To or From Bitcoin?
MintChip is pegged to the Canadian dollar I believe. Is there a way to use this method to do fiat conversions of cryptocurrency without having to register as a "money transmitter"?
|
|
|
|
|
So is there a way to use mintchip as an avenue to solve some of these problems? Don't get me wrong; I do not like mintchip and was against it from the start but if it can be used as a loophole to do fiat conversions then I am all for it.
|
|
|
|
|
I could be wrong, but isn't mintchip pegged to the Canadian dollar?
If you can convert mintchip back to usd without having to register as a "money transmitter" then that would solve your liquidity problems on a p2p exchange (or any exchange for that matter)
|
|
|
|
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)
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.) |
|
|
|
(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) |
|
|
|
|
Its obvious that you did not read all of the post.
Go back and read about the multi-teir BTA
Its a decentralized exchange.
What that means is that even if you were somehow able to hack one of the tier-I BTA-virtual-servers you would only affect a very very small percent of all the users on the exchange. Its decentralized!
This design is designed to be resistant to seizure and DDoS attacks. Theft is mitigated through the use of multi-server interactions. (You might find out if you let me finish my example).
What would you propose for a decentralized exchange? Ripple?
I worked at four banks and at a Internet Data Center. Most of the platforms I supported had systems that were not "compiled into binary". What planet do you live on?
|
|
|
|
The greatest part of security for this p2p network will be in the interactions between the servers. In order to hack the system multiple servers would have to be compromised. 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.
If your worried about the wallet banks you can put them on separate secure wallet-virtual-servers that will process the actual cryptocurrency transactions. There are a number of ways you can make this network more secure. This design is to show the feasibility of a p2p decentralized exchange. |
|
|
|
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. |
|
|
|
New Updates!https://bitcointalk.org/index.php?topic=209269.0Example 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!)
|
|
|
|
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!) |
|
|
|
So, is this like, an offshore bank account, for BTC?
A offshore p2p virtual bank account for BTC |
|
|
|
|
Show Posts
