text:
Are P2PKH or P2SH transactions malleable?
BIP66 fixed one source of transaction malleability and segwit, to my understanding, fixed the rest of the sources. Yet, there are still many common types of non-segwit transactions in use, like P2PKH P2SH(PWPKH) P2SH-multisig, are these subject to malleability attacks by a stranger?
I understand that even if someone knows how to do a malleability attack on these transactions, he might choose to answer "no" (or don't answer) to prevent these attacks. But, on the other hand, if a malleability attack on these common transactions was possible, I believe someone that wants to push for segwit adoption would have already build an app to systematically attack.

Yes. Many of the malleability sources listed in BIP 62 still exist today. Most (if not all) are not standard, i.e. most nodes will not relay transactions that exploit them, but they are not consensus rules. So a miner can still perform malleability attacks.

So in theory a miner or mining pool could be doing malleability attacks consistenly and openly to promote segwit adoption?


text:
Generate keys/addresses for all altcoins
I'm looking for a library or method to generate addresses for as many of the most popular currencies/altcoins as possible. Is there a known library that supports this? Or do I need to use a specific client for each coin?
Thanks!

You've asked multiple questions here, requiring quite big answers. I'm voting to close this as too broad until you separate the questions. Tag me a comment if you do separate them, and I'll do what I can to undo my vote or reopen it.

It's basically 1 question - whats the easiest way to generate addresses for various altcoins. @HighlyIrregular

Then perhaps the "Which altcoins use..." part of the question can be removed?

@HighlyIrregular updated

You should find libbitcoin's bx command line interface to be quite useful. The code line references BIP44 Altcoin Version Mapping Table might be a bit stale, but the content of this table has strong trace-ability. Example 7 through Example 11 should get things going quickly. These examples merely extend the initial work documented by Andreas M. Antonopoulos in Chapter 4.

Here is my "quite big answer":
I've successfully used http://cryptolife.net/upwg/ which is stated to be "Open Source JavaScript Client-Side Universal Paper Wallet Generator".
It doesn't generate wallet addresses by coinname, but instead by the leading character within the wallet address.  I get these from the block explorer for the coin, looking at top address.
http://www.universalwalletgenerator.net/ lets you do it by coin name.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Is there a way I can get my own independent vanilla p2p cli wallet?
To elaborate, I want a wallet that's independent of any third party intervention unlike coinbase wallets being dependent on the company.
If there is the way how much privacy can be maintained?
And is there a way I can access it globally.
Also, it would be better to have a solution in which I won't have to download the entire ledger.

Related: https://bitcoin.stackexchange.com/questions/52/how-anonymous-are-bitcoin-transactions

@HighlyIrregular Thank you, for the edit.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Monitor a bunch of addresses for deposits
I have a situation where I create one address per user through GetNewAddress(User.Id)
So, in the end, I have a lot of addresses to monitor, to see if any user has deposited money.
I can do something like this:
foreach (var User in Users)
{
  var T = GetReceivedByAccount(User.Id);
  .. do something if money arrived
}

Wait 30 seconds and repeat...

But I'm guessing it's not the most efficient.
Is there a better way to do this?
Or can I get all transactions within a specific range in the wallet and then parse them by account?
Sorry if the question seems basic, I'm extremely new to this.. got some code running for the first time something like 16 hours ago :)

Does this answer your question? Get notified of incoming Bitcoin transaction, as soon as it broadcasted one answer says "If using the wallet notify option in bitcoin.conf, you can get a notification any time a transaction occurs on the network that matches a bitcoin address in the wallet. To use this, of course, you'll have to keep Bitcoin-QT or bitcoind running at all times." See also How do I use walletnotify

We use a third party service for this - i’d recommend https://blockchainwebhooks.com - You can set a webhook for each address, and when a new transaction enters a block with this address as an input or output the webhooks will trigger and send you the transaction details. Hope this helps!

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Are wallet credentials really safe?
I’m using Copay as my Bitcoin wallet. I see it is opensource with the code available in github. What guarantees that they uploaded binary based on that source code? Does it go through Apple approval? Storing more money in bitcoin, I want to be sure my password / credentials are safe and that the developers are not sending out in a hidden way, via backdoor.

You don't have any guarantee. You are relying completely on the developers to submit the binary application file based on that source. You are also relying on Apple not to manipulate the application binary once it gets to them.
It's no different with Bitcoin Core or any other wallet or software. In all cases you're putting your trust in whoever does the build and the source and tools they use.
One option is to look at the history of the software. If it's relatively mature and has had no faults, either malicious or competency related, then it may be safe to put a degree of trust in it.

Is web based bitcoin transaction more save? There I can see HTML code. Or is it any server side programming need to do a transaction?

Web based is even riskier, look at Mt Gox and the many other similar cases. Safest is a hardware wallet such as Ledger or Trezor.

Would not a paper wallet be considered the safest ?
Only you know under which stone you tucked away the note about
private key and backup phrase.

Yes,it safe because is not like bank account and no óne can hack it wallet account unless the person share his deatials to someone


text:
What information can an attacker gain from watching the users behavior in block chain?
Given the blockchain is a public ledger, if user chooses not not change their public key (address) every time they make a transaction, what information can an attacker gain from watching the users behavior?

If you use the same address for every transaction you receive, then anyone who knows that address is yours (and is watching the blockchain) will have record of your entire history of transactions. You will have zero financial privacy.
Address reuse is also indirectly bad for the users you transact with: anyone who knows the other user's address will now also know that they transacted with you. Approximate time, and the transaction amount will all be public knowledge.
Thankfully, by using a new address for each transaction, it becomes extremely difficult to make such assumptions, as doing so creates a very high level of plausible deniability and uncertainty when attempting blockchain analysis.
Bitcoin privacy is a highly nuanced topic, for a much more in depth explanation see: https://en.bitcoin.it/wiki/Privacy


text:
I received an email that says someone sent me bitcoin
I was sent bitcoin through email, but I am being told to pay a fee first so that I can receive the funds. What should I do and I don't have the fees?

This sounds like a scam. Receiving bitcoins does not require paying fees.
If you are not otherwise expecting this payment, then you can safely just ignore the message. It is spam.

You should never trust people who promise you money in exchange for more money.
Ignore and delete the mail.


text:
What happens if I buy BTC from an ATM, but the transaction never confirms?
I bought bitcoin through the atm machine, it was sent to me but is yet to be confirmed over 52hrs.. if the transactions later disappeared from the mempool / blockchain, how will the sender get back the fund, since not send from a wallet?

In this case, you would need to contact the ATM operator / service provider, and provide them with some proof of your purchase and the failed transaction. When completing your interaction with the ATM, you should receive some sort of receipt that details this information, though the exact specifics will likely vary from one ATM to another.
If you are running a full node, perhaps you could find the transaction which was supposed to pay you in your node's mempool, and then save it to be rebroadcast in case of an extended period of non-confirmation.
But I think that in most cases, you will just need to contact the customer service department of the ATM operator, and request that they complete the transaction.


text:
I had bitcoin stored on my phone, but then lost my phone, please help
I had some bitcoins stored on my cell phone, but then it was stolen from me. How can I recover the bitcoins? Please help me!

Sorry to hear that you have had your device stolen. When using Coinomi all you need to be able to restore your funds on a new device is the 24word recovery phrase which you were given when you set up your wallet. You can learn more about this here

Since Coinomi is an HD wallet, all you need as a backup is your Recovery Phrase

...

If you ever lose or change phones, or want to use multiple devices at the same time, simply install Coinomi and choose the option "restore a wallet" and input all words in order. Make sure all characters are typed in lowercase and that there is a single space between each word. Type the first 3 or 4 letters of each word and select the suggestion that pops up to avoid misspellings.

Please open a ticket on that site if you require further support. Thank you

You should include the important and relevant content from the link in your answer - stackexchange aims to avoid link-only answers as they tend to be useless once the linked content is deleted or updated.


text:
Knowing if a public address is spendable by an HD seed?
I want to know if an address is spendable by an HD seed and for that purpose I am using the following command:
> bitcoin-cli getaddressinfo 3LFc64RRd96ejjYvm14KaogBF9fmeNmePW | jq '.solvable'
false

However as mentioned here and here it's impossible to know with 100% certainty that an HD seed can't spend from a certain address as one would need to generate infinite addresses. To counterbalance that I discovered a command that increases the 'search space':
> bitcoin-cli keypoolrefill 1000

However, I am not sure getaddressinfo is sentitive to this keypoolinfo parameter or is just checking the addresses so far generated (the ones that can be obtained via bitcoin-cli listreceivedbyaddress 0 true). I could test this with a second node but my other node might be using another seed to generate new addresses. Even though I used sethdseed, I see a different xpriv when dumping the wallet.

Trying to enumerate all private keys using Bitcoin Core's wallet is extremely inefficient. Furthermore, any address that you generate in Bitcoin Core will inherently come from a HD seed because Bitcoin Core is a HD wallet and uses a HD seed. You also aren't going to get any information for a HD address that is not part of your wallet.

However, I am not sure getaddressinfo is sentitive to this keypoolinfo parameter or is just checking the addresses so far generated (the ones that can be obtained via bitcoin-cli listreceivedbyaddress 0 true).

It is "sensitive" to the keypool. When you add keys to the keypool, they are actually generated and saved to the wallet file along with some metadata. getaddressinfo looks up whatever metadata is available regardless of the associated key being in the keypool or not.

I could test this with a second node but my other node might be using another seed to generate new addresses.

Unless you have explicitly set a specific seed, then it most definitely is. Otherwise that would be a security vulnerability and anyone could steal anyone else's coins if they all used the same seed.

Even though I used sethdseed, I see a different xpriv when dumping the wallet.

You need to provide the seed of your first wallet. Otherwise it will generate a new random seed and use that.

Thanks for the quick answer, good to know getaddressinfo is 'sensitive to keypoolrefill. Is there any way to read the information contained inside wallet.dat (or fee_estimates.dat for that matter?)
Regarding the last the last topic, yes, I know every new wallet will have a random new seed by default, it just seemed that I was not 'overriding' this new seed with the sethdseed command that I used to import


text:
How to verify a signed message by bitcoin core?
I want to verify, in Java, a signature produced with bitcoin core's signmessagewithprivkey (equivalent to the verifymessage). I noticed a bitcoinj method similar to the bitcoin core's verifymessage - org.bitcoinj.core.ECKey.verify. What follows is my implementation attempt and its test.
For testing I will generate a signature and check it in bitcoin core:
>bitcoin-cli signmessagewithprivkey $(bitcoin-cli dumpprivkey 1CwKH9PQPkFPjQagEv483FUM5ngk57L3Pp) ""
H2wp/+5N2+OQwP6a5GFRbt8S+EfML1Szx4uhWPfiO0e/QcY2rZQOkLOR+unknNl4NgDWBacRRXOLjr+m53V0xic=
> bitcoin-cli verifymessage "1CwKH9PQPkFPjQagEv483FUM5ngk57L3Pp" "H2wp/+5N2+OQwP6a5GFRbt8S+EfML1Szx4uhWPfiO0e/QcY2rZQOkLOR+unknNl4NgDWBacRRXOLjr+m53V0xic=" ""
true

So, signing an empty message with the RPC using the address 1CwKH9PQPkFPjQagEv483FUM5ngk57L3Pp (public key: 021c3be5fb7820c56d881ea2d02a906d87540ec8888bbe819b7abd2e39f6f6e512), produces the signature H2wp/+5N2+OQwP6a5GFRbt8S+EfML1Szx4uhWPfiO0e/QcY2rZQOkLOR+unknNl4NgDWBacRRXOLjr+m53V0xic=.
My Java implementation attempt:
import org.apache.commons.codec.binary.Hex;
import org.bitcoinj.core.ECKey;
import org.bitcoinj.core.Sha256Hash;
import java.math.BigInteger;
import java.util.Base64;

public class Notebook {

    public static BigInteger[] ParseSig(byte[] sigBytes, int sigOff) {

        BigInteger r = new BigInteger( 1 ,sigBytes, sigOff, 32);
        BigInteger s = new BigInteger( 1, sigBytes, sigOff + 32, 32);
        return new BigInteger[] { r, s };
    }

    public static void main(String[] args) throws Exception{

        // Signature
        String signatureString = "H2wp/+5N2+OQwP6a5GFRbt8S+EfML1Szx4uhWPfiO0e/QcY2rZQOkLOR+unknNl4NgDWBacRRXOLjr+m53V0xic=";
        byte[] signatureBytes = Base64.getDecoder().decode(signatureString);
        BigInteger[] signatureRandS = ParseSig(signatureBytes, 1);
        ECKey.ECDSASignature signature = new ECKey.ECDSASignature(signatureRandS[0], signatureRandS[1]);

        // Public key
        String pubKeyString = "021c3be5fb7820c56d881ea2d02a906d87540ec8888bbe819b7abd2e39f6f6e512";
        byte[] decodedPubKeyString = Hex.decodeHex(pubKeyString.toCharArray());
        ECKey publicKey = ECKey.fromPublicOnly(decodedPubKeyString);

        // Message
        String message = "Bitcoin Signed Message:\n";
        Sha256Hash messageHash = Sha256Hash.of(message.getBytes());
        Sha256Hash messageDoubleHash = Sha256Hash.of(messageHash.getBytes());

        // Test
        boolean result = publicKey.verify(messageDoubleHash, signature);
        System.out.println("Result: " + result);
    }
}

Notice that I used the salt Bitcoin Signed Message:\n before hashing the message - this is done by signmessagewithprivkey as shown here and here. The problem is the above implementation doesn't pass my test and I don't know why...
EDIT:
Thanks to Septem151 I was able to fix this. The code passes the test, if the message section is replaced with:
        // Message
        String message = "Bitcoin Signed Message:\n";
        byte[] messageBytesEncoded = new byte[message.getBytes().length + 2];
        messageBytesEncoded[0] = 0x18;
        messageBytesEncoded[messageBytesEncoded.length - 1] = 0x00;
        for(int i=1; i <= message.getBytes().length; i++) messageBytesEncoded[i] = message.getBytes()[i-1];

        Sha256Hash messageHash = Sha256Hash.of(messageBytesEncoded);
        Sha256Hash messageDoubleHash = Sha256Hash.of(messageHash.getBytes());

FYI you could use "\030Bitcoin Signed Message:\n\0".getBytes()

The preimage used when signing messages with Bitcoin Core is a combination of the "Magic" phrase: Bitcoin Signed Message:\n and the Message you are signing. However there is one caveat, being you must have a VarInt prepended to both the "Magic" and the Message. The VarInt encodes the byte-length of the message (encoded in UTF-8). Since the "Magic" value never changes, its VarInt value will always be 0x18.
For your example, the message is nothing, therefore your VarInt will be 0x00. Your preimage and sighash becomes:
Preimage: 0x18426974636f696e205369676e6564204d6573736167653a0a00
Sighash: SHA256(SHA256(preimage)) = 0x80e795d4a4caadd7047af389d9f7f220562feb6196032e2131e10563352c4bcc

    0x18       0x426974636f696e205369676e6564204d6573736167653a0a        0x00      (empty)
MAGIC_VARINT                       MAGIC                           MESSAGE_VARINT  MESSAGE


text:
How to get the pool name from coinbase transaction?
Is it possible to retrieve the name of the pool that mined a block looking at the address in the coinbase transaction?
For example, the address in the coinbase transaction of block 00000000000000000002dce191b529017edae3c76d91ab21f757d156daebf43f is: 1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY.
From Blockchain Explorer, that block has been mined by F2pool.
Is there a way to associate F2pool with 1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY?

Although is may be possible to associate addresses that appear in coinbase transactions with mining pools, this relationship can be quickly broken - because they can easily change this address - and that's not how tipically mining pools are identified.
Mining pools/miners that want to identify themselves do so in the scriptsig of the coinbase. In your example, the scriptSig is:
03404a092cfabe6d6d5995dc2134639c494208abda86747b0f77fe5b92e9456a85974f452f51a3da0910000000f09f909f00144d696e6564206279206365616d6b7978696c6f6f000000000000000000000000000000000000000000000005001f450000.
If you decode this hexadecimal number to ascii, you get:
@J ,ú¾mmYÜ!4cIB«Út{wþ[éEjOE/Q£Ú    ðMined by ceamkyxilooE
You can see that it contains the string Mined by ceamkyxiloo, which is what identifies F2pool. Most of the decoded text is unintelligible because this field (expect the first ~4 bytes) are used to create entropy during mining - what is called "extra nonce".
Most block explorers keep a mapping of these signatures to miners/mining pools. Here is an (outdated) mapping.

Keep in mind: anyone can add Mined by ceamkyxiloo (or similar) to the scriptsig of a coinbase output, so it isn't a foolproof method of determining the pool that mined a block.

They can and do have false self attribution. I know because I was responsible for at least one.

Why should someone add "Mined by ceamkyxiloo" even if the block was not mined by F2pool?
Also, there is a reason why a pool should keep on changing its address?

@Rick its impossible to answer "why would someone do this?", but the point is that they can, and have. Mining is designed to be something that can be done anonymously, for hopefully obvious reasons.

I did it because I thought it was hilarious that people keep trying to “measure decentralization” by looking at a self reported value. Nobody ever noticed, not even the pool it was falsely attributed to.


text:
Is it possible to create a token on the Bitcoin blockchain?
If so, would this token adhere to the same principles as Bitcoin, such as halving events and mining techniques?

BRC-20 tokens are created on the Bitcoin blockchain and don't follow Bitcoin rules for halving and mining.
You could think of it as a bit like like writing "IOU €50" on a $1 banknote. The US Treasury and The Bureau of Engraving and Printing don't know about or control those IOUs.

Many different projects have been started as an attempt to bring tokenization on to Bitcoin such as Taro, Counterparty, and RGB. It is worth noting these are not Bitcoin core standards but are projects built on top of existing Bitcoin functionality. Therefore they do not have any implicit tie to Bitcoins proof of work consensus mechanism and also would not automatically inherit the halving cycle of Bitcoin. Even if tokenization was built at the core level, tokens always have rules that are distinctly separate from the rules of the chain's native coin.

Yes, that's what BRC-20 tokens (aka 'ordinals') are. It sort of jumped the shark though. It was popular for about 3 weeks, but it's difficult to get started for most new users. They are created using ordinal inscriptions, which are a type of script file that can be stored on the Bitcoin blockchain. BRC-20 tokens can be used to represent a variety of assets, such as digital art, collectibles, and gaming items as well, so they might end up competing with NFTs some day.


text:
What is the point of "Bitcoin Lightning" and "Bitcoin Liquid"?
Even having been "into" Bitcoin since almost since the start, I constantly find new weird things mentioned which are just apparently taken for granted and exist suddenly and somehow have tons of support and users.
Today I learned about the existence of "Bitcoin Liquid". I had not heard of it ever until today (2021-01-21). Apparently, it's the same thing as "Bitcoin Lightning", in that it's not a separate "altcoin", but somehow "attached to" Bitcoin yet not using the Bitcoin blockchain. This makes no sense to me.
I do know that "Lightning" was touted as a solution when the Bitcoin network was all clogged up with waiting times for transactions a few years ago, but since then, I've not heard one peep of it. Never heard it mentioned at all. I assumed that it was dead. But apparently it still exists, and now "Liquid" also exists. Are they competing against each other?
I find it utterly impossible to figure anything out by reading their official websites, because they always use bombastic wording and list how many groups support them and they are the future and blablabla... Useless information. I want to know neutral, real information. I can't find it anywhere.
What exactly are "Bitcoin Lightning" and "Bitcoin Liquid"? Why do they exist? Why aren't these "BIP"s put into Bitcoin itself? How can they be attached to Bitcoin yet be separate? Is one of them objectively better than the other? Do they solve different problems? Is one of them dead now? Should I be using/bothering with them? Are they an attempt to take over Bitcoin slowly by not being an "altcoin" upfront, but slowly turning away from Bitcoin?
I swear, I could probably sit there and spend my entire life doing nothing but trying to read up on Bitcoin-related stuff and still never have any clue what's going on. It seems like not one day passes without some "revolutionary" and "fantastic" new invention which seems to be little more than a slick website with nonsensical sales talk on it.
I'm looking to get a grasp of the state of Bitcoin and its development. I have no idea how these weird "sidechains" fit into that or why I should pay any attention to them. Maybe it's the best thing ever and makes perfect sense?

The lightning-network (LN) is an instant payment system built on top of Bitcoin. Its relationship to Bitcoin is akin to that of Visa card payments and the US banking system. The LN is a convenient and efficient way to pay directly from one user to another, especially for smaller amounts. Under the hood, the Lightning Network works by spanning payment channels between users and providing cryptographic guarantees to prevent abuse. Compared to on-chain payments, the LN trades off different privacy properties, lower transactions fees, and manifold increased transaction throughput with different security assumptions and the opportunity-cost of staging funds in payment channels.
The liquid sidechain is an alternative blockchain protocol whose native currency is "Liquid Bitcoin" (L-BTC). Users may convert Bitcoin to L-BTC 1:1 by paying into the custody of the federated peg or withdraw BTC by returning L-BTC back to the peg on Liquid. The Liquid sidechain operates with different consensus rules that give it better privacy (via confidential-transactions), greater throughput, and the ability to issue other assets. This comes at the cost of trusting that the majority of the Federation remains honest. Being closely related to Bitcoin, Liquid has its own Lightning Network.
LN and Liquid are sufficiently separate from Bitcoin's protocol development that they are not covered by the Bitcoin Improvement Proposal process even though LN is widely considered to be part of Bitcoin, while Liquid is more distinct. LN and Liquid solve different problems and are optional.

So, basically Liquid is another altcoin…

@Geremia in the singular sense that a separate ledger/token are maintained, yes. But it uses the BTC ledger as the final settlement layer. There's no point in day trading L-BTC. Is arbitrage even possible, idk?

No, given the peg always provides 1:1 exchanges, arbitrage doesn't make sense.

The other answers here are great, but I thought I would add a more meta look at the situation:
Money systems seem to benefit from hierarchical architectures. The modern system of money is very complicated in this regard: there is a worldwide reserve currency ($USD), and then a whole plethora of financial instruments that exist above it! These financial instruments can be seen as 'higher layer' of money, which depend on the base layer ($USD) as their anchor of value.
To give an example, its probably easier to rewind to a simpler time, back to an age where metals were used as hard currency (gold, silver, etc). If you wanted to settle a debt in those times, then you would likely make a payment in the form of gold coins. This was perhaps cumbersome (you had to transport the gold to the recipient, etc), and so over time a 'higher level' system of paper notes was developed, with each note representing a claim to some amount of gold, as issued by some trusted third party. These paper notes proved much easier to transact with, though they perhaps also had more risks involved than just gold (eg, what if the issuer of the paper couldn't make good on the promise for gold?). People adopted the paper money for convenience, and thus a 'second layer' of money was born, that exists above the base layer of gold (and/or other metal monies).
In this example, we see that a higher level money system, which calls back to a base layer, can provide benefits in various ways. The citizen no longer needs to carry around a heavy bag of metal coins to buy their daily goods at market, they can instead carry around the much more portable paper notes. In modern times, we see all sorts of higher layer financial instruments, each crafted to provide some benefit to the users of it. These instruments range greatly, from more basic things like online banking services or government savings bonds, to complicated financial derivatives that are used to hedge against risk.
So now we can return to bitcoin, and consider networks like lightning or liquid as 'higher level' monies built on top of bitcoin. Both of these networks come with additional risks/considerations, but also with their own potential benefits and use-cases. Higher-level systems built on bitcoin are not necessarily engaged in some sort of 'winner take all' battle, it is more likely that each network (lightning, liquid, OMNI, etc) will find its own place in the hierarchy, according to its usefulness to the end user. They may compete in some aspects, but each of these technologies comes with its own benefits and risks, and it is up to the free-market to decide which of them is indeed valuable. It is hard to imagine that none of them will be found valuable though, as they will ultimately serve to increase the utility of the bitcoin network as a whole.
Building this utility out in a safe way will take time, and adoption can only come after that, so I do understand your frustration as an observer, waiting for the 'next big jump' in bitcoin adoption/usability. Smart people working on these problems often talk of grand ideas and end-goals that they see down the line, and that can create a disconnect between the eventual idea, and the current situation. Where we end up remains to be seen, but the general approach being used (a hierarchical monetary system) is nothing new, it is something we have seen develop in legacy financial systems for hundreds, if not thousands or years already. Likewise, many people are hopeful that this approach will also achieve a good balance of security and utility for bitcoin users.

What exactly are "Bitcoin Lightning" and "Bitcoin Liquid"?

Those are protocols built upon Bitcoin. They are responsible for their stuff to be both Lightning/Liquid spec AND Bitcoin compatible while Bitcoin nodes are only responsible for Bitcoin-side validation.

Why do they exist?

Reason 1: scalability: Instead of keeping everything on-chain, by moving stuff off-chain we make the blockchain more easy to store and easier to process for on-chain nodes. (Liquid, Lightning)
Reason 2: timestamping: Instead of creating a separate PoW blockchain and node network, they could use Bitcoin's infrastructure. Same nodes, same miners. (Omni)

Why aren't these "BIP"s put into Bitcoin itself?

Because the Bitcoin protocol, mostly doesn't care about when they work. If they require changes to the Bitcoin protocol, then these will be implemented with BIPs. (See OP_CHECKLOCKTIMEVERIFY and SegWit)

How can they be attached to Bitcoin yet be separate?

By having a separate (consensus) protocol, yet also satisfying Bitcoin's rules.

Is one of them objectively better than the other?

This is outside of my expertise

Do they solve different problems? Is one of them dead now? Should I be using/bothering with them? Are they an attempt to take over Bitcoin slowly by not being an "altcoin" upfront, but slowly turning away from Bitcoin?

???


text:
Mining: what is the lowest possible target? Could it be a block hash of all zeros?
I had a basic question about Bitcoin mining. I understand that as the bitcoin difficulty adjustment becomes harder the hash output will require more 0s in the beginning of the hash. Is it theoretically possible that the Bitcoin difficulty adjustment would be so large that the hash output would just be all 0s? I know this is theoretical bit I'm just curious.

I understand that as the bitcoin difficulty adjustment becomes harder the hash output will require more 0s in the beginning of the hash.

This is slightly incorrect: a higher difficulty will require a valid block hash to have more leading zeros, but validity is not determined by counting the number of zeros. Rather, it is determined by comparing the value of the hash to the target (as defined by the network difficulty).
In other words: a difficulty adjustment may lower the target, but a valid hash post-adjustment could still have the same number of leading zeros as a valid hash pre-adjustment, despite the target being lower.

To dig in a little deeper, lets consider what the lowest target could be.This question contains some relevant info, as does this one, and this one.
Quoting from those answers:
difficulty (D) = hashrate / (2^256 / max_target / intended_time_per_block)
               = hashrate / (2^256 / (2^208*65535) / 600)
               = hashrate / (2^48 / 65535 / 600)
               = hashrate / 7158388.055

(where hashrate is expressed in hashes/s)
The target (T) is defined by:
D = Tmax/T

where Tmax is: 2^224
Rearranging and combining these formulae, we find:
T = Tmax / D
T = Tmax / (hashrate/7158388.055)

So we can see that the lowest possible target would be the result of an infinite hashrate, which of course is not possible. But nonetheless, as hashrate approaches infinity, the target would asymptotically approach zero (but being an asymptote, it would never reach it).

One question. Difficulty cannot increase more than a factor of 4 at a time. when target hash reaches 0x1 (leading 0s omitted) it will remain there as a jump from 0x1 to 0x0 will be an infinite jump.

@UgamKamat I think you have confused the rules about the max difficulty change with the change in target.

Just so I understand this correctly, let us say that the current difficulty is 2.695953529101131e+67 so, your current target header hash is 0x01. Now to move from 0x01 to 0x00, wouldn't that be impossible as difficulty only adjusted by 4 at a time?

The difficulty could continue to increase 4x per retargeting period, but the target cannot reach zero. So I suppose the target would eventually just stall out in the extreme end of the limit

I think that is exactly what I was pointing out. It would stop at 0x01 as non-integer values won't be allowed. Since you mentioned asymptotically approach zero, I was confused

The retargeting every 2016 blocks is computed as follows:

previous_target * (T2-T1) / (20160 minutes)

Where:

T2: timestamp of previous block
T1: timestamp of block at current height - 2016
Target adjustment bounded to factor 4

Ignoring the target adjustment limit: For the resulting target to be zero, T2-T1 would need to equal zero. That would require an infinite amount of hash-rate. Therefore we can approach your scenario, but never reach it.

Couldn't the division round down to 0?

For high difficulties, as we currently have, no. The block intervals are too high. For low difficulties, there is a min difficulty of 1, which bounds the max target value.


text:
wallet that does not abstract change addresses?
I wanted a hands on approach to see change adresses myself instead of hiding away all the details.
I also want to see non-deterministic wallets just for education so that I can understand. When we need to make regular backups in non-deterministics wallets might apply actually making a back up of change adresses?
This type of question has not been asked before.

There are indeed wallets that allow a more manual and granular control of UTXOs, in my experience desktop wallets such as Electrum are more likely to have this feature. Mobile wallets are often more tuned for ease-of-use.
The best way to find something you like is to simply try a few and see what works best for you. Check out the Bitcoin.org wallet page, and always ensure you download wallet software from a trusted source, verify developer signatures, etc.

I also want to see non-deterministic wallets just for education so that I can understand. When we need to make regular backups in non-deterministics wallets might apply actually making a back up of change adresses?

The backup of a non-deterministic wallet will include every address the wallet has used, including change addresses. This will be true whether or not the wallet shows the user the change addresses.


text:
Conf file is unresponsive/nonexisting
The file says it has no content(47 bytes to be specific) and there's no way to open and edit it.
Anyone what I'm doing wrong. Mac operator*

It's not really clear from what your description what you're doing exactly, nor what application is generating the error.  Can you give more details?  Screenshots or even a video could be helpful.

By the way, this is unlikely to be a bitcoin-specific problem, since bitcoin.conf is just a plain text file.  So you might also get useful Mac-specific advice at http://apple.stackexchange.com.

I have added some photos now. Maybe you can see something strange now?

I think it's just that the OS doesn't know that files named .conf can be opened with a text editor.  There should be a way to open it manually.  I don't use a Mac so I don't know exactly how to do that.  You should ask on apple.SE about that, since it is not really a Bitcoin question.  (Zero bytes just means that there is currently nothing in the file.  I'm not sure where you saw 47 bytes.)


text:
When does Bitcoin update the UTXO set?
I am kind of confused with something. I hope you can clarify it for me...
Let's say I want to make a transaction. So my exchange wallet does that for me. The way it does this is it first grabs the UTXO list (let's say it has that on disk D), grabs those that can be used, and using those UTXO creates a transaction with the valid inputs. Then, this transaction goes to the node's mempool. Then, when starting to mine a block, the node grabs those transactions, puts them in a block and mining starts.
Question 1) when will the UTXO list be updated on disk D? Before putting a transaction into a mempool, or after a miner solves a block or maybe at that time when the miner grabs transactions from the mempool?
If the answer is: before putting a transaction into a mempool, then, things get complicated because if that node doesn't solve the block, there's a chance that updating UTXO shouldn't have happened, so it means that the node will revert the utxo back to what it was.
If the answer is: after a miner solves a block, then it's possible that my node will let me do the same transaction twice, since before creating a transaction, it checks UTXO list.
If the answer is: when a miner grabs transactions from mempool, then this is pretty wrong, since mempool already contains validated transactions.
What do you think?
UPDATE QUESTION:
Let's say I have 1 BTC and published 1BTC transaction to Bob on nodeA and the same 1BTC transaction to Alice on nodeB.
So, let's say transaction broadcasting didn't happen, so they(nodeA, nodeB)  don't know each other's transaction.
Now, nodeA mined a block first and broadcasted the block. nodeB received this block. Now, nodeB uses lots of different UTXO's as you stated. One check that gets done is nodeB loops through the nodeA's block's transactions and if any of the transaction can be found(compares transaction id's) in its mempool, it removes it. Now, How will nodeB remove the transaction to Alice(which is now a double spend) ? How does it come to this conclusion ?

This is implementation dependent, but in Bitcoin Core there is not just a single UTXO set:

The UTXO set on disk in the chainstate/ directory in a database. It corresponds to the state as of the last flushed block (and does not include the effects of any mempool transaction, or of any block since the last flush).
The in-memory coins cache is a cache on top of the UTXO set on disk (1), with spends/creations from recent unflushed blocks applied. It only physically stores the changed values; querying it for other UTXOs will cause a read from the disk database (1) instead.
The mempool implicitly defines yet another UTXO set on top of (2). This isn't materialized at all: when querying, we just check if either (2) or the mempool has the transaction output asked for AND whether there is no mempool transaction that spends it. The mempool is always kept consistent with the blockchain (e.g. if a transaction is confirmed that conflicts with a mempool transaction, that mempool transaction is deleted).
During processing of a block, a temporary cache of UTXO changes is maintained, as a patch on top of (2). This allows blocks to spend outputs created by themselves, while if a block is invalid for whatever reason, that temporary cache can just be thrown out without doing extra work. Only if the block is actually completely valid are the changes from this temporary cache merged into (2), and the mempool (3) updated to be consistent with the result.
Wallets conceptually also maintain their own set of UTXOs (that are watched and/or spendable by the owner), though they don't use the same interface in the codebase. This is necessary because a wallet may contain transactions that are unconfirmed and aren't in the mempool (e.g. because they were removed due to eviction, but we still want to retry inserting them).

Finally it's important to note that every node has its own UTXO set(s). Your own wallet/node won't be updating anything when a miner (which one?) starts including your transaction in their candidate blocks - you don't even have any way of knowing they're doing so.

Pieter, Thanks so much for such a great answer. I added only one question, see the question again.  I'd really appreciate the answer ASAP. Thanks in advance.

I believe I answered that in point 3: the mempool is always kept consistent with the accepted best block. When nodeB receives nodeA's block, it gets accepted as best block. Whatever is in nodeB's mempool that conflicts with that new block will be thrown out.

Yes, but transation comparison with txid between nodeA's blocks transaction and between nodeB's mempool won't happen since my double spend transactions's id's are different. Do you agree to what I will just say ? nodeB will receive the nodeA's block (will update the utxo of the disk - 1 type in your answer) and then, nodeB will loop through its mempool's  transactions, and apply the check again for each transaction depending on the newly updated utxo, if it fails(due to not enough balance, it will remove from the mempool). correct ?

and another one. So If I had 2BTC and published 1BTC transaction to one node and another 1BTC to another node, both of them will get accepted in the final blockchain since the above check I mentioned won't fail. correct ?

There are no balances in Bitcoin. UTXOs are created once and spent once in their entirety. Any mempool transaction that spends a UTXO that no longer exists after a block was received will be deleted from the mempool.

Yes, i mentioned balance for an easier understanding. So If I had 2BTC and published 1BTC transaction to one node and another 1BTC to another node, both of them will get accepted in the final blockchain since the above check I mentioned won't fail. correct ?

You're missing the point. The numbers don't matter. There are no balances, there are UTXOs. If tx T had one output, regardless of its amount, that output can be spent once. If it had two outputs, each of those outputs can be spent once - possibly in distinct transactions or even distinct blocks. A transaction conflicts with another transaction if they directly or indirectly spend the same output.

Got it. What my point is that If I have 2BTC and transfer 1btc to alice on nodeA, and 1btc to bob on nodeB(let's assume transaction broadcast doesn't happen).  what might happen is one of them might still get rejected. right ? since they might have used the same outputs for the inputs. correct ?

It depends on whether those 2 BTC were in one or multiple outputs. If there was only one output, then a transaction moving 1 BTC to alice would be spending the 2 BTC output, and creating 1 BTC output assigned to alice and another 1 BTC output back to the sender. When that transaction is confirmed, the 2 BTC does not exist anymore, and nothing else can spend it. A new transaction would need to spend the 1 BTC change output instead. If there were two 1 BTC outputs to start with, and transactions spending each, then those transactions wouldn't necessarily conflict.

Pieter, this discussion led me to something. Let's say in a genesis block, there's only 1 transaction, 50 BTC to my address: addr123. Can I make 2 transactions immediatelly so that those 2 transactions end up in the 2nd block. The way this would work is after creating the first transaction, utxo would get updated. and second transaction would use different output. what's your thought ?

Well, the genesis block has no outputs (intentionally or due to an oversight in the original codebase). Ignoring that, if you have a single UTXO of 50 BTC, yes you can construct two transactions that can end up in the same block. A first one would spend the 50 BTC and create say a 10 BTC and 40 BTC output to yourself. Another transaction would then spend the 40 BTC output and create say a 5 BTC output and a 35 BTC output. These two transactions can legally appear in the same block, and the net effect is splitting 50 BTC into 10 BTC + 5 BTC + 35 BTC.

The reason I asked this is because maybe output can only be used if that output is already included in a blockchain. In my example of creating 2 transactions, the second transaction's output won't be in blockchain. It will be just in the temporary utxo which got updated by the first transaction. So, I guess , 2nd transaction can still be valid by using the output of the not already mined transaction. Right ?

Yes, I explained this in point 4: this is why a temporary UTXO set is used during validation of a block: transactions in a block can spend outputs created by (earlier) transactions in the same block (and also not spend outputs that were already spent in the same block).


text:
What is the state of the Wasabi wallet - when will it be ready for mainstream mass usage?
The wasabi wallet https://twitter.com/wasabiwallet
Is still under development. Anyone here who can tell about the roadmap? Whats the status currently and when is expected to be ready for mass mainstream usage (when devs are comfortable to have rigorously tested it)?
And who is validating the transactions in the wasabi wallet ?  Is it a SPV concept or full node, or centralized, owned by wasabi company servers?
And is it a HD (hierarchical deterministic) wallet??
Thanks

This looks like there are at least 3 independent questions here. It would be better to split them up.

Wasabi Wallet is usable right now.
"When will it be ready for mainstream use" is a question of opinion / service availability, and those are off-topic here. See the help centre for more info.

And who is validating the transactions in the wasabi wallet ? Is it a SPV concept or full node, or centralized, owned by wasabi company servers?

The Wasabi server validates the blocks. It creates block filters out of them and sends them to the client. From those filters the client can figure out which blocks it is interested in and it downloads those blocks from the Bitcoin P2P network, one block from one peer over new Tor stream. Optionally one can use his own full node for block downloading, but the ultimate source of truth is still the Wasabi server.

And is (Wasabi) a HD (hierarchical deterministic) wallet??

Yes


text:
Wallet validation methods (centralized, SPV, etc.) - please clarify for Ledger and in general
1) ledger: https://bitcoin.org/en/wallets/hardware/ledgernanos/

Variable validation - Payment validation features are provided by the software wallet you use with this device.

2) wasabi: https://bitcoin.org/en/wallets/desktop/windows/wasabi/

