I'm pretty sure I did quite a few times till I put you on my ignore list. Well, including that one time you compared a transaction fees to a tax, not sure what you were implying. Now that you say, perhaps I should supplement the answer above.
As compared to the fiat system that you adore, Bitcoin does not have a steady or increasing inflation but rather it has a decreasing inflation. This means that Bitcoin will have a fixed supply cap and will not exceed the maximum limit as documented in the protocol, well unless you fork it for an altcoin. The primary function of a block reward is to distribute the coins fairly. If the currency has a fixed supply cap, there is no way you can achieve that without the block rewards being zero or negligible throughout it's lifespan. It does not matter if they get a chance to earn block rewards or not. The difficulty system ensures that the difficulty of mining a block is proportional to the cost of mining that block.

Having a steady/constant inflation would undoubtedly devalue the price of Bitcoins and the miner's would probably get compensated to the same effect if they're mining solely for the transaction fees in the future. If you don't see the block rewards and the transaction fees as a compensation for the miner's expenses to mine Bitcoins, then you probably won't accept most of the reasoning. Appreciate the reply though, hope we can finally have some constructive discussion.

I'm not sure why would you spend all your time trying to undermine Bitcoin when there is obviously loads of altcoins that does exactly what you envision, lifetime inflation, free from riding the coattails of fiat, whatever. There's probably an altcoin that is suitable for you. It's meaningless to try to entertain you when you obviously won't accept any logical answers. If you think Bitcoin should act like fiat, go use fiat.

Do you have the private keys? (5..., K... or L...)?

If you do, download and verify[1] Electrum from Electrum.org. Install it and start the Electrum. You should be greeted with this:


Press Next> Create A New Seed> Segwit and you should see a 12 word sentence. Copy that down and keep it safe, it's your only way to retrieve your funds if something happens to your Electrum Client. After you verify, enter a password (or not), you should be greeted with an empty wallet. Next, go to Wallet>Private Keys>Sweep and enter it this way:



Press Sweep, adjust the fees accordingly, Press Finalize, Sign and finally Broadcast.


[1] https://bitcointalk.org/index.php?topic=5240594.0

Calculate the fees that you require.
- Assuming Bech32 (bc1...) transaction
A typical bech32 transaction should be roughly 110 vbytes, assuming 1 input and 1 output. Add the size of your OP_return message as well, that'll be roughly 190vbytes, give or take. Your fees should not be below 190 satoshi, if you want a confirmation anytime soon you would probably be looking at ~ 2290vbytes , deduct the transaction fees from the inputs and you would be left with the change that you should have. If it's below 294 satoshis, you should probably just omit it completely.

That being said, please do not craft the raw transaction yourself if you're not familiar with what you're doing. If you want, using a utility like Coinb.in to craft it and validate using your Bitcoin Core client would probably be more suitable. If you're just looking to experiment with it, either use regtest or Testnet.

Is one of your outputs is below 546 or 294 satoshis. If that's the case, you have to omit that output or use less funds as your fees.

Correct.
Correct. As long as you control at least one of the outputs in that unconfirmed transaction. The amount is a bit wrong as the change should be 0.000001BTC and that's a dust but it's not a problem since most wallets will not include a dust output.

You can. Just make sure that your wallet includes at least one of the outputs from that specific transaction, and you'll be able to do CPFP even if you spend the other confirmed output as well.

Child pay for parent involves two transactions.

The parent transaction is unconfirmed.

A -> B
   -> C   Fees: 1 sat/vbyte 142 bytes

B is the address that you're sending to and C is the address that you control which is the change address. Unfortunately, your fee rate is too low and it remains unconfirmed.

Since you have the ability to spend output C, you can create a transaction which spends it with a larger than proportionate fee (say 20sat/vbyte).
Child transaction:

C -> D Fees: 20 sat/vbyte 299 bytes

Total fees: 142sat+ 5980sat
Fee rate: 13.8sat/vbyte

If you combine both of the size and fees together to get the fee rates, it should be fairly high.  If the combined fee/size is sufficiently high, miners are incentivized to mine both of your transaction so as to obtain the transaction fees for both.

To answer your question: Depends. As illustrated, miners are incentivized with CPFP only if you're spending an output from the unconfirmed transaction so they would confirm both to collect all the fees. CPFP requires you to include at least one output from the unconfirmed transaction. If possible, enable opt-in RBF.
 

---

CPFP is not the most ideal method to bump fee. Spending C entails the fact that you also have to pay for the cost to spend that output and thus incurs an additional fee ontop of your current fees. In comparison, Replace-By-Fee is better as you can just replace the original transaction with a higher fee rate for it to be confirmed. There are cases where CPFP is useful, if you're not the sender and/or if you didn't enable RBF.

On a protocol level, there is OP_return, an opcode which allows you to store about ~80 bytes of data as an output. You can encode arbitrary data with it to burn coins or to place messages. Go to any recent blocks and you'll see that the Coinbase transaction (which has the block reward) has an OP_return that indicates the merkle root of the witness tree.

There is no limits that's defined on a protocol level but you can only have one of such output and it has to be less than 80 bytes unless you're able to find a miner to help you and put it in their block. Anything greater than 80bytes is considered non-standard and will not be relayed by the nodes. It's inherently expensive to store huge data on Bitcoin's blockchain, blockchain bloat is a serious concern.

Logically, if on the node hasn't seen a transaction on the stale chain, it would also be pushed from the stale block into the mempool, unless it is a non-standard transaction.

If a node is well connected, then it would probably be able to see both of the blocks (albeit only validating the entire block for the first block received) as the block header would be relayed.

