In the past, i've succesfully compiled my own litecoin wallet for both linux and windows by doing a gitian build on linux... Pretty straight foreward, just follow the walktrough

https://github.com/litecoin-project/litecoin/blob/master/doc/gitian-building.md
now points to
https://github.com/bitcoin-core/docs/blob/master/gitian-building.md

if you run bitcoin-cli as the same user that's running bitcoind, and the config file is in the home ~/.bitcoin of that exact user, bitcoin-cli will also parse bitcoin.conf and automatically authenticate.

My first guesses would be:
- is the same user running bitcoind and bitcoin-cli?
- is there something else wrong with your configuration (is your daemon listening for connections?)
- maybe there's something wrong with the owner or permission of your bitcoin.conf?

Eventough i have never voiced my opinion about this in the past, i can only say that i've never been a fan of those pre-funded physical coins... DIY coins are perfectly fine, but the pre-funded ones are a big risk IMHO.
I've seen one of those coin creators that lost his list of private keys, and a lot of clients of him lost their funds (i can't remember his name tough... I have bad memory).

For me "Be your own bank" means that you, and you alone, should be the only one in complete controll of your private keys. Offcourse, you can share keys with your spouse or children, but as far as i'm concerned, nobody else should ever have any access to your private keys.

a bip38 encrypted pre-generated key... I wouldn't even apply to get one for free... There's no guarantee whatsoever the company didn't keep logs of every private key they generated.

Completely agree with Royse777's answer... But wanted to elaborate:
It's perfectly possible to use an unspent output funding one of your address to fund an address whose private key is unkown to anybody... These are so called "burner addresses". Any funds you send to such a burner address is considered to be lost, since nobody has the private key that could be used to sign a transaction spending the funds sent to this burner address.
If somebody would ever bruteforce the private key to those burner addresses, he/she would be able to spent all those unspent outputs that were "burned" (so he would un-burn the burned funds).

Before you start imagining things, the keyspace for potential private keys is soooooooooooooooooooooooooooooooooooooooo big, not even all computers in existence pooled together would be able to scan 1% of the keyspace in your lifetime... Many have tried and failed.
Unless there was a flaw in the random number generator used to generate the private key, it's ludicrous to attempt finding a private key whose public key hash is still funded.
That being said, there were instances of flaws in the RNG of some services in the past, and funds have been stolen due to these flaws

Probably because unspent outputs funding those addresses were used together with unspent outputs funding other addresses... This way addresses can get linked together. If you have positive confirmation one of those addresses that are linked to other addresses belongs to coinbase, you have confirmation all addresses linked to this confirmed address belong to coinbase.

no

no... Addresses are not pre-created

All addresses are 'unknown', it's only when you link a real life person or a company to one address, people can use data analysis to find other addresses that can be linked to the address that was 'de-anonymised'


I'll update this post in about 30 minutes and try to give some theory as to how this works exactly... check back in 30 minutes

Some theory.... greatly simplified
Your wallet generates either random private keys, or it generated 1 master private key randomly and it derives private keys from this master private key (HD wallet).
The private key is used to generate a public key. The public key is hashed and the results of the hash is the address.

When you pay somebody, you use an unspent output that funds an addres whose private key you own, and you create a transaction that basically says "i use the unspent output x  from transaction y to fund address z" and you sign this transaction with the private key belonging to the address that belongs to you.

At this point, this transaction is pseudo-anonymous. As long as nobody knows you're the owner of the address, everybody can see the transaction, but it's unknown to anybody.

How can addresses be linked together? Well, for example, your wallet holds 2 funded addresses 1AAA and 1BBB, 1AAA is anonymous, but you've made a forum post indicating 1BBB belongs to you...
If you create a transaction that basically says:
"i'll be using unspent output x from transaction y that funded address 1AAA AND i'll be using unspent output a from transaction b that funded address 1BBB to fund address 1CCC", everybody can now see address 1AAA and 1BBB belong to the same wallet, so everybody now knows 1AAA is no longer anonymous

This issue has been brought up so many times in the past...
The main problem is that the current forum runs on an old version of SMF. Theymos has extensively patched and hacked the code, so upgrading to a new version would be pretty hard for him.
Next to this, a new forum software is being developed for bitcointalk... This decreases the odds of migrating to a newer version of SMF that might be mobile friendly. The new forum script developed for bitcointalk is called epochtalk. The main problem is that epochtalk doesn't seem to move out of beta phase (it's been in beta for yeeeeaaaarrrrssss)... Not much is being developed, and it's just not moving along (at least, so it seems to me)

To tell you the truth, i've never used the module "BitcoinKeypair". That being said, i do see a potential problem with the identation of the code you've shared:
on line 10, you start looping over all private keys in list in_prvkey, but on line 14 you haven't used any identation, so the line "outfile.write(k.address(x)+"\n")" will only write one address to your file (the address generated by the last private key in in_prvkey.
If, accidentally, your input file contains a newline at the bottom of the file, there is a chance the last ellement of the list is empty, so the address-function might fail due to this...

Anyways, if you see errors, my gut feeling tells me that it's either a wrong identation combined with an error on the last line of the input file, or a misusage of the BitcoinKeypair module... Can you post the exact error message?

In the past, i started a complete lecture why it's a very, very, very bad (and useless) idear to mine bitcoin with your phone... However, since this topic comes up soooooo many times, i started pointing to this PINNED topic in the mining subforum written by a legendary moderator who has been running a mining pool for many, many years and who's also an active (and knowledgeable) developer:

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

Please read the 3rd topic in the OP.

I'm happy to hear you're taking steps in the right direction with cloudflare. To be honest, moving away from them should be a rather easy task... Most registrars offer to use their nameservers for free. That way you can edit your dns records straight from a gui offered by your registrar.
On top of that, you can use letsencrypt's free certificates, they even have a certificate bot that makes installing and renewing certificates rather easy (even for novice users).