Centralized validation - This wallet relies on a centralized service by default. This means a third party must be trusted to not hide or simulate payments.

3)  Simplified validation (SPV) - This wallet uses SPV and random servers from a list.
Community, above linked definitions for wallet validation types is taken from the popular bitcoin website. I can understand every type, but the first one called "Variable validation" of Ledger.

Question: Is this technically correct to define Ledger's validation method like bitcoin.org defines it above?
If not, what is from your knowledge Ledger's validation method?
And If yes, I do not understand their definition. Can you explain from technical/censorship standpoint, what it means?  How is Ledger using servers for validation, is it their own servers or what is the difference to a centralized validation method?
Thanks

The answer is simple: Ledger is not a wallet, it's a device to improve the security of a wallet. Everything depends on what wallet you use it with.
It's a hardware signing device. They're often called "hardware wallets", but that is a misleading name. It does not manage your money, or send or receive transactions. It's simply a secure, offline, device to hold your private keys, and sign transactions provided to it.
As such, it's really just a way to improve the security of an actual wallet, which it is used in conjunction with.
Ledger has their own, but several more common software wallets (e.g. Electrum, Green, Bitcoin Core through the HWI toolset, ...) can use Ledgers as a signing device. The security and privacy tradeoffs you get depend on the software you use it with.

