Perhaps I should have waited to post : https://bitcointalk.org/index.php?topic=852917.msg9489290#msg9489290

Though my idea was generating two private keys from many private parts generated on different sides and shared in certain steps so that they both reveal each others private keys at the same time. (while leaving proof that the transaction occured and both addresses in fact were derived from shared keyparts.)
A few public keys from the transaction along with signed transaction logs from all three parties would be added to the public ledger (for each node that can process the type of request ie: BTC - LTC | LTC - DOGE)


Since private keys are essentially large numbers there shouldn't be any problems using different ECC curves in generating keypairs from another curve when being used in split key generation.

Though the keys would appear different the math involved would never change the fact that we are just adding, subtracting, multiplying, and dividing large numbers on scalar charts. I don't believe there would be issues with prime number curves either.
Perhaps to add a type of miner to the system it could use a private key that is partially known with a range of numbers that could have been subtracted from it to give it a sort of difficulty and require the miners to find the missing keypart solution.

o.o I just read that stuff and my chart is almost exactly what that thing is.

Would a lite node.js p2p version of this win the bounty?

Federal regulations (recently clarified that they apply) require them to have security systems that cover their audit systems.
ontop of that they are required to also have an anti laundering system.

Especially since they qualify as MSB and need a Money Transfer License in order to be operated.

What exchanges do you use?

This actually sounds remarkably similar to something I am working on:
https://bitcointalk.org/index.php?topic=852917.msg9489290#msg9489290

Your systems could easily be spoofed upon a database breach. I believe you should take a look at forms of verification to prove where the transaction is from and who it is to. The server should also have a method of proving it allowed the transaction within the system. Otherwise once a hacker gets inside they will have a hayday with your money. Other things to think about adding are systems such as solvency ensurer.
In my system I use private keys that are generated on the browser. The users use them when making requests so that their requests can not be faked
by another person. Their requests are also usable once unless they sign again and send a new signature.

You should really take a look at reworking your whole account structure.

Currently we do see an issue with many transactions clogging the queue. Could we convert the wallets to broadcast anyone can pay transactions so that any wallet that sees the transactions could append to it? That would mean many people could accomplish all of their moving in single lump transactions. Perhaps just by letting anyone can pay transactions be rebroadcast and used if available is a better solution. Could that also be a great method of mitigating dust attacks on top of keeping the minimum send amount?

Hi, I have just spent the last 12+ hours working on a mind racking concept to allow trading between seperate cryptocurrencies PEER TO PEER without the need for operator trust. The main issue faced by other similar projects is ensuring the node nor the buyer/seller could trick the system or steal the money. I believe this graph represents a great method of removing the risk of peer to peer trading. I believe in this structure The Clients (Left and Right side) can safely make a trade after the node has helped them find each other.


http://ress-luapod.rhcloud.com/Diagram.jpg


In my head everything plays out. I am working on doing a concept if any programmers would like to give some assistance!
Any pointers would be great! This (in theory) removes completely the need to trust that the other user will send their secret key.


Another Method:

Two transactions are made (timelocked hashlocked transaction.) Instead of A1 and A2 outputting address keypairs it would output a key that will redeem your transaction!  


A trading ledger will exist with the math to prove trades could have occured. This ledger will be used by the network to determine the stability and trustworthiness of a node.
The information that will be recorded onto the ledger will be the Public Keys used in the process of generating the Two addresses. Since they both can be verified as being derived from the
nodes key which it gives out in the beginning of the transaction. In order for the ledger to be accepted into the system the trading wallets must sign a response that will be signed by all three
parties, the node and both clients,  If either of them disagree to this signing step the transaction will not continue and the funds will instead revert back to their accounts after the timelock.
Therefore keeping a nodes trust level low and fractional trust points removed. The trust points are merely used to determine their position on the Node list and availability on the network (Transactions failing from no-response causes the trust score to drop)

In the systems I am developing at LuaPod we do not store our funds as float or double values. They are stored in single satoshi increments
(1 = 0.00000001 )

The wallets are not capable of being accessed by the webserver. In fact our balances
can not even be adjusted from the webserver if it were compromised. The main thing
we are doing to create a form of transparency is disclosing full access to the front-end
database. The system in order to continue running and in order to make withdraws must
also pass several steps that are described at : http://xboxtrial.cf/info/info.lua

Companies should move towards being more transparent is what needs to happen
in order for us to get a consensus of what is going on. Most of the money stolen
has actually been because these systems somehow had control over the money in
areas where users had frequent access (such as webservers)

The domain is a demonstration (Hence the reason deposits are not allowed)
of a framework that I have been working on since Jan.
Next month we are coming out with full access to the front-end sql user.
Incorporating also (in the new base) elliptical curve signatures so that client requests are signed and can't be
forged without having the private key.


The xbox codes are given out in the shop in exchange for Lua (Moon) which are earned by doing surveys.

The site doesn't have any form of income other than that. As I have said right now it exists primarily for
demonstration.






As for the security of this vanity pool
We have no need for your private key so we don't even ask for it.
The private key and public key you must generate are generated on your browser at another site (not belonging to me)

The public key is used by the miners to generate a private key part which if added to your other private key which
you have kept hidden will be the main private key to control the address belonging to the public key of

