text:
What is the Electrum seed "hash"?
When creating a new wallet, Electrum generates a seed which is a bunch of human-readable words. However, in the wallet file, the seed is like a 129-length string, it looks like a hash.
Is that a hash? Is there any way to revert the operation and obtain the original words from it? Can it be used to restore an Electrum wallet? How?

a seed which is a bunch of human-readable words.

There is a difference between a "seed phrase" and a "seed number". The latter is generated from the former (or generated randomly if no seed phrase is used).
Electrum doeesn't always follow the usual BIPs but we can look at BIP-39 to see how a seed can be generated from a seed-phrase

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

Note that 64 bytes can be written as 128 hexadecimal characters.
Note also the distinction between seed-phrase and passphrase. These are two different things that are both used (though the passphrase may be empty).

the seed is like a 129-length string, it looks like a hash. Is that a hash?

According to Wikipedia

PBKDF2 applies a pseudorandom function, such as hash-based message authentication code (HMAC), to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key,

So yes, hashing operations are involved. The seed isn't a simple hash of the seed-phase though.

Can [the seed number] be used to restore an Electrum wallet?

So far as I can tell, Electrum provides a way to restore from a seed-phrase but not from a seed number.


text:
Why emitter and receptor see different information about the same transaction in Electrum?
I have made a transfer from one Electrum wallet to another one. When I inspect this transaction from the emitter wallet and from the receiver wallet, I see different that. In particular, the input transaction data is different.
In the emitter I can see the transaction ID, the wallet address and its balance. Something like (ID, address, utxo):
12b9003b752x9b    1f88cd918200d7e6dad91a5ace35f2ff1f88cd9182    0.25

However, in the receiver, for the same transaction, I see something like:
69e8f9e8b5:e4   <address unknown>    unknown

Isn't blockchain supposed to be crystal clear for anyone that can query it? Why the receiver cannot see certain information?

TL;DR: everyone sees the same data, but some sites/programs don't exactly represent this in the same way for human consumption.
Bitcoin transaction outputs are scripts, which are tiny programs that control how and when the associated funds can be spent. Some of those scripts have a convenient shorthand human representation called addresses, which can be easily given by a receiver to a sender. However, there is no requirement that on-chain transactions follow one of the forms for which an address exists. In fact, addresses are purely a human interface layer - they don't exist on chain at all.
In this case, you are presumably looking at a transaction spending an output to a script which has no associated address. Different sites and software may represent this in different ways. Some invent their own notation, while others will state that no address is known for it. They're both right, though it can be confusing.

In this case, when you say "address", you don't mean the address (derived from a public key) of a wallet, you mean the address of a transaction? How can I query the blockchain as it is, without "human layers"?

Ultimately, the address may only be known to the sender and the receiver. Blockchain explorer sites and other software guess this address based on blockchain data, but some (not very standard) address formats cannot be guessed at all either. How to query just the blockchain? Many sites and software are able to show you the raw script data in transaction outputs directly.

source: Stack Exchange

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

sort: votes


text:
Manually checking for credited bitcoins
If I have the bitcoin address, the private key and a transaction ID from Bitcoin (regtest mode) in shell variables, what Python code do I need to run to claim the Bitcoins are indeed intended for this private key?
I have been following this excellent article - Bitcoins the hard way : Using the raw Bitcoin protocol. I hope to replicate this with Bitcoin in regtest mode as part of a larger design.
To begin with, I had to ensure that the code mentioned in the article (available here) can generate Bitcoin address with m or n as the prefix and uses 111 as the network ID. See here. I made the following code changes to generate addresses for regtest mode:
keyUtils.pubKeyToAddr

def pubKeyToAddr(s):
    ripemd160 = hashlib.new('ripemd160')
    ripemd160.update(hashlib.sha256(s.decode('hex')).digest())
    return utils.base58CheckEncode(111, ripemd160.digest())

utils.base58CheckEncode

def base58CheckEncode(version, payload):
    s = chr(version) + payload
    checksum = hashlib.sha256(hashlib.sha256(s).digest()).digest()[0:4]
    result = s + checksum
    leadingZeros = countLeadingChars(result, '\0')
    return 'm' * leadingZeros + base58encode(base256decode(result))