@peter-wuille, thanks. Then let me ask a followup please: If you use with the ledger device the ledger's own software wallet , which validation method does this ledger software wallet use?  centralized or SPV or other?  And what is your analysis from technical view, which is more secure/censorship resistant , centralized or SPV validation method?
Thanks

That's a different question, which I don't know the answer to (I've never used their own software).


text:
Do block rewards appear immediately in the miner's wallet?
This question is about how Bitcoin rewards would appear in a miner's wallet. Let's assume that two miners have solved the next block hash, and broadcast their block to the network  simultaneously...

On solving a block hash, does the block reward show in the miner's wallets immediately, or if there some network delay or verification process that must occur before a miner sees their block reward?

Since both miners have solved the next block hash simultaneously, only one of them can win. In this case the network's longest chain succeeds. Would the losing miner in this case see their wallet balance decrease?

Both miners should see their total funds increase the moment they mine a block. (Since from each of their perspectives, they're on the best chain and the other chain is extinct at that moment.) Then, when one chaintip pulls ahead, the miner that found the extinct chaintip would see their funds decrease again as the stale block gets reorganized out and they switch away from their own chaintip.
However, the spendable funds would not increase and decrease: coinbase transaction outputs are only spendable after maturing for 100 blocks.


text:
Does a soft fork result in two different blockchain versions?
I've read the following:

Both forks create a split, but a hard fork creates two blockchains
and a soft fork is meant to result in one.

Let's consider 2 situations:

block size max limit is 1mb and bitcoin introduced a new version which increased block size limit by 1, so it's 2mb now. Now, this is called hard fork, since new versions wouldn't be compatible with the old ones, because when new versions solve a block (let's say 1.5mb), old ones wouldn't accept it. (NOTE: if old ones send blocks to new ones (since old ones would only solve blocks with less than 1, new ones would always accept it)); So new ones can't communicate with old ones, but old ones can with new ones.

block size was 1mb and now, we decreased it by 0.5, so it's 0.5mb now. Now, new versions are compatible with the old ones, because, new versions would always solve blocks with 0.5mb or lower and when they send it to old ones, they would accept it. (NOTE: when old ones send blocks to new ones (since old ones might solve block with 0.8mb, new ones wouldn't accept it)); So, new ones can communicate with old ones, but old ones can't with the new ones.

Do you agree with the above? If so, why in my first sentence, does it say: that a soft work is meant to result in one ? It won't result in one, since when old ones solve blocks bigger than 0.5mb, new ones wouldn't accept it, so we still would have a different version of blockchains. Any idea?
UPDATE: @Murch, you say in the second one that since the small blocks(from new nodes) are acceptable to the old nodes, big block nodes will reorganize to the small block chain.
If 5% minority(which work on old big block chain) solves a block, only those 5% nodes will add it to their chains. 95% wont, since they have smaller limit on block size. Now, 5% minority nodes have the last block different from the last block of 95% majority.(length of both chains are the same - that could have been since after splitting the chains, 5% solved it in the same seed as 95% on their respective chain). if 95% majority now produces a new block, and share it to 5%, they still won't add it because  this newly shared block's prev hash won't match their last block's hash. So in this case, 95% majority will produce a newer block faster(at least now, the lengths are not the same), so now, majority will share 2-3 blocks to minority since they have the longest chain and that's why minority will adapt to majority's chain in the end. Is my explanation and understanding correct ?

Your observation is correct, except that a fork is expected to be activated by a supermajority of nodes and miners in the network. The most recent soft fork had an activation threshold of 950 blocks in specific segments of 1,000 blocks signaling readiness (95% hashrate) for the new rules.
So, assuming that only 5% of the mining power don't follow the new rules:

Increasing block size: 95% of the mining power allows bigger blocks now, 5% continue to enforce the smaller limit. As soon as a block with the new rules is found, the old nodes that do not allow bigger blocks reject the main chain and start their own chain-tip. The minority chain moves much slower, and thus the majority of the miners and nodes ignores it. Assuming the split's proportions remain stable, the two chains remain irreconcilable. To mend the network split, one side would have to concede and adopt the other sides rules.

Decreasing block size: About 1 in 20 blocks will exceed the limit enforced by the majority. Only nodes still using the old rules will accept the bigger block, all other nodes ignore it. The majority of the hashrate will quickly outpace the big block minority. Since the small blocks are acceptable to the old nodes, big block nodes will reorganize to the small block chain as soon as that chaintip has more total proof of work. Since the difficulty between chaintips can only differ across difficulty readjustments, this generally happens whenever the small block chain pulls ahead by one block in height. As the big block now becomes part of a stale chaintip, the miner that authored the big block loses their block reward. In result, whenever a short chainfork with big blocks occurs, the network converges back on the smaller chain eventually. The big block miners are losing money unless they adopt the rules of the majority, or force the split to become permanent (essentially hardforking from the softforked majority).

Thanks Murch for the nice explanation. I've just added an update on my question. Would appreciate it if you could let me know if that explanation looks correct to you.

@NikaKurashvili: I've amended my answer to clarify that point.

Soft fork and hard fork here, if you want to accurate, are statements about the conditions under which all nodes are guaranteed to eventually agree on the same chain. So it is about avoiding permanent forks, and the conditions to avoid them. Temporary splits are always possible, even when there is no consensus change at all.
A consensus rule change is called a soft forking change if it is guaranteed that no permanent split occurs when a majority of the hashrate adopts the new change. Mechanisms are in place to let miners signal their readiness, and activation typically only happens when a large majority of the hashrate signals. This is the case when new blocks are acceptable by both old and new nodes, because even if old nodes continue mining, they'll never manage to build the longer chain - instead the new nodes will outmine them, and the old ones will switch to building on top of the new nodes' majority chain after every block.
A hard forking change is one where the majority of the hashrate adopting it is not sufficient. These usually require effectively a 100% hashrate adoption (or, more commonly, a 100% node software adoption).


text:
how does bitcoin's 6 confirmation really help?
I've read the following:

transaction is “confirmed” once it is buried 6 blocks into the
blockchain. This is taken to be a sufficient proof of work such that
reversing 6 blocks to double spend coins in a specific transaction is
infeasible. As we mentioned

Let's say Alice's blocks(honest node) is A->B->C and I included my transaction into that node which transforms 1BTC to starbucks to buy some coffee. (I am a malicious node), so my local chain is A->B->C' (note: It's C' and not C, and C' doesn't include my starbucks transaction, since i am trying to use 51% attack and double spend).
Now, Alice and other nodes do append blocks to their chain. Let's say A->B->C->D->E->F->G->H->I->J. That's great C block is already more than 6 deep into the blockchain. While Alice and others were building this chain, I am also building my chain(I have 51% hash rate power). and My local chain now looks like this A->B->C'->D'->E'->F'->G'->H'->I'->J' . Now, I solved one more and now after J', I also got K'...
If I now broadcast this, Alice is gonna accept this(longest) and I still double-spent it...
So, how does 6 confirmation really help at all? if someone has 51% power, 6 confirmation really doesn't matter. Any easy and good explanations about this?
My observation and answer IMHO:  I think 6 confirmation doesn't solve double spend or 51% attack. It's for the situation when blocks get mined at the same time. If that's the case,it's possible that someone's transaction might get slashed since other longest chain will appear after blocks don't get mined anymore at any given point. So 6 confirmation means that blocks don't get mined at the same time for 6 times sequentially. Correct ?
UPDATE: @murch This is what you're saying:

Generally, requiring more confirmations before considering a
transaction reliable makes reorganization attacks more expensive

And This is the only thing I don't understand.
If a malicious user has 51% attack power, why would more confirmations make it harder for him to attack ?

HN(honest Node) - A->B->C
AN(Attacker Node) - A-B-C

Attacker makes a transaction to HN (sending 5BTC to some merchant). but not in his own node, since it's local and doesn't broadcast. So we have the following:

HN(honest Node) - A->B->C->D(includes 5btc transaction)
AN(Attacker Node) - A-B-C->D' (note D' , it's different from D - because it doesn't include the 5BTC transaction).

