You can actually run electrum as a daemon and run a systemd timer or a cronjob to automate weekly payments.

Here's some more info in case you're interested: https://electrum.readthedocs.io/en/latest/cmdline.html#how-to-use-the-daemon

Once the daemon is started, you can even use the json rpc api, this reply basically tells you how you can do this: https://github.com/spesmilo/electrum/issues/2400#issuecomment-676127361

Do keep an eye on your opsec tough... I would not recommend loading a wallet on a publicly accesible server while being funded with more than pocket change.

AFAIK, freewallet is a non custodial wallet... Which means that the only thing we can see is that freewallet moved funds (at least, i suppose that's how you deduced he got his money, by looking at the block explorer?), there is no way of knowing whether or not OP got his funds unless he tells us.

I've worked with AIX for many years, at that point i had freeBSD on all my home computers. Several years ago, my company switched to SLES (suse linux enterprise) because IBM hardware (POWER architecture) was simply to expensive. At this point, i swiched my freeBSD home machines to opensuse leap (so i had a sneak preview of the features that would be available to my work servers in the future). I'd probably rate AIX (which is closed source) safer than most (if not all) linux distro's. Usually, there was no choice of package selection, but everything you needed to do to harden a system and run a certain product was completely described from a to z in a redbook. Every binary was tested by ibm engineers and downloaded straight from ibm... Updates were regular, and they simply worked... Those systems could handle a huge workload flawless and we've never had any security breaches... But it was pricey...

I can say, without a doubt, that security isn't just depending on wether or not the OS you're running is open source or not... When you talk about linux, it depends on which specific distro you run (cubes OS for example is considered really safe), it depends on how you configured said OS (for example, do you run a lot of daemons that are listening, did you configure a firewall,...), it depends on your behaviour,... I'm pretty sure some people run a not-considered-to-be-really-safe distro in a very secure way, whilst others run a considered-to-be-really-safe distro in a really unsecure way.


In my experience, i'd say that openBSD is one of the most secure free os's out of the box that i've ever ran. I haven't used it in a long while tough, so my info might be outdated. A common misconception is that BSD is linux, it isn't... BSD started from the unix sourcecode, linux was initially an attempt to copy unix's features for free. If you really want to run an as-secure-as-possible distro, it might be worth looking into openbsd, cubes os, sles,..., but you'll also have to look at all the hardening guides (in my workplace, i use audit tools like openscap together with very hard profiles in order to make sure my systems are hardened as much as possible)

For phones, it'll probably get pretty hard to find an open source OS that's not linux based... Like Faisal2202 already said: android is linux based...

There are several open source firmware alternatives, but most of them are not as stable as android (or not as mature), and afaik, most (if not all) are linux based.

When you're talking about open source desktop os's that are not linux based, i'm thinking about BSD...

Open source doesn't automatically make things safe tough... It's not because you can read the sourcecode it won't contain any vulnerability's, it just means that people have access to the sourcecode.


No, not per se... I'm an android enthusiast myself, i don't like apple products (i think their price/quality ratio for the EU market is bad) but a closed source OS *can* be much safer than an open source OS. It all depends on the competence level of who wrote the code and the competence level of the people that reviewed the (open source) sourcecode.

I agree, but you did cherry-pick this one sentence out of a big text that basically told OP that he was decreasing his security by doing this (the complete context was keeping the seed words offline and saving the very complex extension word you'll need every time you want to spend from, for example, a hardware wallet in an encrypted password safe in the cloud)... I clearly stated that everything except using an unique seed phrase + strong extension word and keeping them completely offline in a safe place and separated from each other was decreasing his security.

I merely stated that for some people, it might be ok to create a seedphrase and keep it 100% offline whilst creating strong extension words and keeping them in an encrypted password vault on a reliable cloud storage *might* be good enough for them... I never said it was the best idea, i even stated i would never do it since it wouldn't feel secure enough for me.

Bottom line is that bitcoin is about personal responsibility and personal choice... If you think you'll lose your seed phrase (and all your funds in the meantime), you might be fine storing your seedphrase in a slightly less secure way so the odds of exposing your seeds rise a very little bit whilst your odds of losing your seed decrease a lot.
If you use a hardware wallet on a daily basis, and you're opting to use the one seed for several wallets using a very long extension 13th (or 25th) word, it might be ok for you to store said extension words in an encrypted keepass safe on a cloud vendor's hardware since you'll need to fetch those words very regularly... Is it the safest option? No, it isn't, but it's the one you might be comfortable with (i wouldn't be).
Who am i to judge... The only thing i can say is that for you personally, and your usecase, the opsec you chose *might* be ok... I can only state that i wouldn't do this, and that it's not the *best* way to store sensitive data... But if this is the way you want to work, i cannot and will not stop you...


That was basically what i wanted to say... People do lose their seedprhases from time to time (or their 13th/25th word). The easyer you make it for yourself not to lose access to this sensitive data, the easyer you make it for an attacker... It's about finding a balance... You could potentially store the seedprhase using an ssss that requires 10 out of 10 chunks to restore your seed, then encrypt the passphrase needed for the ssss scheme, then encrypt the 13the/25th word and store all this data in seperated physical places... No hacker will ever be able to rob you, but if you ever need that seed or those extension words, odds are small you'll be able to restore it yourself...

there's a big difference between a passphrase and an extension word...

In case of a password/passphrase/pin =>  If you have the same seedphrase and use it on different wallets and use a different passphrase (or pin, or password), you're undermining your security. If one of those wallets is vulnerable and the attacker is able to get his hands on either the seed or the mpk, the attacker is able to rob all 5 wallets since the password merely encrypts the mpk, so it doesn't matter if you used different passwords to encrypt said mpk (since he'll steal the unencrypted version anyways... Or the encrypted version which only needs to be bruteforced once, not 5 times).

If you're extending your seed with a 13th or 25th word, things are a bit different... This being said, if for some reason an attacker exploits a weakness in the wallet that allows him to capture the first 12 or 24 (or whatever number) of seedwords, he only has to bruteforce this extension word 5 times, which is far easyer than bruteforcing the complete seed + extension word (which is impossible). Offcourse, a long extension word makes this a lot harder (if not practically impossible). This is basically my setup, but i keep no unencrypted version of my seedphrase and i only use hardware wallets to store my funds.

For your next question: keeping the password or the extension word in an online password manager decreases your security... If an attacker is able to exploit an attack vector that lets him get his hands on your seed phrase he no longer needs your password. Keeping an extension word in an online password manager will require him to steal your seed + brute force his way into your password manager, which is hard (but certainly not as safe as keeping everything offline).

Basically, the "ideal" way to create the wallets is completely offline seed creation + completely offline extension word. The best way to store the seeds are 5 different seeds + 5 different extension words saved in at least 2 safe places, and never store seed + extension word @ the same place... All other things described in your post decrease your security.. This being said: you might be fine willing to decrease your secutiy in order to increase your redundancy of backups, but that's very hard for a thirth party to decide... You're probably fine re-using the seed and adding a very long extension word that you keep in a very secure cloud environment using a very hard passphrase for encryption, but I would never do this since for me it wouldn't feel secure enough (but maybe for you it does?).

Personally, i have one 24 word seed phrase + several extension words. I use this seed on my 2 hardware wallets, and i keep said 2 hardware wallets in two safe places. I have different wallets on both hardware wallets by using the different extension words. I then used ssss to split the seed up into 3 parts using a 2 out of 3 scheme with passphrase encryption and i stored the 3 slices in 3 very safe places. I did not keep several copy's of the seed phrase, since i have 2 physical wallets + one encrypted copy of the seed phrase split in 3 parts using a 2/3 ssss scheme. Odds of me losing both hardware devices and 2 out of 3 slices are negligible (since the storage spots are physically far apart... It would basically need an atomic bomb nuking half my country in order for me to lose access to my wallets).

If an attacker:

• gets his hands on one slice: he can't do anything since he needs 2
• gets his hands on two slices: he needs to bruteforce the passphrase of the ssss scheme + the extension words
• gets his hands on a physical hardware wallet and bruteforce the pin + the extension words

The thing does remain: there are always attack vectors... The more attack vectors you eliminate, the bigger the odds of you losing access to your wallet or funds... If you try to make up schemes to make sure you will never lose access to your funds, you'll inevitably open up very small attack vectors for potential thiefs. It's very hard to find a balance.

There's a big difference between the implementation of limits in the node software and the actual consensus rules.

If you'd change the constants defining the dust limit and minimum fee in bitcoin core's sourcecode (iirc, they're defined in https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h) and compile the sourcecode, then get enough people to run your node's "implementation", you'd be able to create a 0 fee transaction with a 1 sat input and a 1 sat output and relay it to anybody running the binary you compiled without breaking any consensus rules (if i'm not mistaking). This is not a fake tx tough, it's just a transaction spending one unspent output with a value of 1 sat and creating an output with a value of one sat... At least, if you can find a one sat unspent output to spend (it won't be easy and it'll probably require running a patched wallet and maybe even the need to pay of a mining pool). Needless to say, the odds of such a transaction ending up in a block are very (very) close to 0.

The "problem" is that most people won't run your binary, they'll run the default binary which has a default value for the dust limit and minimum transaction fee... This means that anybody not running your binary will simply reject the transaction, eventough it's not breaking any consensus rules. They won't put the tx in their mempool due to the fact they no longer relay 0 fee transactions and they reject transactions with an output under the dust limit. So, you cannot use this method to scam anybody without putting in more effort than it's worth.

It's a fake advertisement. AFAIK something like this simply does not exist (and i've been around for a while, so if it was something real i would have heared about it by now).

There are ways to broadcast a transaction with a very low chance of ever getting confirmed (for example by paying a fee that's way to low, or having unconfirmed parents with a low fee)... These transactions stay in the mempool of most nodes for about 2 weeks after which they get pruned from most node's mempools, but during this time they remain UNCONFIRMED transactions, and nobody should accept an unconfirmed transaction as a payment confirmation...

Once a transaction is confirmed (and a couple more blocks were added to the chain afterwards), it stays confirmed.

If you only have one confirmation, there's always a very low chance of a chain reorg, but even then, most transactions that are in the stale chain are usually also included in the longest chain aswell... And after a couple of confirmations, the odds are very (very, very, very) low...

TL;DR; => it's a fake ad, probably aimed to scam people that want to scam others using these "flash" transactions?

Tor can't completely mitigate all abuse, but it does make it a lot harder for an attacker tough:

https://support.torproject.org/abuse/what-about-ddos/

I've ran hidden services in the past, it's actually quite easy to setup and maintain... But in the end it's up to Theymos to see if he has the time and resources, since i can only assume that the time investment in setting up a hidden service for bitcointalk is a different magnitude than the time to setup a hidden service for a testnet faucet

Just a suggestion: you mention you're learning, why not mine on the testnet instead? The diff is still pretty high for a TEST network, but with an S9 you should be able to mine a couple of blocks once in a while (with allmost 0 block reward nowadays), but atleast you'll be able to see everything in action

If the testnet cannot entice you, there are a couple altcoins that are clones from bitcoin and use sha256d as POW algo with a much lower diff than bitcoin's main net... The income will be peanuts aswell tough.

https://coinmarketcap.com/view/sha-256/

I used to mine peercoin with a usb block eruptor back in the days, when the bitcoin networks diff was waaaay to high to use an usb miner, but on peercoin it was still low enough... Don't know if this is still valid tough!

I hate to say it, but you're not the first one that says they'll get their lawyer involved... I've heard it dozens of times... But freewallet is still going strong and selectively scamming people on a regular basis.
This either tells me they've got a very good lawyer and a TOS that allows them to selectively scam, or people tend not to follow up on their thread of getting their lawyer involved...

This being said: the advice to keep making noise is usually the only advice we can give after the scam has happened... It seem to work from time to time, but most victims lose their funds.
The only thing we, as a community, can do is keep raising awareness about freewallet's tactics.

Adding a small fee doesn't make your transaction slow, nor the process... Adding a small fee will give the miners a smaller incentive to add your transaction to the block they're working on...

A block can contain up to 1Mb of transaction data (+ a maximum of 3 Mb of witness data). The difficulty gets adjusted every 2016 blocks so that the average time between two blocks is about ~10 minutes (on average).

This means that (on average) about 6 Mb of "actual" transaction data can end up in the blockchain per hour. If more than 6 Mb of unconfirmed transactions get broadcasted per hour, the mempool of the nodes get filled with a backlog of unconfirmed transactions.
Since miners are businessmen, they try to optimize their financial gains. They do this by prioritizing the transactions with the highest fee per (virtual) byte of transaction data. They do this because a miner can add a coinbase transaction to the block. This coinbase transaction funds an address generated by the mining pool with a value of the current block reward PLUS the sum of the fees of all transactions included in a block. So, if you add insufficient fees, you give no incentive to miners to prioritize your transaction and the odds are it remains in the mempool of the nodes for a longer period of time. By default, nodes prune old unconfirmed transactions from their mempool after 2 weeks (if my memory serves me right)

However, there are tricks to increase the incentive for pool operators to prioritize your transactions... If you loop back to my previous post in this very thread:

• if you wait it out, you do not increase the incentive of the pool operators. Usually, your transaction will only be mined if the backlog of unconfirmed transactions is gone. If this takes more than 2 weeks, odds are most nodes will prune your tx from their mempool
• if you wait but keep rebroadcasting, it's the same situation as the one above (just waiting it out), but you periodically remind the nodes of your unconfirmed tx, pushing your tx back in their mempools once it gets pruned
• if you bump the fee, you replace your transaction with one with a higher fee, so the amount of sats per (virtual) byte of transaction data is higher, giving the pool operators a higher incentive to add your tx to the block they're trying to solve
• if you double spend the unspent output used as an input for the stuck transaction, you kind of try to achieve the same thing as bumping the fee, but in a much more artisinal way with waaaaaaay less chance of succes
• if you do a cpfp, you basically use one of the outputs of the stuck transaction as input for a new transaction. The miner can only add the fees of the new transaction to the coinbase reward if they also add the stuck transaction to their block. The trick is to make the CPFP transaction with such a high fee (per virtual byte of transaction data) that the pool operator has a high incentive to add both in order to be able to claim the fees of the second (cpfp) tx
• if you pay a mining pool to add your transaction, you directly give money to the pool operator to counter balance the low fee... This is a non-technical sollution, but it does work (eventough, as noted before, it can be pretty pricey)

One thing to remember: those are all odds and averages... It IS possible to get into a block with a tx with a 10 sat/vbyte fee whilst there are 15 sat/vbyte fee tx's still in the mempool. It IS possible your 100 sat/vbyte tx doesn't get added to a block eventough most other tx's in the mempool have a 15 sat/vbyte fee... This being said: the selection of the tx's from the mempool is allmost always an automatic process, and usually you can predict pretty well which tx's from the mempool will be added to the next block.



Eventough insufficient fees is allmost allways the culprit, it does happen that a transaction has unconfirmed parents, or is dropped from the mempool of most nodes (usually because it has been broadcasted to long ago). There might even be other reasons, but i can't think of any except those two right now.

I remember people talking about using gambling platforms instead of mixers for many, many years... The fact does remain that a gambling platform is not built to mix (or launder) money. They do keep extensive logs (part of their business actually depends on those logs so they can catch fraudsters), sometimes they even require KYC... If you're going to launder criminal funds using casino's, you're just going to get caught sooner or later (and since we're talking about criminal funds, i kinda hope the launderers get caught)

Personally, i don't see anything wrong if you just want to hide your money to protect yourself from a $5 crowbar attack or beggars... You can use about any service that allows you to deposit and withdraw funds... An exchange, a casino, a custodial wallet,... I don't know if the wager requirements of casinos are actually there to stop money laundering, and i wonder if their main goal is to make sure their business stays afloat. Only by requiring your balance to be wagered, they stop people from not gambling... The fact they're discouraging money launderers is just a happy coincidence. Personally, if i'd just want to hide my funds from criminals and beggars, i'd rather use a big exchange for this purpose: the risk is much lower than using a gambling website.

Full disclosure: i'm not a "real" gambler. I did visit gambling sites in the past a couple of times, but i'm far from an experienced gambler, and i haven't logged on to any of my accounts for years... Maybe my image of the gambling industry is wrong...

if you underpayed the fees (which is the case in most stuck transaction cases), there are several things you can do... They depend on how you initially created the transaction, the receiving wallet,, your technical knowledge and the urgency...

• wait it out... if it's a transaction between your own wallets, it'll either get included in a block sooner or later, or most network nodes will prune it after a couple of weeks and you can re-use the unspent outputs
• wait it out, but keep broadcasting the transaction so the network nodes won't prune it (usefull if you're paying somebody else that trusts you completely... like a family member or a close friend... It'll probably be slower than the first option, but the receiver won't see a "dissapearing" unconfirmed transaction)
• bump the fee (this only works if your transaction is opt-in rbf). I don't know blockchain's wallet... haven't used them in many, many years... But if they create opt-in rbf transactions, i suppose they'll have some kind of menu to bump the fee (but other users have already pointed out that they believe blockchain does not create opt-in rbf transactions)
• you can try to double spend the unspent output but use a bigger fee this time... The problem is that most (if not all) nodes will reject your transaction... This is more or less the "bump the fee" equivalent of a non-opt-in-rbf transaction, with waaaaaaay less chance of succes and it requires waaaaaaay more technical knowledge.
• you can do a CPFP IF you either received change from this transaction or if you're also the receiver. Some wallets (like electrum) even have a nifty wizard to help you with this process... I don't know if blockchain or trust wallet have such a feature tough (can you import your trust wallet into electrum? That would probably help you a little bit?)
• you can pay a TRUSTWORTHY BIG bitcoin mining pool to include your transaction in their next block... I know and trust viabtc... But i'm not affiliated with them! If you payed > 10 sat/vbyte you can even use their free tx accelerator (but, if you payed more than 10 sat/vbyte, i guess your tx wouldn't be stuck for 20 hours) => https://www.viabtc.com/tools/txaccelerator

