The only thing i wanted to add to ranochigo's answer is:

source: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.0.md

This answers your last question (if estimate_mode is unset, how fee calculated?)

I think that's the last time there were changes in this call. Whenever i use the call, i usually do add either economical or conservative estimation...

I know what you're saying, but just to be clear: a miner has full controll over which transaction he/she includes in a block (as long as it's a valid transaction, otherwise his block would be rejected by the other nodes).

A miner can add a 0 sat/byte tx into the block he's trying to mine, even if his mempool has 1 Gb of transactions with a fee over 100 sat/vbyte.

Even a small, home miner using a default setup node has a very simple command to increase the priority of low fee transactions in his mempool.

Offcourse, financial incentives do push him/her to add the transactions with the highest fee (in sat/vbyte).

Well, i don't know any decent, semi-trusted, wallet that does this. Maybe you'll find some online non-custodial wallet that does this, but i wouldn't recommend using a non-trusted wallet just for this feature.

But yeah, the sollution i offered is not a one-buttom sollution... OP will need to do some scripting (or ask somebody to write him a script).

bitcoin core or electrum can be run as a daemon... Then you can use the json-rpc interface to create, sign and broadcast transactions.

I'm not saying this is an easy procedure, you'll need to run a daemon, write a payment script and schedule it to run daily... And i'd defenately urge you to test on the testnet first

There's a rumour it's China this time, apparently one of the biggest banks has stated they will systematically close and report any account that has crypto dealings.
Seems like it's plausible this is the explanation this time, but nobody can be 100% sure.

What you propose is a modified newbie jail... Here's what Theymos said about this concept:

https://bitcointalk.org/index.php?topic=4538227.msg40849533#msg40849533


So, the odds of this proposal being implemented are small...

The sad truth is that it doesn't matter if you agree to a council or not... It doesn't matter if I agree to a council or not...

If they don't change the consensus algorithm, but merely do things like not including certain transactions, not relaying certain blocks, not connecting to certain peers,... they don't need our permission to do so.
If they start changing the consensus algorithm (like, for example, switch from POW to POS), they'll most likely create a major fork between them and the miners that did not follow the "council"'s advice.

The truth is that if they do this, the only thing WE can do is start using a different crypto currency, or in case of a fork: keep with the "original" bitcoin and exchange their forked coin for "real" btc asap...
The way we vote is with our wallets: look at bitcoin cash: there was nothing we could do to stop the fork from happening, since Roger did not need our permission to create a fork... But we, as a community, decided to keep using the "original" bitcoin, and not his fork... And at this point his forked altcoin is worth only a fraction of our original coin

I'm defenately not involved in this project, but if i had to take an educated guess, the burn address would not be used to burn coin on the bitcoin chain, but rather to burn coins on OP's "bitcoin eco" chain.

The OP indicated he cloned bitcoin, changed the POW algo to POS and premined >21M coins. He then indicated he'll give btc holders the chance to switch to his chain and afterwards he promises (eventough you'd have to take his word for it) that he'll burn any leftover coin.
So, i assume the burn address will be used to burn leftover "bitcoin eco", since nobody in his right mind would burn btc (worth ~$40k) to get an equivalent amount "btc eco" (worth ~$0 at this point in time).

What the OP is doing is nothing new... Byteball (for example) had a similar distribution method.
On the other hand, if the OP was serious about distributing his "eco" altcoin according to current BTC holdings, he should have forked at a certain blockheight in the future, hence everybody who would have had funds on the original chain before the forkheight, would have also had funds on the "eco" altcoin chain... And by doing this, he would have been able to incentivise POS mining, since not all "eco" coins would have been mined, and there would have been some room left for block rewards. Also, by forking instead of premining, he would have built something that didn't rely on trusting him to burn all his premine, but he would have had a project that was completely verifyable and trustless.

But hey, bitcoin is open source, OP is free to try and experiment if he wants to... On the other hand, his "green" (white) paper contains little to no techical background, and his questions sometimes make me wonder if he has sufficient technical knowledge to pull something like this off.....

No problem... I know all those numbers seems daunting when you look at them, and as a non-technical problem it's pretty easy to fall into a FUD-trap like this.