Scenario 1)  HN just mines nodes, and AN also mines nodes.  Let's say they mined E and E' respectively. Now the 5BTC transaction has the confirmation of 2 block. Attacker mined one more block F' and broadcasted it. HN will reorganize chain. and 5BTC is not in AN's chain anymore... So attack successfully happened.
Scenario 2) While AN mines nodes, HN also mines nodes. attacker is faster, so AN mined 10 blocks starting at D'. HN mined 5 blocks starting at D. Now even though HN's D block has 6 confirmations, AN now broadcasts its longer chain and reorganization will happen on HN (removing D block, which consists of 5BTC transaction). so attack succeded.
So, we have 2 scenarios, one with 2 confirmations, one with 6 confirmations. How did 6 help at all in these cases, or at least cease the danger ?

related: https://bitcoin.stackexchange.com/q/658/5406, https://bitcoin.stackexchange.com/q/75884/5406, https://bitcoin.stackexchange.com/q/1093/5406

I read those, but still doesn't help. If attacker and honest have the same chain (A->B->C) and now, someone made a transaction, so honest added it in D block (A->B->C->D), attacker didn't and attacker has (A->B->C->D'), now attacker will mine one more block faster and share it and honest node's D block which had a transaction of someone is still gone.

Luckily, I'm already working on a fully fledged answer. :)

Re your update: it's not harder, but it takes longer and is uneconomic. The attacker loses more money by creating the attacking chain than they gain by swindling the victim out of 5 BTC. Generally, if the attacker has a sustained majority of the mining power and starts using it maliciously, it's pretty much game over for Bitcoin.

How does the attacker lose more money(except the electricity cost ? ) and i am sure electricity cost will be lower than 5BTC which he gets back.

The mining power doesn't appear from thin air. Someone has to stop trying to mine honest blocks for revenue and instead try to reorganize the chaintip. If the attack succeeds they will make back the lost revenue in block rewards, but if it fails they get zilch. Additionally, a successful majority attack may damage the long term value of Bitcoin which is highly unattractive to miners who have made an enormous hardware investment that can only be used to mine bitcoins.

Generally, the cost of mining tends towards the value of the mining reward: https://bitcoin.stackexchange.com/q/2154/5406. Each block's reward is currently about 6.5 BTC. To reorganize a n-block chaintip, someone is losing n block rewards. Unless the attacker can make this risk/loss worth the participating miner's costs, they are not going to have miners participating willingly.

i guess by lost revenue you meant electricity + mining costs. 2) That still doesn't answer the question why 6confirmations are better than 2. if i am an attacker and i don't care about economy or loss, in this case,  it doesn't make any easier if bitcoin has 2 or 6 confirmations. right ?