As long as you keep using cloudflare's SSL you HAVE to realise your users are sending/receiving encrypted requests to CLOUDFLARE, cloudflare decrypts these requests and
forewards them to your server (either encrypted OR UNENCRYPTED... We have no idear if your host has ssl encryption). Cloudflare will be able to log EVERYTHING (they literally have the UNENCRYPTED data in hand)... They know who your visitor is (his ip), they know the exact content of your letter of guarantee, they know which deposit address you presented him/her with, they know which receiving address was sent to you,... They know (and potentially log) EVERYTHING... They are US based to...

About the continued use of google analytics, i strongly disagree that this should ever be an acceptable move for a mixing service... The key point of your business is offering anonimity for your users. As long as you enable google analytics, google will know exactly who visited your site, when, from where, using which browser, which refferer, and they might even track your visitors to the next site they visit.
Imagine their next visit is an online wallet (novice users can be ignorant and still use online wallets): wallets don't have to be completely anonymous, so it's perfectly acceptible if they also enabled google analytics. At this point, google will know where your visitor came from, which pages he visited on your site and where he went afterwards... This way the chain is complete and you've given a complete overview of your customer to a big, US based company.

Now, let's start from the worst case scenario: i'm a person that uses your mixer, but for some reason the US doesn't like me... A quick request sent to both cloudflare and google will allow them:

• To know which page i visited before visiting your host
• To know at which exact moment i visited your host
• Every piece of data send from or received from your host
• Every timestamp, my browser, my language, my OS,...
• Which site i visited after visiting your mixer

In other words, they'll be able to identify my source address and my destination address aswell as all metadata related to the mixing process (timestamps, pages, hosts, browser info, os info,...)

That should work... Do realise your node will start downloading all blocks

make sure your indentations are correct... Tab =/= space

As for writing to a file...
file= open("outputfile.txt","a+")
file.write("key %s\r\n" % firstline)
file.close()

I'll be heading home for the day, if you have more questions... Don't hesitate to ask them, i'll be answering them tomorrow (or somebody else will probably help you out in my absence)

in python, that's relatively easy...
I wrote this code from memory (and copy/pasted 2 lines from the source i mentioned below), it should work, but typos might happen


part of the source : https://qiita.com/visualskyrim/items/1922429a07ca5f974467 (i was to lazy to write a loop over a filehandle from memory)

Is the 270 BYMC you're offering as collateral the same you're selling in this thread: https://bitcointalk.org/index.php?topic=5183072.0;topicseen ?

It is legit, which does not mean that it can't turn into a scam later on,... It can be used by scammers, it can be used by phishers, it can close your account, it can freeze your funds, it can be hacked, it can go bancrupt,... but for now (afaik) it's legit...

Only use exchanges you trust, investigate before using them, and only keep your funds on an exchange for as long as you need to complete the trade... Always store your funds in a wallet for which you're the only one in complete controll of your private keys!

I speak dutch, and i did a quick google search... Ended up on sites like this one: https://www.bruzz.be/brussel-kiest-2018/partij-islam-haalt-nergens-verkozene-2018-10-15  or on wikipedia https://nl.wikipedia.org/wiki/Islam_(politieke_partij) (and a bunch of other sites that tell basically the same thing)


For those that do not wish to use google translate, the TL;DR; version is:
- There is a political party called "Islam" in Belgium
- They want to install an islamic ruling, and Sharia
- In 2012 they tried to gain votes in 3 of the most muslim-centralised cities in brussels, they only got 2 seats in the city's council. This means they had nothing to say even in those 3 cities they tried to infiltrate
- In the last elections in 2019 2018 they even lost these 2 seats, and they are now a non-issue

EDIT: Fixed a typo

Are you telling me you've watched the 44 minute movie in 3 minutes 19 seconds, since that was the time from the moment the OP created this post untill you've posted your review 

As for the movie itself, it's a bit slow for me... I've watched the first couple of minutes and then became bored and did something else.

I think the problem here is the fact you use google translate.
After reading your posts, i think what you're actually trying to say is:

You're a developer/admin who is going to launch a lottery site that's provably fair because you'll use the hash of a future block in order to pick your winner. You'll accept all kinds of altcoins as payment for this lottery.

I'm no gambler, so i probably won't use your site, but if you want to promote your lottery game on this forum, it might be a good idear to contact an established, on forum, escrow to hold the lottery's funds...
IF you create an appealing lottery site with a low house edge, provably fair, and all funds escrowed by somebody trusted on bitcointalk, you might gain some business here.

Good luck!

If you have *any* idear what your password *might* look like, you can always try to setup btcrecover:
https://github.com/gurnec/btcrecover

Mind you, this will ONLY work if you have a clue what your password will more or less look like (for example, if you know you only used upper/lowercase letters and numbers, and always create passwords that are 5 - 10 letters long, and you're pretty sure you always use a date in your password => you might have a shot at bruteforcing the password, eventough it might take a very long time)

Next to the tips others have already given, it *might* also be a reasonable idear to add your attacker to your trustlist, preceded with a "~". At this moment, while you both are new to the forum, this doesn't matter the slightest bit... But rejecting him/her from your trustlist will make sure that you indicate to the forum that you don't trust any ratings left by this individual, and you would not like to see him end up in DT. It's a longshot that this will ever happen, and if it does it's defenately not sure that your rejection will prevent him from ending up in DT, but i'd still do this out of principle.... Just in case.
Only do this if you don't trust the ratings left by your troll tough

So, in your case, go to
"profile" => "Trust" => "Trust settings"
Add
~Trollname
in the form, and click on "update".