Public Key 1 + Public Key 2



A nodejs method of verifying the submitted work (Without the private key) is:



Whenever you sumbit a request for a vanity address you must submit a public address.
For that public address you will have the matching private key. WE DO NOT ASK FOR THAT
The private key is required by you to generate the full private key with the mined private
key part.

LuaPod is allowing public use of it's demonstration website's Vanity Pool NO FEES AND WE DO NOT ASK FOR YOUR PRIVATE KEY.

http://xboxtrial.cf





This is a secure vanity pool that was built using the software VanityGenMiner
It operates securely by calculating addresses in a two part step called
split key generation. In order to make a Bitcoin address you need a public key
The public keys used by Bitcoin (to my understanding) are ECDSA (Elliptical Curve)
Which is another method of saying A HUGE NUMBER that is graphed with points.

The public key and private keys are technically "huge" numbers.
We can actually do two steps to generate a single private/public key from two.
The logical laymans math is this:

Bitcoin Address = bitcoinshafunction(Pub Key 1 + Pub Key 2)

and the Private key for that address would be

Main Private Key = Priv Key Part 1 + Priv Key Part 2


Since we are capable of generating the Bitcoin address with just the
public keys we are able to keep the other Private key hidden
and even out of our servers hands. This is kept safely by the user.




Newer methods are being worked on and do exist for split address generation
such as multiplication however these two options provide the same amount of entropy regardless.
The chance of hitting the same key is 1 in an unthinkable number for me.

Here is a statistic that sticks pretty well for most people:

 Over nine thousand

classic

I have spent a year racking my brain on this. I have pretty good confidence in it's security and stability (Except that the webserver currently doesn't have ddos protection turned on)

So much faith that even with the authentication given out I believe that it is safe still.

Server Login:

justin7674
HACKMEPLEASEorz94358




#Wastingmylifewaitingformagic

I have 1 bitcoin on that server. Almost EVERY btc exchange hack is the stupidity of the creator and programmer.  


PASSWORD WILL REMAIN THE PREVIOUS SAID FOR A MONTH

I will give you the username and password for the DB right now

Mysql_User = "front-end"
Mysql_Pass = "m1taLu4ayu84vO7eVu27JOw1vIk7mo"
Mysql_Host = "25.15.147.88"


DNS NAME
luapod-sql.cloudapp.net
HOST NAME
LuaPod-Sql
PUBLIC VIRTUAL IP (VIP) ADDRESS
191.238.226.47

There you go. I already thought of the things you have said. The system is secure enough that I can give a hacker the mysql information and they would be incapable of financially harming me NOR revealing private user information other than email addresses.

The funny thing is you still couldn't get access to the database.


Also, the database isn't encrypted. The signature and hash passwords are entered upon each server boot. You would have to intercept me trying to boot the software. But good luck getting past the subversion code control with code signing.

How could you make changes with a SQL user that has no write access to any of the finance tables nor any direct access to methods manipulating balances? If you were to read the description on the front page it clearly states that the SQL gives no permissions to the front-end except to view user information and to view balance information. IT can submit a request to be processed by the back end server that is structured like
create/trade/5/1000/100/5 and is signed and encrypted. Even if you managed to figure out the signing and encryption the backend servers do another check to verify the trade is even allowed to be created.

The servers all are on a closed network with communication enabled ONLY to the SQL database. Each server has its own SQL user with its own permission.



To even prove that you lacked the true effort of reading here is an excerpt from the main page:




ANOTHER THING IS you can't just change a balance on this. If you change the balance on any transaction the system comes to a halt (because it detects that there is an discrepancy between the information inside the account balance and the signature for the transaction that has been changed) NOT ONLY does it know that it has been changed, but it knows what it was changed from. So through a type of persistence I can also keep transactions from being deleted.

YOU ARE EXACTLY RIGHT! The reason exchanges keep getting hacked is because their webservers have some sort of access to the MONEY. Take a look at luapod if this is your type of area. I have already completely separated the handling of users money from the webserver. The webserver actually has no permission to handle anybodies money. It only builds and signs requests. EVEN though a request is signed that doesn't mean the backend server accepts it as true. The backend does its own check on the information. You can read up a little bit on how it works at the index page: http://luapod-web.cloudapp.net/index.lua



If I wanted to I could have my computer running a VPS with 13 GB of ram aloted and close all ports with outbound requests only. I could then use that Virtual machine to run the wallets. No ports being forwarded or any direct communications from anything. The servers decide their job based off of the Mysql Database they are connected to through a virtual network that is hub and spoke managed.

http://luapod-web.cloudapp.net/index.lua







Rules of LuaPod Moneys:
Steps of Withdraw:
   
Why This Structure?


Rules for Continuing Operation:

   
-----Network Information-----
   
   Network Rules:
      1. Webserver:
      2. Wallets:
      3. SQL:


[This is the current behavior of the LuaPod main and sub-systems]

Any opinions?



I believe a system structure of this nature could have protected many exchanges and perhaps in real world scenarios where finance companies through a fluke were losing millions and not even knowing.

BlockChain implements their own storage methods for the blockchain if I am correct. They have things "pre-indexed" as a laymans term. As you said listunspent is actually a very good method of doing it.

Np, I will be keeping my eye on this for sure.