Maybe you need to clarify how the miner acquires the mining power in order to attack. Regardless, six block take roughly three times as long to discover as two blocks, so it gives other participants more time to react to the attack.

Let us continue this discussion in chat.

Generally, all confirmations are relativistic: any chaintip could still be replaced with a heavier chain! However, reorganizations become increasingly costly and unlikely the more proof of work is piled on a block.
You are right, an attacker exerting a majority-attack can censor or rollback any transactions, and thus perform a doublespend-attack to return a payment they previously made to another party to themselves (also see What can an attacker with 51% of hash power do?).
If you are receiving payments that are orders of magnitudes larger than block rewards, you should consider additional precautions (e.g. KYC, collateral, waiting for more confirmations). The occurrence of a sustained majority attack on Bitcoin could be considered a fatal scenario for Bitcoin: no transaction could be trusted anymore at any number of confirmations.
You may have read that Bitcoin requires the majority of the hashrate to be "honest" to work. Honest in this context means "not collaborating to attack the network" or "independently creating good-faith blocks". Fortunately, it is rather expensive to control the majority of the hashrate. Each block reward is currently worth about $70,000, so a six block majority attack would likely cost $350,000+ in electricity cost alone. Additionally, it would require access to a majority of highly coveted and expensive hardware. Industrial Bitcoin miners have made enormous investments into application specific integrated circuits (ASICs), which can be used for nothing else than SHA-256d mining. The most likely way for a majority attack to come to pass on Bitcoin would be for someone to take over the mining controllers of multiple of the largest mining pools. I would hope that this would be discovered and remedied quickly.
That is not to say that your majority attack scenario hasn't come to pass before. Especially minority forks of larger networks, or other coins that use the same hashing algorithm than bigger networks have been majority attacked in the past. For example Bitcoin Gold was attacked with a 1,300 block reorganization in January 2020.

