What do you mean, "get the private key securely?". Just use a decent wallet on a clean computer (or even better: a hardware wallet), it'll generate your private keys for you in a secure way..

If you want a private keys whose public key hash results in a vanity address (an address starting with, or containing a certain sequence of desirable characters), franky1 already answered your question: vanitygen

https://en.bitcoin.it/wiki/Vanitygen

*disclaimer*: the following text reflects my personal beliefs, they talk about my gut feeling, so the following text should in no way be interpreted as an official statement

I personally believe that the altcoin/bounty subforums is filled with scams... Just pump and dumps, quick scams or worthless shitcoins. I guess a maximum of 10% of the announced projects in these subforums have some sort of legitimacy (at least, i belief a maximum of 10% of the announced tokens start with good intentions), and only a very few of those 10% actually result in a project that does what's promised. The other projects are just some get-rich-quick schemes, or just script kiddies trying to clone some coins in order to get famous.

As soon as i see a token/altcoin announcement talking about a serious subject in combination with the word ICO, bounty, campaign,... I just stop reading... It's not worth my time.
These scammers usually just pick a subject, any subject, create a colorfull ANN thread with a mock whitepaper, clone a clonecoin and try to scam the community by releasing an ICO, and try to draw community members into their madness by promising stakes of their scamcoin if they promote the hell out of it.

As far as i'm concerned, i haven't seen any believable project that combines medical data storage with a believable token... But like i said: i have an extremely short attention span when it comes to new altcoins. As soon as something (anything) seems off to me, i just walk away... It's not worth my time.

Well, like i said: it's a dual answer.
Easy technically: sure, just find a competent dev and he'll be able to create a blockchain in a matter of weeks
Easy legally: nope, not by a longshot... In a lot of developed countries, the medical secret outweighs even some legal affairs.

Just do the exercise without thinking about blockchain technology... Just imagine if you were uploading data onto a medium like facebook, redit, twitter but you only had an account that was able to post data, but doesn't have the authority to edit or delete data...
Which patient data would you be willing to upload? My initial reaction would be: none... Not even with a signed informed consent from the patient, Not even the initials of your patients, Not even the internal database's private keys (which would be utterly useless without a complete data breach of your hospital),...

Being from the EU myself, i can safely say that even within the EU there would be hardly any data you could ever upload without getting into ethical or legal problems. I mean: at the time i was working in the healthcare field, there were a couple of EU countries that had a law that forbid any patient data to leave the country. You could not rent secure data storage in the US and store encrypted backups of your patient data abroad without opening yourself up to a lot of lawsuits.

I think if you're really going to continue with this plan, it might be best to contact an international law firm with experience in the healthcare business in order to assist you... Nobody on this forum (not even the ones like me, with IT healthcare experience) will be able to give you any foolproof advice.

