text:
Crypto-currency interoperability
My question is about Bitcoin, Litecoin and Ripple, to which other currencies (crypto-currency and regular) they can be exchanged? Are they exchangeable with any currency or can each one be exchanged with specific currencies?

There are services such as ShapeShift that have built whole businesses around exchanging cryptocurrencies for each other.
There are numerous exchanges in many different countries that allow customers to trade national currencies for cryptocurrencies.
There are several payment processors that accept cryptocurrency payments for their customers and reimburse them in national currency.
There are some services that automatically convert your salary into cryptocurrency, allowing you to be indirectly paid in cryptocurrency by regular companies.
There are services that allow you to pay virtually any bill or order from any webshop through them as intermediaries, paying the with cryptocurrency.
By using a combination of the above, you can virtually trade any currency, your labor, any service, produce or physical object for pretty much any cryptocurrency.


text:
How to check Bitcoind is mining?
I am still very new to Bitcoin.
I installed bitcoind on my Ubuntu server as described on bitcoin.org.
After installation I issued

bitcoind -daemon

and the tool started to download/get the blockchain (which is finished meanwhile).
Three questions:

In contrast to what the setup guide says, the tool did not complain about a missing rpcuser and rpcpassword in the bitcoin.conf file. Is that an issue with the documentation or is there something wrong with my installation?
In case my node gets the chance to process a block, I would be rewarded those 25 BTCs. But to which account would the be sent? Is there a default or do I need to do some configuration for that?
As the process to become the node to mine the next block is computational very heavy, I would have expected that the CPU usage of my server should always be very high - but it's only at <10%. How can I make sure that my node participates to become the one to process the next block? Is there some configuration that I missed?

There is no use attempting to CPU mine in 2016, you have a significantly better chance of winning a lottery than solving a block.

I know that. But the server I am using is there anyways and not really used at the moment for anything. So maybe I'm lucky...

The extra electricity used to mine will still cost you orders of magnitude more than what you can hope to gain. A lottery is literally more profitable than what you're trying to do.

Answers to your respective questions:

Since 0.12, bitcoind supports cookie file authentication. This means that on startup of bitcoind, a file with a random key in it is created. Anyone who can present the contents of that file to the running bitcoind is allowed access. Since bitcoin-cli runs locally and as the same user, it can read this file and do so.
Bitcoin does not have any concept of accounts (at least not at the protocol level). Generated funds by bitcoind's built-in miner are sent to an address taken from your local wallet. If you want to modify that, use mining software instead of the built-in miner (which is only there for testing purposes).
The built-in miner is off by default. You can enable it by setting gen=1 in the bitcoin.conf file, but I would strongly discourage you from doing so. The chance of finding a block using that setup is about 1 in a billion, if you leave it running for 10000 years. If you insist on using your CPU for mining (which won't ever be profitable), at least use optimized software like bfgminer, and sign up with a pool, so you can get small rewards for work, rather than waiting for a lottery you'll never win.

Update august 2016: The internal miner is removed entirely in Bitcoin Core 0.13.

source: Stack Exchange

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

sort: votes


text:
Bitcoin Halving - What is it? How is it calculated? Does it affect my bitcoin balance?
I have read a lot about the halving that is set to take place later this year, but my question is how is halving calculated? Will it also effect my bitcoin balance as a whole?

The halving takes place approximately every 4 years. It is programmed in the software.
It will not affect your current bitcoins at all. It only affects the newly mined bitcoins which will be 12.5 after the halving (instead of 25).
The halving is expected to influence the price of bitcoin. With less supply the price will probably rise given that demand is the same... at least in the long run, since supply could also stay the same or even increase if people that were holding bitcoins start to sell.

A Bitcoin block reward is composed of two parts:

the block subsidy, which are newly minted coins
the transaction fees, which are paid by the transactions included in the block

The block subsidy halves every 210,000 blocks which take about four years. The subsidy started with 50 BTC, halved to 25 BTC in 2012, to 12.5 BTC in 2016, and will halve to 6.25 BTC in May 2020. Eventually, the halving will reduce the block subsidy to an amount below one satoshi and no new bitcoins will be created. The block reward will be only composed by transaction fees then.
Existing Bitcoin balances are not changed by the halving.

Halving reduces the block reward by 50%.
Current block reward is 12.5 Bitcoins. As a result, after halving the block reward of bitcoin will fall to 6.25 Bitcoins. After 4 years from now, block reward will be reduced again, and will fall to 3.125 BTC and so on.
According to this countdown of bitcoin, halving will happen in just 18 days https://bit4.sale/en/halving/btc/, so that is approximately on the 11th or 12th of May, depending on which time zone you're located in.
Your Bitcoin balance won't be affected in any way. Halving only reduces the reward that miners will get from each block.

The link is dead

all_licenses: 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:
Is there a way to use the block chain as entropy in random number generator?
I want to create a transparent gambling/lotto site and use the block chain as entropy for lotto numbers, dice rolls, that kind of thing.  Would the transaction hash of the latest transaction be the best way to do this?  How often are transaction hashes created?  How would you, programmatically, access them?

This feels slightly off topic.

why off-topic? from the FAQ: " practical, answerable questions based on actual problems that you face".  Seems pretty on-topic unless I am missing something.

because it would be impractical to use Bitcoin for entropy in a gambling site. There are other easier ways to do this today. http://www.random.org/

wouldn't "impractical" be up to me?  The question is not about how to implement a gambling site, it's about using the blockchain as entropy.  The use of it is irrelevant, it's still a valid question.    And random.org doesn't solve all my problems.

It may be a valid question, but it's not a particularly bitcoinish one--smells more like programming technique to me, which should go on Stack Overflow.

The Bitcoin Lottery used an SHA256 hash of the two most recent blocks to generate random data and to my recollection there were not too many complaints about that method they chose. In any case it's only good for 256 bits of questionably random data every 10 minutes (20 if you don't reuse blocks) so there are probably better entropy sources, such as the setup they've built over at random.org

And here, "questionably random" means that given a suitably large reward and a suitably motivated miner this would absolutely be gamed.

Actually a correct random implementation with Mersenne Twister would suffice. If people get paid, they don't care much about how do you generate the numbers. Joe Six Pack wants his price, not to know.

Only sort of. The transaction hash is specifically chosen because it is smaller than some number X (--> difficulty factor), so it isn't fully random. However, it has a lot of entropy in the sense that it contains input from a lot of different, not predictable transactions. So you could use this hash as a seed for your RNG.
If you just want to generate lotto numbers and dice rolls, I'd say it's more important that you find a good random number generator (RNG) - you won't reseed that often anyway.
If you wanted to use the hash as the random number directly, there's a problem: you only get one hash every ~10 minutes. Not all that many random numbers.

See my Python implementation to derive a random probability from a predetermined block height. This enables untrusted parties to use the Bitcoin blockchain as a cryptographic beacon, by just agreeing to a future block height.
See also On Bitcoin as a public randomness source and this related video.

With Bitcoin Core, you only get one block hash every 10 minutes, but a block is composed of - with block height prefix - unique transaction hashes. SHA256 sliding ngrams on this data do appear to be uniformly frequent.

If I may answer with my stack overflow hat on...
Here's how I'd draw a random number in way that no participant can influence the result of.
Invite each player to pick a random number, x, and publish the hash(x). Once each hash has been published, each player should then reveal their x. With those x's, add them all together and hash the result. Use that final hash as the random value.
UPDATE: To work around the attack described in the comment below, use two rounds.

Each player selects a randon number, x, and reveals hash(x).
When all hashes have been revealed, each player reveals x.
All x's are combined and hashed. y=hash(all x)
Each player selects a new random number, z, and reveals hash(y+z).
When all of the second round of hashes have been revealed, each player reveals z.
All z's are combined and hashed. The result is used as the random value.

If the player has a prepared hash collision, they could only use it to select their prefered y value. This doesn't help because they would now need a way to find a collision where both inputs have the same prefix (y) which won't be known in advance. If you can do that in a timely manner, we all need a new hash function.
(I welcome comments. Its possible I've missed something else.)

An attacker could find a hash collision where hash(a) = hash(b), publish the common hash value, and then observe the other players' revealed numbers before choosing whether to reveal a or b.

@JGWeissman - I missed that. Thank you. I've updated the protocol to work around that issue. (Or maybe I've made it worse.)

Now an attacker with a hash collision on a and b can reveal in step 4 that hash(y+z) is the common hash of a and b, and then in step 5 choose to reveal either that z = a-y or that z = b-y.

So, in step 4, require also that each player reveals hash(z).

Ah, by + I meant concatenation, rather than addition. Anyway, I suggest we move this discussion to a different SE. I've taken the liberty of opening this Q.
http://crypto.stackexchange.com/questions/767/how-to-fairly-produce-a-random-number-between-game-players-wihout-trusted-third-p

@JFWeissman.  There is no known collision attack for SHA-256.  As long as a cryptographically secure hash is being used your attack is theoretical only.

You could scrape data from http://bitcoincharts.com/bitcoin/ to get the hashes of transactions that had just been submitted.  It wouldn't super easy to do, but it'd be a constant source of fairly random data.