I am so sorry , but still one thing is vague to me. I updated the answer. Could you take a look at it ? That's the most important thing I am trying to grasp. you will find UPDATED word in my question..

Hi Murch, I'd appreciate it if you could take a look at those: 1) https://bitcoin.stackexchange.com/questions/99386/how-does-merkle-root-actualy-send-proof-to-light-node. 2)  https://bitcoin.stackexchange.com/questions/99385/how-transactions-work-in-bitcoin THANK YOU IN ADVANCE


text:
Using HODL invoices as escrow services, nostr integration?
With the growth of the nostr network, it's easy to imagine a whole new family of apps being created that could work in a decentralized manner (Marketplaces, AirBnB, Uber). But for these apps which require a type of deposit, an escrow system would be needed.
And just like relay addresses don't have to be hardcoded into Nostr apps, it should be possible to not have to hard-code trusted escrow services into apps, such that different implementations can discover mutual trusted escrow nodes in a real-time fashion.
I could imagine that a NIP could be created describing how escrow nodes could broadcast their services, such that two different marketplace apps being used by buyer/seller could dynamically discover available escrow nodes to facilitate the deposit payment. If we don't want to resort to base-chain multi-sig, or require wallets to add support for obscure side-chains, it seems that HODL invoices on the lightning network could achieve this in a non-custodial way, either forwarding the payment on success, or reversing the payment if the trade is disputed by the buyer.
I know that there are technical limitations to HODL invoices, such as the fact that they cause payments to get stuck and that each channel can only have a certain number of open HTLCs, but I want to know if there's an issue that would make it literally impossible to achieve this. The problems are as follows:

Max payment timeout: HODL invoices are possible for 2 weeks and under, but is there a reason that they cannot be held for 6 months, if trying to pre-book a hotel room for example.
If there isn't a technical reason for not being able to hold payments for arbitrary amount of time, why would it not be possible for channels to price themselves by how long they're willing to lock funds for a specific payment?
It seems that the network for instant payments could stay functional, where nodes charge small fees to route payments that timeout after 1 day for example, but other channels offer to route payments with a 1+ month timeout, but charge sizeable fees for locking up liquidity for that long. Why would it not be possible to have part of the lightning network optimized and priced for instant payments, and other channels optimized for longer pending 'deposits' and the two working symbiotically without impeding the other's capabilities?

Max concurrent HTLCs. Sounds like escrow nodes could only hold 483 concurrent deposits at a time due to the max size of bitcoin transactions. But does that mean that with some simple automated node management, an escrow node could open more channels to multiply the number of concurrent HTLCs in total? Would eventual transition to PTLCs up the limit of inflight payments at all?

Lastly, and least importantly, when a buyer is requesting the long-lasting payment invoice from the seller, there needs to be a way to specify a longer expiry. Current lightning-address capability doesn't seem to support this, but possibly the endpoints currently used for zaps could be used with some relatively minor? adjustments.

All in all, is this a no-go? Not possible? How else can we enable non-custodial escrow on nostr without resorting to base-chain or side-chains?

Take a look at Robosats


text:
Does wallet support multi account/user?
Does bitcoinj wallet support multiple accounts/users?
It seems BIP44 is not supported and found multiple threads indicating lack of support.
Just wanna get a definitely answer. If not yet, any plan to support it in the near future?
Thanks in advance.

Bitcoinj only supports one user and one account per wallet. Because i think managing multiple accounts can make the API
unnecessary complex. Normally you would use one wallet per user and that's what happens
automatically if you use your OS to switch users.
Also
I would recommend taking a look at this if you're interested in using BitcoinJ with BIP44. You would have to have one instance of Wallet per "BIP44 account" but it can still work.


text:
Do サトシ (Satoshi) or ナカモト (Nakamoto) mean anything in Japanese?
Do サトシ (Satoshi) and ナカモト (Nakamoto) have any special meaning in Japanese?
For example, the last name "Smith" or "Miller" refers to a blacksmith or grain miller, respectively.

language-nerd quibble: when asking "does X mean something in Japanese", probably better to just use the Latin alphabet ("satoshi") rather than katakana, or maybe use hiragana if you want the multilingual flair. Katakana is used a lot (though not exclusively) for things, such as loanwords, that don't have a clear etymology within Japanese.

Yes, サトシ ("Satoshi" in Katakana) or 覚 ("Satoshi" in Kanji)

Means "wisdom" or "sense" in Japanese.

(source)
ナカモト ("Nakamoto" in Katakana) or 中本 ("Nakamoto" in Kanji) is

From Japanese 中 (naka) meaning "middle" and 本 (moto) meaning "base, root, origin".

(source)

I don't think that kanji for "satoshi" is correct. I'm getting "satori", a mythical creature that can read minds; along with several different words (like "oboeru") that relate to memory.

Without knowing the intended kanji, it's unclear exactly what meaning "Satoshi" and "Nakamoto" have, because there are sometimes many homophones in Japanese (including homophonous names). The Japanese Wikipedia article on Satoshi Nakamoto does not give kanji (and also treats it, typographically, as a Western name), suggesting that the exact intended meaning is unknown. But, we can make educated guesses.
For "Satoshi", there are over a dozen possibilities listed on a Japanese name site, but many of them relate to virtue, wisdom, intelligence, and other intellectual traits.
For "Nakamoto", it's much easier to provide a solid guess. 中本 is a common family name, roughly meaning "middle-origin". 仲本 might also be plausible, with this "naka" meaning "relation, relationship". And, even if "moto" were written as 元, this still roughly means "origin".

If the "moto" in Nakamoto was written as 元 wouldn't that be the same character China uses for their money? In chinese it's pronounced "yuan". That is interesting and I wonder if it could be intentional. Or would it be like writing satoshi as "$ato$hi"

I don't understand japanese, but FWIW in chinese I've always seen it written 中本聪, as far as I can tell 中本 is indeed a very common last name in Japan, as accepted response already pointed out.
中 is the "middle", 本 the "root".
聪 means "cleverness", as in 聪明 in chinese, but I don't know if it has different meanings in japanese.
But overall I never felt it has any particular meaning or hidden signification. My personal guess is that Satoshi chose it because it was related to his personal experience, maybe someone he knew or some character in a japanese story he liked. Or maybe he just picked a random, common and very generic japanese name that has no connection whatsoever with him, it would  make so much sense since he took so much pain to not leave any hint of who he really was.

Satoshi = enlightenment, wisdom, or intelligence.
Nakamoto = root hit, center / origin.
Satoshi Nakamoto could be "Central Intelligence".
Hahaha

From my research, beside from the individual meaning of the phrase "Satoshi" and "Nakamoto", the two together mean "Intelligent History".


text:
Eclipse attack vs. Sybil attack
I came across this paper Eclipse Attacks on Bitcoin’s Peer-to-Peer Network ∗ that sounds very similar to the Sybil attack.
Can someone point out the difference between both attacks.

An eclipse attack is when most (if not all) of your peers are malicious and they basically prevent you from being well-connected to the network to obtain information about transactions you're interested in. An eclipse attack is particular useful when a payer has sent some bitcoins to you in some transaction, then decides to also doublespend the same bitcoins. The doublespender (or payer) will use the eclipse attack to prevent you from knowing that there is also a doublespend transaction out in the open, so you get misled into believing that there's only the original transaction.
A sybil attack on the other hand is where a malicious actor is trying to spam the network with nodes that they control attempting to subvert the network's reputation system. For example, false signalling of support using version bits.
To summarise, an eclipse attack is targeted at a single party; whereas a sybil attack is network targeted. In the context of bitcoin, a sybil attack is not particularly harmful since all nodes operate based on consensus rules and any deviation will lead to said node getting DoS banned.

I think it's worth pointing out that in the Bitcoin and cryptocurrency space, the term "Sybil attack" was traditionally used for both actual Sybil attacks and what is now known as eclipse attacks, due to there not really being a good term for the second until it was introduced by the paper referred to by OP.