I have worked in the healtcare industry myself for about 8 years in the past (i'm currently not working in the healthcare industry anymore), i do think you're touching a very delicate subject.
In the past, there were some really tough laws in place to protect patients data, and recently the laws seems to have gotten a lot tougher.

I remember having to encrypt all data that was being sent to the governement, upload it to a sftp whose keys were exchanged in person, then send the encryption key on a dvd via snail mail, and the password to unlock the key via text message, and the hash of the encrypted data in a signed letter to a different instance... I just wanted to point out that even in the past, the security measures with patient data were rather paranoid

The problem is that a blockchain is a public, immutable, trustless, decentralised ledger. Anything data you include in a block is there to stay.

• What if the patient changes his mind? There is no way to "erase" his data
• What if data that is considered harmless at this point in time, becomes something of great intrest/value to for example insurance companies (for example, at this moment in time, you think it might be a good idear to record your pollen alergy into a blockchain, but in 50 years pollen alergies get linked to a specific type of terminal iless and an isurance company decides to double the premiums for everybody having a pollen alergy based on this data
• I've also heared some companies saying that anonimising the patient's data is the sollution, but what if the key gets leaked? What if one of the hospital's databases gets breached and a hacker is able to link each anonymous key to a real life person?

I'm not saying it's a bad idear, i just think a person who wants to develop such a blockchain should do their homework and think about as many attack vectors as humanly possible before writing a single line of code.

Hmm... You don't need to register an offline wallet. Also, AFAIK, there is no link between extra security and segwit support (correct me if i'm wrong tough).


I've repeated this soooo many times
blockchain.info and blockchain.com = private company
blockchain = technology for a decentral, trustless, immutable datastore on which bitcoin is built
blockchain.info/.com != the blockchain

blockchain.com/info is just using the blockchain name, they are not the inventors of the blockchain technology. They did not write the whitepaper, they are not the only ones that store the complete blockchain (that's why it's called decentral), they have no power to change anything without consensus, they do not have the power to modify transactions in the chain, they do not support anything but their own apps,...

blockchain.info is an online wallet. Eventough it's one of the safer ONLINE wallets, it's still an online wallet thus inherently unsafer than a truely vetted desktop wallet/hardware wallet/offline wallet/paper wallet.

Real hackers (in the classical sense) are only a small part of the problem of online wallets.
It all starts with the fact that when you use an online wallet, you're usually not the only one in controll of your private keys (sometimes you don't even have access to the private keys at all).
You depend completely on the exchange or online wallet to handle all your needs (generating new private keys => public keys => addresses; safely storing those keys; managing your contacts; managing unspent outputs; generating and signing transactions; broadcasting; signing messages;...).

If the online wallet goes bancrupt => best case scenario you're able to restore your wallet somewhere else, worst case scenario you lose everything

If the online wallet doesn't support a certain feature => you're out of luck

If the online wallet has a bug => you'll have to wait untill they fix it

If you have a problem => the online wallet's support team will be the only ones that can help you, so you'll have to wait

If the online wallet turns scam => you lose everything

If the online wallet gets hacked => you lose everything

If you get hacked/infected => you lose everything

If the security scheme or RNG of the online wallet is bad => you lose everything

If you fall for a phising link => you lose everything

---

If you use at least a half-decent wallet, most of the things above do not apply... You should be the only one in controll of your keys, you should be in controll of the software running on your system, you should be in controll of generating new addresses, signing, managing, broadcasting...
Sure, things can still go wrong if you make mistakes, but at least they were YOUR mistakes, not the online wallets'. And IF things go wrong while you're using a decent wallet, at least the rest of the community *might* be able to help you fix things.

Fixed that for you  
Offcourse, you forgot about airgapped cold wallets and paper wallets... They are as safe as a hardware wallet. Online wallets and exchanges do not belong in the same sentence as the word "safe", unless preceded by the word "not"

I'm glad to hear you hash your passwords instead of encrypting them, i really was under the impression you were using encryption instead of hashing...
You'd be supprised how many times i had arguments with developers about this subject, for some strange reason a lot of devs seems to prefer to put plaintext passwords in databases instead of using a proper hashing algos... A lot of them don't think they'll ever be a victim of a hacker attack, or they simply overestimate their own talent, or underestimate an evildoer...

Good luck with your project

I've been writing web applications for my employer for quite a while... I'm not a good scripter/programmer and defenatly a bad designer, but i do know a thing or two about security... Things i've picked up over the years

Let's review 2 situations from a malicious person's view:
Situation A: You store your passwords, chopped in 5 pieces and encrypted into a database

• Would it be imaginable you wrote a single bug somewhere in either your code or your webpages? An attack vector you didn't think about? A misconfiguration of your apache/nginx/lighthttpd? A misconfiguration in your database installation? A weak OS/db password? An unpatched binary? If so, would it be unimaginable that the attacker could find a backdoor or a sql injection point that allowed him to dump your database, thus getting his hands on all 5 encrypted pieces of all passwords stored in your database?
• If the attacker got his hands on hundreds of chopped up passwords, would it be imaginable that he found the logic in how to decrypt your passwords? I mean, unless you encrypt the pieces using an offline machine, the passphrase or key *would* technically be hardcoded or stored in a database somewhere on an online machine, right? If the password or the logic wasn't stored online, how would you ever encrypt/decrypt the pieces yourself? The same attack vector as the one in step one *could* *potentially* be used to rip your sourcecode to look for the hardcoded password/password logic
• IF an attacker managed to get past the first 2 hurdles, would it be imaginable he could then execute the first step and apply what he learned in the second step and decrypt NEW passwords in a matter of seconds?
• Sure, this is a longshot, but if your service ever becomes *the next big thing*, you should be prepared for really smart evil people investing a lot of time into breaking your security model... So why not build it foolproof from the start?