text:
Is Quark as secure as SHA 256?
I'm trying to make certain I'm understanding the purpose behind the Quark algorithm.
There are lots of devices that need secure algorithms but have severe power and processing constraints such as RFIDs (the chips found in everything from clothes to cars) - hence Quark (and other algorithms) were developed. Quark seems to be secure and yet lightweight enough that CPUs are more that capable of hashing them without maxing out.
I've read lots of articles and posts that come up with reasons pro and con re Quark. What I'm wondering about is what makes Quark worthy as an algorithm for a currency? One advantage is that it uses multiple algorithms and the chance of multiple hash functions getting cracked at the same time approaches zero. But why would we really care if more or less electricity is being spent in creating a block? Of course I want my electric costs to be less - the same as anyone else. But more important than my electric costs is knowing that the currency is secure. I would also prefer that mining is distributed across the network (as opposed to ASICs) but again what counts first and foremost is that the system is secure.
That being the case how is an algorithm designed for RFID's able to compete with SHA256?
I'm still struggling with these algorithms so I may be missing something very basic.

I'm confused by the remark about RFID's - SHA256 can run in an RFID chip too.

Really! See I am missing things. I thought that Quark was designed for RFIDs because they needed something with minimal power usage - something that SHA 256 wasn't suitable for.

SHA256 can run with about 100 bytes of memory. It's all of the other stuff, like maintaining a 1.3 GB unspent transaction set, that makes an RFID chip unsuitable for running a full node.

The biggest problem with Quark (or any other "memory hard" algorithm) as a hashing algorithm is that verification is synchronous. So in order to verify things you have to do a lot of work, compared to the very small amount of work required to verify SHA256. This could lead to a DoS attack where an attacker sends you a whole lot of bad blocks and makes you tie up memory and CPU trying to verify them.


text:
I heard a message was encoded into the blockchain, how can I read it?
I have been running a few full Bitcoin nodes for a long while now and I've decided to start learning how to interact with a node to get different information. Recently, Elon Musk's two messages were added to the Bitcoin blockchain. I wondered if as a starting pointI could directly interact with my BTC node and extract information like reading these two messages?

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


text:
Is the 51% attack the only technical reason no country will adopt Bitcoin as a state currency?
Is the 51% attack the only technical reason no country will adopt Bitcoin as a state currency?
Lets suppose a country with GDP size less than 300 Billion USD adopt the Bitcoin as an official currency. It will be very easy to crush or take control of state currency if a country like US or China invest to run 51% of mining pool.

Related: https://bitcoin.stackexchange.com/q/256/63872

A lot of companies used to be (and some still are) uneasy about leaving critical infrastructure to open-source development.  It's hard to believe either US or China would be comfortable with their currency being maintained by developers out of their control.

If what you mean by adopt bitcoin as a state currency means replace their existing fiat currency; I believe there would a lot bigger problems to consider. If they did do that, it would essentially be saying that their money no longer has any value, which would cause a massive panic within their population. A type of panic similar to when India banned the 500 and 1000 Rupee notes.
You'd also have to consider countries that have that type of GDP, they would need the infrastructure for everyone to be able to be connected to the internet and have devices to use Bitcoin. Also they would need everyone to be tech savy enough to understand how to use bitcoin.
Also, with the lightning network at its current state, bitcoin transactions can't scale to an entire countries' economic activity.
So I would say that a 51% attack is pretty low concern for a country looking to adopt bitcoin as a state currency. A better approach would probably be to start stock piling bitcoin and perhaps even use it to back their fiat currency to strengthen it.

You would not do PoW if you have a state as central authority and trust anchor. You would simply switch to Proof of Authority or other strategies, e.g. permission-ed blockchains. Further, you could use other Decentralized Ledger Technologies.
PoW is so great because everyone can join the network without revealing their identity.


text:
How to generate valid BTC address to withdraw coins to
I set up bitcoind, and the complete blockchain is synced. I created a wallet, and I loaded the wallet.
How can I generate an address to deposit BTC to? I tried bitcoin-cli getnewaddress and I get this address bc1q4mglxdp28f693lw476fnmcesq25tmfkcsfqnpk, but at the Huobi exchange when I try to withdraw 0.001 BTC to that address as a test, I get the message "Invalid address."
What am I doing wrong? How can I create a valid BTC address on my loaded wallet to send BTC to?

Your bitcoin client is generating a P2WPKH (bech32 encoded) address, which is a newer address format which has some benefits compared to legacy formats. The address is valid, but for whatever reason, the exchange mentioned has not upgraded it's code to recognize and send to this address type yet.
The fix is easy: you just need to tell bitcoin-core to generate a legacy address. You can use the following command:
$ bitcoin-cli getnewaddress "(address_label)" "legacy"
You can substitute your own label in for the (address_label), this is just for local book-keeping purposes, it can also just be left blank if you'd like:
$ bitcoin-cli getnewaddress "" "legacy"


text:
Why would people buy bitcoin these days if its too expensive?
I'm curious on why would bitcoin rise in the near future since its not affordable anymore. It's actually but for wealthy people only. How could it even reach mass adoption because of its extreme price?
It seems reasonable that people will switch to alt-coins because of their lower prices hence that would cause bitcoin to loose its value over time since people will start to sell it..
How can people/experts make claims that we could see bitcoin over 100k etc. It's total nonsense or am I missing something?

When Bitcoin price was less than 1$ and reached 20,000$ Does this fact make any sense?

Why would anyone want a ten dollar bill if it costs a thousand pennies?  Isn't a thousand a really big number?

What you are probably missing is the fact that you can buy partial bitcoins, you don't have to purchase a whole bitcoin at once. You could buy a small bit of bitcoin for $20 if you wanted, it can be an affordable investment for anyone.

Yeah, I definitely missed but again, you know people mindset who wants a quarter, half? We all want at least a whole number....

@eugene_sunic: Evidently, lots of people don't feel that way.  You can look at any Bitcoin exchange and see lots of trades for much less than 1 BTC.  So I think your assumptions are simply mistaken.

Well they obviously are. Will look at the exchange more carefully to examine the situation... Tnx guys for the reply

@eugene_sunic please remember to accept my answer if it satisfied your question :)


text:
How does Bitcoin core knows whether CPFP carve out rule is already used?
Bitcoin node has 2 rules that limit the use of CPFP:

number of descendants (including transaction itself) can't be more than 25
total size of transaction and all its descendants can't be more than 100 000 vbytes

However, with CPFP carve out rule previously mentioned numbers can be exceeded. CPFP carve out says that one additional transaction up to 1000 vbytes can "added" to unconfirmed transaction (that does not have unconfirmed ancestors) even thought it will exceed 25 number of descendants and 100 000 vbytes limit.
I am interested in how is CPFP carve out rule checked? In other words, how does a Bitcoin node prevent a given rule from being used twice or more?
For example, assume a transaction with 3 outputs where one of them already made 25 descendant count and 100 000 vbytes. If we add a new transaction (200 vbytes) directly to one of two remaining outputs, what prevents us from adding another transaction (size up to 800 bytes) to that remaining third output?
Is there maybe some indicator for CPFP carve out which say whether it is used or not (although I'm not sure how it could be implemented since you can't know when CPFC carve out happens)? Does the given rule can be activated only when the transaction has exactly 2 outputs since then the CPFP carve out rule cannot be used on more than one outputs? Or is a third way used?

You can only use the carve-out rule once since it creates a 26th descendant. The CPFP carve out rule can only be used when a transaction has 25 descendants (including itself), not more.
That's the reason why the carve-out can only be used for two-parties contract, and why Lightning makes sure no transaction has two outputs directly spendable by the same party: it can be exhausted.

For example, assume a transaction with 3 outputs where one of them already made 25 descendant count and 100 000 vbytes. If we add a new transaction (200 vbytes) directly to one of two remaining outputs, what prevents us from adding another transaction (size up to 800 bytes) to that remaining third output?

From your example it seems your confusion stems from thinking in outputs, whereas the descendant limit is per transaction. In your example, let's say this transaction has no ancestor and from the first output 24 transactions are chain. The 25-descendants limit is hit for this transaction. However the carve-out allows one to chain a single, small, additional transaction on the second output. The transaction now has 26 descendants (accounting for itself). The carve-out rule can't be used to chain one more transaction using the third output.

Nodes generally will only permit a new transaction into their mempool if it does not increase an existing transaction’s descendant set count past 25 and doesn’t make a descendant set exceed 100'000 vB in sum (in both cases the transaction itself is included in its descendant set). This check will be performed for each ancestor transactions of the transaction under consideration. This rule leads to a pinning attack, where one recipient of a transaction can chain 24 additional transactions (or one very large transactions) off of their output, thus preventing other recipients of that transaction from CPFPing the transaction.
The CPFP carve-out permits addition of a 25th descendant (i.e. a descendant count of 26) under the conditions that this new transaction must have only a single unconfirmed ancestor transaction and may not exceed 10'000 vB. Since the carve-out transaction can only have a single unconfirmed ancestor, it necessarily attaches to the first transaction in a tree of unconfirmed transactions. This carve-out mitigates the above described pinning attack by guaranteeing that a transaction can be attached to at least one other output of the original transaction, even when the descendant limit has already been exhausted by another recipient. Given a transaction in which each recipient at most controls one output, this guarantees that at least two recipients can attach child transactions.
We do not need to explicitly track whether the carve-out was already used, because it is obvious from the descendant count of the parent. The carve-out cannot be used twice, because that would raise the descendant count to 27, or the descendant set size is already in excess of 100'000 vB.
Other than one might expect, the transaction making use of the CPFP carve-out is not required to pay a higher feerate than the parent.

