Just building my user database.. how should I manage users bitcoins? I am trying to automatically assign every new user a public key for which only I know the private key. Please help me I am really really stupid.--
-- Table structure for table `users`
--
CREATE TABLE IF NOT EXISTS `users` (
`name` varchar(15) NOT NULL,
`surname` varchar(15) NOT NULL,
`country` varchar(15) NOT NULL,
`address` varchar(30) NOT NULL,
`password` varchar(15) NOT NULL,
`email` varchar(30) NOT NULL,
`username` varchar(15) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
-- Dumping data for table `users`
--
INSERT INTO `users` (`name`, `surname`, `country`, `address`, `password`, `email`, `username`) VALUES
('Carmine', 'Benedetto', 'Italy', 'Via Campania, 3 56124 Pisa', 'neoben', '[email protected]', 'neoben'),
('John', 'Snow', 'Winterfell', 'Lord Stark''s Castle', 'winteriscoming', '[email protected]', 'bastardsnow');
>>51637298
By automatic I mean randomly unique public key that is different for every client.
>>51637336
you're fucking joking, right?
you sure you only want 15 character long names anon
also whats wrong with just giving them an auto incrementing ID and then hashing it when you need to display it to them
>>51637374
No I am just that retarded please help.. I am new to this shit.
>>51637298
>Writing raw sql
AHAHAHAHHAHA
We have thse things called ORMS OP, You can write your SQL and have it translate to almost any SQL implementation and their little quirks.
>>51637298
Medium rare bait.
>>51637396
>auto incrementing ID
No I want a completely random public key for the privacy of the users.
>>51637465
>duplicate keys though
let me just explain this for you. you give everyone an id (for each row in the table of their info).
say carmine gets id 0, john gets 1.
by hashing you can make the 0 appear as 019O12DNOC124 with the right algorithm. you'd use a single key that is private to convert the id to a hashed value.
think how youtube video urls exist. they are hashed ids. so video #24987 becomes ?v=091fc4
^ simplified explaination, but really not that hard.
>>51637416
>thse things called ORMS
>thse
I am a COMPLETE RETARD.. don't use your technical lingo on me.
>>51637529
What are my other options? also have any other business used your model..
>>51637529
This is actually fucking really smart yet minimalistic. How should I go about creating the algorithm?
>>51637529ID int NOT NULL AUTO_INCREMENT,
Just trying to understand how to automate the hashing process with PHP.
>>51637298
>how should I manage users bitcoins?
Why not just use one of the many Bitcoin APIs that exist instead of trying to re-invent the wheel with your own implementation?
>>51637609
>>51637733 if you *really* want to roll your own then any bijective function should work really. you could even use base36 - at the end of the day if your database/website gets compromised you're still fucked
>>51637766 fucked up the replies, too tired for this shit anon
using someone else's bitcoin API is better than rolling your own, but if you really must then what i suggested should probably suffice
>>51637766
I just wanted to make sure that I could truly verify what I was doing and also educate myself.
>>51637949
np anon, though maybe consider doing a few smaller projects before tacking something that requires a fair amount of security
like you should probably know what an ORM is - not that it's necessary, but its a staple in web dev, really.
that being said there is merit in knowing SQL. ORMs don't solve everything (and sometimes the database is so trivial you don't need it)
object relational mapping - basically you can interact with a database via your chosen language (php, unfortunately) as if it was an object.
>>51638112
Really glad people like you are able to help. This site would be a larger pile of shit without you. Thanks.
>>51637949
While there is merit in wanting to create your own implementation for the sake of learning... if you're dealing with sensitive information (such as anything related to money), or security, and you have ANY plans at all of putting your project in some sort of production environment for people to actually use, it's better to just go with something that's been audited and tested thoroughly.
Years ago I created a simple online bitcoin wallet using PHP and an API. It handled everything like generating bitcoin addresses, checking for valid addresses, relating addresses to user accounts, etc. There is no need to store information about users' bitcoins in a SQL database, it just introduces another layer of potential security holes
>>51638500
>dubs
Thanks for your honesty.
>>51637609
Get a degree nub