Situation B: You store your passwords, not chopped but stored as a SALTED hash in your database (for example, bcrypt with a high cost)

• Would it be imaginable you wrote a single bug somewhere in either your code or your webpages? An attack vector you didn't think about? A misconfiguration of your apache/nginx/lighthttpd? A misconfiguration in your database installation? A weak OS/db password? An unpatched binary? If so, would it be unimaginable that the attacker could find a backdoor or a sql injection point that allowed him to dump your database, thus getting his hands on the salted hash?
• Now here is where things get different: even if he dumps all passwords, he needs to brute force each and every one of those passwords starting from 0. Since you have long passwords, and they got salted during the encryption process, there is simply no way he'll ever be able to brute force a single password within any reasonable timeframe

In situation B it doesn't even matter if your complete sourcecode, password file and database dump ever get leaked... The attacker won't be able to use that information to decrypt the password hashes.
As long as there are no rainbow tables for bcrypt passwords with a length of 23-25 characters are generated, your users will always be safe (hint: i don't think such rainbow tables will exist in our lifetime... It would require bcrypt asics and a corporate SAN to generate and store this data)

And from a programming point of view: what's the difference between comparing two plaintext strings and two hashes? The only extra cost is that you have to hash the user's input twice... Costing you a couple processor cycles and maybe a couple miliseconds... Seems like a fair price to protect your users, doesn't it?

Yes, there are things you can do:
1) open a thread in meta (which you already did) => Hope the dude gets banned, or at least red tagged by DT members

2) report his posts to the moderator(s) => hope he doesn't get payed because all his posts get nuked, thus remove the incentive to start all over when his account gets banned

3) contact the bounty manager of the campaign he's spamming for => hope he doesn't get payed, thus remove the incentive to start all over when his account gets banned.

As a matter of fact: if you contact the bounty manager and you receive no answer, it might be a good idear to update this topic with this information, maybe somebody on DT would be willing to red tag the bounty manager untill he complies in removing shitposters like this one...

BTW: my eyes actually hurt after trying to read his gibberish... WTF

Ik ben zelf geen bitcoin debit card gebruiker, maar heb wel langs de kantlijn gevolgd wat er gebeurde...
Blijkbaar is er een bedrijf, "WaveCrest" genaamd dat VISA kaarten mocht verdelen. Bijna alle exchanges die debit cards uitdeelden maakten gebruik van de diensten van "WaveCrest" (maw: de exchange had geen licentie van VISA, de kaarten die zij verdeelden werden dus eigenlijk door WaveCrest uitgegeven in hun naam).
Ergens begin 2018 heeft WaveCrest zijn licentie bij VISA verloren, dus werden van de ene dag op de andere bijna alle bitcoin debit cards waardeloos.

Could you elaborate on the quoted text? Do i understand it correctly if i presume the passwords go into an encrypted database, but they're stored in plain text in this database?
If so, this is a huge security risk, even if your database is encrypted... I'd rather use a system with an unencrypted database that stores a salted hash of my password than using a system with an encrypted database that stores my password in plain text...

Testnet would also be my first choice. Another option would be to setup a node in regtest mode:
https://bitcoin.org/en/glossary/regression-test-mode

The network behaves as it was initially designed. Every 2016 blocks there is a retarget, the difficulty gets adjusted upwards or downwards so the AVERAGE time between two blocks is ~10 minutes.
You are correct tough, if the networks hashrate would drop to 50% in the first 10 minutes after a retarget, it would take about 4 weeks untill the next retarget, at which point the time between two blocks would once again be ~10 minutes. This is still "working as designed" tough, theoretically, there is no problem... Sure, blocks would probably be completely full for the next 4 weeks, a fee war could start, it would take a longer time to get a confirmation,.... But everything would sort itself out, without technical problems.