Nice answer, thanks. Have 2 questions. 1) Descendant set includes the transaction itself, so the size of the transaction itself + its descendants cannot exceed 100'000 vB? 2) "...and may not exceed 10'000 vB", isn't it 1'000 vB, not 10'000 vB?

Yes, 2) the EXTRA_DESCENDANT_TX_SIZE_LIMIT is 10'000: https://github.com/bitcoin/bitcoin/blob/d5e5810bd36f6e899d64a57e9264729b27a9c3f8/src/policy/policy.h#L73-L78

Was it 10,000 from the beginning? I ask because the proposal mentions 1,000. Also, in bitcoin optech it says in global 101'000, not 110'000.

It was 10'000 vB in the original PR, and appears to be 10'000 in the current codebase. Perhaps you should file an issue in the Optech repository to request clarification.

Thanks for the clarification.

Or you could ask about the discrepancy as a new question here on BSE, I suppose


text:
Why was the BIP33 ("Stratized Nodes") never implemented?
What are the technical reasons that BIP33 was never implemented ?

It seems to have expired
See BIP-0002

BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.

To see the exact details of the discussion of this proposal I believe you need to become a member of the bitcoin developers mailing list and bitcoin developers forum.
If you look at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-May/subject.html it seems this BIP was maybe superseded by some work on Bloom filters?
To get a complete picture, I think you'd have to dig around a lot more.

TQ TQ.! At the 1st place, i don;t know where to look for extra information.! That why I asked.


text:
Why does Bitcoin Core's `estimatesmartfee` return a higher feerate than necessary?
For past ~36 hours, the fees returned from bitcoind are very high compared to the fees returned by other estimators, for instance the mempool.space explorer. It is also much higher than the feerate of most of the transactions in the recent blocks.
Since the Bitcoin Core fee estimator is based on historical transaction feerates, why is it giving such a high estimate?

The Bitcoin Core fee estimator does not aim to provide the minimum possible feerate to be included within N blocks. It aims to provide the minimum feerate such as one has a high degree of confidence the transactions will be mined within N blocks.
It therefore tends to often give a higher estimate than appears to have been necessary on any particular transaction. But it also provides a guarantee [0] that over time a high percentage of the transactions created with the recommended feerate will have been mined within the required N blocks.
Bitcoin enthusiats often use mempool-based estimates to try to minimize the fees and tend to view this guarantee as unnecessary. This is because they understand how Bitcoin works and can cope with a transaction sometimes taking longer than necessary to confirm (or use techniques such as RBF). They tend to overlook it is an important property for people who don't want to be Bitcoin experts and just want their money to work reliably.
That said:

An economical mode can be used with estimatesmartfee instead of the default conservative mode. By trading off some reliability, this mode is more responsive to short term drops in the prevailing fee market.
A discussion was recently started on the Bitcoin Core Github repository about how the accuracy of the fee estimator can be improved.

[0]: it's still an estimation. It only guarantees as much as an estimation can.


text:
Sweep Taproot and native Segwit v0 coins in a single transaction using Bitcoin Core wallet
My goal
Learn how to send an imported tr(wif) and wpkh() utxo in the same transaction.
What I've tried
I imported a WIF utxo containing a v1 segwit utxo.
bitcoin-cli importdescriptors '[{"desc":"tr(wifkey)#checksum", "timestamp":unixts}]'
I didn't know the checksum, but when importing I got an error that told me what the checksum should be, so I used that.
The balance showed up after import, I assume it was imported correctly.
Learned createrawtransaction, fundrawtransaction, signrawtransactionwithwallet are not acceptable for taproot. This was resulting in "Witness program was passed an empty witness".
It seems psbt commands are more appropriate. However, I couldn't figure out how to successfully sign with cli. I kept getting "complete": false returned.
I then tried bitcoin-qt and attempted to sweep funds to an address as a test.
I received this:
While using bitcoin-cli and running bitcoin-cli listunspent I see:
[
  {
    "txid": "TX_1",
    "vout": x,
    "address": "ADDR_1",
    "label": "xxx1",
    "scriptPubKey": "44_LEGNTH_HEX_STRING",
    "amount": xxxxxx.xxxxxx,
    "confirmations": xxx,
    "spendable": true,
    "solvable": true,
    "desc": "wpkh([FINGERPRINT/84'/0'/0'/0/0]KEY)#CHECKSUM1",
    "parent_descs": [
      "wpkh(xpub_key/84'/0'/0'/0/*)#CHECKSUM-parent"
    ],
    "safe": true
  },
  {
    "txid": "TX_2",
    "vout": xx,
    "address": "ADDR_2",
    "label": "xxx2",
    "scriptPubKey": "68_LENGTH_HEX_STRING",
    "amount": xxxxxx.xxxxxx,
    "confirmations": xxxx,
    "spendable": true,
    "solvable": true,
    "desc": "tr([FINGERPRINT2]KEY2)#CHECKSUM2",
    "parent_descs": [
      "tr(KEY2)#CHECKSUM2"
    ],
    "safe": true
  }
]

Output sanitized
Question

What are the methodical steps starting with an imported WIF/taproot utxo + wpkh utxo and creating a signed tx to send funds?