Then, with bitcoin-qt, I transferred some BTC to an address generated from above. The transfer goes through and is confirmed when a new block is created.
However, I am unable to see the amount credited to this new address with the getreceivedbyaddress command. I am running this command in the Debug Window console (for some reason, bitcoin-cli wouldn't connect even after configuring bitcoind). I think, the reason could be the fact that, the private key and the bitcoin address was generated elsewhere from command line rather than the default --data-dir location that bitcoin-qt used when it was launched. I understand this.

Did you import either the private key or the address into Bitcoin Core's wallet? getreceivedbyaddress is a wallet RPC and can only know about transactions that the wallet considers to be its own.

Actually I don't want to import the private keys into the wallet that belongs to the full node. I want to treat the mabuakky created Bitcoin address as a separate wallet .

Bitcoin Core only supports one wallet for now.

You don't need to import the private key, by the way. You can just import the address (with importaddress) as a watch-only address.

Did you mean, only one wallet is supported in the regtest mode?

If the store of transactions is a BerkleyDB, surely, it should be as easy as running a query against that DB with my Bitcoin address as the input? The query output could be just the hex string that can be solved only by me because I own the private key.

Bitcoin Core has no database per address, and it doesn't need it. Its wallet only keeps track of the relevant transactions. If you want to use getreceivedbyaddress, you must make the wallet track that address first.

Sorry, I didn't mean a per address database. I was referring to the blockchain itself. Quoting your answer here ( :D ) - http://bitcoin.stackexchange.com/a/11108/6975 - I was thinking, if I can query blocks/blk*.dat with my Bitcoin address as the input. After all, https://blockchain.info/ allows searching via address. So, why not in this case too?

There is no by-address index of the blockchain, as there is no need for one. Scanning through the chain is possible (and the wallet will do that for you at import time), but that may easily take dozens of minutes by- not something you want to do when you issue an RPC call.

blockchain.info has a massive database pre-indexed for every address. That's not implemented in Bitcoin Core, and you generally don't need it. Letting the wallet track transactions that are relevant is far more scalable.

Thank you, @PieterWuille, for the explanation. I think, I will just create another node and move on.

I am unable to see the amount credited to this new address with the getreceivedbyaddress command.

There is no by-address index of the blockchain in Bitcoin core.
For bitcoin-core to track an address you must, for example, add an address to the wallet as a watch-only address.

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

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


text:
How to fund an account in a Stellar private network?
I know, I can set-up a Stellar private network as described here. Once set-up, an account needs to be created as described here. The Stellar documentation says -

In order to prevent people from making a huge number of unnecessary
  accounts, each account must have a minimum balance of 20 lumens
  (lumens are the built-in currency of the Stellar network). Since you
  don’t yet have any lumens, though, you can’t pay for an account. In
  the real world, you’ll usually pay an exchange that sells lumens in
  order to create a new account.

It goes on to say -

On Stellar’s test network, however, you can ask Friendbot, our
  friendly robot with a very fat wallet, to create an account for you.

So, on the main network, lumens need to be purchased at an exchange. On the test network, there is the bot. What should I use on my private network?

Visit: https://galactictalk.org/d/735-is-it-possible-to-build-my-own-blockchain-private-blockchain-on-stellar/2

The stellar network doesn't use mining. It doesn't even have "blocks". I'm not sure what exactly you are looking for.
When you start a private network you get the root account key in the logs with 100 billion Lumens. It should work like the public network. If you want to remove the need for Lumens you would need to modify the software.

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


text:
Error: Can not sign for input #0 with the key 03c3f3495867xxxx
import { ECPairFactory, ECPairInterface } from 'ecpair';
import { initEccLib, networks, payments, Psbt, Transaction, address, script, opcodes, crypto, Network } from 'bitcoinjs-lib';
import * as ecc from 'tiny-secp256k1';
import axios from 'axios';

initEccLib(ecc);
const ECPair = ECPairFactory(ecc);

const network = networks.bitcoin

function tweakSigner(signer: ECPairInterface, opts: any = {}): any {
  let privateKey: Buffer | undefined = signer.privateKey;
  if (!privateKey) {
    throw new Error('Private key is required for tweaking signer');
  }
  const publicKey = toXOnly(signer.publicKey);
  const tweakedPrivateKey = ecc.privateAdd(
    privateKey,
    tapTweakHash(publicKey, opts.tweakHash)
  );
  if (!tweakedPrivateKey) {
    throw new Error('Invalid tweaked private key');
  }
  return ECPair.fromPrivateKey(Buffer.from(tweakedPrivateKey), {
    network: opts.network,
  });
}

function tapTweakHash(pubKey: Buffer, h: Buffer | undefined): Buffer {
  return crypto.taggedHash(
    'TapTweak',
    Buffer.concat(h ? [pubKey, h] : [pubKey])
  );
}

function toXOnly(pubkey: Buffer): Buffer {
  return pubkey.slice(1, 33);
}

async function getUTXOs(address: string) {
  const response = await axios.get(`https://mempool-testnet.fractalbitcoin.io/api/address/${address}/utxo`);
  const utxos = response.data
  let availableUTXO = utxos.filter((k: any) => (k?.status.confirmed && k.value > 546))
  availableUTXO = availableUTXO.sort((a: any, b: any) => b.value - a.value);
  return availableUTXO;
}

export async function main() {
  const private_key = 'L5Pe2yFCjshJrXoJHkXe8xEQofYHXvNKcxGS6XqNiiS7XzETRVPF' // setting private key
  const keyPair = ECPair.fromWIF(private_key, network);

  const mainWallet = payments.p2tr({
    internalPubkey: toXOnly(keyPair.publicKey),
    network: network
  });

  const utxos = await getUTXOs(String(mainWallet.address))
  console.log(utxos)
  const utxo = utxos[0]

  const finalPsbt = new Psbt({ network });

  const tweakedSigner = tweakSigner(keyPair, { network });

  finalPsbt.addInput({
    hash: utxo.txid,
    index: utxo.vout,
    witnessUtxo: {
      script: mainWallet.output!,
      value: utxo.value,
    },
    tapInternalKey: toXOnly(keyPair.publicKey)
  });

  finalPsbt.addOutput({
    address: mainWallet.address!,
    value: 10000,
  });

  finalPsbt.signInput(0, tweakedSigner);  // this will get error

}

main();

Then I got error: Error: Can not sign for input #0 with the key 03c3f349586717e8707ef8e0d74
I think the possible reason is utxo vout is 0
How to fix this? Thanks.
This can online edit : codesandbox online test


text:
Which value is appropriate for the MARKER field of a segwit tx messages: 0x00 or nonzero?
Reading at the Specification chapter in the BIP-0144 document, there seems to be conflicting statements.
The Description of the marker field in the table says "Must be zero"

Field Size
Name
Type
Description

...
...
...
...

1
marker
char
Must be zero

...
...
...
...

However, what follows description is:

Rationale for not using just a single 0x00 byte as marker: that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data

As I understand it, the marker would need to be 0 for old nodes to treat the transaction as valid. So it looks like the 'not' should be removed from this sentence. Is there something I'm missing?
Would you also point me in the direction of where to look in the Bitcoin Core code?

the marker would need to be 0 for old nodes to treat the transaction as valid. [...] Is there something I'm missing?

What you may be missing is that old (pre-segwit) nodes never see segwit data, when segwit nodes send data to pre-segwit nodes they edit out all the segwit fields.
Part of the protocol handshake identifies segwit nodes
Consequently the marker is always zero and the only currently defined value for the flag is 1 (as far as I know). When parsing I rely on the marker being zero, to distinguish it from an input count, but I allow for any non zero value of flag.

Rationale for not using just a single 0x00 byte as marker: that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data

This says that the 0x00 marker is necessary but is not sufficient to reliably distinguish pre-segwit transaction serialisation from segwit transaction serialisation.
I believe it claims you need the additional flag to distinguish a segwit transaction (with any number of inputs) from a pre-segwit transaction that has no inputs (input count = 0).
I don't think this is actually true for mainnet†. I think there are no transactions using the pre-segwit serialisation that have no inputs. Perhaps it is true for one of the other Bitcoin networks (testnet etc). I wrote a parser that would fail if fed a pre-segwit transaction with no inputs - It hasn't failed but admittedly I haven't tested it against every transaction in the whole mainnet blockchain.

Related

What's the segwit transaction serialization "flag" field for?

Footnotes
† Minimum number of inputs

https://developer.bitcoin.org/devguide/transactions.html says

Each transaction has at least one input

How to create a bitcoin transaction without inputs

Only the coinbase transaction is allowed to have a null, or non-existent input [...] Coinbase transactions have inputs. They just reference null outpoints

Thank you for your response. I understand why it needs to be 0.
The point I'm confused about is the 'not' in the "Rationale for not using just a single 0x00 bytes as marker." As English is not my first language and I'm newbie in Bitcoin dev space, so I'm not sure if I understood correctly. Is it correct that this word 'not' should be deleted?
Additionally, can you give me a hint to help me check it in the code?

The "not" applies to the "single" - I'll update my answer to elaborate a bit how I interpret this.

This is correct. Just a zero byte marker would be insufficient, which is why there is a marker plus a flag byte. And @RedGrittyBrick is technically right that 0-input transaction are strictly speaking illegal anyway, however they are (or at least were) common when dealing with incomplete/unsigned transactions that were being passed around before people were done adding inputs/outputs to them. Even though these are never allowed on chain, we needed to be unambiguous w.r.t. those as well.


text:
In which format (format, not cypher algo.) does Electrum encrypt its files?
Electrum wallet encrypts its files using the AES-256-CBC algorithm, but in which format does it encrypt files? (I mean, what headers, vectors, checksums etc. it adds and where?)
By format I mean OpenPGP, S/MIME etc.


text:
Is there any HW wallet that works with Electrum without the need for installing anything?
Ledger Nano S Plus needs to you download Ledger Live and install the Bitcoin application in order to be able to open it with Electrum.
Is there any HW wallet that can be opened with Electrum directly, without the need for intermediate steps such as the above one? (steps that involve to connect the HW wallet to the internet and download/install stuff)

good question. unfortunately most hardware wallets are going to need an intermediate initial one time step like you described above to begin interfacing with the software wallet.
Even coldcard exports a skeleton wallet file to software wallets like electrum, or sparrow wallet. This enables the software wallet to know what it is looking at.
Functionally though, skeleton wallets can be much more secure to use than something like installing the ledger bitcoin wallet app on the ledger via USB.
Trezor also has an initial one time setup step, where you download their bridge app on your desktop so your device can talk to it's web app.
With all that said, I would try to aim for the more sovereign open source bitcoin only options as a guiding principle to your wallet journey.
Convenience can be the enemy of security.


text:
Can it happen that, after a bitcoin transaction, the change is sent to a receiving (not change) address?
I have an Electrum wallet and I can see there are 2 types of addresses: receiving and change.
Change addresses are supposed to receive the change bitcoins after a transaction, but can it happen that such change is sent to a receiving address instead of to a change one?

Change addresses are supposed to receive the change bitcoins after a transaction,

Delivering change is part of the transaction, not something separate that happens "after a transaction" Change is part of a transaction and transactions submitted to the Bitcoin network are indivisible.

can it happen that such change is sent to a receiving address instead of to a change one?

Your wallet will always construct transactions so that change goes to an address it regards as a change address. You could manually construct a transaction that pays your change to one of your receiving addresses. The Bitcoin network cannot distinguish between change addresses and receiving addresses. It doesn't care about that distinction.

So the destination address of the change depends on the wallet itself, not on Bitcoin core?

The concept of "change address" is something local to your own wallet. If your wallet is Bitcoin Core, then it will handle change. If you use other software (like Electrum, as you appear to be using) as wallet software, then that software is responsible for handling change (and all other aspects of transaction creation).


text:
Why do I see a Bitcoin address prefix starting with 4?
I have an old Bitcoin (Counterparty) wallet that I am importing past transactions. I found a Tx that has a missing output address on one API, but it shows on another. I cannot find any documentation on what the Bitcoin address prefixed with '4' means. Is this valid or just a place holder?
Tx Hash: 5288973c6e2a323a2fbc95b84fbfd18b4ed2f75895c8295db03c653ea58c70d6
Blockcypher is showing the '4' (4PTehVhW6qTNhn88DK3JPBMkXfB2wR4juB)
https://api.blockcypher.com/v1/btc/main/txs/5288973c6e2a323a2fbc95b84fbfd18b4ed2f75895c8295db03c653ea58c70d6
Original API call is through Blockchain.Info
https://www.blockchain.com/btc/tx/5288973c6e2a323a2fbc95b84fbfd18b4ed2f75895c8295db03c653ea58c70d6
Blockchain just says "Unable to decode output address".
This is a counterparty transaction so I am thinking it may have something to do with that. Thoughts?

These are bare multisig scripts, there is no address format for such type of output. So explorers basically came up with confusing (and constantly differents, as there is no right one) placeholders.


text:
A life-cycle of a transaction - correct?
Newbie alert ! Please let me know if this is not the right forum.
So I have spent time reading up on Bitcoin. I think, I understand now; but, would love to have it confirmed.
To start with, we have a transaction, t1 as below.
t1 : {a1, 50.00 BTC, a2}

Where,
t1 is the transaction that goes to the block-chain (ledger) for confirmation.
a1 is the input, for example, Mt Gox from whom 50.00 BTC were purchased.
a2 is the output address who purchased the bitcoins from Mt Gox.
After t1 is confirmed, the unspent amount of a2 is 50.00 BTC.
Let us say, a2 wants to send 40.00 BTC to a3 for some service. Then, a new transaction t2 is created as below.
t2 : {a1, 40.00 BTC, a3}

As before, t2 goes to block-chain awaiting confirmation. The input to t2 is a1, amount 40.00 BTC and the addressee (or recipient) is a3.
Are the following correct ?

t2 has input address as a1 as described here - What does a transaction look like?
Because t2 does not mention a2, the anonymity of a2 is preserved.
t2 is confirmed because unspent balance of a2 at this point is 50.00 BTC. (Not sure how, but sounds like it.)
After t2 is confirmed, unspent balance of a2 is 10.00 BTC.

For reference, I used the following.
t1 : eac977ae6ee885b62c4756230f6bdd27ccfa7de215836e6f5fc379c66f4c6a81
a1 : 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q
a2 : 16fKtcRS2P57pH6dF5stJ4wF1SC4SzaMJK

and,
t2 : c8a8db01733a4300ad14e1fd78ff776ec21260e7081dd48c7b2f5ad1a9a1da46
a3 : 1Cmerw473xaaNpR6T9Lo5DA6d99uXLe3gc

What is your question exactly. You've stated your points, but it is not clear what you are asking. I think you are mistaking Unspent Transaction Outputs (UTXOs), with addresses, because in your example a1 would have to have to have previously received money to pay both transactions.

I just want to understand a transaction completely. I think, I know the dots, but am unable to connect them. :( How do the t1, t2, a1, a2 and a3 all work out ?

I'm not sure you do 'know the dots'. I found the following explanation very helpful, it is a specific piece of software, but the README breaks down all the steps in a transaction. https://github.com/spesmilo/sx

Transacions don't have input and output addresses, they have input and output scripts. Addresses are just short-hand notation for particular scripts.
When making a transaction, you don't just say what the input and output scripts are. You have to explicitly reference which UTXO (unspent transaction outputs) a transaction spends, and then you also make a set of new UTXOs. Each UTXO has an amount associated with it.

t2 has input address as a1 as described here - What does a transaction look like?

If t2 is trying to spend the coins that were sent to it in t1, then it would need to reference t1 (not a1 or a2). Specifically, it would need to reference the UTXO in t1 that credited the a2 script.

Because t2 does not mention a2, the anonymity of a2 is preserved.

Not really. Anonymity is only preserved by not linking your address to your name, such as by posting on a social media website.

t2 is confirmed because unspent balance of a2 at this point is 50.00 BTC. (Not sure how, but sounds like it.)

If t2 were confirmed, spending the UTXO made in t1, then, yes, it would be successful because the total inputs is more than the total outputs. Actually, it's total inputs are 10 BTC more than it's total outputs, so that 10 BTC would just go to the miners (and not be left on the 'address balance').

After t2 is confirmed, unspent balance of a2 is 10.00 BTC.

Not actually, like mentioned above, it doesn't really work like that. Transaction outputs are either completely spent or are unspent. So after t2, the output is completely spent. If the 10 BTC is not sent to another output in t2, then it is just assumed to be a very generous miner fee.

"Transacions don't have input and output addresses, they have input and output scripts. Addresses are just short-hand notation for particular scripts. " Thanks for that !
My intention is to co-relate the debit/credit and its confirmation in the block-chain.
I will do some more reading.


text:
How to transfer from watch only wallet
What is the real and legit name of the app that I can use to transfer tokens from watch only wallet?

A watch-only wallet is a type of wallet that allows you to monitor the balance and transaction history of a particular address(es) without having access to the private keys. This means you can't spend or transfer funds from a watch-only wallet directly. You need to have access to the original wallet that holds the private keys associated with the address you're monitoring. If you don't have access to the private keys, you won't be able to transfer funds from a watch-only wallet. This seems to be a duplicate to following question: https://bitcoin.stackexchange.com/q/67253/87158

There is none. A "watch only wallet" lets you watch tokens that are not yours. Only the owner of the tokens who created the address and knows the private key can transfer the tokens.


text:
I wrote down my 12 words before uninstalling my app. I put them in after reinstalling the app and it gives name a different wallet address, why i?
I’ve tried to put the 12 words in different wallets and it keeps changing the wallet address

Does the new address by any chance start with a different letter?

Current wallets create a new address every time you ask them. This is to improve your privacy.
The wallet keeps track of all these addresses.
If you restore a Hierarchical Deterministic (HD) wallet from a seed phrase it can generate exactly the same set of addresses. That is the "deterministic" part.
You must make sure the wallet is configured to use the same "derivation path" and type of address e.g. Segwit  ...


text:
COIN FILTERING OF 10%
I recently hired a  3rd party to trace and retrieve my investment which was being scammed. They said they were able to retrieve and sent the investment to an exchange. When I tried to withdraw, the exchange says I must deposit a 10% value of Bitcoin to their wallet to filter the coins which had come from a flagged wallet with fraudulent activities. They claim this is a standard procedure set by Finra. They have now given me 2 weeks to do this before my account is blocked permanently. What should I make of this?

Without providing more details including the name of the organizations that you are working with little can be done to assist you. Please include as much information as possible.

I'm sorry to say, this is a fairly common scam. Often victims of scams are targeted by scammers, telling them they can retrieve their money so long as they pay more.
This exchange wanting you to deposit funds in order to withdraw your "recovered" funds is a scam. If you deposit funds to them, they will not let you withdraw them for some other made up reason.
Please do not give the exchange or the 3rd party any more money.
They are lying to you.


text:
Generate a Bitcoin taproot address with specific prefix for burning assets
I would like to generate a bitcoin taproot address (bc1p) for burning assets. Which means not one would have the private key. But in the mean time I would also want a vanity address (an address start with a certain prefix).
I did some search but can't find a tool that meets the above 2 requirements. So I wrote one by my own but it looks very inefficient. Is there any better way to do this? Thanks a lot!
Here's my script:
const { validate, getAddressInfo } = require('bitcoin-address-validation');

var chars = '0123456789abcdefghijklmnopqrstuvwxyz'

prefix = 'bc1pXXXXXX' //THE_PREFIX_I_WANT
subLen = 62 - prefix.length
subDigits = Array(subLen).fill(0)
digit = 0
limit = 36
while (true) {
    subString = ''
    for (i in subDigits) {
        subString = chars[subDigits[i]] + subString
    }
    while (true) {
        subDigits[digit] += 1
        if (subDigits[digit] >= limit) {
            subDigits[digit] = 0
            digit++
        } else {
            break
        }
    }
    digit = 0
    addr = prefix + subString
    if (validate(addr)) {
        console.log(addr, 'IS VALID!!')
        break
    }
}

Why not use an OP_RETURN output?

It's not only about burning bitcoins. I'm considering send inscriptions to an inaccessable address, so it can be seen by anyone but no one can touch it.

An OP_RETURN script could be used just the same. It could potentially also be slightly cheaper than a taproot address.

Thanks, I'll look into that


text:
Working with the Bitcoin network protocol
I am very interested in the p2p protocol used by Bitcoin clients. There are some excellent answers here that describe the way clients connect to the network.

How does the bitcoin client determine the first IP address to connect?
Peer to Peer: Methods of Finding Peers

I want to replicate the peer-to-peer network only without participating in the crypto-currency part. This is for an experiment on peer to peer discovery.
So, can you please show me some code instructions to set-up such a network?


text:
Duplicate blocks in Bitcoin blockchain
I created a parser and split the entire chain into pieces.
When inserting them into a database, to my surprise there were 187 blocks with the same hashes, so initially I thought there was something wrong with what I was doing, but after debugging, I found duplicates inside the blockchain.
I only investigated one block with the hash: 00000000000000000002927103A1BC8426DEFE05CFFA40BE468072B984C8876B.
I found the same block in two different .dat files: blk03361.dat, blk03363.dat.
I know for sure that the two blocks are identical because I split both dat files into blocks and compared the hashes:
sha256sum 1/1_part_65.bin
d81340e3e1c1759e4b78dc1cd531230b55d1828fd14ed0f9ba8cd9269a7ee322  1/1_part_65.bin
sha256sum 3/3_part_77.bin
d81340e3e1c1759e4b78dc1cd531230b55d1828fd14ed0f9ba8cd9269a7ee322  3/3_part_77.bin

The first one has the height 772553 and the second 772776.
Is this normal?

This question is similar to: How does the bitcoin network recover in case of a hash collision in the block hash?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

Quite similar but not identical. That question is referring the case where by chance a block will hash identical to a previous hash, meaning its transactions and all will differ.
Also the answer is saying that eventually that block will be ignored and marked as obsolete eventually. In my chain, the duplicated first block is dated "Wednesday, January 18, 2023 12:55:42 PM" which is some time ago...
In my chain I have 187 duplicate blocks, not by the hashes, but everything inside them are identical.

It is perfectly possible that the same block is stored twice in the Bitcoin Core blk*.dat files.; there is no guarantee that the files contain the blocks in sequential order, or continuously, and unused space may exist in them which contain (parts of) blocks as well, from the active chain or stale blocks.
Bitcoin Core maintains an index of where which block is to be found on disk. If you parse things yourself, you will need to figure out the relation between all the blocks you find, and determine which ones are valid. Since every block contains a hash of its parent, if you see the same block data twice, it is necessarily the same block, at the same height.

Short question: Does that space ever get cleaned up?

No, similar to how stale blocks never get cleaned up. If the few % extra space that these together may cause is an issue, you almost certainly just want to enable pruning, which deletes all block data after some time, stale or not.


text:
I connect my coinstats wallet to coinbase but can't find my money
I'm Christopher Lintnaar I from South Africa I connect my coinstats wallet to my coinbase wallet but i can't find it they said is in blockchain smart contract please help me to get my coins or money out of blockchain or coinstats help me please I was scam for 2 year's and I loose my job because of depression about all the scam
WITH MUST THANKS
CHRISTOPHER LINTNAAR

they said is in blockchain smart contract

I believe they are almost certainly lying to you.
From what you write, there is no obvious reason to use smart contracts
The use of a smart contract is never a surprise to participants in any honest transaction.

please help me to get my coins or money out of blockchain or coinstats

From what you write, it seems likely that someone you have been communicating with stole your money and there is nothing in your wallets. That would mean no way to get coins or money out.

I was scam for 2 year's

That makes you a target for other scammers and fake recovery agents who believe you are more likely to be easy for them to deceive. You need to be very careful.
If I was you I would only get advice from public question and answer websites where you can see a history of people correcting bad answers to other questions. I would not ever seek or use advice from people using private messaging if those were people I had only met online.


text:
HELP! Bitcoin bought back in 2017
Can somebody help me recover my Bitcoin I bought it that years ago before it took off about $60 I have the receipts but the ink is a little faded I kind of make out the wallet address but I have no way of accessing it can anyone help me in the situation on the steps to take through one of those Bitcoin ATMs. I went to the store and they refuse to help.


text:
Stuck Bitcoin Core Wallet can't send out
I have a wallet from 2013 that has a fair amount in it I'd like to get to. I have it restored on bitcoin core on a few separate machines, each with a full node. When I made it I didn't put on a passphrase but it now asks for when when I try to make a transaction. On one machine only it will not ask for a passphrase if I go through Bitcoin CLI.
I also can't get it to give the private key so that I can import it to electrum. It will either ask for a passphrase or it will say that there isn't a private key known. When I do a dumpwallet I can't seem to find the right private key to import to electrum. I might just not know which so any help with that would be appreciated.
When looking at the transaction to rebroadcast them it says that they have bad-txns-nonstandard-inputs (code -26). This may be due to some dust, the lowest amount I have on a singular input is 868 sats. I've tried to sendmany to conjoin it but when I do it tells me that there is a JSON parsing error. sendmany "" {"walletaddress": amountofdust} It tells me similar when I try to specify the input for a transaction it tells me similar.
Any help would be greatly appreciated and thank you.


text:
ZeroMQ Notifications in Browser JavaScript
I am trying to develop an online application primarily in JavaScript. As I am aware, the only way to receive notifications for unconfirmed/mempool transactions as they appear on the network is to utilize the -zmqpubrawtx or -zmqpubhashtx commands in the startup of Bitcoin-Core. I have setup one of these values to be the example -zmqpubhashtx=tcp://127.0.0.1:28332
However, I am having a difficult time implementing this in any browser based JavaScript. The only library that is not based solely on Node.js is JSMQ which does not appear to support tcp:// as the socket type (apparently relies on JavaScripts WebSocket which only lets you use ws:// or wss://). I am trying to avoid online API usage such as blockchain.info, etc.
My question:
Are there any other methods of receiving realtime unconfirmed transactions notifications (that don't belong to a specific wallet) and that doesn't rely on an external/online API? If there is no alternative, are there any known/reputable libraries available for ZeroMQ for JavaScript

If I understand this correctly, you're trying to communicate with Bitcoin Core through ZeroMQ directly from the browser.
This is not possible.
The reason why JSMQ only supports Websockets (ws://) is that browsers don't allow you to use raw TCP sockets. The only protocols you can access from within the browser are HTTP(S), Websockets, and WebRTC (which is still not supported everywhere).
In other words: the browser won't let you communicate directly through ZeroMQ.
If you don't want to rely on an external API, then you can always write your own and run it on the same server/computer where you are currently running Bitcoin Core.
This software should receive updates from the Bitcoin node through ZeroMQ, and send them to the browser via websockets.
As long as it supports websockets or HTTP(S) you'll be able to connect to it from within your browser.


text:
Why does the decode function of the segwit bech32 encoder/decoder take a hrp (human readable part) as input?
Looking at the code referenced in bip-0173, specifically for example here:
https://github.com/sipa/bech32/blob/master/ref/javascript/segwit_addr.js
  function decode (hrp, addr) {
      var dec = bech32.decode(addr);
      if (dec === null || dec.hrp !== hrp || dec.data.length < 1 || dec.data[0] > 16) {
        return null;
      }
      ...

I understand that this is an error checking statement, but why check a (user?) inputted hrp vs the decoded hrp from bech32.decode?
Also I'm assuming that the "dec.data[0] > 16" check is to make sure that the byte at index zero doesn't exceed a value of 16, which would be invalid hex.  Is this correct?

The HRP is part of the bech32 encoded string, and in the bech32 decoding API, it is returned along with the payload by the decoder, after checking the checksum.
We still want to compare it with the expected HRP in BIP173, which encodes the chain the software is operating on.
Otherwise you could have a testnet node that accepts mainnet BIP173 addresses or the other way around.

I'm assuming that the "dec.data[0] > 16" check is to make sure that the byte at index zero doesn't exceed a value of 16, which would be invalid hex. Is this correct?

No, it's because only versions 0 - 16 are specified. Other versions might behave entirely differently. (As an aside, if it were a comparison for the sake of clamping to the range of a single hex character the test would be >15 not >16).

Ah, I see now.  Also, dec.data[0] is a byte's worth of data (two hex chars), which can hold 256 different states.

From BIP173 > Specification > Segwit address format > Decoding:

Software interpreting a segwit address:

MUST verify that the human-readable part is "bc" for mainnet and "tb"    for testnet.
MUST verify that the first decoded data value (the    witness version) is between 0 and 16, inclusive


text:
What mobile lightning wallets show the user the preimage?
It seems like most mobile lightning wallets don't make the preimage accessible to the user after a lightning invoice is paid, other than Muun. Does anyone know of any others that do?

When checking the Breez lightning wallet on an iPhone, it is possible to view the payment preimage for both incoming and outgoing transactions. While I cannot confirm it, I would anticipate that both the Phoenix and Zap wallets also offer access to the payment preimage.

If you use your own node you can use the Zeus mobile app, which will show you the preimage if you need it. Zeus devs are right now working on olympusln, possibly this will give you a similar feature without running your own node soon.


text:
List unused multi-sig wallet addresses
Is there a way to list all bitcoin wallet addresses (or at least the count) which are receivers in a multi-sig transaction such that those addresses have never been used as senders in any other transaction?

According to Chytrik's answer to How can one see if an address is multisig?

Taproot ... allow[s] for coins held at multi-sig addresses to be spent in a way which does not sacrifice privacy by revealing the full locking script in the spending transaction.

I think this means you can't always list individual receiver's addresses.
Addresses don't exist in transaction data so the question is a bit difficult. For many transaction types there is no standard way to derive an address and I'm not sure it is always meaningful to try.


text:
New to bitcoin core I don’t know where my balance is after selling a digital item
Hey I sold my digital item off roblox for bitcoin but when I got the money when it was done pending it went to the exact wallet address and completed but I never got it when using bitcoin core

Short Answer
You probably need to wait for Bitcoin core to finish "synchronising". This can take days or weeks depending on your computer and your Internet connection.
Longer Answer

I got the money when it was done pending

In the Bitcoin network, "pending" is not an adjective used about money. A bitcoin transaction can be "unconfirmed". I guess the word "pending" might be used by Roblox about a Robux transaction and maybe this causes confusion?

it went to the exact wallet address ...

All is well if you mean a Bitcoin transaction, with a known Bitcoin Transaction-ID, paid money in BTC to a Bitcoin address controlled exclusively by your Bitcoin-core Wallet.

... and completed

The adjective "completed" is not used for Bitcoin transactions, perhaps that is a word used by Roblox about their internal money. Bitcoin transactions change from "unconfirmed" to "confirmed" and accumulate an ever greater number of confirmations as time goes on. A bitcoin transaction is confirmed when it is included in a new block added to the top of the Bitcoin blockchain. Every block added after that, linked back to the block containing a transaction, increases the count of confirmations of that transaction. Six or more confirmations is generally regarded as safe.

I never got it when using bitcoin core

Bitcoin wallets do not contain money. They do not really receive money. All Bitcoin money is recorded in the list of transactions called the blockchain.
I think it best to think of a wallet as a key-safe, as a window on the blockchain and as enabling you to create and circulate "unconfirmed" transactions.
As a window on the blockchain, Bitcoin core must collect a copy of all Bitcoin transactions since the beginning before it can sum the credits and debits to calculate a balance. Credits are transaction outputs paying to an address your wallet controls (has the key for). Debits are transaction inputs spending prior outputs for addresses your wallet controls.
The process of collecting all transaction data in the blockchain is called synchronising.


text:
BitcoinD Fails to Return Transaction Data After Receiving GetData P2P Message
Question:
I’m developing a Neutrino client that communicates with BitcoinD. Most P2P messages are working as expected, but when I send a GetData message for a transaction (Tx type), BitcoinD doesn't respond with the expected transaction data. I’ve verified that the transaction is indeed present on the node. Below is the log from BitcoinD:
2024-10-16T11:24:22Z [net] received getdata (1 invsz) peer=32
2024-10-16T11:24:22Z [net] received getdata for: tx
c1b5b6fb155a8fd41d241abe5efb5aa9de7c8942fdd923ad1e6d94e9deedc3f9 peer=32

Here are the details of my setup:
BitcoinD version: 24
Configuration:
bitcoind
-server=1
-regtest=1
-rpcauth={{rpcUser}}:{{rpcAuth}}
-debug=1
-zmqpubrawblock=tcp://0.0.0.0:28334
-zmqpubrawtx=tcp://0.0.0.0:28335
-zmqpubhashblock=tcp://0.0.0.0:28336
-txindex=1
-dnsseed=0
-upnp=0
-rpcbind=0.0.0.0
-rpcallowip=0.0.0.0/0
-rpcport=18443
-rest
-listen=1
-listenonion=0
-fallbackfee=0.0002
-blockfilterindex=1
-peerblockfilters=1

Has anyone encountered a similar issue? Any suggestions on what could be going wrong here or how I might troubleshoot this further?

What does "is present on the node" mean? You can only request transactions the node has just announced to you.

My previous thought was that  "getdata" request with "inv type" 1 does not depend on whether the node has announced those transactions to you beforehand. If this is not the case, can you shed more light on how a client is neutrino client is meant to receive transaction by communicating only through p2p.

Bitcoin nodes do not generally maintain an index of all transactions ever, as this is not necessary for normal operation, and thus such functionality is not exposed over the network. For historical transactions, wallet software generally downloads blocks (using getdata with block invs), not transactions (finding them using BIP157 for a Neutrino-like client).


text:
Bitcoins didn't arrived
3-4 days ago, I transferred bitcoins from Virwox to my Electrum wallet, but this bitcoins didn't arrived, what can i do?
1JPSVx7hjcu7rR2Vr6nyz7z8mok3yryGZ

Do you see a green dot in the bottom-right corner of Electrum, showing that it's synced?

No, i got red dot

Does this answer your question? Why is my Electron Cash not detecting any servers?

Don't worry, you're coins are safe. You only need to fix the connection. You should go to Tools -> Network and then choose a server.

Glad that your problem is solved! If you could click on the ✔ button, that'd be great as it shows others that my solution worked for you.


text:
Does bitcoind re-index or reverify downloaded blocks upon startup?
If so is there a way to prevent this from happening?

It walks back a small number of blocks and re-verifies them, this ensures there's no obvious corruption and warms the cache. It takes a few tens of seconds at maximum on most hardware. You can adjust or effectively disable this using checklevel=1, but it is generally inadvisable to do so.


text:
How many non-web wallets discard private-keys? or How common are non-deterministic wallets?
I'm concerned about non-web wallets that discard private keys after use.

Web wallets - share addresses between users, so the user can consider all private keys to be immediately discarded.
Deterministic wallets - All receiving addresses can be regenerated at any time and so it's impossible to lose funds that are transferred to previous addresses even ancient ones.
Paper wallets - are essentially permanent addresses, so no issue there beyond user-error.

So this just leaves me with the question of how many non-deterministic wallets discard previous addresses (including change addresses)?
It has been stated that "the BIP 0032 standard for Hierarchical Deterministic Wallets is used by all good wallets as of 2019.".  Should I take that assessment literally with regard to non-web wallets, that non-deterministic wallets are uncommon even on mobile?

Why would you ever discard keys?

@Anonymous change addresses may not be said to serve a useful purpose once the coins are signed out to another address.  change addresses are not created for the express purpose of receiving funds and therefore some wallets may assume that no funds will be received at that address and dispose of the address to save memory/disk space.

They’re 32 bytes. Nobody is discarding them to save space.

@Anonymous Once that payment is made, the receiving party has no reason to retain the data for the address (technical details simplified) and may discard it. at least one person disagrees with you.

The Bitcoin Wiki has never been a particularly solid source of information at the best of times. No software has ever operated like this.

I think that statement may be more about the fact that the owner of the receiving wallet may decide to move on to other wallet software, and stop caring enough about the old wallet to retain the keys. Thus, while no software will intentionally discard keys, the sender can't assume the receiver person will forever have access to old keys.

None. No wallet that exists discards private keys. That would be superbly idiotic to do because that means that money could be thrown away permanently. No wallet would intentionally do that.


text:
How to find transaction's original author in Bitcoin Core?
I have recently installed Bitcoin Core on my PC and downloaded the blockchain in prune mode. I want to find out if there is a way to find transactions original author, the node which broadcasted a transaction first.
I have enabled debug=net in bitcoin.conf file and I can see the list of messages sent between my peers, but I can't figure out how to tell if a transaction is broadcasted for the first time or is it just being relayed?

There is no way to gain this information with certainty.
Information about whom crafted a transaction is not included when a transaction is broadcast; that would be very obviously bad for privacy.
There is also no saying that the node which broadcasts a transaction had anything to do with authoring said transaction. In fact there exist many services that allow users to publish their transactions to the bitcoin network with varying degrees of privacy/anonymity.
You could perhaps run a great number of bitcoin nodes, strategically positioned around the world in a way that would allow you to perform a timing analysis for new transactions seen by each node. If you were able to cover enough of the network graph, you could start to make guesses about which other node first published said transaction-- but it would be a guess at best. There is no way to know for certain, by design.

Thank you for you answer! I have seen similar information but could not see why and you gave a great explanation.


text:
Can I find out who this belongs to 36R1pfifzXLu3FDaBVtTy42EX6qLmvpUcL
I sent a payment to that address and it's not the business I thought it was. Can I find out where my Bitcoin went?

In general no, The Bitcoin network does not keep track of what businesses or individuals own which addresses.
A few addresses are associated with some well-known businesses but nowadays people use a new receiving address for each transaction to improve privacy.
Criminals pretending to be genuine are likely to contact you offering to trace that address for an up-front fee. Take great care or you will lose even more money.


text:
BlockCypher transaction failed status fetch
At this moment we are developing mobile app and using BlockCypher.
Each completed transaction got 3 states: success/failed/pending.
We using link: https://www.blockcypher.com/dev/bitcoin/#transaction-hash-endpoint
We write success if confirmations more than 2,
pending if <2
But how we can detect failed transactions?
Can't understand which field I can use for it?

What would you consider a failure?

Hi @Murch. For example check this hash:
https://etherscan.io/tx/0x75b7ad2401800c85eb2558ae86d284f373e98b7baa0a23381ceebfe6343734c9
it got status failed.

Hi Sergey, we only talk about Bitcoin on this site. You will probably get a good answer on the Ethereum Stack Exchange for this topic!

From a comment on the migrated question on ETH.SE:

Hi @Murch! I'm asking abound bitcoin ) about block cypher usage ) etherscan I've post as example ) Or bitcoin can't get failed transactions?)

The only way that transactions in Bitcoin can "fail" is by being replaced with a conflicting transaction that spends some of the same inputs. Each input can only be spent once, so the original transaction would no longer be eligible for inclusion in the blockchain after the conflicting transaction got confirmed. As far as I understand, Ethereum blocks can include transactions that ran out of gas during evaluation i.e. they failed to conclude, but are part of the blockchain. This cannot happen in Bitcoin.

How we can check that it failed?  Can block cypher provide this info ? I mean if I had failed transaction and hash, how I can see that transaction failed ? There are no "error" fields in https://www.blockcypher.com/dev/bitcoin/#transaction-hash-endpoint ... Or we can't send it and we got error before sending ? )

Are you now talking about a replaced transaction?


text:
Someone is saying that they haven’t received their money but I show that deposit is in the blockchain. What is going on?
I’ve sent someone Bitcoin via Cashapp. I’ve received notice that the withdrawal have been posted to the blockchain but the person says they haven’t received nor can they see it. Can someone explain this. I did send it “regular speed” so it should show up within 24 hours but they are impatient. Should I believe them or do you think they are not telling me the truth.

can you please post the transaction ID? That way we can confirm that this has in fact been confirmed and the counter-party is lying. Otherwise it is possible that they have not received it yet, if the transaction is stuck in the mempool or something.

Just to clarify, when you say “in the blockchain” and “posted to the blockchain”, do you mean that it was included in a block (i.e. confirmed) or that it was submitted to the Bitcoin network?


text:
Why do I get incorrect password error when running bitcoind?
2023-07-24T19:29:18Z ThreadRPCServer incorrect password attempt from 127.0.0.1:34976
2023-07-24T19:29:18Z ThreadRPCServer incorrect password attempt from 127.0.0.1:34992
2023-07-24T19:29:23Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53546
2023-07-24T19:29:23Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53560
2023-07-24T19:29:23Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53570
2023-07-24T19:29:24Z Syncing txindex with block chain from height 552401
2023-07-24T19:29:28Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53572
2023-07-24T19:29:28Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53584
2023-07-24T19:29:28Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53596
2023-07-24T19:29:33Z ThreadRPCServer incorrect password attempt from 127.0.0.1:39826
2023-07-24T19:29:33Z ThreadRPCServer incorrect password attempt from 127.0.0.1:39828
2023-07-24T19:29:33Z ThreadRPCServer incorrect password attempt from 127.0.0.1:39836
2023-07-24T19:29:34Z Saw new header hash=0000000000000000000045e3ad3ef1bb4793b9ce8af5c74935d856f2763d160b height=800103
2023-07-24T19:29:38Z ThreadRPCServer incorrect password attempt from 127.0.0.1:39840
2023-07-24T19:29:38Z ThreadRPCServer incorrect password attempt from 127.0.0.1:39842
2023-07-24T19:29:38Z ThreadRPCServer incorrect password attempt from 127.0.0.1:39850
2023-07-24T19:29:39Z UpdateTip: new best=0000000000000000000045e3ad3ef1bb4793b9ce8af5c74935d856f2763d160b height=800103 version=0x2cda8000 log2_work=94.319396 tx=869321812 date='2023-07-24T19:28:50Z' progress=1.000000 cache=5.6MiB(38132txo)
2023-07-24T19:29:43Z ThreadRPCServer incorrect password attempt from 127.0.0.1:53514

What are you doing? How did you configure things? Presumably, you, or something, is trying to connect with the wrong password.

I followed ministry of nodes youtube guide to setup bitcoind on ubuntu and these are my configuration settings                                                                                bitcoin.conf settings
server=1
txindex=1
daemon=1
rpcport=8332
rpcbind=0.0.0.0
rpcallowip=127.0.0.1
rpcallowip=10.0.0.0/8
rpcallowip=172.0.0.0/8
rpcallowip=192.0.0.0/8
zmqpubrawblock=tcp://0.0.0.0:28332
zmqpubrawtx=tcp://0.0.0.0:28333
zmqpubhashblock=tcp://0.0.0.0:28334
whitelist=127.0.0.1
rpcauth=bitcoin:[output of rpcauth.py]

proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
onlynet=onion

Are you or some software that you are running trying to connect to your node over the RPC interface (e.g. with bitcoin-cli)? The error message means exactly what it says - something tried to connect to it from the given ip and port, and it gave the wrong password.


text:
Does BitcoinABC implement replay protection for the upcoming November 15th hardfork
Does BitcoinABC implement replay protection for the upcoming November 15th hardfork. With the arguing between the two camps BitcoinABC and BitcoinSV will replay protection be implemented before the split?

I'm voting to close this question as off-topic because not related to Bitcoin.

Why not? A replay attack can work both ways, right? One can spend a forkcoin and without realizing spend actual bitcoins? So it's a valid concern for bitcoin users?

Yes, there's OP_CHECKDATASIG in ABC's code and OP_MUL in SV's code.
There's already a coin splitting tool.


text:
Dash constants and prefixes
Is there any list of Dash constants available? Something like Bitcoin list of address prefixes

Yes.  This Table will be very useful for techies. The application of version numbers in the referenced table are used to compute prefixes for various private keys for numerous alts.  The file references to the far right of the table should be correct.  However, the line numbers have surely changed during the last 3 years. Then also look at the 1st column of the lower table you referenced.
Here is how the referenced libbitcoin table can be utilized for Dash. Let's assume the DASH secp256k1 private key is one of the worst private keys possible in hexadecimal format is
0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff
and its associated hexadecimal compressed public key can be calculated simply with:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public
020d47568a5e517067a2836c3823fbc58169a7662bfae934a4d41da3e23c98d816
Associated Compressed Wallet Input Format (WIF) Private Key:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | sed 's/$/01/' | bx base58check-encode -v 204
XBHdfdHC4YocfzyfuFRx3DxjmvFJmK3txDh3zXk29GxpMWaWfDKL
Associated Wallet Input Format (WIF) Private Key:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx base58check-encode -v 204
7qYrzgwRFrM5TWSyqzeNXs4ZoRka2Rw8EsTHzSYVojawgYVzSH5
Associated Compressed Pay to Public Key Hash (P2PKH) Address:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public | bx ec-to-address -v 76
XyHHinPZB5Q4FC9jtbksaQBJmXq48gtVGb
where: bx ec-to-address -v 76  ==  bx sha256 | bx ripemd160 | bx base58check-encode -v 76
Associated Uncompressed Pay to Public Key Hash (P2PKH) Address:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public -u | bx ec-to-address -v 76
XwxeKFtAXa9wGvX4QijQxz2yC4hMzfAa13
An Associated Simple Pay to Script Hash (P2SH) Address:
% echo "[020d47568a5e517067a2836c3823fbc58169a7662bfae934a4d41da3e23c98d816] checksig" | bx script-to-address -v 16
7fePc8Mf7RYghdxkSp5yaWfT9WR4F2Dsqa
where: bx script-to-address -v 16  ==  bx script-encode | bx sha256 | bx ripemd160 | bx base58check-encode -v 16

The version bytes commonly used by Dash are:
   0x4c for P2PKH addresses on the main Dash network (mainnet)
   0x8c for P2PKH addresses on the Dash testing network (testnet)
   0x10 for P2SH addresses on mainnet
   0x13 for P2SH addresses on testnet


text:
Using Python: create a private key of my choosing, then generate public key and address
I'm looking for a simple, easy to use Bitcoin library for Python.
What I want to do is verify I can enter a hex private key that I want, and get the expected pubkey in compressed format, and the 1Btc... address.
I've looked at cryptotools on github which looked promising, and easy to use, but it would not accept a hex value that wasn't a multiple of 2.  I know that sounds odd, but I want to be able to enter a hex value like c12 and have it work as expected (unless I have to enter 0c12 and that will work, with the leading zero discarded).  I expect than when I enter 0cfa721d that this will be interpreted as big endian.
bitcoinlib looks promising, but I find it confusing and I've tried for a couple of hours but unsure of how to get what I want.

Input private key in hex
Get back pub key in hash160 format, compressed
Get the 1Btc... address as well.

I wonder if this is a strict mathematical relationship.  For instance could there be an arbitrary or infinite number of pub keys from the private key?  Is there a way to ensure I get the pubkey I want from the private key?  I want to test known private keys with the pubkey and BTC address generated that corresponds to known private keys and addresses, so I can try and figure out how whoever generated these addresses from choices of private keys I can try to replicate and do the same thing myself.
Thank you for any help or suggestions.

Hi, author of cryptotools here. The reason it wont accept odd digits hex is that it will store the private key inteternally as Python bytes object and the bytes.fromhex method requires full bytes. I'll have a look at it. As a workaround you can simply pad with a zero if it has odd amount of digits.0x0cfa721d is exactly the same as 0xcfa721d. The other functionality is there, just do myprivatekey.to_public().to_address('P2PKH', compressed=True)

For this very reduced case, you can take a look at https://github.com/circulosmeos/bitcoin-in-tiny-pieces
It has each operation coded for ease of understanding, isolated in a different file, but they're easy to join or to use directly from command line: for example:
$ echo 0x01 | ./bitcoin-public-from-private.py | ./bitcoin-address-from-public-key.py
And for the question:

For instance could there be an arbitrary or infinite number of pub keys from the private key?

In principle, from a private key only one public key is derived: but this can be coded in three different Bitcoin addresses. Normally only one or two of these formats are used.
This is in the most simple case, not considering more complex cases introduced later in Bitcoin (like HD keys, etc)...

Hey thank you!  I forked your repository at https://github.com/jamesyoungdigital/bitcoin-in-tiny-pieces.git to add a new little tool that checks brainwallet address balances.  I wasn't having much success with the shell script.  It now depends on my fork of pybitcointools.git, which is really easy to use and depends on almost nothing.  Hope you might like the little additions! :)

Glad it has been useful! As for the shell script just open an issue and I'll take a look: it'd work flawlessly!

Star given!  I'd like to give a few more but they won't let me, haha. :-)  With the shell script, I try like this:  ./bitcoin-test-address-balance.sh satoshi but the output is always: ... 2 .... n and as far as I can tell, never ends.  The problem seems to be in the address balance python script, lines 62 to 64, when an exception is caught.  The URL should use the {} for interpolation.  Please see my pull request.  Thanks! :-)

Hi James, I think that the exception is correctly caught: the thing is that blockchain.info sometimes discard the petition, probably due to high traffic: in that case the script sleeps 1 to n minutes between retries: as it is done for running in batches, this is not considered a problem :-o but thanks for your pull!

I find the Bit module the easiest and most straight forward, albeit a tad, limited but with bit you can simply:
from bit import Key

# To generate private key
privKey= Key()

# Create Ripemd-160 Hash (address)
privKey.address

# or

myAddress = privKey.address

# Segwit

MySegwitAddress = privKey.segwit_address

You can also import your own existing private keys like so:

# For wif format:
privKey = Key.('L1VotKmtZRLZSnSPhLhQxfts2aqBMru2APTs4Yuc8TYJ4jNhQoGB')

# For hex format:

privKey = Key.from_hex('ccb8c423403f4d5b6cde505d2a8f39d1d9399f6e06853339f5b11593cc502dc9')

# For int format:

privKey = Key.from_int('92598274663553697917256765988661195316245391320286084491562671024534692310473')

privKey = Key.from_byte('b'\xcc\xb8\xc4#@?M[l\xdeP]*\x8f9\xd1\xd99\x9fn\x06\x8539\xf5\xb1\x15\x93\xccP-\xc9')

Exporting works pretty much the same way as importing except you replace from.[format here] with to.[format here], you can even import or export a PEM file of your private key.
The documentation is enough for the library to give you the core functions, but is also somewhat lacking, for example you can't create compressed bitcoin addresses. But otherwise you can sign, send transactions, even select exactly which outputs you want to use .etc


text:
How much can you compress a bitcoin for storage?
I've just implanted an NFC chip in my hand and I'm wondering if a bitcoin will fit in the chip. it has a capacity of 868 bytes.

"A bitcoin" is not really a single concept. A bitcoin can be composed of 1000 outputs worth 0.001 BTC each, or 1 output worth 1 BTC, or any other such combination.
Bitcoin outputs are linked to private keys (for standard outputs). There are many ways to derive and encode private keys, and each of them would certainly fit in 868 bytes. However, you would likely have to extract the key into another device to actually use to to access your coins, which could be a security issue. You will most likely be better served, and more secure, by buying a hardware wallet.

I see what you are doing here! :)
like the previous answer stated, a bitcoin is NOT a 'separated' thing that can be stored...
BUT
I have an idea for you:
1 - Print a PapperWallet (Google it...) to a TXT file...
2 - Save that TXT file on your 'chip'
3 - DESTROY the storage container where you first generated the TXT file (so it will exist ONLY on your chip)
What could go wrong:

not having enough space on your chip (you have to check that yourself...)
you could store a corrupted copy to your chip, so useless in the future
it could get corrupted by magnetic fields or somethin'
oh... you could die, before ever using it in the future...

It is possible tho!
Have fun!

of course, that wallet HAS to have the 1 BTC on it already...


text:
Can any one seed potentially generate every single Bitcoin address?
Since you can generate multiple addresses from a single seed, I'm wondering what would happen if you continued to generate addresses forever? Would you eventually derive every possible address? Or would you only be able to generate some subset of addresses? Would you get repeat addresses before all the possible addresses were used up?
I expect such a thing would be infeasible but I'm curious as to what would happen hypothetically.

The BIP32 standard, which is used almost universally for key/address derivation, permits up to 231 (roughly 2.1 billion) keys to be derived within a single chain.
Typically wallets only use one or two chains (one for addresses to give out externally, and one for keys used internally for change), or one or two per address type. Nothing prevents wallets from using more chains than that, but there is no real need as billions of addresses ought to be more than sufficient for any individual user (there have only been almost 880 million transaction in Bitcoin's history in total). Where multiple chains are used, it is for organizational purposes (e.g. keys used for distinct purposes).
Hypothetically, if you kept creating new chains (from the same seed even), and kept computing all addresses in each chain, you would eventually generate every valid key. You won't see anything loop; each generated key will look indistinguishable from random (to anyone not knowing the seed/chain it is derived from).
Due to this random nature, you need to generate some multiple of the number of valid keys before you have a reasonable chance of hitting them all. As an analogy, think of throwing balls at a number of bins, such that each ball lands in a random bin. If there are 10 bins, you will need significantly more than 10 throws before all bins are likely to have at least one ball in it (on average ~29.3), because some will randomly end up in already-hit bins.
After ~2264 addresses you are very likely to have all keys. For 160-bit addresses like P2PKH and P2WPKH, ~2167 should suffice. Note that these are extremely large numbers that are unattainable by current computing power, not even all computers in the world together could compute this many addresses in billions of years.


text:
My bitcoin transaction hasn’t confirmed for 2 months
I sent a transaction with a very low transaction fee and the transaction has been waiting to be confirmed for the past 2 months. How long until the bitcoin is returned to my wallet or sent through?

If a transaction has not been confirmed then the coins have not left your address / wallet. Generally you will have an RBF (Replace By Fee) option that will allow you to signal to the Bitcoin full node network that you wish to get this transaction confirmed faster, in which case you can bump your sat per byte fee rate.


text:
How can OP_CAT be used to implement additional covenants?
OP_CAT takes the top 2 stack items, concatenates them and pushes the result to the stack. How can this be used to add new restrictions how a UTXO can be spent? (Beyond the existing signature and time lock covenants)

Background
Bitcoin script is a stack-based verification language. Because it's a verification language any operation available in the language can be used to either take inputs and produce an output for later use in the script, or require inputs to be provided for use in the script which produce a pre-determined output. As Andrew Poelstra says - operations can be run forward or backward.
Currently, bitcoin scripts have 3 ways to verify the transaction in which they are spent:

Requiring a specific nLockTime field on the transaction  (OP_CHECKLOCKTIMEVERIFY)
Requiring a specific nSequence field on the input (OP_CHECKSEQUENCEVERIFY)
Requiring a signature over a hash of the transaction (OP_CHECKSIG and its variants)

When people discuss "adding covenants" to bitcoin, they refer to adding additional ways to verify the spending transaction, most commonly restrictions on the outputs the transaction will make.
Bitcoin signature checking operations internally hash the transaction being verified. Because the hashing and signing are contained in a single operation, neither the signature hash nor the input data for that hash can be directly inspected by script.
BIP 340 signatures consist of (R,s) satisfying the function s⋅G = R + hash(R || P || m)⋅P where m is the signature hash, P is the signer's public key, and G is the secp256k1 generator point.
Getting the signature hash on the stack
As Andrew Poelstra describes in detail, by setting R and P equal to G, we can force s to be equal to hash(G || G || m) + 1. Using CAT, we can deconstruct the 64-byte signature into its R and s values, and if we further require the spend stack to include the first 31 bytes of hash(G || G || m) (ground until the last byte would have been 0x00), we can then further require the spend stack to provide m.
Verifying transaction elements
BIP 341 signature hashes are composed of internal hashes of many parts of the transaction being verified. Using CAT, a bitcoin spend script can require the spend stack to include the unconstrained inputs to the signature hashes and concatenate them with script-provided constrained portions to verify that the constrained portions match the actual transaction. This means that any datum included in the signature hash can be constrained individually using CAT.
Thus, by including (for example) a hash of transaction outputs in a locking script, an OP_CAT-based covenant script can require the caller to provide all other transaction data and the hashes described above and require that the spending transaction has the required outputs. An additional covenant in bitcoin script.

Full working code using these techniques can be seen in @rot13maxi's Purrfect Vaults

I did a deep dive on this topic with more naive eyes and wrote up my understanding (with some ascii art!). I'd be happy to write up a more condensed version here to complement your answer, or feel free to poach some or none of this.

Thanks! Added some text that based on your write-up that I think was missing here.


text:
Pruned nodes update tip performance
If I run a node with prune=550 does the Bitcoin Daemon still receive update tips (mined blocks) just as fast as a full node?

A pruned node is a full node.  "Full node" means fully validating and enforcing the Bitcoin rule.  Pruning just means that the node does not bother keeping old historical data that is never used for anything except helping new nodes sync up, wallet rescans, and similar.
Pruning will not impact validation performance other than perhaps there may be some small latency spikes created by periodically deleting old blockfiles, or small latency improvements from not participating in feeding historic blocks to newly syncing peers.


text:
How to detect if there is new payments
I want to make a cryptocoin payments php in my website, all info already ok. The only problem is, how to know if my member already pay that payments and if already pay update my database,
anybody know about this?

why question is not clear is not clear for me.


text:
Do I need to store my hardware wallet's derivation path?
"Not your keys, not your coins" is common mantra. I thought all I needed to do was to safeguard my private keys (via hardware wallet, cold storage) to be able to reconstitute my BTC at any point in the future. However, I recently read an, admittedly pretty old, article stating that this is not sufficient; that I must also safeguard my derivation path in order to reconstitute a wallet in the future.
I have several questions related to this:

Generally speaking, is this because different derivation paths can yield, ultimately, different public keys, and thus if I don't have my derivation path saved, I may be unable to reconstitute a wallet that reaches the addresses of my UTXOs?
If so, how can I A. obtain the derivation path from my hardware wallet and B. how is this typically stored?
How does this play in with multisig? The article indicates the order of the multisig set up can change the derivation path. Is this similar to me needing to 'keep track of UTXOs' when it comes to multisig? I have heard this often before but am not really sure what is means; do I need to keep a list of all the public addresses associated with the multisig? Is simply a list of the addresses sufficient? What if the wallets are from different manufacturers? Do they have different derivation paths?
Why is this not talked about more? A random tweet I saw today was the first time I've heard of this.

I think if you’re using a wallet that uses BIP39 and BIP 44 standards (many popular wallets do), then the derivation path is standardized. That was a major benefit of those BIPs vs every wallet doing something different.

Generally speaking, is this because different derivation paths can yield, ultimately, different public keys, and thus if I don't have my derivation path saved, I may be unable to reconstitute a wallet that reaches the addresses of my UTXOs?

Yes. BIP 32 allows for up to 255 path indexes, with each index having 2^32 possible values. It would be impossible to do a simple brute force search. So you would need to store the derivation paths used.
Note that "store" doesn't necessarily require actually storing them. Simply knowing or remembering the wallet software and version that was used to create your wallet may be sufficient. These are often documented, although perhaps not well. https://walletsrecovery.org/ attempts to document the default derivation paths for a large variety of wallets.
You may notice that many of those wallets use the same paths. This is due to standardization efforts with BIPs 44, 49, 84, and 86 which specified some standard derivation paths for single key addresses. It's usually good enough to start there when searching. But there are wallets that do unusual and non-standardized things with derivation paths, so you'll need to confirm the paths that they use with their documentation or even source code.
Some wallets are now also adopting the use of output script descriptors. These descriptors can specify the derivation paths used directly, thereby removing the guesswork required. If your backup consisted of descriptors, then the derivation paths would be stored explicitly.

If so, how can I A. obtain the derivation path from my hardware wallet and B. how is this typically stored?

Hardware wallets themselves do not store derivation paths. They generally don't actually have a mechanism for "get a new address" that would require a default set of derivation paths. Rather they rely on the wallet software to do that. The wallet software asks the hardware wallet to do operations with the key at a particular derivation path, and so the derivation paths used is determined by that wallet software.

How does this play in with multisig? The article indicates the order of the multisig set up can change the derivation path. Is this similar to me needing to 'keep track of UTXOs' when it comes to multisig? I have heard this often before but am not really sure what is means; do I need to keep a list of all the public addresses associated with the multisig? Is simply a list of the addresses sufficient? What if the wallets are from different manufacturers? Do they have different derivation paths?

Multisigs also have some standard derivation paths, although less so. Both BIPs 45 and 48 do this. You also need to know the derivation paths for your co-signers. However multisigs are also more complicated in that the order of keys in the multisig is important. In some multisig constructions, the order of the keys does also determine the derivation path to use.
As with the single key addresses, the derivation paths used all comes down to the wallet software being used. You will need to investigate the wallet software in order to know what derivation paths and ordering it actually uses. But as with single key addresses, the use of output script descriptors would alleviate these issues as those descriptors would also contain the derivation paths used and the order of the keys.

Different cryptocurrencies, like Bitcoin, use hierarchical deterministic (HD) wallets that generate a tree-like structure of key pairs from a single seed phrase (usually 12 or 24 words).  These key pairs are derived from the seed through a process specified by the derivation path.  Each key pair in the tree corresponds to a specific address and its associated private key.
The derivation path is a set of parameters used to derive the keys, and slight changes in the derivation path can result in different public keys being generated.  Therefore, if you don't have the correct derivation path, you might not be able to reconstitute your wallet and access the funds associated with its addresses.


text:
Why are n public keys needed for reconstitution of an x of n multisig?
Trying to conceptually understand why I must store the public keys of the n hardware wallets in an x of n multisig set up? Only x of the seed phrases/private keys are needed to reconstitute/recover the multisig wallet, but why do I need all n public keys?
My understanding is that to send btc I only need x private keys (aka the x wallets on hand), to receive I just need the resultant multisig public key stored, but to recover I need x private keys and n public keys? Why is this?

The conditions for spending a coin (UTxO) are expressed using a small script. In order to be able to recover your coins, you need to back up both:

The script template
The private key(s) corresponding to the public key(s) used in the script

You need the script template because the script expressing the spending conditions is part of the coin itself. And the wallet needs to be able to locate which coins you own from the set of all existing ones (the "UTxO set").
This is true for any type of script (single-sigs, multisigs, or even more complex constructions). But it is often implicitly assumed backups with no corresponding script template are for a single-sig. The wallet would therefore reconstruct a single-sig script template from your private key.
It is however not possible to reconstruct any other script than a single-sig only from a private key. Hence the recommendation to back up other public keys involved in the multisig along with your own private key. This is simply a manner of backing up the script template to be able to locate your coins. (It's however a very incomplete manner.)
Backing up the public keys as a way to reconstruct the script template is suboptimal because it's leaving out a lot of information:

What's the script type? Is it using a bare script, a P2SH, a P2WSH, a P2TR?
What's the construction used? Is it using CHECKMULTISIG, a list of CHECKSIGs? A list of CHECKSIGADDs?
If using Taproot, in what leaf is the multisig? Is it spanning multiple leaves?

Modern Bitcoin wallets nowadays use Output Script Descriptors as a way of describing all the information needed to reconstruct a script template. I recommend using it to backup your multisig (or anything else) instead of relying on implicit information for something so critical.

I don't fully follow. 1. Would the Output Script Descriptor contain the derivation paths or would it be kept separate? 2. In the case of a multisig from 2 hardware wallets & 1 seed signer would there be a single OSD for the multisg wallet? Or 3 individual OSDs, one for each multisig constituent?

It's part of the descriptor. 2. Yes. It looks something like multi(2,xpub1/*,xpub2/*,xpub3/*) (not technically correct but simplified so you get the gist).

And how would this be generated? If I self create the multisig via sparrow, is there an automated mechanism to generate this OSD?

You would generate one (or your wallet would) before receiving funds, and derive addresses from it. I'm not sure but i think you can access your descriptor from within Sparrow.

The common practice in Bitcoin is to use "pay-to-script-hash" for multisig. In fact that is the only way to receive money in a standard "address" for your multisig wallet (there are variants in non-SegWit world, SegWit v0 and Taproot).
Pay-to-script-hash means the sender doesn't know where the money is being sent to. All it knows is that it is sending it to a "hash" of the actual script that specifies the spending conditions -- in this case a multisig script that looks like 2 <key1> <key2> <key3> 3 OP_CHECKMULTISIG.
To spend any pay-to-script-hash UTXO you have to provide the actual script first -- which the Bitcoin verification process will hash and check. And then (in the same transaction) you provide the signatures that will fulfill the script.
For example, this transaction is sending 1631068 satoshis to a 2-of-3 multisig address, but you can't know that just by looking at it. All you can see is that it is paying to the hash a64224765fa40b1bb04a4e8f82d29ca580e2022e20750078b5c3bd610b9015c9.
However, since it was spent in this transaction you can see the script that it used. It is the last element in the witness stack -- 522102b4608d0bba8f2f5665648462819d4a0fe97a8012d386d88ebb4e1ddc93fba5af2102db19c6f47c04ac128a8d9015a75dc350e5291849f999d267598d019dcdf5cbae21030994d7f93c0fb81eeeae14cabe0dbc8a547a9770aca304f4633eaab743fbc06a53ae, which translates (using bitcoin-cli decodescript or hal script decode) into:
OP_PUSHNUM_2
OP_PUSHBYTES_33 02b4608d0bba8f2f5665648462819d4a0fe97a8012d386d88ebb4e1ddc93fba5af
OP_PUSHBYTES_33 02db19c6f47c04ac128a8d9015a75dc350e5291849f999d267598d019dcdf5cbae
OP_PUSHBYTES_33 030994d7f93c0fb81eeeae14cabe0dbc8a547a9770aca304f4633eaab743fbc06a
OP_PUSHNUM_3
OP_CHECKMULTISIG

Finally, if you check the sha256 hash of the (byte-encoded) script above you'll see that it matches the script hash from the previous transaction.
>>> b = bytes.fromhex('522102b4608d0bba8f2f5665648462819d4a0fe97a8012d386d88ebb4e1ddc93fba5af2102db19c6f47c04ac128a8d9015a75dc350e5291849f999d267598d019dcdf5cbae21030994d7f93c0fb81eeeae14cabe0dbc8a547a9770aca304f4633eaab743fbc06a53ae')
>>> hashlib.sha256(b).hexdigest()
'a64224765fa40b1bb04a4e8f82d29ca580e2022e20750078b5c3bd610b9015c9'

You could perhaps explicitly answer the question of the asker by mentioning that you can only provide the actual script if you know all public keys. E.g. you could append “If you don’t know all public keys, you cannot reconstitute the actual script.” to the third paragraph.


text:
Can smart contracts be set up on a side chain or 2nd layer solution?
I am not even personally convinced of the utility of smart contracts, but that aside, is it theoretically possible for a side chain or second layer solution to utilize/implement smart contracts? Ie is there is possibility that the 'DeFi' space eventually transitions to simply being a 2nd layer solution on the BTC network instead of on ETH, etc...? Not so much asking about likelihood, just feasibility given the structure of the BTC network and what is possible with sidechains/2nd layer solutions.

Yes. Given that many applications for smartcontracts would have vastly diverging blockspace and interaction frequency requirements from the payment usecase, segregating such usecases onto sidechains or second layer networks with different performance trade-offs seems like a promising approach. There are already tentative beginnings of such a development. You may find it interesting to read for example more about:

RSK
Liquid
Lightning Network
Discreet Log Contracts
Etleneum
Simplicity
RGB
Drivechains
OP_CHECKTEMPLATEVERIFY


text:
How do i recover the bit coin i purchased via online with a credit card 20 years ago?
I was just 18 years old,  living at my parents. Always playing on computers.  We had AOL at the time.  I still remember my password. I remember my email address.  But my parents passed away and the aol account was in there name.  My parent have been gone for over 10 years now and lost that screen name when the account got closed because ofnthe death of my parents.   Who could i reach out to forbhelp on a recovery option?

Bitcoin didn’t exist 20 years ago. Anyway, to recover it, you need the wallet’s private keys. Emails or accounts may help if they hold recovery info, but without private keys, access to ₿ is impossible. For your parents’ email, contact AOL directly.


text:
is there any way i can get my money back? i paided more then 200 dollars on site named adurite
my payments got stuck in the memory pool for months after using adurite to buy roblox Limited's
is there any way i can fix this for the payment to go threw or can i use console commands to cancel the payment because it never got confirmed

A bitcoin payment that never got confirmed is a bitcoin payment that never happened. In which case you still have the money and should only need to instruct your wallet to forget the unconfirmed transaction


text:
Does Bitcoin Core store private keys
As of 2024 does bitcoin core store private keys. List open source wallets that doesn't store private keys

A wallet is essentially software that manages private keys. It’s not clear to me what you are asking for when you are asking for a "wallet that doesn’t store private keys"? Are you asking about watch-only wallets? Or did you mean to ask about wallets that don’t store the entire blockchain?

The primary purpose of any normal Bitcoin wallet is to store private keys.
By normal I mean non-custodial, the sort that Bitcoin's inventor intended us all to be using.
For me, it isn't possible for something be be a Bitcoin wallet and not store keys. The only exception would be a specialised watch-only wallet (so zero spendable balance) that doesn't automatically generate its own keys when first used.


text:
What happens to miner's fees when a Bitcoin transaction is rejected?
Going through the following resource:

When a miner creates a block proposal, the miner is entitled to
specify where all the fees paid by the transactions in that block
proposal should be sent. If the proposal results in a valid block that
becomes a part of the best block chain, the fee income will be sent to
the specified recipient. If a valid block does not collect all
available fees, the amount not collected is permanently destroyed;
this has happened on more than 1,000 occasions from 2011 to
2017,[1][2] with decreasing frequency over time.

I understand that transaction fees are eventually refunded to the sender. However, what about the miner's fee? If miner's fees are also refunded, how does Bitcoin protect the miner's mempool from being flooded or spammed with invalid transactions? Shouldn't there be some form of deterrent in place to safeguard these mempools?

Transactions are never cancelled, and there is no refund. However, the sender also does not need to wait for anything to happen before attempting to use their money in another manner, at least in theory.
When a user broadcasts a transaction, it expresses an attempt to move the coins involved. Once that transaction confirms, everyone will agree that that happened. But before confirmation, it is a matter of perspective. Typically, the sender's wallet will treat the coins as gone as soon as the transaction is created, but as far as the blockchain is concerned, they still reside in the sender's wallet.
The protocol does not prevent the sender from creating another transaction that spends the same coins, which therefore necessarily conflicts with the first one (through a principle known as Replace-By-Fee (RBF)). Some wallets allow RBF just for the purpose of increasing the fee of a transaction that is happening too slow, but some also allow a user to "abandon" a non-confirming transactions in some circumstances, permitting the funds to be spent in another way.
In short, there is nothing to refund, because as far as the network is concerned, a non-confirmed transaction simply hasn't happened. It is a matter for the sender's wallet how to deal with that.

Thank you! That really helped clarify things for me. I have a follow-up question, though: How does Bitcoin prevent miners' mempools from being overwhelmed with invalid transactions? Is it possible for an attacker to flood the mempool with a ton of invalid transactions, knowing that they would eventually be rejected by the network, like in a double spending scenario?

@Learner it is best to ask follow up questions as new questions using the "ask question" button. But no bitcoin software would ever put an invalid transaction into its mempool. All Bitcoin nodes  check data and discard invalid data. I don't know if there are any measures that prevent a node's mempool  being flooded with unconfirmed but valid transactions spending a common input.


text:
Will the bitcoin blockchain eventually grow too large to be able to be run 'by anyone'?
A key component of bitcoin is its decentralization (which effectively only exists with BTC and virtually nothing else). Part of this decentralization is the decentralization of the bitcoin nodes, which is owed to the fact that basically anybody can run a node (raspberry pi, bitcoin core software, a few other pieces, etc...) for a relatively cheap cost. I know this is why BCH hardforked off of BTC in 2017, since the latter refused to increase the block size to intentionally keep the chain small enough to be run by whomever. This makes a lot of sense to me.
However, what is going to happen when the bitcoin blockchain continues to increase in size over time? Even if the blocksize is kept constant, will the chain not eventually become unwieldy? Once it is the global base layer, will it not be too large of a chain for the everyday person to be able to download the chain and run the node? Will consensus allow for chopping off some portion of the earliest transactions that everyone has agreed upon? There are obvious downsides to this. What is the solution?

The claim that Bitcoin refused to increase the blocksize is BCH propaganda. Bitcoin did indeed double the block size in 2017. (This was a bad move, but it happened nonetheless)

Although as people say in answers the BTC blockchain does not grow fast enough to risk overload in our lifetimes it is certainly a good idea to think about ways to decrease blockchain size, at least for most nodes - this applies to all cryptos. This could be achieved either by increasing pruning of the blockchain or by compressing what can be compressed of the blockchain. Some global irreversible pruning may be considered, placing a cutoff on the size of transactions recorded or lumping together/summarizing old transactions in some accepted way. - Caveat: im no specialist.

There is a risk that the blockchain will continue to grow too quickly and become unwieldy, yes. However, if technology improvements continue at their current pace for several decades, and Bitcoin survives the intermediate turmoil, it will eventually start to get easier to run a node again.
"Chopping off some portion" significantly changes the security model, because not only are you no longer verifying the early blocks, but you are also now blindly trusting a "chain state" assigning coins to keys. There is no current known solution to avoid this blind trust - to verify the chainstate requires processing the old blocks.

I don't think it will ever happen. In almost 12 years, size of bitcoin blockchain is around 400 GB. 500 GB hard disk is so cheap right now. Even 1 TB SSD comes under 100 USD, and HDD even for less. Think about 250 GB hard disk just 5 years earlier (blockchain size would have been around 200 GB then), it used to be so costly. I believe by time goes by, rate of increase in CPU & hard disc price (if it doesn't decrease) will be much slower than increase in size of Bitcoin blockchain. So comparatively, running Bitcoin node will become cheaper relative to the income in future even with increasing blockchain size.

As the number of transactions increase, so called "layer 2" transactions will sprout up to keep lower level transactions off the blockchain--the tx fee will be too high to justify putting small transactions directly on.  For example consider a credit card--people charge to the card for 30 days and then pay the card once from their bank account at the end of the month.  It could work similarly with bitcoin, processing transactions all month on a credit card and then consumer paying the credit card bank at the end of the month from a wallet.  Technically, the credit card bank could keep the direct purchase transactions on its own books and put only one tx on the bitcoin blockchain at the end of the month.


text:
Is the 'real barrier' to attack bitcoin's consensus 33.34%, rather than 51%?
Saw a random tweet thread that claimed that the "51" in "51% attack" was misinformation, and that in reality only 33.34% of hash power would be needed for a bad actor to attack the network.
I was skeptical, but one of the posters linked to a talk by Dr. Leeman Baird where, as far as I can interpret, he explains that if you put a firewall around 1/3rd of the hash power and refuse to allow it to talk to the other 2/3rds, then you only need slightly more than half of this remaining 66% (33.34%) to maliciously attack the network. (The relevant part of the video begins at 1:01:08 or so).
I sort of get it as a concept, but as one of the students asks, it seems prohibitively difficult for a bad actor to cordon off 1/3rd of the world's hash power with a firewall. As they ask, is building a firewall around 1/3rd of hash power significantly easier than obtaining the remaining 18% of the hashpower they would've needed (18+33=51%) to conduct a standard 51% attack? This seems like a great question, but Dr. Baird casually responds that China already has a firewall around all of their internet, so doing so is pretty simple since it already exists.
Wouldn't the hash power just move? He explains that recognizing that it has been cordoned off would be difficult and thus makes this solution infeasible.
Is this legit? Would love for someone to give insight.

Why did I get a downvote? I'm asking a sincere question here, and even postulated why the person stating this would be wrong. Wth?

In this proposed attack, you need more than just hash power. However, if you assume that you can partition the network as this attack imagines, you need no hashing power at all.
If I can split the bitcoin network in half, I can deposit the same bitcoins into two exchanges, one on each half of the split. I can wait for both deposits to accumulate as many confirmations as the exchanges require, trade them for some other crypto, and withdraw the other crypto.
So if you can partition the network, you don't need any hashing power at all to double spend bitcoins. And if you can't partition the network, you still need >50% to double spend.
So I don't think that the existence of these kinds of attacks makes the >50% figure invalid. There exists all kinds of attacks that requires less than 50% of the hashing power (as little as none at all) and something else to launch an attack.

There also exists lots of organizations claiming bad things about bitcoin that their own coin magically fixes without giving any evidence as to how.

The funny thing about these absurd hypotheses that keep popping up is that if the assumptions involved in executing such a thing were true then they could easily become the richest people in the world just by executing this plan. But they never have the courage to because they all cut corners with the assumptions they make along the way. If you can't tell the main reason they need to attack Bitcoin is because they are trying to grasp the majority share of an unregistered "crypto" security called Hedera Hashgraph which is a completely censorship enforcing permission requiring model of a blockchain.
I can go into the details about why you can't force reorganizations with 30% of the network hashpower if you really don't see how that is impossible, but actually this 50% attack network hashpower thing is really just misbehavior that individual users could opt out of if they were to notice it. Just like in this crazy model of an attack the attacker "firewalls" the rest of the network away. If they do that they consent to having no one actually using bitcoin validate their blocks and they will never be included in the main chain. Seems bat shit crazy to me. Not to mention that there are so many individuals involved in 30% of the network hashpower, good luck getting an army of self serving miners to do an attack just because you asked them to. They would rather earn coins honestly like a sane person.