In a sybil attack, the attacker impersonates multiple identities.
In an eclipse attack, the attacker eclipses a victim from the network. That means the attacker basically controls which information the victim is able to send to the network and vice versa.
I would therefore say that a sybil attack is what an adversary uses in order to perform an eclipse attack. This is because a Bitcoin node normally connects to multiple peers. The adversary therefore would have to impersonate all peers of the victim in order to eclipse the victim from the rest of the network.

FWIW, the Bitcoin wiki still refers to eclipse attacks as Sybil attacks.


text:
Why does my withdrawal fee not match the transaction fee I'm seeing on a block explorer website?
Sent ~$7 worth of BTC from a Coinbase wallet, to a cold wallet. Coinbase charged a ~$2 "network fee".
Make sense so far, but the transaction listed on blockchain.com shows a magnitudes larger fee: ~$80
The receiving cold wallet app shows the $7 received and also displays the ~$80 fee, in its confirmed transaction history.

Who paid that fee ?
Why would they do that and how does it make sense on a small transaction ?
Where did the $2 fee go and why is it not listed anywhere on the blockchain transaction ?

As an aside, Bitcoin transaction fees are paid in BTC, not in dollars. To understand how and why bitcoin transaction fees work, you need to consider them in this way.
From what you have written, it sounds like Coinbase batches withdrawals, which means they will pay many of their customers at once, in a single bitcoin transaction. A transaction can have 1 or more inputs, and 1 or more outputs, so if you have to pay many people, you can save costs by sending one transaction, which pays all of those people at once, rather than individual transactions witch pay them one at a time.
When Coinbase processes your withdrawal, they can charge you whatever they would like ($2 in this case). But the actual transaction fee that Coinbase paid to make that bitcoin transaction was apparently around ~$80 worth of BTC. Whether the sum of all fees they charged their customers would be equal to this amount, or more, or less, is all just a matter of Coinbase's company policy.

Okay that would fit what I am seeing and does appear to be from what I can tell, thank you:  "Transaction batching works by packaging up many customer send requests into a single transaction rather than creating a new transaction for every request." https://blog.coinbase.com/reflections-on-bitcoin-transaction-batching-b13dad12a12


text:
How to send small amount of BTC to thousands of addresses?
I'd like to create a pool of addresses using Blockchain.com API.
But because of the gap limit on unused addresses I want to transfer minimal amount (ideally 1 Satoshi) and without any fees.
What's the easiest way to send small amount of BTC to thousands of addresses?
I don't care about speed as this is a background operation.
UPD: This is NOT a question "how to create addresses?" this is a question how to distribute small amount of money to multiple addresses with minimal fees. It is not related to  any service provider, Blockchain.com was indicated as a context only.

This is really a service problem that you have with blockchain.com that they don't have a configurable gap limit flooding transactions is a really lazy solution. There is naturally a high cost to this sort of behavior, which you can't bypass.

blockchain.com has a configurable gap limit, however this is just to create addresses, not to track them. I can afford reasonable fees, just want to minimize it.

Sorry, this is nonsensical. You don't need to send money to an address to create it.

The only way to do this is by making a regular transaction with lots of outputs. Moreover, you will have great difficulty broadcasting a transaction with outputs of 1 Satoshi due to the dust limit.
A far easier solution would be to switch to a wallet provider that allows you to bypass the gap limit, such as bitgo (although it may be restricted to their commercial offering), or build your own transaction indexing system

Blockchain.com CAN create addresses beyond gap limit, it is just useles as it doesn't track them.
It could be 1000 Satoshi or more if this helps.

Creating addresses is not the hard part. Sending BTC to them to avoid the gap limit is not a viable solution, and your time/money would likely be better spent integrating a system that does not have a gap limit issue.


text:
How is it possible that the same WIF Private Key generates two different addresses?
I am wondering if you can explain this.
I went here:
https://coinb.in/#newSegWit
Created the SegWit Address below:
3ASaGJ8h2bLn6Jha3hncBzXUKRCLyfv9bk

RedeemScript
037fa484e4b870082298d6acca0702a48714323664c647604e6461d4739feb0d9b

Public key
00147a201aa7e1cfb799dcfc2b447a0238421ae2fa60

Private key (WIF key)
KzVonapu3Cf7DaMpaqkUQ9tpsBQPBH7Yk6tXJdvMwuJSy97GK7dc

Then I opened Electrum  v3.1.3 and Imported WIF Pkey above.
And I got this address instead:
1C8ju39MFSPXNqtYDhsuB3Ek45L46dBr3G

So now there are two addresses,  one SegWit (or I think P2SH) starting with 3... and the legacy address from Electrum starting with 1...
Appreciate an explanation of this.

are you asking how addresses are generated or do you not understand why there are different types of addresses?

I want to understand how is it possible that the same WIF Private Key generates two different addresses? I knew that each address has its unique private key.

There was a longer thread here: https://bitcoin.stackexchange.com/questions/69315/how-are-compressed-pubkeys-generated, which looks at the WIF keys and corresponding priv and pubkeys (though there is no P2SH involved).

The same private key can be used to derive a couple of different addresses. For example, there will be a different address generated depending on whether you use a compressed or uncompressed public key in the derivation.
More relevant to your question, you can use a private key to derive a P2SH-wrapped segwit address (3ASaGJ.. in your example), or just a plain old P2PKH address (1C8ju3.. in your example). Both addresses are spendable using the same private key, since they are both derived from the same private key.
Note that you should not design a wallet to create segwit addresses using an uncompressed public key (use the compressed key only!), due to potential backwards-compatibility issues in the future.
This image from the bitcoin wiki Address page helps to illustrate this point:

Thanks for all answers, I think this one is the most detailed.

There are many types of addresses, see Bitcoin Transaction, each can be created for the same recipient (key pair). For example:

Pay to PubKey Hash (P2PKH) - These start with 1. This is basically just a hash of your public key. If you can prove you own the public key, you can spend it.
Pay to Script Hash (P2SH) - These start with 3. This is a script that you must prove you can satisfy using your private key. There are many types of scripts as well.

They are just different ways of locking Bitcoin for a recipient, but in all of them the recipient must use the private key to satisfy the lock to spend the Bitcoin.

An overview of the address types, check out:
https://en.bitcoin.it/wiki/Address
You are looking for P2SH, https://segwitaddress.org/ just scroll down and put in your compressed WIF key at the 'Details' section.
Further check out https://iancoleman.io/bip39/
BIP44, BIP49 and BIP 85 are also implemented in the Coinomi Wallet.
https://coinomi.freshdesk.com/support/solutions/articles/29000009746-what-are-default-compatibility-and-legacy-addresses-all-about-segwit-

You meant BIP84 there. BIP85 is very different

First a private key is created. Then a public key is generated from it. Finally it is encoded into a format.
See https://coinb.in/?verify=037fa484e4b870082298d6acca0702a48714323664c647604e6461d4739feb0d9b#verify


text:
Scammed by bitcoin mining

This Instagram account managed to scam me into sending bitcoin to the miner she said would make me money. I explained I was a novice and she said she would help me through the process, she then blocked me after three weeks of telling me I need to add more money to it and open up "dormant miners" she said people had abandoned for no reason. When I asked for my money she blocked me .what can I do to stop others being scammed by her instagram doesn't care .
How can I stop this account scamming other people?

what can I do to stop others being scammed by her

Very little.
She probably isn't real, the account is almost-certainly fake. That isn't her  photo it is probably a stock photo or stolen from a web-page somewhere. The scammer might not be a woman.
Just as you probably didn't look at this independent website (bitcoin.stackexchange.com) before "investing" in bitcoin mining, so other future victims are likely to walk into this without really looking around and educating themselves about "bitcoin mining".
Maybe you could get your local news media to write a story about your experience. That might save one or two people from losing money.
This website already has many stories similar to yours.


text:
When did BIP66 switch from activation to enforcement?
Recently, BIP66 switched from activation (miners enforce rules within block) to enforcement (network enforces rules on all blocks).
I'm having trouble figuring out when this happened, or on what block it happened.

From BIP66:

The new rules are in effect for every block (at height H) with nVersion = 3 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 3. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 3, nVersion = 2 blocks become invalid, and all further blocks enforce the new rules.

I wrote this script to monitor the number of the last 1000 blocks that have nVersion set to 3.

require_once 'jsonRPCClient.php';

$daemon = new jsonRPCClient('http://{my_user}:{my_password}@127.0.0.1:8332/');
$blkStart = 364136 - (24 * 14 * 6);

$ver3InLast1000 = 0;
for ($i = $blkStart;; $i++) {
    try {
        $blockHashOld = $daemon->getblockhash($i-1000);
        $blockHashNew = $daemon->getblockhash($i);
        $blockOld = $daemon->getblock($blockHashOld);
        $blockNew = $daemon->getblock($blockHashNew);
    } catch(Exception $e) {
        break;
    }

    // Don't want to start subtracting until have processed 1000 blocks
    if ($blockOld["version"] == 3 && ($i - $blkStart >= 1000)) {
        $ver3InLast1000--;
    }

    if ($blockNew["version"] == 3) {
        $ver3InLast1000++;
    }

    if ($i - $blkStart >= 1000) {
        echo "$i, $ver3InLast1000\n";
    }

}

The result can be found in this pastebin.

Block number 363724 is the block that turned on nVersion=3 enforcement for all further blocks.

For anyone reading this answer in the future, Bitcoin Core 0.12 and later will include this information in the getblockchaininfo RPC.  See  this pull request for details.

excellent answer!