You need to use a descriptor wallet, and import the key as a taproot descriptor (if it's just a key path key, it would be tr(WIF), but scripts can also be included there). Further, you need to use PSBT RPCs; the old raw transacrion RPCs in general do not support taproot.

I'm currently doing createpsbt then walletcreatefundedpsbt but not sure where to go from here. I've tried both walletprocesspsbt and finalizepsbt but they return the base64 encoding and "complete": false.
I've tried utxoupdatepsbt but unsure what I would need to do since I've already successfully imported this into my wallet.
What steps am I missing?

It would be useful if you'd include the exact commands and output you're seeing in your question. If need be, you can try to recreate on regtest / signet / testnet.

I tried to reproduce everything on regtest, but I keep getting "complete": true and no issues like what I'm seeing on mainnet.
The main difference I see is when I do getaddressinfo on regtest it shows I'm using an hd key I believe via:
"desc": "tr([e4b96d59/86'/1'/0'/0/0]d5de651411b49df50bc37a17620755ec019866332794cc3e73a6effbb766aa1c)#kh27dth2",
on mainnet when I run getaddressinfo I see something similar minus the /86'/1'/0'/0/0.

It would seem that the way you import things on mainnet and on regtest differs then.

Yeah, I'm trying to reproduce, I did find another discrepancy though, "isrange": false, on mainnet but true on regtest. What does this mean? I get this after running the getdescriptorinfo command

A tr(WIF) descriptor is not ranged, so that's clearly not what you're doing on regtest

Let us continue this discussion in chat.

When looking at the output of getdescriptorinfo why would
solvable be true but hasprivatekeys be false.
After doing a non ranged tr(wif) import?
Shouldn't they both be true?

This is all impossible to say without knowing what your actual commands are.

bitcoin-cli importdescriptors '[{"desc":"tr(WIF)", "timestamp":UNIXTIME}]'
bitcoin-cli listdescriptors

(grab the desc for the imported wif = "tr(hex)#CHECKSUM")

bitcoin-cli getdescriptorinfo "DESC"

listdescriptors will give descriptors without private key material (the "hex" you state is the public key); that's why it says hasprivatekeys false. But please update your question to reflect all information, with the commands you did, and the responses you get. It's very hard to discuss this via comments.

so.. just working through this

bitcoin-cli createpsbt '[{"txid":"TX_ASSOCIATED_WITH_WIF","vout":INDEX}]' '[{"BTC_ADDRESS":AMOUNT},{ "data": "WHAT_IS_SUPPOSED_TO_GO_HERE?"}]'
I've been putting 00 for data maybe that is incorrect?

Similarly for walletcreatefundedpsbt with the same json parameter. Not sure if 00 is ok. Or how to find out what to put for this.

Whatever you want to go in an OP_RETURN goes there. But again, please update your question with whatever your question has now evolved to be

In the future, especially if you don’t have answers yet, please edit instead of opening a new question.

@Murch thanks for the tip. I edited the original post with most up to date info.

Wrong:  "Further, you need to use PSBT RPCs; the old raw transacrion RPCs in general do not support taproot. – Pieter Wuille Jun 4 at 11:32" . As a matter of fact, Bitcoin Core v. 24 RPC commands like createrawtransaction and signrawtransactionwithwallet support Taproot (P2TR). Also, the goal could be acheived without using any PSBT-related RPC.

There is the example of using the raw transaction RPC commands: https://bitcoin.stackexchange.com/a/117013/135945.

Regularly you'd use walletcreatefundedpsbt and then walletprocesspsbt. But since you've only got two coins in your wallet that you want to sweep you can simply use sendall.
Let's walk through a reproduction of your scenario. I've created two regtest-WIF-encoded private keys:

cRZ9wuYhwKYm82rXfSk9hhc9beJy6p7rV4y3aoAdzqFD6YAUVQcJ (corresponding to 029d759b09cec94b6f2bd322cedd5d136e7f24a4936998fe24da09827d8a12e9dd)
cVFkDn9fS1rwU1SR7geC3rgoGNXLpZXsnrCq2gutYVsGA2FoLpCD (corresponding to 03bd0d0b820dae844107803c9323fe73e81b9adf8abe329930ae9311dab6c3573e)

I'm creating a new wallet and importing a tr() and wpkh() descriptor.
$ bitcoin-cli -regtest createwallet repro_stackexchange
{
  "name": "repro_stackexchange",
  "warning": ""
}
$ bitcoin-cli -regtest -rpcwallet=repro_stackexchange importdescriptors '[{"desc":"tr(cRZ9wuYhwKYm82rXfSk9hhc9beJy6p7rV4y3aoAdzqFD6YAUVQcJ)#uj39yr2v","timestamp":"now"},{"desc":"wpkh(cVFkDn9fS1rwU1SR7geC3rgoGNXLpZXsnrCq2gutYVsGA2FoLpCD)#nayxphlw","timestamp":"now"}]'
[
  {
    "success": true
  },
  {
    "success": true
  }
]

Now i'm sending a coin to each descriptor:
$ bitcoin-cli -named -regtest -rpcwallet=main sendtoaddress address=bcrt1ps66a3wss3l0ay0agnkd57cfu6qrw26z632e0kez0ppjzkyaq0vhskxlrvs amount=0.00042 fee_rate=1
b2e975dee4ab0c68748e85fc847d7ef3fef44f53ee95e4765b1cc2b2c33939d2
$ bitcoin-cli -named -regtest -rpcwallet=main sendtoaddress address=bcrt1q9vsfxgf4t3wmtj9429g539txyv4p2qnuak03sv amount=0.00043 fee_rate=1
e34a3b8116f328d2b1529134dfcc795fbe27eae3991eeb017bc582879cb73b81

We can see that the reproduction wallet got the two coins:
$ bitcoin-cli -regtest -rpcwallet=repro_stackexchange listunspent 0
[
  {
    "txid": "e34a3b8116f328d2b1529134dfcc795fbe27eae3991eeb017bc582879cb73b81",
    "vout": 0,
    "address": "bcrt1q9vsfxgf4t3wmtj9429g539txyv4p2qnuak03sv",
    "label": "",
    "scriptPubKey": "00142b209321355c5db5c8b55151489566232a15027c",
    "amount": 0.00043000,
    "confirmations": 0,
    "ancestorcount": 1,
    "ancestorsize": 130,
    "ancestorfees": 130,
    "spendable": true,
    "solvable": true,
    "desc": "wpkh([2b209321]03bd0d0b820dae844107803c9323fe73e81b9adf8abe329930ae9311dab6c3573e)#k6qfdnw5",
    "parent_descs": [
      "wpkh(03bd0d0b820dae844107803c9323fe73e81b9adf8abe329930ae9311dab6c3573e)#45n94hja"
    ],
    "safe": false
  },
  {
    "txid": "b2e975dee4ab0c68748e85fc847d7ef3fef44f53ee95e4765b1cc2b2c33939d2",
    "vout": 1,
    "address": "bcrt1ps66a3wss3l0ay0agnkd57cfu6qrw26z632e0kez0ppjzkyaq0vhskxlrvs",
    "label": "",
    "scriptPubKey": "512086b5d8ba108fdfd23fa89d9b4f613cd006e5685a8ab2fb644f08642b13a07b2f",
    "amount": 0.00042000,
    "confirmations": 0,
    "ancestorcount": 1,
    "ancestorsize": 154,
    "ancestorfees": 154,
    "spendable": true,
    "solvable": true,
    "desc": "tr([caa3ae90]9d759b09cec94b6f2bd322cedd5d136e7f24a4936998fe24da09827d8a12e9dd)#e2lr407t",
    "parent_descs": [
      "tr(9d759b09cec94b6f2bd322cedd5d136e7f24a4936998fe24da09827d8a12e9dd)#u9ras3xm"
    ],
    "safe": false
  }
]

Now i'll get the transactions confirmed and sweep the coins using sendall:
$ bitcoin-cli -regtest -rpcwallet=main generatetoaddress 1 $(bitcoin-cli -regtest -rpcwallet=main getnewaddress)
$ bitcoin-cli -named -regtest -rpcwallet=repro_stackexchange sendall recipients='["bcrt1qre2fezscuke8qaj9ham2klddj2rt7m4s78tvqq"]' fee_rate=1
{
  "txid": "a39b70bf4636bb78053d10a3bc03eb6866e6777e84aeb274bb4002a543b7bb99",
  "complete": true
}

Let's inspect the transaction. It does indeed spend the two coins from the wallet (one Taproot and one native segwit v0 as you can see from the witness):
$ bitcoin-cli -regtest getrawtransaction a39b70bf4636bb78053d10a3bc03eb6866e6777e84aeb274bb4002a543b7bb99 1
{
  "txid": "a39b70bf4636bb78053d10a3bc03eb6866e6777e84aeb274bb4002a543b7bb99",
  "hash": "be1fcf89ec92649ee0780a8ea86ade1512a7fff6cfc8f75430b1115f1321b8f1",
  "version": 2,
  "size": 298,
  "vsize": 167,
  "weight": 667,
  "locktime": 0,
  "vin": [
    {
      "txid": "e34a3b8116f328d2b1529134dfcc795fbe27eae3991eeb017bc582879cb73b81",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402201e3ba83ca58a357e72d9df4d555f11a747e128ab2131868cb5620afc9b383d540220011c6fe77e37ed8ca83d50870fc5cc3995ecbd1cbd6305ede59bd4fd8aa05c2901",
        "03bd0d0b820dae844107803c9323fe73e81b9adf8abe329930ae9311dab6c3573e"
      ],
      "sequence": 4294967293
    },
    {
      "txid": "b2e975dee4ab0c68748e85fc847d7ef3fef44f53ee95e4765b1cc2b2c33939d2",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "6cd85a806478d00f062e0bd7a43f46d7be082e4287819fcf07d3dda1d6a613a11e1197d15021f87aad16a697e326181d82156ff957fcb6593f5d030f33516471"
      ],
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.00084833,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 1e549c8a18e5b2707645bf76ab7dad9286bf6eb0",
        "desc": "addr(bcrt1qre2fezscuke8qaj9ham2klddj2rt7m4s78tvqq)#5gumgp89",
        "hex": "00141e549c8a18e5b2707645bf76ab7dad9286bf6eb0",
        "address": "bcrt1qre2fezscuke8qaj9ham2klddj2rt7m4s78tvqq",
        "type": "witness_v0_keyhash"
      }
    }
  ],
  "hex": "02000000000102813bb79c8782c57b01eb1e99e3ea27be5f79ccdf349152b1d228f316813b4ae30000000000fdffffffd23939c3b2c21c5b76e495ee534ff4fef37e7d84fc858e74680cabe4de75e9b20100000000fdffffff01614b0100000000001600141e549c8a18e5b2707645bf76ab7dad9286bf6eb00247304402201e3ba83ca58a357e72d9df4d555f11a747e128ab2131868cb5620afc9b383d540220011c6fe77e37ed8ca83d50870fc5cc3995ecbd1cbd6305ede59bd4fd8aa05c29012103bd0d0b820dae844107803c9323fe73e81b9adf8abe329930ae9311dab6c3573e01406cd85a806478d00f062e0bd7a43f46d7be082e4287819fcf07d3dda1d6a613a11e1197d15021f87aad16a697e326181d82156ff957fcb6593f5d030f3351647100000000"
}

Antoine, great thorough answer. I do have a concept question follow up. Can you take any WIF and import it as any descriptor type? For instance if you previously had a taproot utxo/descriptor would you need to make sure that was imported as a tr()? or could you import also as wpkh()?

Antoine, another followup question.
When i run something like bitcoin-cli -rpcwallet=wallet_x2 getnewaddress "label" "bech32m" How do I know it's using the imported tr() descriptor? and not the wallet's generic tr ranged descriptor?

You can use a WIF encoded private key everywhere a key expression is expected.