The fact that at this moment, the time between the last 6 blocks was ~20 minutes (i didn't verify this): no problem, it's completely possible... That's why the difficulty is adjusted so the AVERAGE time between two blocks is ~10minutes, and that's also why we don't retarget every 10 or 20 blocks (if we would retarget to often, the difficulty would jump up and down quite a bit, since the number of samples would be to low).

Solving a block requires the miners to increment a nonce in the block header, then create a sha256d hash of this new header and check if the result in under the current target. It's possible that after a miner receives a new block and start working on the next block, he finds a header whose sha256d hash is under the target in less than a second, it's also possible he'll never find a valid block...

I've generated a list of all funded addresses for somebody on this forum a while ago... I used this script: https://github.com/cryptah/utxo-dump

IIRC, at that time, there were ~40.000.000 unspent outputs in the UTXO set, don't remember how many addresses were funded (multiple unspent outputs can fund the same address).
I can only estimate this number to have grown since then (about a month ago iirc)

Wouldn't that require a huge database?
I think it wouldn't be practical to save all balances for all addresses that ever existed at each blockheight, but you could probably save balance of each address whose balance was changed by a transaction in a block at each height... That way you should be able to query the value of the sum of the unspent outputs funding address x at height y where the blockheight = the max blockheight for an entry for address x.

Something like this

For example, if my address was funded for the very first time at height 40000, then was funded for a second time at 401000 and i spent both outputs at 402000, only 3 inserts would be needed for my total history...


Each new block you'd have to parse 1500? transactions, so if you'd only have to save the balances of addresses whose balance changed at each blockheight, you'd have to insert at least ~1500 changes/block * ~144 blocks/day = 216000 changes each day... That seems doable

Because when you install a node, it syncs the complete blockchain. During this syncing, the blocks are parsed and verified, and a node builds the UTXO set while syncing (it aggregates from block #1 up untill the current height). This syncing process takes hours, sometimes even days (depending on your node's version, the IO capacity, the memory speed, the cpu,...). After the initial sync, the UTXO set up untill a certain height is built, so as long as you keep your node running 24/7, or at least start it a couple times a week, it can keep up with all the new blocks pretty fast, your node just parses a new block when it receives it, and adapts its utxo set accordingly.

So, when you use a full client, your PC/server already did all these aggregations in the past, so you can now see your balance instantly. If you use an SPV client (like electrum, or most of the hardware wallets), this SPV client is connected to a full node, this node built the UTXO set in the past when it was syncing, so it can also reply instantly when an SPV client querys the unspent outputs funding a certain address.

Sure, given an infinite timeframe, the odds become 100%, but still, the block would get rejected, so it's just the miner who mined the block with the colliding hash loses the block reward + fees for that block, and that's about all that'll happen.

In our lifetime, i doubt we'll ever see such a collision happening... My math is not good enough to calculate the exact odds tough, but it would be an extremely small number...

You always aggregate from the genesis block to the required block... The latest block does not specify all unspent outputs (which you can use to calculate the total value funding each of your addresses). Basically, a block contains a bunch of transactions. Each transaction just tells you which unspent output(s) from the UTXO set are used, and which new (unspent) outputs are generated. Offcourse, there is also some other data in a block (like the signature , the block header).

In order to generate the UTXO set (the set of unspent outputs that you can use to calculate your balance), you start from the genesis block and follow each unspent output. As soon as a transaction uses an unspent output from your current utxo set, it must be removed from the utxo set, and the output of the transaction will be added to the utxo set... The coinbase transaction also generates a new unspent output. If you do this upto height x, you automatically know all unspent outputs at height x, so you can use them to calculate the balances.

I never used the accounts functionality of bitcoin core, but didn't i read somewhere it's deprecated?
But you are correct tough, the only thing the OP needs is a new, unique address per user (or a set of addresses). I'd say it might be a good idear to keep the account management in a seperate database (create a small relational db and keep track of which user "owns" which addresses, do make sure you keep track of change addresses when he spends his unspent outputs!!!)