No one in the right mind accepts a $22 million with 1 confirmation when there's obviously a competing fork alongside it. I'll say 6 confirmations at least and at that point, trying to outpace the entire network would just be burning money. This is NOT a double spend attempt in any malicious manner, conflicting transactions were mined in two competing forks and one of the chain eventually won. There was no evidence that this could have been planned, either forks would have won easily.

I'd say that the news headline took some random responses on Twitter and threw it on their headline to either buy some cheap Bitcoins or to get more traffic. Depends on which you believe.

Why do you include 30240 though? The time taken for that block can't be considered because it only takes into account the timestamp that that block has but not the block prior to that to give the code a representation of the time to generate that specific block, and thus wouldn't actually include the time taken for that block right? Am I missing something?

If we're going by the logic to calculate time intervals of 2016 blocks and if we want to consider block 30240, wouldn't we include 30239 as well?

The test code is here[1], I'm not very well versed in cpp but from my limited understanding, the underlying logic is to calculate the time taken to generate the previous 2015 blocks (and by extension the time interval within the 2015 blocks) because the time taken to generate the #0 block is not accounted for or else the code would overlap into the block prior to the #0 block to also account for the time taken for it. Please do correct me if I'm wrong, but that's what I understood when I skimmed through it previously. It's the off-by-one error, after a brief search and I can't find any remedy done for it.


[1] https://github.com/bitcoin/bitcoin/blob/4a540683ec40393d6369da1a9e02e45614db936d/src/test/pow_tests.cpp#L14

Difficulty is just a representation of the target. Each block header has a target and it is represent in bits. The current target is 170da8a1 or 0000000000000000000da8a10000000000000000000000000000000000000000 in hexadecimal. For a block to be valid, the hash of the block header must be lower than or equals to the current target. For the current difficulty, you'll just use the maximum target/current target which will result in 00000000FFFF0000000000000000000000000000000000000000000000000000 / 0000000000000000000da8a10000000000000000000000000000000000000000 , equals to approximately 20607418304385.63 which is the current difficulty.

Now, since difficulty is a function of target, you can do it in reverse to obtain the next difficulty. When calculating the next difficulty, you'll be taking the expected time/actual time of the last 2015 blocks. Let's take for example the previous difficulty adjustment which was on 9 Jan 2021. The average block time was about 9 minutes and 2 seconds. The expected difficulty increment would be 600/542 which is roughly 10.7% increment. If you were to convert the new target from the new difficulty (18,599,593,048,299 x ~1.107), you would be using 00000000FFFF0000000000000000000000000000000000000000000000000000 / 20607418304385.63 which would give you a target of 0000000000000000000da8a10000000000000000000000000000000000000000.

You can actually just calculate the target without a conversion to the difficulty but I wanted to show how they're linked. Given that the network attempts to keep the block interval at an average of 10 minutes, the difficulty adjustment is based on the deviation from the expected time and uses it to calculate the difficulty increase, or the decrease in the target. They have an inverse relationship.

Might have been intentionally mined by SlushPool. There's apparently another RBFed transaction prior to the transaction that was included in the F2Pool's block. It seems highly unlikely that the delay was so significant and that SlushPool didn't see the other transaction as well[1]. I don't think SlushPool has a way to PushTx but it's still quite weird.

[1] https://twitter.com/BitMEXResearch/status/1352256363704037377/photo/1

I don't think SHA1 was used for your brainwallet, that was the signature for the webpage itself and has nothing to do with your brainwallet. A small change in your brainwallet phrase will have an avalanche effect in your resultant WIF private key, having knowledge of that can possibly help you to verify if the key is correct but won't help you to reduce the time if you were to bruteforce using the phrase.

If it's a dictionary phrase, I would expect it to be wiped by now. I'm not exactly sure how Bitaddress used to generate them but I presume they are not salted.

Yes, Blockchain.com actually do have a lot of features missing so that could leave some clues but it won't be concrete. Though I'm not sure why that would be an issue at all. I don't use Blockchain.com wallet as the features that it has pales in comparison to Electrum. Consider switching to Electrum nonetheless.

Looking at the raw transaction, no. You'd have to probably do an indepth analysis of the spending behaviour. There could be some behaviours that could give clues to what kind of wallet it is. It's by no means accurate though. For example, a transaction without opt-in RBF and with a legacy address could be a Blockchain.com wallet but it could also be someone intentionally disabling opt-in RBF or just spending from an old Bitcoin Core client.

You can also spend Segwit inputs together with P2SH(3...) or P2PKH(1...) inputs on most wallets so a transaction won't be indicative of what kind of wallet it is primarily.

It's not exactly a RBF either. RBF would've pushed the 1 sat/byte transaction out of the mempool. There were two other RBF transactions that replaced the 1sat/byte transaction. In a scenario where RBF is in play, either of the subsequent transactions would've been more likely to be included in a block. It's either that SlushPool doesn't include RBF transactions, the subsequent transactions had poor propagation or the user used some utility to directly push it to Slush.

The subsequent transactions were propagated well due to RBF but that won't account for why the 1 sat/byte transaction got in. Anyways, it's just a typical case of the media capitalizing on this. There's a reason why exchanges requires more than one confirmation, this would've been malicious if either of the transaction wasn't broadcasted beforehand but that's not the case.

Have you tried signing it with Electrum? Might be just a problem with mine but it won't sign and shows it as signed already.

I don't think CoinB.in would be the best idea. Using Electrum to script raw unsigned transaction is much more convenient as it displays the size of the transaction beforehand for a more accurate fee. Using the master public key in place of individual addresses would help the user to spend all the funds if needed. It also doesn't have a QR code plugin to encode QR codes.