You can set a descriptor as active when importing it to use it to generate receive addresses (but it needs to be ranged if i'm remembering correctly). Otherwise just use deriveaddresses.


text:
Does miner's reward get added to blockchain
Whenever someone makes a transaction it gets verified by the miners & after that it becomes the part of the ledger. So as a reward miners get a small amount of bitcoin. Now my doubt is the reward that a miner is getting for successful validation, it should also be added to ledger and needs to be verified by someone say 'new miner'. The new miner's reward should also be verified by someone else. And this process of verifying rewards will continue forever.
Is my understanding right or am I missing something?

The miner's reward is verified by every node (you referred to "someone else"). It gets rejected if invalid conditions are contained. The keyword here is "coinbase transaction", and it needs to follow the rules mentioned in the book. This coinbase tx goes into the ledger, if it follows the rules.
Source

Thanks for the link. Precisely it has been answered in the book. Each miner includes a special transaction in his block, one that pays his own bitcoin address a reward of newly created bitcoins

authors: Марина Желтухина


text:
What are all the meanings of the nSequence field?
I know the original purpose of the nSequence field was to hold the transaction in the mempool with the transaction being replaced when the larger value comes and so on up to 0xFFFFFFFF when the transaction becomes "finalized" and ready to be mined and included in the block. Since this is not properly implemented, it is completely disabled in Bitcoin.
Now this field has a different purpose and if you don't want any of that, you just need to set the value to 0xFFFFFFFF. However, if the value is not 0xFFFFFFFF, it is an indicator for different things.
For example, if the most significant bit (32nd, or 31 if counting from zero) is not set, it is an indicator for a relative time lock.
But what if the most significant bit is set, what are the other flags? That is, if the 32nd bit is set (1 << 31)  together with, for example, the 15th or 22nd or 4th bit?
Are there other flags? If so, what are they and any related BIPs about it?
Also, how does the value of nSequence relates to the usage of the nLockTime field?

You are right in saying nodes nowadays do not enforce the original ordering meaning given to the nSequence field, though note this was never implemented as part of block validation (couldn't have been). This was indeed "disabled" but was not a change to the consensus rules. We can say it was only "policy".
However this field was also attached a consensus meaning early on. On October 29th 2009 Satoshi (in commit cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9) made the IsFinal() function consensus critical. This introduced absolute timelock capability through the nLockTime transaction field, which is disabled if all the transactions inputs have an nSequence that is 0xffffffff. See also this question on this topic.
Nowadays, additional meanings were given to this field. Both "policy" and consensus:

Relative timelocks. This is consensus. BIP68 specifies a way of using the first 16 bits of the nSequence to denote a relative locktime either in a number of blocks or as a multiple of 512 seconds. This is only possible if the transaction's nVersion is superior or equal to 2. The type is determined by setting the 23rd bit (in seconds) or not (in blocks). The relative timelock may be disabled by setting the 32nd bit.
RBF. This is "policy" only. The Bitcoin Core client has been refusing unconfirmed transactions replacement if the original transaction's inputs all have their nSequence field set to 0xfffffffe or 0xffffffff. Even if the replacement transaction pays more fees. Note like the original ordering meaning from Satoshi, this cannot be enforced by consensus. And a miner would obviously be incentivized, at least in theory, to not respect this rule. See rule #1 from this doc.

It's also worth mentioning the Lightning Network specifications have been (ab)using part of the nSequence field in commitment transactions to store the (obscured) commitment number.

You said that nLockTime functionality is disabled if any of the transaction inputs has an nSequence that is not 0xffffffff and it is the consensus rule. However, nowhere in the link u left I couldn't see the relation between nSequence and nLocktime. Does this rule still exist? What if I want to enable RBF and put some nSequence different than 0xffffffff? Does it mean that in this case the value of nLocktime won't have any meaning?

You need to look at the definition of the IsFinal method on CTransaction: https://github.com/bitcoin/bitcoin/blob/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9/main.h#L404-L418. It calls CTxIn's own IsFinal method for each input. This method checks the nSequence is 0xffffffff. See https://github.com/bitcoin/bitcoin/blob/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9/main.h#L232-L235.

I am not a programmer. I do not understand the code that much. I posted a new question related to this. https://bitcoin.stackexchange.com/questions/120256/what-is-the-relation-between-nlocktime-and-nsequence

My bad. Brainfart. I wrote this backward: nLockTime is disregarded if all inputs are final. I updated my answer accordingly.

So, if I set 0xffffffff to all input nSequence, I can disable nLocktime and absolute timelock, that is, in this case the value of nLocktime does not have any effect?

Yes, in this case the value of nLockTime would effectively be disregarded.


text:
How to recover and sweep P2PK coins
In an effort to recover some old dust, I've been working on a sweep script to be used on a bunch of old private keys with a little BTC locked inside multiple p2pk utxos.
First I tried using python's bitcoinlib, but after creating and signing the hex, it was rejected on broadcast with
{"code":-26,"message":"mandatory-script-verify-flag-failed (Signature is found in scriptCode)"}
Further investigation concluded that in bitcoinlib "... the ‘pubkey’ lockscript and ‘signature’ unlocking script are ancient and not supported by BitcoinLib at the moment."
Next I tried bitgo-utxo-lib, and again it created and signed hex but was rejected on broadcast with the same error.
Can anyone please point me to a library or method by which I can correctly create and sign a raw transaction which will broadcast without an error? Examples in any common modern programming language appreciated.

Thanks for the info! I was not aware of these RPC methods. I had a little trouble implementing tho.
$ ./bitcoin-cli getdescriptorinfo "pk($privkey)"
 {
   "descriptor": "pk($PUBKEY)#8m2***n6",
   "checksum": "tpd***ym",
   "isrange": false,
   "issolvable": true,
   "hasprivatekeys": true
 }

$ ./bitcoin-cli createwallet p2pk_recovery_test false true
 {
   "name": "p2pk_recovery_test",
   "warning": ""
 }

$ ./bitcoin-cli -rpcwallet=p2pk_recovery_test importdescriptors '[{"desc":"pk($PUBKEY)#8m2***n6","timestamp":"now"}]'
  error code: -4
  error message:
  importdescriptors is not available for non-descriptor wallets

In the end between a friend and I, we got a working script using an mix of bitcoinjs-lib, bitgo-utxo-lib, ecpair and tiny-secp256k1
Link to script at https://github.com/gcharang/nn-return-btc
and posted below for reference
const bitcoinjs = require('bitcoinjs-lib');
const bitcoin = require("bitgo-utxo-lib");
const axios = require('axios');
const ecpair = require('ecpair');
const secp256k1 = require('tiny-secp256k1');

// Set your wif key
const wifKey = "";
// Set the destination address
const DESTINATION_ADDRESS = "";
const ECPair = ecpair.ECPairFactory(secp256k1);
const keyPair = ECPair.fromWIF(wifKey);

// Use bitgo-utxo-lib to get address
let BTC_ADDRESS = bitcoin.ECPair.fromWIF(wifKey).getAddress();

const processUtxos = async utxos => {
    let inputs = [];
    let hex_dict = {};
    for (const utxo of utxos) {
        // Get raw hex of tx from api, and store in dict to avoid multiple calls for same tx
        if (hex_dict[utxo.tx_hash_big_endian] == undefined) {
            console.log("Gettng raw hex for tx: " + utxo.tx_hash_big_endian)
            hex_dict[utxo.tx_hash_big_endian] = await axios.get(`https://blockchain.info/rawtx/${utxo.tx_hash_big_endian}?format=hex`);
        }
        // Add input to array
        inputs.push({
            txId: utxo.tx_hash_big_endian,
            vout: utxo.tx_output_n,
            satoshis: utxo.value,
            rawhex: hex_dict[utxo.tx_hash_big_endian].data
        });
        if (inputs.length == 250) {
            break;
        }
    }

    // Create psbt object (https://thebitcoinmanual.com/articles/what-is-psbt/)
    const psbt = new bitcoinjs.Psbt();
    psbt.setVersion(2);
    psbt.setLocktime(0);

    // Add inputs to psbt object
    inputs.forEach((input) => {
        console.log("Adding input: " + input.txId + " vout " + input.vout);
        psbt.addInput({
            hash: input.txId,
            index: input.vout,
            sequence: 0xffffffff,
            // non-segwit inputs now require passing the raw hex of the previous tx as Buffer
            nonWitnessUtxo: Buffer.from(
                input.rawhex,
                'hex',
            )
        })
    });

    let fee = 1200*(inputs.length); // in satoshis. Tweak this according to current fee rate via https://buybitcoinworldwide.com/fee-calculator/ for <= 48 blocks
    const totalValue = inputs.reduce((sum, input) => sum + input.satoshis, 0);
    // Add output to psbt object
    psbt.addOutput({
        address: DESTINATION_ADDRESS,
        value: totalValue - fee,
    });
    // Sign inputs
    inputs.forEach((input, index) => {
        console.log("signing input "+ index + " of " + inputs.length + " inputs");
        psbt.signInput(index, keyPair);
    });
    // Finalize inputs
    psbt.finalizeAllInputs();
    // Print signed transaction hex
    console.log(psbt.extractTransaction().toHex())
    console.log("Copy the above hex and decode it via https://live.blockcypher.com/btc/decodetx/");
    console.log("If it decodes and is correct, broadcast it via https://blockstream.info/tx/push");
    if (inputs.length == 250) {
        console.log("There is a limit of 250 inputs per transaction. Please run this script again to sweep the remaining inputs.");
    }
}

async function consolidateUtxos() {
    try {
        // Get UTXOs from address
        const utxosResponse = await axios.get(`https://blockchain.info/unspent?active=${BTC_ADDRESS}`);
        let utxos = utxosResponse.data["unspent_outputs"];
        utxos = utxos.filter(utxo => utxo.confirmations > 6) //spend only confirmed utxos
        if (utxos.length === 0) {
            console.log(`No UTXOs found for address ${BTC_ADDRESS}`);
            return;
        }
        await processUtxos(utxos)
    } catch (error) {
        console.error('Error consolidating UTXOs:', error.message);
    }
}

consolidateUtxos();

You can achieve this without any script, simply using the Bitcoin Core wallet. For each public key you received funds on you can import a pk() descriptor containing the corresponding private key, WIF-encoded. Then you can rescan the block chain for the wallet to get knowledge of the outputs paying to you. Finally you can sweep those funds as you would normally spend from a Bitcoin Core wallet.

Let me guide you through an example to achieve this on regtest. Note the WIF encoding differs on test networks, but the process is the same on mainnet. I'll be using the private key cSWVo8YMehg6STxqw6xGgmMJE6Ac6RCJ7owcrBZRAT7QANtyAAEj, corresponding to public key 023ad6336ae257527ff59ec4356fa5d2ac33fff5e04be9e5958dfed9b0100b7948.
First, create a descriptor for the private key and get its checksum using getdescriptorinfo:
$ bitcoin-cli -regtest getdescriptorinfo "pk(cSWVo8YMehg6STxqw6xGgmMJE6Ac6RCJ7owcrBZRAT7QANtyAAEj)"
{
  "descriptor": "pk(023ad6336ae257527ff59ec4356fa5d2ac33fff5e04be9e5958dfed9b0100b7948)#vl2598s2",
  "checksum": "0hjwa0sj",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": true
}

Then create a wallet and import this descriptor:
$ bitcoin-cli -regtest createwallet p2pk_recovery false true
{
  "name": "p2pk_recovery",
  "warning": ""
}
$ bitcoin-cli -regtest -rpcwallet=p2pk_recovery importdescriptors '[{"desc":"pk(cSWVo8YMehg6STxqw6xGgmMJE6Ac6RCJ7owcrBZRAT7QANtyAAEj)#0hjwa0sj","timestamp":"now"}]'
[
  {
    "success": true
  }
]
$ bitcoin-cli -regtest -rpcwallet=p2pk_recovery listdescriptors
{
  "wallet_name": "p2pk_recovery",
  "descriptors": [
    {
      "desc": "pk(023ad6336ae257527ff59ec4356fa5d2ac33fff5e04be9e5958dfed9b0100b7948)#vl2598s2",
      "timestamp": 1681809105,
      "active": false
    }
  ]
}

Then rescan the chain. I didn't have to do this on my end, but you can use rescanblockchain. If you already know the height of the outputs you are looking for i strongly advise you specify a range to speed up the rescan. For instance if you know you've only got outputs between blocks 100 and 150:
$ bitcoin-cli -regtest -rpcwallet=p2pk_recovery rescanblockchain 100 150
{
  "start_height": 100,
  "stop_height": 150
}

By now you should have at least one utxo for at least one of the imported descriptors in your wallet:
$ bitcoin-cli -regtest -rpcwallet=p2pk_recovery listunspent
[
  {
    "txid": "29c3b60341cff26bdce49c3611259ac50cddde4225307c6a130f12abfdb7e22a",
    "vout": 0,
    "address": "myzWnxTFbp4La7uSAK4ppyg45bTw96hQ2S",
    "label": "",
    "scriptPubKey": "21023ad6336ae257527ff59ec4356fa5d2ac33fff5e04be9e5958dfed9b0100b7948ac",
    "amount": 0.00051000,
    "confirmations": 1,
    "spendable": true,
    "solvable": true,
    "desc": "pk([caa89f91]023ad6336ae257527ff59ec4356fa5d2ac33fff5e04be9e5958dfed9b0100b7948)#kmv3ht9h",
    "parent_descs": [
      "pk(023ad6336ae257527ff59ec4356fa5d2ac33fff5e04be9e5958dfed9b0100b7948)#vl2598s2"
    ],
    "safe": true
  }
]

You can then trivially spend the coins from your wallet. For instance:
$ bitcoin-cli -named -regtest -rpcwallet=p2pk_recovery sendtoaddress address=bcrt1pne0s48y6akyw2zd4uzua033u9dxeywxu7wd6fzu3l2dcf7sc3qhsd87l2x amount=0.0005 fee_rate=1
de3c9371404c07493e8c5f43149b91c5c1ed556ebc93ace47617d96026d4902d

If you are using Bitcoin Core version 24 or higher you can also use the sendall command that allows for an easier sweep of all confirmed coins in the wallet since you don't have to set the amount. For instance (with the same value as above):
bitcoin-cli -named -regtest -rpcwallet=p2pk_recovery sendall recipients='["bcrt1pne0s48y6akyw2zd4uzua033u9dxeywxu7wd6fzu3l2dcf7sc3qhsd87l2x"]' fee_rate=1

Note also that i'm using a 1sat/vb feerate on regtest, but on mainnet you want to use an accurate fee estimation instead of this arbitrary value.

Excellent answer. If you’re on a recent version of Bitcoin Core, you could also use the sendall RPC to sweep everything into a new address. You should perhaps explicitly comment on the feerate, as currently the mempool is kinda bonkers.

Thanks. Yeah i started trying sendall and for some reason figured i'd just stick to the familiar sendtoaddress. I've added some comments on using sendall and on the feerate. Feel free to amend if you think it could be clearer.


text:
Can Lightning Network be used for individual small transactions?
Today I went to use shapeshift.io to trade some BTC for IOTA. I only have a small amount of BTC, and I will only be performing a single transaction. Due to congestion on the network coupled with impractical fees the aforementioned operation is infeasible.
My question is, in theory, does the lightning network help me in this situation?
I get that it can help me pay merchants several times without bloating the network/incurring multiple fees, but does it help an individual user in a single transaction like the one above? I feel like I'm missing something, because lightning is supposed to solve both congestion and fees, but in my limited understanding, it seems to do this only indirectly. It clearly would unclog the mempool a great deal, and thereby, because of a decrease in congestion result in a concurrent decrease in transaction fees. Right? But is there a direct application for single transactions not involving multiple small in/outputs like my very real world example above?
Thanks a lot for your responses.

Please rephrase your question title other than "Does Lightning Network solve this?".

What would you suggest?

Well, ask specifically what you wonder LN can solve. Like "Can Lightning Network be used for individual small transactions?" or  "Can Lightning Network be used for non-recurring small transactions?"

Yes, LN would help you directly.
Suppose you have an open LN channel with Shapeshift or are able to route a payment through LN (i.e. you have a channel open with someone else who has channels to other people). Suppose that IOTA also has implemented LN and you have an open payment channel on IOTA. Now when you want to exchange BTC for IOTA with Shapeshift, you would route your payment through LN to Shapeshift and they would then route a payment on IOTA through IOTA's LN to you.
In fact, this could be done as one route with the guarantee that you will get your money and not have to rely on Shapeshift or any other third party. This is known as an atomic swap. LN allows for atomic swaps like this for coins that have LN implemented.
So in this scenario, you don't have to pay a transaction fee to send money to Shapeshift. Instead you paid a transaction fee to open the payment channel which you are using for transacting with many different people, not just Shapeshift.

Thanks! So why hasn't lightning taken off like wild fire? If it really does what it claims, why has it languished for more than three years?

It hasn't been languishing. It is still being developed so it can't have been used yet. Furthermore, the current design of LN (and previous iterations) have relied on Segwit which was only activated 5 months ago.

@AndrewChow, I believe that the LN used multiSig. I read their whitepaper and viewed their conference videos to understand this better. Is the use cases of segwit and multisig the same here? I'm a little confused.

My understanding too is that LN will help, as you say, at least indirectly in this instance. If your goal is to perform only a single transaction with shapeshift.io, then you will have to put that transaction on the blockchain at some point and pay mining fees for it. But if the mempool is less congested, due to the lightning network offloading other transactions from the blockchain, then that will let you perform your transaction faster and with lower fees.
On the other hand, if other people maintain payment channels such that your wallet is able to find a way to route your transaction via one of these channels to shapeshift, then that would let you perform your transaction cheaply through the lightning network.
Incidentally, you would not need shapeshift if you could do a cross-chain atomic swap.


text:
Lost computer with bitcoins
I had purchased bitcoins several years ago.  I installed the version of this software that was available at the time and I think everything was saved on the computer I was using it at that time.  The computer that had my bitcoins on it has disappeared.  I am installing the latest version of the Bitcoin Core wallet now but how would I go about getting my bitcoins back.
I couldn't seem to find an exact answer on how to restore my bitcoins.

to less info to provide precise answer: you don't mention type of OS, nor where you purchased, or which wallet you used (looks like bitcoin core), if you where mining... On unixoide systems, maybe you had a backup of your home directory, then it would contain a folder named ".bitcoin", with a file named "wallet.dat". That's probably all you need... If there is no backup, and you haven't written down the private key, then you are nearly lost. Sure you didn't use an online wallet?

If the computer "disappeared", there is no way to get your Bitcoins other than finding the computer again.
You had a "wallet.dat" file on the there which stores the information necessary to access your Bitcoins. Without it you cannot access your Bitcoins.


text:
How to convert bitcoins to cash
I was informed by the company who sold me my bitcoins machine that I could convert my bitcoins to cash by using a mastercard so that I could make purchases or pay other bills using that mastercard, is this true and how do I do this?  If not, what is the best method to convert bitcoins to cash?

Off topic, but depends on your country is the answer. I've seen a visa: https://bitpay.com/card/

I recommend going on localbitcoin.net and sell your Bitcoins in person. You can also send them to a service such as Coinbase, but I highly recommend doing it in person as you won't pay for a cut.
Here are extra resources to help you throught your situation :
4 ways to convert Bitcoins to Dollars
A guide to selling Bitcoin in person


text:
How to consolidate a large amount of unspent outputs?
I have tried different solutions to consolidate a large amount of unspent outputs, but I am stuck:
1st option: Create transaction using "coinb.in/#newTransaction". But I need private key to create transaction and I am cant find option to export private key. There are steps given on support site for new and classic blockchain.info wallets. But I do not see option of "Private Key" when I click on Manage - More Options.
2nd step: there are some steps showing transfer/sweep funds - which I have tried but it did not work.

To consolidate coins to a single address, just send a transaction for the entire amount stored in your wallet to a new address. You shouldn’t need any outside tools, just use the wallet software to send a transaction to yourself.
You should pretty much never enter your private keys into an online website/service. Access to your private keys could allow that service to steal your coins, there is very seldom a reason you should need to trust someone else to not rob you of your bitcoin.


text:
Besides Bitfinex, which crypto currency exchange(s) have Trailing Stop Loss
I was using Bitfinex until they stopped allowing U.S. clients.
They are the only exchange I know that has a Trailing Stop Loss feature.
Are there any others?
It's very dangerous to ones portfolio to trade cryptos without stop loss functionality if you cannot stay glued to your screen all day long. And a normal stop loss is too rigid to work well in the very volatile crypto environment.

Please don't create multiple new tags in a single question unless you expect them to be useful in categorizing content in the future.

bitmex also have trailing stop-loss.

Kraken have the real deal, where one can set stop-loss based on %, but their trading platform has been a bit unreliable lately.
Bistamp also have trailing stop-loss, but very low on selection of coins.


text:
When do miners include low-fee-transactions?
Are Low-fee-transactions low priority to be included in block?
When do miners include low-fee-transactions?
Do they have their own formula to get priority?
Or just oldest transactions are first?

They will never include low fees transactions before high fee transactions because they have an incentive to mine higher fee transactions before lower fee ones. If they mine higher fee transactions they will make more money. If you make a transaction and pay a $1 fee while the average is $50, it is likely to never be processed. The miner will only process your transaction once there's no more transactions with a fee above $1.

So super low-fee never get block?

No, because the miner has no incentive to waste CPU in order to be poorly rewarded when it can be rewarded in a better way.

"So super low-fee never get block?" It depends on the situation. They are very high at the moment. But they were very low 3-4 months ago. Wait until the lightning-network works and the fees are low again. I made a 550$ transaction 3 months ago with a fee of 0.07$ and it went throguh within 2 days.

Well, a miner can also mine his own transactions. So the miner will probably prefer them, too.

@CedricMartens The CPU consumption is pretty much the same regardless of what transactions are included in the block. The block size however sets a limit so given a choice between low-paying and high-paying transactions it is obvious which will give better payout.

@Alpha On the short term it makes sense for miners to fill up blocks even if it means some of the included transactions pay very low fees. A low fee is still better than nothing. However there may be miners who want to push up fees for gains on the longer term and thus will skip low-paying transactions even if it would have fit in a block they are mining.


text:
Can mining rewards be based on real world data
Is is possible to replace mining as a guessing game where your chance of winning is related to the how quickly your machine can perform calculations compared to how quickly other miners are performing similar calculations with electricity generation data rather than a solution to a mathematical problem to generate block rewards.
Is it possible to have the network generate a unique random number which is assigned to the transaction which records the successful production of a predetermined amount of electricity from data derived from an electricity meter, the electricity meter is attached to a network node and records and transmits transactions (data logs) to the network.
Each energy producer uses a smart meter to record their electricity production a computer with the blockchain installed which is attached to the meter that collects and transmits those transactions to and from the blockchain network, the transactions are validated and do not allow for conflicting transactions, the transactions are put into blocks of up to 2KB or about 70 transactions,  the M.I. devices compute cryptographic hashes until they find a block good enough to count, the block  is then submitted to the blockchain network which earns the energy producer a reward.
Every electricity producer that produces the require amount of kWh of electricity will have the same chance earning a reward as it is a guessing game where your chance of winning is related to the how quickly you produce the electricity, and not how much processing power you have.

It would be difficult to prevent cheating.

This is not really possible: other participants can not provably verify the output of the electricity meter. What if it is malfunctioning or modified by a malicious entity? Proof-of-work has the key advantage of being independently verifiable. Anyone can compute the blockhash and see that it is smaller than the target without any additional information or having to trust anyone.

The electricity meters are attached to network nodes, and this data is transmitted to the network every 5 minutes

The meters are class 1 smart meters ,they communicate every 5 minutes to the energy utilities, any tampering is a criminal offence. Every participant in the system has a smart meter and a computer with a network node that communicates both electricity consumption and production with every other participant in the network on a 5 minute interval

"tampering is a criminal offence" - the whole point of [open] blockchains is to avoid the "call the cops" security model. Sure, if you trust the government and the police to act in your best interest, this is fine, but for the majority of the global population this is a bad security assumption.


text:
how to get address from transaction with empty ScriptSig?
look here https://blockchain.info/tx/d4223672c9043c17a2775abde858778fca38b53152e165757188ab747850770e
why does address start with bc1q... ? Is it some standart?
How can I derive this value from witness?
witness script here:
2 0375E00EB72E29DA82B89367947F29EF34AFB75E8654F6EA368E0ACDFD92976B7C 03A1B26313F430C4B15BB1FDCE663207659D8CAC749A0E53D70EFF01874496FEFF 03C96D495BFDD5BA4145E3E046FEE45E84A8A48AD05BD8DBB395C011A32CF9F880 3 OP_CHECKMULTISIG

why does address start with bc1q... ? Is it some standard?

Yes, it's a Bech32 address, specified in BIP173.

How can I derive this value from witness?

In general, you can't.
The address defines under what conditions an output is spendable. The scriptSig or script witness gives the proof that those conditions are satisfied. If you know that a particular output is a V0 witness, then you can determine what that output was based on the input spending it (the last witness stack element is the public key). However, without knowing exactly what type of output was being spent you can't generally do so.

but how this site derive this particular value?

By looking at the output being spent.

@PieterWuille please tell how to trace transaction via blockchain.info site or any other?


text:
how to verify the first segwit litecoin transaction?
I know than the first litecoin segwit transaction was put to blockchain in 2017/05/10,
and it seem that no signature in witness data,
how this transaction signed and verified?
https://chain.so/tx/LTC/ce385e55fb2a73fa438426145b074f08314812fa3396472dc572b3079e26e0f9
{
  "txid": "ce385e55fb2a73fa438426145b074f08314812fa3396472dc572b3079e26e0f9",
  "hash": "5f866ef62ad40b448090c444e86a3848af7626bb4b9108c0a517a05e9a957898",
  "version": 1,
  "size": 3665,
  "vsize": 994,
  "locktime": 1201535,
  "vin": [
    {
      "txid": "6f45775d5f5b62bdd1527151ddb7f6b19a01bbcb6c3ecebf4c581f11851c1e37",
      "vout": 0,
      "scriptSig": {
        "asm": "002091fb57fbeb6404cb412c104fcfb6bbcbe144884135d260879738f34f97d3d0ed",
        "hex": "22002091fb57fbeb6404cb412c104fcfb6bbcbe144884135d260879738f34f97d3d0ed"
      },
      "txinwitness": [
        "[encoded data, 7112 characters]"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN 736567776974",
        "hex": "6a06736567776974",
        "type": "nulldata"
      }
    }
  ]
}

sha256 of last element must be 0x91fb57fbeb6404cb412c104fcfb6bbcbe144884135d260879738f34f97d3d0ed
witness contains only one element. let us calculate (long lines stripped):
static void test_litecoin ( )
{
  const MyByteArray witness ( QByteArray::fromHex ( "4df501ffd8f[....]8c621ffd9696969696969" ));
  const MyKey32 sha256 ( witness.sha256 ( ) );
  qDebug ( ) << "sha256=" << sha256.toStringRev ( );
}

The output of my simple program is:
sha256= "91fb57fbeb6404cb412c104fcfb6bbcbe144884135d260879738f34f97d3d0ed"
OK, this is correct. Now execute the script itself. write in console the following command:
decodescript 4df501ffd8f[....]8c621ffd9696969696969

The result is (long lines stripped again):
{
  "asm": "ffd8f[...]fd9 ffd8f[...]fd9 ffd8f[...]fd9 ffd8f[...]fd9 ffd8[...]fd9 ffd8[...]fd9 ffd8[...]fd9
          OP_VERIFY OP_VERIFY OP_VERIFY OP_VERIFY OP_VERIFY OP_VERIFY",
  "type": "nonstandard",
}

Seven times script pushes some garbage data and six times runs OP_VERIFY. This script evaluates to true
So, spending from the address 32zyb29Yv4TBUnusDDLZ9kLKT55Fs772JW does not require signing. And verifying transaction does not check any ECDSA signatures

hi @amaclin
why litecoin blockchain can accept this transaction even there is no any signature including in signing process,
Does this mean this type transaction is ANY_ONE_CAN_SPEND and how to sign this transaction with bitcoin-cli? I understand below.
bob want to pay 1BTC to alice, alice show bob the xxxx= has256(garbage data),
and bob send to xxxx, when alice want to redeem this 1 BTC, alice just put garbage data in witness and broadcast it, this is ok.
But if the black hat jack also know the garbage data,Does this mean jack also can spend this input without any signature?

The witness script was known only by creator of address 32zyb.... Yes, today this address is ANYONE_CAN_SPEND because anyone can construct the same scriptSig and witness. Any significant amount from it can be redeemed without any additional knowledge.


text:
Would a memory bound POW facilitate decentralization?
Today I was musing on the complaints that Bitcoin network is too energy greedy and centralized (let's not discuss if this is actually true) and the suggestions that memory bound POW would be improvement for both issues.
My thoughts are that:

regardless of POW mechanism the main cost of mining is operational cost, and operational cost is mostly energy; this is becomes even closer to true assessment as time goes by;
given the above, for the same price (which is mostly demand driven), the same operational costs would be justified, so the same (order of) energy will be spent;
I assume that memory bound hardware to be (much) more expensive than current ASICs (for the same value (as in mined coins) per input energy); this seems to work only for the benefit of HW vendors and increase the threshold for entry, thus working against the decentralization.

In the end (which means after some initial period - exemplified by the raise of ASICs for CPU POW) it seems that we end up with a network that costs roughly the same to the environment, but more centralized because of higher HW costs.
Does this reasoning make sense. Are some assumptions too speculative or outright false?


text:
Are the Mt.Gox markets for different currencies completely separated?
MtGox supports multiple currencies. Usually referred to as f.e. mtgoxUSD, mtgoxEUR, ...
Now, MtGox has different market depth listings for it's different markets and keeps a separate price for them.
Are these markets completely separated, meaning that when I place a buying order in euros, it can only be matched with selling orders in euro? This would also mean that less popular markets inside MtGox, which have less average volume, can have the same delay effects as less volumous non-MtGox markets in let's say US dollars?
So, is it possible that I buy bitcoins with euros and that someone else receives dollars for the coins I bought?

There is only one order book in MtGox. Orders aren't segregated by currency, rather, all prices are relative to the currency with the highest volume (based off The European Central Bank's daily rates). In their own words,

For example, if a buy order for bitcoins is placed in EUR, the order can be executed against another user selling bitcoins in any currency and not necessarily only against another user selling bitcoins in EUR.

That said, wallet currencies are completely separate. There's no converting between them unless you're transferring that value via bitcoins themselves. For example, you can buy bitcoins in a EUR wallet with EUR, transfer them to a USD wallet and sell them in USD. Of course, you have to consider how you'll withdraw the resulting currency.

Do you know what is the exchange rate they are using to compare values of fiat currency?

added that info to my post


text:
Mining algorithm in vb.net
I wanted to convert the following bitcoin mining python code to VB.net (2012) and I tried to convert it's functionality, but it throws some errors and I'm stuck as I even can't get the resulting value of "header" variable.
and the final hash result should be 0000000000000000e067a478024addfecdc93628978aa52d91fabd4292982a50, but I'm no where near that.
why this produces errors, converting from hex to byte is not the correct method?
in python L is used to format it to long right?, so what does the <L & <LLL in the python code do? and is this ::-1 used to prevent overflow when reading the hex string?
and, in exp = bits >> 24 what does it do, bitwise operations?
import hashlib, struct

ver = 2
prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"
mrkl_root = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"
time_ = 0x53058b35 # 2014-02-20 04:57:25
bits = 0x19015f53

# https://en.bitcoin.it/wiki/Difficulty
exp = bits >> 24
mant = bits & 0xffffff
target_hexstr = '%064x' % (mant * (1<<(8*(exp - 3))))
target_str = target_hexstr.decode('hex')

nonce = 0
while nonce < 0x100000000:
    header = ( struct.pack("<L", ver) + prev_block.decode('hex')[::-1] +
          mrkl_root.decode('hex')[::-1] + struct.pack("<LLL", time_, bits, nonce))
    hash = hashlib.sha256(hashlib.sha256(header).digest()).digest()
    print nonce, hash[::-1].encode('hex')
    if hash[::-1] < target_str:
        print 'success'
        break
nonce += 1

The VB.NET code I've been coding up until now is,
Public Class Form1
Dim version As Long = 0
Dim time As Integer
Dim pblock As Byte
Dim mklroot As Byte
Dim header As String
Dim nonce As Integer = 856192328

Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    Textbox1.Text = "2"
    Textbox2.Text = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"
    Textbox3.Text = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"
    Textbox4.Text = "0x53058b35" '2014-02-20 04:57:25
    Textbox5.Text = "0x19015f53"

    Dim n As Int32 = T2.Text.Length - 1

    version = CLng(Textbox1.Text)
    'pblock = CByte(Textbox2.Text)
    pblock = Convert.ToByte(Convert.ToInt32(Textbox2.Text, 16))
    mklroot = Convert.ToByte(Convert.ToInt32(Textbox3.Text, 16))
    time = CInt(Textbox4.Text)

    header = version & pblock & mklroot & time & nonce
    Textbox6.Text = header

   End Sub
 End Class

Chech this explanation..
OR
TL;DR version
Assuming you came accros this site bitcoin-mining-hard-way-algorithms.
I'll show you in C# and you can convert to VB, using the same logic.
Here is the deal:
All information in a bitcoin block is hexadecimal.
So the header you are formming is compounded by:
var header = $"{ver}{prev_block}{mrkl_root}{timestamp}{bits}{nonce}";

Let's calculate each:
ver = 2

Must be converted to a 8 byte hexadecimal, but afterwards must be reversed. ( when reversing a hex string you reverse the pairs so "00-00-02" become "02-00-00";
A simple function to reverse can be as:
string reverse(string hex)
{
   char[] reverted = new char[hex.Length];
   for (int i = hex.Length - 1, j = 0; i > 0; i -= 2, j += 2)
   {
       reverted[j] = hex[i - 1];
       reverted[j + 1] = hex[i];
   }
   return new string(reverted);
}

So:
var ver = 2.ToString("X8"); // Returns a hex representation: 00000002
ver = reverse(ver); //02000000

Then:
prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"

Its the previous block hash of the chain, and must be reversed too.
var prev_block = reverse("000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717");

Then, the mrkl_root is calculated from 99 transaction hashes. The resulting Merkle root is (If you don't know MerkleRoot take a look in this repo: diegomary/bitcoin-merkle-root-netcore):
mrkl_root = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"

And again you reverse it:
var mrkl_root = reverse("871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a")

Then the timestamp is a unixtimestamp to the date "2014-02-20 04:57:25", the timestamp value of that date is 1392872245, so you convert to hexadecimal value 53058B35, and REVERSE IT = "358b0553" (I wont put the code but you get the picture, ^^)
var timestamp= "358b0553";// # 2014-02-20 04:57:25

Then the number of bits as you can see here (https://blockchain.info/block-height/286819), is 419520339, convert to hexadecimal and you get 19015F53; And reverse it: 535f0119
var bits = "535f0119";

The nonce is a arbitrary value that you will iterate over until you get the desired final hash, in this examples was a integer value 856192328. You convert to 8 bytes hexadecimal and reverse it.
var nonce = reverse(856192328.ToString("X8"));

And that's it, if you apply the SHA256 two times over this header will give you the desired result:
var header = $"{ver}{prev_block}{mrkl_root}{timestamp}{bits}{nonce}";
byte[] a1 = Enumerable.Range(0, header.Length)
                     .Where(x => x % 2 == 0)
                     .Select(x => Convert.ToByte(header.Substring(x, 2), 16))
                     .ToArray();
var c = a1.ToArray();
SHA256 sha256 = SHA256.Create();
byte[] firstHash = sha256.ComputeHash(c);
byte[] hashOfHash = sha256.ComputeHash(firstHash);
Console.WriteLine(BitConverter.ToString(hashOfHash).Replace("-", "").ToLower()); //Output: 0000000000000000e067a478024addfecdc93628978aa52d91fabd4292982a50


text:
API for large number of queries to different addresses every few minutes
I have an application that needs to makes queries to get address balances and transaction data from Bitcoin.
What are some possible solutions to this? It would be great if I didn't have to manage a full node if possible.

Host your own node, and run some code that allows you to make these queries to it. If you are handling customer funds this is the responsible thing to do.

You can use a self-hosted (but low-burden!) instance of Esplora.
Blockstream is also exposing an instance for free (at the moment) at blockstream.info.
Disclaimer: if you take part of Bitcoin as an economic actor (as an application providing account balances may imply), you should really consider using your own source of truth and self-host the instance. It's just a docker to start and an nginx reverse proxy to set up after all :-).

i forgot why i couldn't use blockstream.info for whatever technical reason. But is there another alternative? My main thing is checking if there is there a balance at an address and if an address has an outgoing or incoming transaction.

There are APIs at all most famous explorer, on the top of my head: mempool.space (https://mempool.space/about), blockchair (https://blockchair.com/bitcoin/), blockcypher (https://live.blockcypher.com/btc/). That said, the best one I know of is Esplora's one (even though mempool.space is great for Bisq support). I'd be very interested in knowing what you couldn't use BS.info.

I'd be interested in setting this up, but have no idea how or where to begin. If you say it's just a docker and nginx reverse proxy, would you know a more detailed guide or tutorial somewhere? Or specifically, what docker images do I need?