What you have to take away from all this is: offcourse somebody can write a tool to try to bruteforce their way into your wallet... After all, they're pretty much using exactly the same code that's used to create a wallet to begin with (they're just looping over this code again and again, and added a function to check unspent outputs funding the created address). This doesn't mean anything at all. There is no way somebody can reverse engineer your address (or your public key) to find your private key (at least, not at this point in time).  
The only thing he/she can do is try all private key(s), derive the public key from this private key, hash the public key (this hash is the address), the lookup this address into a database to see if unspent outputs are funding said address. In order to attack one specific address and have a 100% chance of robbing you, he needs to try out 2^256 private keys... That seems like it's something easy to do, but believe me, it isn't.

2^256 = 11579208923731619542357098500869000000000000000000000000000000000000000000 (rounded down).
This is the number of loops he/she has to perform... Each loop has a big cost... It's not easy to derive a public key from a private key. It's not easy to hash this public key, it's not easy to lookup the address in a database. Like i said before, if you'd give EVERY human on the planet one million latest gen GPU's and let them try to find a funded address for 100 years (continuously), there would be a 1 in 20 million chance one person on earth would find one funded address in those 100 years...

You'd think that, if hardware becomes better, these numbers would go down significantly... but no... Sombody very smart (not me) has proven that you'd need to capture all energy ever delivered by our sun (during it's complete lifetime) to power a computer to simply count to 2^256. So, eventough the number "256" or "160" seems cute and feasible, it simply isn't

Now, don't just think your money is safe all the time... You yourself say you've been phished... Next to phishing, there are also people that use flawed wallets. You have people that are reckless with their seedphrase. There are people that use brainwallets. There are people that run infected PC's. There are people that save their wallets in the cloud. There are people that buy hardware wallets from unknown sources....
Plenty of ways to get robbed or scammed... Just not by somebody randomly guessing your private key... It's not that it's technically impossible, just that it's practically impossible...

I guess the problem isn't that people don't believe in math, the problem is that human minds are not capable of grasping numbers like 2^160 or 2^256.
They just see an number, so they deduct there IS a chance... They write a tool, and they see that technically, it would be capable of finding a private key whose public key hash was already funded. What they do not grasp is that if every human on earth would be running a 1.000.000 GPU farm for 100 years, the odds somebody somewhere finds a funded address is still smaller than 1 in 20 million.

They don't grasp they have a better chance of winning the big price in the euromillion lottery several times in their lifetime than they'd have at finding the private key to a funded address.
So, instead of trying to steal from somebody, you're (much) better off buying lottery tickets... It's legal, the odds of "winning" are MUCH higher, and the payout is much better (multiple millions vs a couple thousand dollars).

Now, there are tools that work... These tools attack flawed implementations...
For example, i know some wallets had flawed RNG's in the past, or there are people that have written tools to crack brain wallets... Just because a human mind is a terrible source of entropy (i don't know who said this, but it's not my quote), they are able to do this. But this tool just tries completely random keys, not flawed implementations, so the odds of actually finding a private key whose public key hash was funded are sooooooooooo close to 0, that in reality you could say the odds are 0.

Ok, i'll bite... How many keys/second are you generating...
The thing you're doing is called bruteforcing, many, many, many have written tools for this and wasted a lot of time with no hits...


Ethereum is estimated to have 100M funded addresses (https://newsletter.thedefiant.io/p/ethereum-addresses-cross-100m-thats)

So you'll have to plug in your speed into following formula
(2^160 / 100.000.000) / speed (in checks/second) = average number of seconds to find a funded address

IF your tool would ever reach vanitygen's speed (which i doubt, since it's a GPU tool written in C++, not using any external api's), it would boil down to this:
((2^160 / 100.000.000)/20.000.000)/(60*60*24*365) = 23.171.956.451.847.141.650.870.193 years on average to find 1 private key (no matter which one).

EDITED: I actually just realised that in the example i removed from this post, i was scanning the keyspace, and not the address space, which is only 2^160.

Technically, however, nothing is holding them back.

Would they destroy bitcoin's decentralisation? Yes
Would they decrease trust in our ecosystem? Probably, Yes
Would it be fair? No
..
Would it be technically possible to create a council with most of the biggest miners and unilaterally decide what they'll mine and what not? Yup...

Now, when i said "technically, nothing is holding them back", i do mean TECHNICALLY... What should hold them back is the fact that by doing this, they'll probably cause a massive dump in the price, a massive dip in trust, a big fight in the ecosystem, and they have little to gain from this (at least, at this point, and from the point of view of commercial mining farms.....).

One last point, when you say (and i quote) "otherwise Bitcoin would easily be attacked and conquered through the backdoor", you have to realise that it's not a back door... It's a heavily fortified gate, with a big waterway and a drawbridge, and heavily armed guards in the watchtower.... There is no "easy" backdoor... It's not like you and me could come together, form a council and disrupt our ecosystem... Your "ticket" to the council would have to be a decent share in the current hashrate... I mean, in order to pull this off, you'd need a combined mining farm that equals or exceeds 51% of the current mining capacity... It would be a billion dollar operation just to get a say in a council like this (unless you're running a pool, and you're using your pool participant's hashrate as a bargaining chip, in which case i hope 99% of your pool participants leave your pool for good).
We're not talking about home miners, not even about guys that run a couple dozen ASIC's... We're talking about huge companies that invested tens and tens of millions of dollars into ASIC's, and pool operators that have hundreds and hundreds of miners... If they want to, they do have the power to disrupt things, and they don't need our permission to do so i'm afraid.

True... If it's 5 mining pools with 15% of the total hasrate per pool, and each pool has it's own "blacklist" of unspent outputs that cannot be spent, there wouldn't be a major problem, just a small confirmation delay (on average) for those that are in one or more of those blacklists.

I was talking more in the sense that if a couple of pools that represent >51% of the total hashrate decide to form an alliance and use a centralised blacklist, and on top of this decide to actively reject any other blocks relayed to them that contain transactions spending blacklisted unspent outputs, it would either mean the end of decentralisation (by forcing most of the non-alliance miners to also adopt their blacklist or risk having their blocks orphaned) or a major chain split (into a censored chain with the biggest hashrate and an uncensored chain with the smallest hashrate... Since the premise was that the censor camp has >51% to begin with). At least, that's how i imagine such a scenario to pan out...

But yeah, at this moment, this is just paranoia... It's a dystopian future, or an allmost-worst-case scenario... We're defenately not there (yet).

Outright censor, no... But they could potentially delay "illegal" transactions.... Especially if most miners would start censoring.
Let's imagine company's like this one one day hold 90% of the hashrate... This would mean about ~90% of the blocks would be found by them.
This would mean the average time between uncensored blocks would drop from ~10 minutes to ~100 minutes. And, those 10% uncensoring miners would indiscriminately pick between all transactions (censored AND uncensored), so the censored transactions would still have to outbid the uncensored ones.

In this dystopian future, the 90% censoring miners could even go as far as rejecting blocks containing censored transactions, making sure those uncensoring miners would always be mining an orphaned chain... Soon even those uncensoring miners would probably fall in line and start censoring for the fear of having their blocks rejected and their income forfeited, or we'd have a chain split (BitcoinCensored and BitcoinUncensored). I guess this is a 51% attack, since this scenario would be possible as soon as 51% of the miners would censor transactions AND actively reject any block that contains a censored transaction.

If this would ever happen, it would be the end of real decentralisation, or it would split our community in parts once again. Let's hope it never comes to that.

It's worth telling that 14 days/300Mb are the default settings for a node...
Every node owner can add startup parameters (in this case maxmempool and mempoolexpiry). So it's not like every node will drop a stuck transaction after 14 days, or when the size of the mempool exceeds 300Mb... Some nodes have waaaay bigger mempools (both in size as in time), so even if 90% of the nodes have dropped a transaction, it might still end up in a block if a couple of miners did not run their node with default settings (which might make sense for them, it's all about the money, and the more transactions you keep in your mempool, the more beneficial blocks you can build).

It's not only the maxmempool (size) or the mempoolexpiry (days) that can be set, a node owner can also set things like maxorphantx, wether or not the mempool will persist after a restart, minimum relay fee,... (and those are just settings for the core implementation, other implementations might have even more settings).

Bottom line: when talking about mempool or tx relaying, it's very hard to talk in absolutes since there is no "main" mempool. "The" mempool is just thousands of people running their own node with their own settings keeping a bunch of unconfirmed transactions in memory.

100% correct.
This being said, an 88 cent fee is ~2300 sats. Since a 1 input, 2 output tx is about ~220 bytes in size, it's safe to assume that (best case scenario) he payed a ~10 sat/vbyte fee.... Worst case a 1 sat/vbyte fee (otherwise the odds are pretty big the tx wouldn't have been relayed).

So, even best case scenario, he used a 10 sat/vbyte fee, whilst a 15 sat/vbyte fee is needed... So my initial advice still stands:

• if it was opt-in rbf (we don't know this), he could bump the fee. This would speed up his tx irregardless if the actual fee was 1 sat/vbyte or 11 sat/vbyte... If he bumped it to > 15 sat/vbyte he'd have a decent chance of getting his tx confirmed
• if he was the receiver or if he received change (we don't know this) he could do a cpfp. Same here, this would work irregardless of his initial fee, as long as the (child transaction's fee + stuck tx fee) / (size of the child tx + stuck tx) > 15 sat/vbyte this would work
• if his feerate was over 10 sat/vbyte (we don't know this, but best case scenario this is possible), he could try the free viabtc tool. This would not work if his fee < 10 sat/vbyte tough
• if he's willing to pay, a big mining pool (like viabtc) can always help him out. This would work irregardless of his initial fee... He just needs to pay them...
• irregardless of his fee, waiting will either solve the problem, or the tx will eventually drop from the mempool of most nodes, so at least he can re-create his tx

rebroadcasting could potentially be good, but could also be a bad idear, depending on the actual fee and how you think the mempool will evolve in the short term.

You did not post the transactionid (posting said txid will decrease your privacy, but not your security).
Depending on the transaction:

• if it was opt-in RBF, you could bump the fee
• if change was sent back to you (or if you're the receiver), you could do a CPFP
• Depending on your feerate, viaBTC offers a free tool (if your fee > 10 sat/byte)

What you could always do (independent on the tx):

• Pay a BIG mining pool to include your transaction (don't entertain offers you get in PM, unless they're verifyable from a big pool owner)
• Wait untill most nodes drop the tx from their mempool, then use the same unspent outputs to create a new transaction

What you *could* in some situations do is keep rebroadcasting the raw transaction, this might or might not be a good idear tough... Keeping rebroadcasting the raw tx will make sure it remains in the mempool of most nodes, making it allmost impossible to be dropped...

Without adding to the rest of the discussion (all other topics were already answered pretty well), i wanted to point out that there's a difference between using and re-using.

If you fund your change address with an unspent output, offcource you can spend this unspent output (using).
Re-using is funding your change address with an unspent output, spending this unspent output, and afterwards funding the exact same address with a new unspent output again...

I used to have ads for both ledger and trezor on my site, a grand total of 4 devices were sold using my affiliate link, giving me a net profit of just a couple of bucks

Truth be told, i'm not a marketer... I just threw some banners online and never actually looked at the output...

Following the same train of tought:

The tax authorities force widows/widowers to open safe deposit boxes with any banks after their spouse dies in order to take a big chunk in inheritance tax => "BANKSAFES CRACKED BY TAX AUTHORITIES... A SAFE DEPOSIT BOX IS NO LONGER SAFE"

The judge forces drug dealers to hand over the key(s) to their car(s) that were bought with the proceedings of drug dealing => "CAR SECURITY SYSTEM CRACKED BY JUDGE, CARS NO LONGER SAFE"

A robber forced a family to drive with him to the ATM machine and forced the father to give his pincode so the robber could withdraw the family's funds => "PINCODE CRACKED BY ROBBER, ATM's NO LONGER SAFE"....



I'm always flabbergasted how much damage a single reporter can do if he's unable/incompetent/unwilling to check his facts and write factual correct articles