5 pages isn't a lot, especially since your screenshot shows search results starting 7 years ago... 5 pages in 7 years, including for-sale threads...

Don't get me wrong, i'm defenately not against your idear if there's a real demand for such a subforum, but maybe Theymos would want to avoid another subforum that's barely used? Anyways, it's Theymos's call, but if you're really serious, i'd try to make a better case (just my 2 satoshi's tough)

If you would have taken the time to read the complete post, it would have had to be obvious for you the only inaccurate part is the fact that I have found no good oclvanitygen gpu benchmarks, so I had to work with data from a Reddit post... I clearly indicated this, it was rather hard to mis IMHO.

In my post, I already used 230.000.000 keys per second in my calculation.. now you say 250.000.000... don't get worked up about the difference, it's bad for your heart health...

Even if a new gpu would generate a tenfold of this, it wouldn't matter: the conclusion of my initial post stays exactly the same.. 16 Septen-decillion years or 1.6 Septen-decillion years for a 0.01 percent chance,  the sun will probably die in 7 billion years, so neither of us will be around in 1,6 septen-decillion years anyways... Why would you say my post is misleading? Would you say you'll be able to bruteforce a private key within a single lifetime? My address is in my profile, if you pm me my full private key (preferably pgp encrypted with my keybase public key), I'll immediately apologize to you and the full community, and let you pick my personal text for a full year (as long as the text is not illegal or gets me banned)

I wonder if you are trying to draw attention to your(?) business in your signature by acting rather condescending and focussing on the wrong things ?

The current exchange rate is 1 BTC =~ 48 ETH
28 ETH =~ 0.58 BTC
you'll need this 0.58  BTC to be 120% of the loaned amount + intrest... This means you'll need to pay back 0.48 BTC

So... with 28 ETH, you should be able to get a loan of 0.4 BTC, repaying 0.48 BTC... I think that should be do-able for several lenders.

Do realise they'll probably want to use a forum escrow to hold the ETH, so the escrow fee should also be deducted from the 0.4 BTC

I take no responsability for any calculation errors i could have made!

Good luck

This changes everything...
You'll need about 30 BCH or 44 ETH as collateral in order to cover a 0.5 BTC loan with a 0.75 BTC return (120% of 0.75 BTC in BCH and/or ETH)...  If you have these amounts of BCH or ETH , and you allow a trusted forum escrow to hold the collateral, i'm pretty sure everybody will jump in to take your deal....

good luck

I think efialtis forgot the sarcasm tag... You're requesting about $5000 without even offering any collateral or having *any* history at all in this community (altough, even if you're a highly trusted member this is not going to happen, nobody is going to lend anybody $5000 without valid collateral)... That's just not going to happen

"Quite some time" is an understatement.

There's a lack of benchmark results for oclvanitygen (the optimized, GPU version of vanitygen)... But one of the results i found was this one: https://www.reddit.com/r/Bitcoin/comments/1sntt7/48_hours_of_gpu_vanitygen_and_4_trillion/

This user claims to have generated 4 000 000 000 000 addresses in 24 hours using "a" GPU. That's about 23.148.148 keys per second. That's feasible, given that i've found "other" vanitygen (not oclvanitygen) benchmarks in the 5 Mk/s range, so throwing a gpu in the mix could result in a 23 Mk/s result.

Let's, for the sake of argument say that this user's setup was using an old GPU and inefficient coding, and a top-shelve GPU with decent address mining software could churn out a tenfold (230.000.000 keys per second).
Let's say you have a theoretical farm of 100 of these GPU's, churning out 23.000.000.000 keys per second...

They'll need to test 2^256 keys... This means your farm will need 2^256  /23.000.000.000 seconds to scan the complete keyspace.

If execute this calculation and convert the results from seconds to years, you'll end up with a total scantime of 159641002742643597687626818499610000000000000000000000000000 years to scan the complete keyspace.
If you want to scan 0.01% of the total keyspace (thus have 0.01% chance of finding the exact private key whose public key hash was funded), you'll need 15964100274264359768762681849961000000000000000000000000 years...
For people that are not used to read such large numbers, i've looked up the proper naming convention... This allows me to say:

If you have 100 High performing, latest gen GPU's and good drivers and software, you'll need to run your farm for 16 Septen-decillion years in order to have a 0.01% (that's percent, that's 0.01 chance in 100) to find a private key that belongs to one specific address..

In my country there was some media coverage about these scams a couple weeks ago... Apparently the amount of scams have reached the threshold needed to attract the attention of the press and the police now.

If i read your story, it's the exact modus operandi described in the media, so i can pretty much guarantee your friend was scammed.
Like it's been suggested before: stop sending them money, go to the police, consider your funds to be lost.

BTW: these scams have NOTHING to do with the actual crypto community... Scammers just pick whatever technology is "hot" in the media right now and use buzzwords from this technology to scam unknowing victims. If bitcoin wouldn't exist they'd find an other angle to scam people using more or less the same methods they're using right now. It's a shame these dirtbags are dragging our community trough the mud, ruining our reputation because we get linked to them... They're just thieves that use our community fame to steal from (mostly) older, non-tech-savvy people.

You can't "just" generate private keys that result in an address that starts with "1D".

The private key is used to generate the public key. The public key is hashed to generate the address.
Both steps are one-directional, they cannot be reversed. You can't say: my address has to start with "1D", so i'll reverse the hash function to find all possible public keys, nor can you start with a public key and calculate the private key...

The only thing you can do is scan the complete private key space, calculate the public keys belonging to the private keys, then hash the public keys and filter out addresses starting with "1D"... This would take even more time than  scanning the complete private key keyspace, calculating the public keys, hashing the public key and NOT filtering out addresses starting with "1D". Do realise that scanning the complete keyspace is ludicrous, even if you pool all computers in existence together, the earth will have ceased to exist before you can scan a significant part of the keyspace

It's a bug in blockchain.com's algorithm...
blockchain.com is just a block explorer... They just run a couple of nodes and parse the blocks and unconfirmed transactions they receive. If somebody messed up the parsing code, you end up with things like negative balances. This bug has no significance in the real world, blockchain.com is not the owner of bitcoin, it's just a private company that builds things like an online wallet and a block explorer.

Most other blockexplorers are probably fine: https://blockchair.com/bitcoin/address/1Fr8qEa7vcwJikeW9q6thaYZPacGY5CQAb

Some nice advice has been given, but i'd like to put some emphasis on part of BitCryptex and jackg's initial posts... They are correct, but it seems their posts have been overlooked...

Running a full node isn't necessary if you don't want to... If you have problems with the time it takes to do a full sync, or the amount of data you need to store, start looking at an SPV wallet.
An SPV wallet only downloads the block headers, not the complete blocks. A "full sync" of all headers happens in a matter of minutes and only uses a couple Mb on disk, and i find SPV wallets sufficient for most day-to-day task.
Let's be honest: it's a good thing for the network if a lot of people run full nodes, it's good for an enduser to verify all blocks and all transactions, but it isn't absolutely necessary for everybody to run such a full node if they are only going to perform enduser tasks. If we have several thousand full nodes, endusers can use SPV wallets without significant impact on the network's security (imho).

Granted, if you use an SPV wallet, you do rely on other nodes and you give away a small part of your privacy... But security-wise SPV wallets seem to be fine.
If you worry so much about synctime and diskusage, download and verify the latest version of electrum, or buy a ledger or trezor (both spv hardware wallets). By using a HW wallet, you'll even add an extra layer of security....

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,...)