In which format is said private key?
https://en.bitcoin.it/wiki/Private_key

But, truth be told, unless it's in mini private key format, your odds are allmost 0 when you can only read 9 characters... (and even if it's in mini private key format, it'll probably take more time and effort than it's worth... I didn't do the math, but my gut tells me that even in this case, it's allmost impossible)

I don't know if you're for real... But if you are: you just posted a big advertisement for scammers...
Personally, i'd disregard all mails arriving at that address from now on cause everybody looking for an easy victim will be mailing you.

An example like that does work to get some initial feedback
My first thought when seeing that score would by: why? What's the rationale behind the number? Was it linked to a scam somewhere, did it get some negative reviews,... ?

I get the fact that you want to limit the amount of querys on your system to avoid having to buy/lease more performant (and more expensive) hardware. This being said, using google's SSO isn't a foolproof way to avoid people signing up with multiple accounts either... It's just an extra hoop multiaccounters have to jump trough. And like i said: using google's SSO will deprive you from several beta testers... I'm not completely against google's SSO, but i avoid it whenever i can (and i only use it for services that i trust and offer little or no other way of creating accounts).

AFAIK, there is no foolproof way to avoid multi accounters... People can create a dozen of google accounts (or buy them in bulk), or they can use throwaway emails, they can use vpn's or proxy's... Or tor... They can change their browser's fingerprint, they can (potentially) bypass (some) captcha vendors...

Personally, i'd probably allow people to sign up using their email and require a captcha completeion, then block >10 lookups per day based on ip address... It's not a perfect system, people can still get around it, but there are sufficient hoops so most of them won't be able to manage more than a handfull of alt accounts on your service.

If you really want to crack down on multi accounts, it'll require grunt work... Maybe work with invites and communicate with your members trough your platform... But it'll require significant effort from your side.

There doesn't seem to be a way to create an account without linking it to my google account (which i usually don't do, especially for new projects)?

no, that should be the actual nonce... If you would re-create the header using this info and do a sha256d hash of said header, the outcome should be under the current target... Starting nonces are not included into the block header when it gets broadcasted.