Sk_Ezaz resetted the account password using a secret question. The forum's database was leaked some time ago which exposed all of the secret questions and made account recovery via secret questions vulnerable.

Your friend has to recover his account using a signed message which can be found in the link in the post above.

Yes. Asking someone to send a specified amount of Bitcoins to your account (while a good idea), does not necessarily proves that he is the correct person you're talking to. It could be someone paying Person A to send some money to your specified address.

A concrete and sure-fire way to validate identity is through signing a message. It doesn't require anyone sending any Bitcoins and you can have them validate their identity at the same time.

For example, you can ask them to sign a message saying:
"Today is 240820, I confirm that I am Person A and is currently speaking to sickfs2 over XX."

If it validates, you would definitely know that whoever owns the private key to the address knows that he's talking to you without any ambiguity.

** Of course, anyone with that private key can sign a message and send Bitcoins from that address.

To be fair, VPNs can't offer the same level of assurance as compared to Tor. You just cannot verify if a VPN provider is indeed not storing logs. Even if you were to purchase a VPN, you might as well just pay the evil fees which is way cheaper than using a VPN to create an account.

It's quite inevitable that Tor IPs will have high evil score. Without that, the forum would be over-whelmed with spam and it'll be hard to filter and read. It's a decent trade-off for a better forum but there might still be better ways to do this.

Do you have any other post to quote as examples? I can't exactly think of why this is deleted but the mods have their own POV. It's possible that there's some moderation bot that was triggered? IIRC, there was a bot like this for Beginner's and Help to filter out the spams some time back.

I doubt the mods would dig up the reason for reporting your post. I'll be very interested to see the reasoning though.

For the wallet import format of the Bitcoin private keys, the last 4 bytes is the checksum. This means, that the last 4 bytes can be any arbitrary Base58 characters. You'll have to derive your ECDSA private key yourself though, most programs would reject private keys with mismatching checksums.

Depending on your luck, there should just be 1 or 2 characters that you should have to guess. It doesn't hurt to guess all the characters but if you're tech savvy enough, you can do with just guessing one or two more characters.

That's weird.
Try sending the transaction again. Now, instead of pressing "Save", press "Pay".

You don't have to worry about the invoices displayed at the Send tab.

As usual, the idea of Bitcoin being decentralised has a huge impact on this.

The first problem being a lack of consensus. Given that each node would see different transactions, it would be impossible to reach a consensus on which transactions are to be included in the "block pool". Miners should have the say in which transaction they want to include since they're the ones collecting the fees, not the users.

Coinbase transactions has to be included in the merkle root of a block. Changing the coinbase transaction would change the entire merkle root.
Users shouldn't trust any transactions until they are put into the blockchain. Even if you can use a huge amount of hashrate to back your own transaction, the final say lies within whatever is put into the blockchain.

There is really a lot of considerations put into this. If you want faster confirmation, the best method is to reduce the block intervals.

Proxyrandomize is primarily a feature that benefits users using Tor. The feature allows the client to generate several different identity to connect to the Tor proxy. For each connection to a node, the traffic is routed through a different exit node. This improves security and "somewhat"(?) defends against sybil attack from a malicious exit node.

It's turned on by default, IIRC.

I'm almost 100% certain that you're just confused and nothing is lost so no worries there.

Saving the transaction doesn't actually do anything and it just creates an invoice for internal tracking. No Bitcoin is sent and no transaction is made. What you're looking for is to press "Pay". You'll be able to adjust your fee and view the final transaction before pressing "Sign" and "Broadcast".

The way Bitcoin transaction works is that the addresses in the inputs cannot be "faked" or changed. To be more exact, the inputs doesn't contain addresses. The block explorer just parses the UTXO to display the address.

Anyhow, asking someone to send a small amount of coins to a specified address is not the best way to prove ownership of an address. Signing a message[1], is a free and easier method.

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

Interesting, I'll have to do more read up on that aspect.
IIRC, quite a few pools still do SPV mining up until now.
With the validation of the block and everything? Won't the pool have to validate and remove the transactions from their mempool first? I'm not sure how much time it takes for it to be done, given all the overheads with the communication with the miners included.

Though the antpool site states that it's 4 seconds, the actual time might be faster.
Given how most pools actually monitor each other's stratum server, I doubt it could be done easily right now.

Yes, most mining pool are able to choose their own transactions. But there isn't any rational mining pool which would intentionally include only the coinbase transaction when they are trying to maximize their profits.
The scenario given is a block being mined 4 seconds after the previous block. It's true that mining pools can issue a message to update the data but in this case, the mining pool likely wanted to utilise the small amount of time that it took to reconstruct their merkle root. My hunch is that they did issue a mining.notify and that they didn't include any transactions as of yet. You can observe how only the blocks with quick succession are empty but the others are populated (to a reasonable capacity).

Yep, selfish mining. Would it work for Antpool though? They only have an estimated 9% of the network's hashrate, they're more likely to lose out from this attack.

Awh sorry, I thought you bidded for lot 1 only 

---

Lot #4 0.00125BTC
Lot #5 0.00125BTC

Um, I don't think the posters above actually read the topic.   You don't have to open your firewall because the communication is done within your LAN.

Anyways, you need to add your RPC username and password. You have to configure your client's config file, the bitcoin.conf equivalent. That's the reason for the connection being refused.

It's very concerning, he should be getting the help that he needs.

Instead of it being tagged as NSFW, does this fall under the "threats to inflict bodily harm, death threat" [1]? The general usage of the rules is when the threat is directed towards someone else but does it count in this instance also?

[1] https://bitcointalk.org/index.php?topic=703657.0#post_rules

Your seeds or private keys shouldn't leave your device in the first place. Connecting to a VPN does help with the anonymity but the impact to the security should be managed fairly well. There's a risk of Sybil attack with SPV  wallets but some wallets tries to mitigate this.

It's really based on luck.  There's nothing dictating the intervals of the blocks being found. Mining is just the act of hashing a block header and changing the variables within it. With luck, a hash with the appropriate target can be found within seconds or hours.

As you said,  it's an average of 10 minutes.  So in a larger sample size, the average is still close to 10 minutes regardless.

That's in theory. In practice, the best real world estimates still puts it below 2MB.
Segwit was activated for quite a long time and that Bitcoin Core has adopted segwit for quite a few revisions already. Majority of the nodes (based on bitnodes) is running on a segwit-compatible version.

It's not quite the right phrasing to upgrade Bitcoin addresses but it's more accurate to say converted. The main culprit is some of the services that refuses to adopt segwit address types. You also cannot tell a normal P2SH from a P2WSH transaction until it is spent at least once. I would say the statistics might be slightly skewed.

It's purely speculation because I don't own a mining pool and neither do I know the inner workings of antpool.

If what is stated on their website is correct, Antpool found the block after 4s of the previous block. My guess is that while they know exactly what is in the block and that it is accurate, the pool took some time to take out the transactions and repopulate their block headers with the relevant transactions. At this time, it is better to not mine any transactions in case the pool accidentally includes a transaction that was already in the previous block.