text:
I sent a transaction from Electrum to Trezor wallet - the transaction has disappeared and the fund taken
Any help please??
I think I lost 0.7 btc
Transaction
d18f69c508d9dd5bb5a5038894a79a2c355100a6a185b8aac1df3494ed131e94
Summary
In Block    Unconfirmed
Total Input 0.6845923 BTC
Total Output    0.68444386 BTC
Fees    0.00014844 BTC
Details
d18f69c508d9dd5bb5a5038894a79a2c355100a6a185b8aac1df3494ed131e94 ⚠
first seen Sun, 03 Jan 2021 03:54:26 UTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02577756 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00758608 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01485129 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00674268 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01514086 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00816756 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00962341 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02080733 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02851153 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02640941 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.018482 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01490001 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02437251 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00757503 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.04133579 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00165945 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01234919 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01105445 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00809206 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02749301 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01243002 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01193373 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00977051 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00124668 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02964461 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.0242969 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01011918 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01134724 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02825585 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00690033 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01524587 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00983011 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.00729229 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01968774 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.03067904 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01569381 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.01044657 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.0287376 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.02337908 BTC
➡ 1LLzrwBEHWsRHk5YLLTFY4w4BqdfbDLghm0.03672393 BTC
36UjonxSP7xBwxvpQghVBGFpXNJqdLX9zS0.68444386 BTC ×
Fee: 0.00014844 BTC
UNCONFIRMED TRANSACTION!0.68444386 BTC
Raw Transaction
{
  "txid": "d18f69c508d9dd5bb5a5038894a79a2c355100a6a185b8aac1df3494ed131e94",
  "hash": "d18f69c508d9dd5bb5a5038894a79a2c355100a6a185b8aac1df3494ed131e94",
  "version": 2,
  "size": 7381,
  "vsize": 7381,
  "weight": 29524,
  "locktime": 664234,
 ...

I can't find d18f69c508d9dd5bb5a5038894a79a2c355100a6a185b8aac1df3494ed131e94 on any block explorer. It seems that you managed to redo the transaction with f1aa25811dd5487deb693a5bde124f674c2bf954de95df40bc23749f706b8968, since it has a lot of similar input values.
In the transaction you posted, it seems that you created a raw transaction that didn't claim the change: all funds from inputs that are not assigned to outputs are transaction fee. After defining the recipient, you must claim all the remainder in a change output to yourself.
If you're experimenting with raw transactions or some new software you're writing,
I would emphatically recommend that you use testnet instead of actual Bitcoin.

All other transactions weren't me. The funds have been taken.
The transaction was generated from Electrum.
Either the private key got out or there is something bad about the initial transaction.

The initial transaction made it to the mempool but didn't get confirmed, and another one got there first.


text:
Verifying that a transaction is in the blockchain
Let me first start off by saying im just learning about blockchain and the technical aspects.
From my understanding, each transaction is cryptographically hashed, the hashes are paired and hashed until a single root hash is generated. The miners hash the entire block containing the root hash, previous hash, timestamp etc. If the hash meets the target difficulty then the block is added to the chain. Cryptographic hashing makes it infeasible to obtain the input from the hash output.
Q. If say, I wanted to go back to block X and see which transactions it contains, how is that possible if all the hashes are cryptographic and its infeasible to find the input from the hash output?
Thanks in advance.

Just to be clear: It's not the entire block that is being hashed, as you said, blocks are found by hashing only the block header of a candidate block. However, the block header includes the Merkle root of the transaction tree which in turn commits to the exact set of transactions in the block.
You're correct, a cryptographic hash function is a one-way function and the block content is not retrievable from the hash. To learn the content of the block, you use the block hash as a unique identifier and request the complete block from an archival node, i.e a full node that keeps the complete Bitcoin blockchain in store.
In turn, if you only have the txid to go from, you can request the full transaction from any node that has knowledge of it. The raw transaction does not include the information in which block it was included though. AFAIU, to get that you'd do a getData request of the MSG_MERKLEBLOCK type. This will not only give you the full transaction, but also hashing partners to form the Merkle branch up to the block hash and the block header, allowing you to fully validate the transaction's inclusion in the blockchain.

The miners hash the entire block containing the root hash, previous hash, timestamp etc. If the hash meets the target difficulty then the block is added to the chain

Not quite, only the block header is hashed for the proof of work. The block header is composed of: the version no, the previous blocks hash, the merkle root, a time stamp, the target (difficulty), and the nonce used to find the valid block.
The block header is just one part of the block though, each block also contains the data for all of the transactions included in it. So to answer your question:

I wanted to go back to block X and see which transactions it contains, how is that possible [...]?

Simple enough, you would just go back to that block, and look at the transaction data in it!
If you're wondering about why/how a merkle root is used, this question has a great answer. The bitcoin wiki also has some relevant info:

[Transactions] are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.


text:
How do I get my master public key from a wallet?
If a HD wallet only gives me the 12 word mnemonic, how can one get the master public key?

What wallet software are you using?  You've tagged this [tag:bitcoin-core] but AFAIK it doesn't use mnemonics.  Some wallet software will show you the master public key, though it might be buried in a menu somewhere.  You can also recover it from the mnemonic with third-party tools like coinomi, though this requires you to trust that the software is not malicious (it could steal your coins if it were).

when you have your 12 words, and you are tech-savvy (the logic behind BIP32 or 39), then you can also try to download this website locally, and go from there: https://iancoleman.io/bip39/#english - but why would you want your master public key? Not the master priv key?

@pebwindkraft if you have the master public key, you can give it to a business for example to send payments spreaded out to different addresses, that's one use case. Thanks for the knowledge!

yup, I have seen your other posts, and now I know, there's more to it. A newbie user would ask for lost keys ... :-)

@pebwindkraft haha yeah you're right! Thanks again pebwindkraft!


text:
How do I use the XPub to generate the Public addresses
Given the XPub and an address, can I write an algorithm to say whether or not that public key was derived from that XPub and consequently belongs to the same user?

You'll need to clarify your question, what do you mean by "all of the addresses on the blockchain"? An xpub can generate child pub keys: an example use case would be a business's server providing payment addresses to customers, without requiring any private keys to be stored on that server.

@chytrik Hey made some clarifications, thanks for the comment

Given the XPub and an address, can I write an algorithm to say whether or not that public key was derived from that XPub and consequently belongs to the same user?

[Edit: my terminology was off, answer edited substantially to be correct]
Given the xpub and an address, you would indeed be able to discern whether the two are related.
BIP32 is the specification that describes hierarchical deterministic (HD) wallets. To extend a parent public key, it is combined with the chain code and the index, then hashed through HMAC-SHA512. The hash output is split in two, and the 'left half of the hash' is added to the parent public key, to produce the child public key.
So by knowing the xpub (parent public key + chaincode), you can write an algorithm to determine if the two addresses have a parent/child relationship, and you would be able to find additional child addresses.
Without the xpub, remember that BIP32 derived keys are otherwise indistinguishable from any other keys. So you can not just look at an arbitrary address and know with certainty how it was derived.

The xpub includes the chaincode.

@PieterWuille my mistake, I've edited my answer to be more correct


text:
How easy is it to solo-mine new altcoins?
It seems to be pretty clear that CPU/GPU mining is obsolete for the big fellas (Litecoin, Bitcoin, Ethereum, arguably Dogecoin). This is a bummer for beginners like myself cause I'm keen to dive in and get my PC grinding away at the digital coalface like it's 2009.
I've decided that I want to mine a bunch of altcoins and completely disregard short-term profitability (mining BTC wasn't profitable in 2009, but look at how much it's worth now!).
My actual question: Exactly how does one go about solo mining altcoins? Is the process the same as mining bitcoin, litecoin, dogecoin, ethereum etc? What program do you need to download and how easy is it to configure? I ask because I have had zero luck even getting set up with mining these more mainstream coins. I was really hoping for a "download program, punch in your wallet code and go" situation, but instead I've had to muck around with mining pools and heaps of complicated settings and I can never get it working. Some guidance would be appreciated

Exactly how does one go about solo mining altcoins? Is the process the same as mining bitcoin, litecoin, dogecoin, ethereum etc?

The process is generally the same for most Proof of Work coins. You download a mining software such as cgminer or bfgminer, and configure it to get its work information from a coin daemon that you run. Most modern coin daemons are forked from a version of Bitcoin Core that has the getblocktemplate protocol implemented. Most mining software also support the getblocktemplate protocol. Thus they can use the getblocktemplate protocol for getting their block information in order to mine a block.

but instead I've had to muck around with mining pools and heaps of complicated settings and I can never get it working

When solo mining, you don't need to mess around with mining pools. You will need to handle complicated settings as these mining software are largely command line software. You can check their help pages (by using the --help option) and look for the options that you want. These are generally ones for setting a username, password, server url, and address. Those are the basic options necessary.

It really depends on the altcoin but it would be very safe to assume that if it's PoW, you will need to use a mining program.
In regards to how easy it is to set up, it really depends on how much existing development support exist in that particular altcoin. Usually, newer and more obscure coins are harder to get started up and running fast; especially with the lack of proper documentation that bitcoin, ethereum, etc have.


text:
When and how did Bitcoin start?
Exactly when was the first block mined and the first bitcoins generated? How many people knew about the project at this point? Had the project been publicly announced before the first block was mined or did that happen afterwards? Is there anything special about this first block or could anyone have mined it?
I realize that there are a number of questions included here but I don't think that it makes sense to ask them separately.

While this site does not yet have the [closed as general reference] criteria, Stack Exchange sites generally do not host ultra basic questions that can be easily found on Wikipedia and the like. Background here: "This question is too basic; it can be definitively and permanently answered by a single link to a standard internet reference source designed specifically to find that type of information."

Some of the details in David's answer are only easily found if you know what to search for and where, i.e. for "Bitcoin history" on the Bitcoin wiki (not Wikipedia). Also, there is more in this question that has not been answered yet: "Is there anything special about this first block or could anyone have mined it?". That information is not easily found.

@Robert There is a Meta discussion that you might want to chime in on regarding whether any questions are too basic.

Bitcoin's design paper was published on cryptography@metzdowd.com on October 31, 2008, which is considered by most to be the official beginning of the project. On January 3, 2009 at 18:15:05 GMT the Genesis block was established. Six days later, Bitcoin 0.1 was released and announced on the Cryptography Mailing List.
It is hard to estimate the size of the community at any point, especially historically, but there is a decent timeline of the major events in Bitcoin history at the official wiki.

Exact Bitcoin timeline can be found here.
As far as I understand the first blocks were mined by Satoshi himself (probably to ensure the protocol is working correctly). The only thing special about the genesis block is that it did not link to a previous block (there was none before it), unlike all following blocks. The original block is also distributed with the Bitcoin client, so they can track any following block back to the genesis block.
Anyone can generate their own genesis block, but it will not be accepted as a part of the current block chain. Most notable non-official genesis block is the testnet genesis block. All Bitcoin-spinoff currencies also have their own genesis blocks.