text:
Why does Muun change the fee without permission?
I am using Muun Wallet. I had a total of 10,500 Sats in my wallet.
I sent 10,000 Sats to a BTC wallet. I chose the fee rate of 1 sat/vB (total 220).
So, I was expecting that my wallet would have 280 Sats remaining. But, I see that all my assets are gone now. On the other hand, I expected to see a fee of 220 Sats and a rate of 1 sat/vB on "mempool.com". But, I see that the fee was 646 sats and the rate was 4.11 sat/vB.
Could you please explain to me what happened here and where are the remaining 280 Sats? With this intransparency, can I trust Muun for future larger transactions?!

Can you provide the transaction id? Your numbers do not add up. If you had 10,500 sats and sent 10,000 sats, then there is not enough remaining for a fee of 646 sats.

Yes, I know!!!! Muun is wild! Here is the tx id. I saw that others have raised similar concerns, too: here and here

I sent an email requesting an explanation from Muun and their support service were so kind and gave me a very informative response. Here is their email:

The reason for your transaction paying a higher fee than what you chose is that your transaction had a very tiny change output. When this happens, Muun and many other bitcoin wallets use the extra money to increase the network fee paid to miners.
To fully understand this, you need to be familiar with bitcoin’s UTXO model. I’m happy to share some information on the topic.
Unlike the traditional financial system, bitcoin does not use accounts and balances. Instead, users own pieces of bitcoin called UTXOs.
Every bitcoin transaction is composed of inputs and outputs. Inputs consume an existing UTXO, while outputs create a new UTXO. When you make a transaction, your wallet selects at least one UTXO to spend and creates new outputs. One output will go to the receiver’s address, and the other will return to your wallet to a different address. This second output is called the change output.
If the change output happens to be too small, it may cost more in fees to spend it than it is worth, or, even more, it may not be viable. When this happens, your wallet will use the tiny change output to boost your transaction fee.

Looking at the transaction, it seems that the wallet actually has 10,646 sats. However, in the past, Muun has sent more to users (via swaps) than they are supposed to receive due to minimum amount requirements, and hidden the overage on the client side. It is possible they are still doing that and that is why you only saw 10,500 sats.
When you went to send 10,000 sats, the resulting transaction has a size of 157 vbytes, and with a feerate of 1 sat/vb, the fee should have been 157 sats. It seems that their size estimation is significantly overestimating if they estimated the fee to be 220 sats with a feerate of 1 sat/vb.
With a fee of 157 sats, the change output would have been 489 sats. Although for all segwit versions, this is greater than the dust threshold of 203 sats, it is less than the dust threshold for legacy addresses of 546 sats. A quick perusal of Muun's code suggests that they still check against the 546 sat threshold. Since they thought that the change output would be dust, and therefore make it harder for the transaction to propagate, they chose to discard that remainder into the transaction fee rather than create a change output.


text:
How can I mine PeerCoin?
I was wondering how I could mine peercoin - I already have experience mining Bitcoins and Litecoins, yet I can't seem to find any software where I can mine them - I would like to be able to mine them on my mac with a GPU, so any applications, or terminal commands would be a great help... I already have my Peercoin wallet and everything set up. I have tried CGMiner except in the recent update they completely dumped support for GPU mining.

You can use this simple guide from peercointalk to help you mine on a mac.

Here you're.Peercoin Starter from A -Z. Best guide you can find in the World
http://www.youtube.com/watch?v=XLb4XAiA2P4&list=PLBt4zAxcWonnA8-InWGUEw-UZofHdUIeT

Yes, CGMiner dropped GPU mining support from version 3.8 upwards - you need to get 3.7.0 which still has it and still works like a charm (at least on Windows and Linux). Be careful to check at a profitability calculator if it's worth it - given too many people with ASICs have diverted them for other SHA256-powered coins, you might not cover your costs.
Or you could simply buy some Peercoins in an exchange and leave your client on and connected all the time: the way PPC works, you'll get a small interest on your coins over time (circa 1% annually). Or you can simply buy them, and after 90+ days (or even 1 year) start up your client and leave it connected for some hours - you'd still earn some riskless interest, but less than if you'd left the client on the whole time, as discussed in-depth  in the answers to this question.

source: Stack Exchange

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/

sort: votes


text:
How can I execute `getnewaddress` at my full node from a remote server?
I have a full node running on a digital ocean droplet. I have an app running at heroku, and I want to execute getnewaddress from this app. I'm trying to generate BTC addresses to which users can send payment to for payment processing in my app. How can I do this? Thanks in advance.
My app is in Python, for what it's worth.

I used SSH. Had to do something special with heroku to get it to work though
https://stackoverflow.com/questions/21575582/ssh-tunneling-from-heroku/27361295#27361295

As chytrik said, a better way of generating new addresses on a remote server would be to export an extended public key (xpub) from your wallet and put only the xpub online. Then your private key material would remain offline, and you could generate new child addresses from the xpub using BIP32.
If you still want to execute getnewaddress on your node, you would have to expose the bitcoin RPC by adding server=1 to the bitcoin.conf file on your node in order to accept JSON-RPC commands and call the getnewaddress directly.

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


text:
Does pruning reveal anything private such as one’s UTXOs?
I am writing a hardened Bitcoin node guide and I don’t fully understand the implications of pruning.
My understanding is that when one has a full copy of the blockchain, the node itself doesn’t reveal much about one’s UTXOs given everyone’s transactions are stored on the node (I believe same applies when using electrs).
Does pruning change something from a privacy perspective?

Actually, electrs doesn’t support pruning, but still curious about privacy implications of pruning.

No. The privacy benefit is not because there is a local copy of the full blockchain but rather because full nodes receive and verify all blocks and transactions. This allows full nodes to determine what transactions belong to any wallets it is managing without having to ask anyone else for those transactions specifically. They receive everything, and so can filter what is needed from there. Whether that data is stored does not matter. The relevant transactions are stored in their respective wallets.
Pruning just affects how blocks are stored on disk. It is a node operation detail and not related to the wallet. Nodes with pruning enabled still receive and verify all blocks and transactions, and so any wallets being managed by the node will learn of their transactions. Blocks are still written to the disk - they just end up getting deleted eventually rather than staying permanently.

Thanks for helping out… what if someone has access to data on node… can person determine which addresses are monitored by wallet such as Electrum? My understanding is that if node is not pruned, this is not possible.

@sunknudsen You seem to be under the impression that pruning only removes things unrelated to the wallet. That is not correct. It removes all old blocks, regardless of whether they are relevant to the wallet or not. The wallet keeps its own copy of transactions that are relevant to it, unrelated to whether pruning is enabled or not.

@PieterWuille Naive question… if node is pruned, one cannot sync an Electrum wallet that relates to pruned blocks right? What happens if one tries to?

Electrum nodes need an Electrum server, not a node. It's up to that server what it indexes or not, and unrelated to whether the node(s) it fetches its data from prune or not,

@PieterWuille Asking in the context of one running Bitcoin Core and electrs on same machine. Guess answer is one simply cannot enable pruning as implied here.

I see; I'm not familiar with the internals of any of the Electrum servers, but certainly they can require non-pruned nodes in order to function. Still, the point holds: pruning is entirely independent of state of the wallet of the Bitcoin Core node.


text:
What are the potential causes for the "block not found on disk" error?
We run several bitcoin core nodes and load balance requests across them all.
We occasionally hit the error "Block not found on disk" shortly after a new block gets confirmed, when looking up the contents of this new block. The error generally disappears when we retry after a few seconds.
Should I be worried about this error, or is it expected, since we are load-balancing requests across multiple nodes? My thinking is that possibly one of our nodes has seen the block and downloaded all of its contents, but another one of our nodes has not yet (and therefore throws the error)

Are you asking for a block B from node N before node N has announced it has received block B? Obviously multiple nodes in a network cannot be guaranteed to learn about the same information at the same time.

Yes that is what I believe is happening. Likely the situation is exactly as you have described... I'm mostly asking the question to confirm that in this situation, the error "block not found on disk" would be expected, and not a cause for concern


text:
Why do we often see 2 blocks mined within a few seconds of each other?
This seems to happen far more frequently than one would expect from a Poisson distribution with a ~10 minute mean. Am I just bad at statistics or is something else going on?

Upvoted, it'd be interesting to see the probability of, for example the next block being made in under a minute. (I think that has the probability of 0.095 according to this, with the help of RC's blog though I'm not knowledgeable enough to write an answer.)

Is your "this seems" based on calculations, or just a guess?  If calculations, would you like to share them?

I haven't done any calculations, just a guess from something I noticed. Would be interesting if anyone felt inclined to put together some actual numbers

I can produce some statistics based on the block timestamps if it would be of interest, but given that they do not necessarily correspond to the time at which the blocks were mined or broadcast, I don't know if that would be helpful.

is something else going on?

Maybe.
AFAIK Mining nodes don't synchronize time. Timestamps in blocks are not accurate. You cannot tell the elapsed time between two blocks by looking at timestamps in those blocks.

this may happened when the two consecutive blocks belongs to the same miner and the second block is normally empty.
460564 AntPool 0 minutes
460533 AntPool 4 minutes
460501 BTC.TOP 6 minutes (460502 BTCC full block right after)
460445 AntPool 1 minutes
460432 F2Pool 0 minutes
460308 GoGreenLight 3 minutes
460281 AntPool 3 minutes
460238 AntPool 1 minutes
460218 1Hash 10 minutes
459932 AntPool 1 minutes
https://criptomonedaseico.com/en/news-en/proof-of-nothing-why-bitcoin-miner-propagate-empty-blocks/


text:
Can two bitcoin chains co-exist if one copied the code and ran a parallel chain?
If someone forked the code without changing any of the fundamental properties and connected nodes / miners, could they not disrupt the main (original chain)?

What exactly would they change?  What do you mean by "disrupt"?

I agree with Nate, you'll need to be more specific what remains the same and what changes to be able to get a good answer. For example, do you count the "Genesis Block" among the fundamental properties? Does the forked version use different ports, network magic, etc.?

if the forked nodes are able to communicate with original nodes (for block propagation), and the rules are all the same, then you would be on the same chain.

So what I mean is this, Bitcoin in its current form running chain A, then someone comes along and runs a new version but from the genesis block again, so from 0 TX onwards without previous history. Would this not upset the current chain if the nodes connected to the same network or would the existing nodes simply reject it ?

Full nodes would simply follow the best chain, which means that they would ignore this new chain and end up on the existing chain.

Yes, this is currently happening.  There are many different implementations of the Bitcoin protocol.  You can see here the a graph of how many people are currently using different implementations.

running a different implementation does not necessarily mean that you have a different chain.

thanks this is helpful. I am researching for an article and just want to cover my bases. kudos.


text:
How can I generate a bitcoin address?
Is there any way to generate bitcoin addresses  other than the Blockchain API? (given the fact that it is not public)

I wrote a long and detailed tutorial on it http://procbits.com/2013/08/27/generating-a-bitcoin-address-with-javascript
In short, scroll all the way down to the summary to see this short version:
var randArr = new Uint8Array(32) //create a typed array of 32 bytes (256 bits)
window.crypto.getRandomValues(randArr) //populate array with cryptographically secure random numbers

//some Bitcoin and Crypto methods don't like Uint8Array for input. They expect regular JS arrays.
var privateKeyBytes = []
for (var i = 0; i < randArr.length; ++i)
  privateKeyBytes[i] = randArr[i]

var eckey = new Bitcoin.ECKey(privateKeyBytes)
eckey.compressed = true
var address = eckey.getBitcoinAddress().toString()
console.log(address)// 1FkKMsKNJqWSDvTvETqcCeHcUQQ64kSC6s

var privateKeyBytesCompressed = privateKeyBytes.slice(0) //clone array
privateKeyBytesCompressed.push(0x01)
var privateKeyWIFCompressed = new Bitcoin.Address(privateKeyBytesCompressed)
privateKeyWIFCompressed.version = 0x80
privateKeyWIFCompressed = privateKeyWIFCompressed.toString()

Open up the JavaScript console on the page (in your browser) and follow along. You can create your very own address right there in the browser. I wouldn't recommend using this newly created address to actually conduct commerce. Just use it as an academic exercise.

I wouldn't recommend using this newly created address to actually conduct commerce. Just use it as an academic exercise. Why do you say that? Are there any risks associated with this method (as I intend to use it for generating personal cold-storage keys)

Yes, generating a private key in the browser where other scripts/plugins may have access to the keys puts your money at risk.

Gotcha, but I can use my own personal Javascript IDE or something just fine. Just wanted to make sure there wasn't a potential risk with the code itself (as opposed to the environment) Thanks for clarification

There are a number of sample programs here: https://bitcointalk.org/index.php?topic=1026.0
Also see the wiki for the step-by-step algorithm for generating a valid address.

There are plenty of very easy-to-use tools that can generate addresses for you, the exact process is detailed in the Bitcoin wiki.
Some examples of such tools are:

BitAddress.org
BrainWallet

Coinbase Your wallet on Coinbase is a collection of bitcoin addresses. New bitcoin addresses are automatically generated for each payment on Coinbase and stay associated with your account forever (so it is safe to reuse them).

I meant programatically, that's why I mentioned the blockchain API. And here you are giving me your "referral" link to coinbase.

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


text:
Where are rewards sent when using `bitcoind submitblock N`?
Where are the rewards sent when using the submitblock function in the case the block is okay?

The payout address that subsidy/fees are sent to is part of the block itself. The very first transaction in every block is called the coinbase transaction. This coinbase transaction has no inputs (it implicitly receives the subsidy and fees of the block) and its outputs define where these new coins are sent to.
So the answer is simply: the rewards are sent wherever the block says they go. This has to be decided before submitblock is invoked. In fact, it has to be decided before mining can even start: as the coinbase is part of the block, modifying it would invalidate the block's proof of work. This also prevents other parties on the network from changing the block to pay them instead.

Ok, thank you. But it's not very clear to me. If I use bitcoin-cli with the submitblock function, how can I specify my wallet address for receiving the rewards if the block is ok ?

You can't specify it. It's something you have decided before you started mining. The mining software and/or hardware you used to build the block needs to be aware of the payout address.

@InvestDataSystemsFR If you could specify the wallet address after making the block, what would stop someone from taking your block after you submitted it and changing the reward address?

Ok, so if I understand well, the reward bitcoin wallet address is in the data submitted with submitblock (coded in the block sent), isn't it ?

Yes, that's correct. The block you submit already has its own payout encoded in it. It's added there by the software you used to mine it in the first place.

Thank you very much ! I'll try to find some pieces of source code that can do that ;)


text:
What is prepended to the front of a ScriptSig and ScriptPubKey of a P2PKH transction?
In some educational materials on bitcoin P2PKH transactions, I'll see 2 digits included in the front of what would be considered the ScriptSig. For example, what is the 8b in the front of the ScriptSig below representing?
8b483045022100a8205f5879952c6a931affae66519c4a4bda0d912dd166d89e7b671efddfd01e022071a6cf9f3f72c61395ea98c5b23606b9a7d4d5aac97b84a3622beeded49ee40a014104f6209daa9543327eb5b7b2ac0b63089af69abad5b14f4b6cfec5c18279848fa214933decd49c1ca1efe03af8f44b5584b1af8eae6a31a95921bba07e5bf78f90

The same with the format of the ScriptPubKey...what is the 19 representing in the front of the ScriptPubKey below?
1976a914b58515a69527c806fd404d3d4aa490d56692310b88ac

In the serialization format, the input and output script are introduced by announcing the length of the script.
So that 0x19 indicates that the length of the scriptPubKey is 76a914b58515a69527c806fd404d3d4aa490d56692310b88ac is 25 bytes, and 0x8b indicates that 483045022100a8205f5879952c6a931affae66519c4a4bda0d912dd166d89e7b671efddfd01e022071a6cf9f3f72c61395ea98c5b23606b9a7d4d5aac97b84a3622beeded49ee40a014104f6209daa9543327eb5b7b2ac0b63089af69abad5b14f4b6cfec5c18279848fa214933decd49c1ca1efe03af8f44b5584b1af8eae6a31a95921bba07e5bf78f90 is a 139 bytes.


text:
Where can I find the list of all possible sendrawtransaction RPC error codes & messages?
Where can I find the list of all possible sendrawtransaction RPC error codes & messages?
Such as this:
{"code":-22,"message":"TX decode failed. Make sure the tx has at least one input."}

The code for the _rawtransaction RPCs is in /src/rpc/rawtransaction.cpp including your example of the "TX decode failed" error message.
If you do a Ctrl-F or git grep in that file for JSONRPCError you'll see some of the other error messages but that may not be an exhaustive list.


text:
Why is little endian used in transaction formatting and other parts of bitcoin?
I've noticed just from studying the raw hex values of transactions that many components are formatted in hexidecimal little endian.
For example, the amount specified in an output will be formatted as b6f5050000000000 instead of 0005F5B6, which represents 390,582 satoshi.
To be honest, I have a basic general understanding of big-endian vs little-endian but why is the little-endian format used? And why not just use the normal hex string format like 0005F5B6 in the example above?

Does this answer your question? Why does the Bitcoin protocol use the little-endian notation?

The replies on this thread and from the link you sent me both give me a better understanding of it. And it does seem like it has more to deal with lower level programming which I am not an expert in. Nonetheless, good education for myself.

To add onto RedGrittyBrick's answer, little endianness is a result of using little endian CPUs, and then sending data as it is stored in memory.
On little endian architectures, integers in memory are stored as little endian. When preparing messages to be sent over the network, Satoshi's serialization functions would simply copy the memory directly, thus inheriting the way that such data is stored in memory.
I believe the only exception to this is the uint256 implementation which is used for storing all 256 bit hashes. This appears to be deliberately written to interpret these integers as little endian.
Otherwise, the 0.1.0 client was written in a way that would not have been compatible with big endian architectures. If it were compiled for and ran on a big endian CPU, I think it would incorrectly deserialize integers. However the endianness used in the vast majority of computers is little endian, so this was unlikely to have caused an issue, not to mention that Windows isn't available on any big endian architectures anyways.

It is probably because Satoshi Nakamoto was sometimes rather careless.
It is a deviation from established standards that I would say has no sufficiently good reason in this particular case.
Just as interoperability among different Bitcoin node implementations is guided by Bitcoin Improvement Proposals (BIPs), interoperability among computers on the internet is guided by a system of Requests For Comments (RFCs). It seems likely that the BIP process was loosely modeled on the earlier RFC process.
RFC1700 by Reynolds and Postel in 1994 says

When a multi-octet quantity is transmitted the most significant octet is
transmitted first.

That is to say that "Network Order" is big-endian.
Computer hardware (the CPU etc) can be little-endian or big-endian. An application running on a little-endian machine is expected to translate to and from big-endian when communicating over the Internet. networking libraries provide for this. Most network protocols and applications do this.
Satashi Nakamoto failed to do this properly.

I should probably add that clumsy mortal imperfect heroes are still heroes.

There is a very obvious good reason. Byte order conversions take time and the vast majority of computers impelementing this protocol are little-endian.

There isn't any other reason for use of little-endian format than just the agreement made among programmers who implemented it. Bitcoin would have worked equally well with big-endian format.

As far as I know Satoshi never explained why both big endian and little endian are used in the Bitcoin protocol. Some of the reasons for using little endian generally are discussed here but I don't know to what extent they apply to its usage in Bitcoin.


text:
What is the use of longest chain consensus rule?
I want to know Couldnt a chain be hardcoded in the bitcoin rules itself? Only so and so chain can be used. During the early days of bitcoin, I know a small group of enthusiasts were miners. And they helped the blockchain takes its initial steps. Assuming that to be the case for a new blockchain, with trusted people in the beginning and with the additional component of hardcoded singular blockchain. What problems might this face?

Hi Tejush Singh, I see a few possible interpretations of your question. Are you asking 1) whether we can know in advance what the block hashes of future blocks will be? 2) whether we can come up with rules that prevent multiple blocks at the same height to be found? 3) what issues a permissioned blockchain with a pre-defined set of authors would have? Could you perhaps clarify your question?

Basically what if only one chain is ever allowed to exist, is that possible?

It is not possible to prevent the existence of two chaintips at the same time while maintaining the current characteristics of Bitcoin's network.
Blocks are found through a random process. Since information is not directly disseminated to all other participants, but propagated through a gossip network, it takes a few seconds for the announcement of a new block to reach all other network participants. Occasionally, two miners will each find a new block at the same height at almost exactly the same time such that neither has heard about the other's block yet. If the network rules prevented more than one chain from existing, each side would be right to say that their chaintip came first and must be the correct one—the network would permanently split.
In business, this problem is often resolved by a centralized coordinator or quorum of decision makers. Bitcoin is a scale-free network in which each node has the same power level as any other. Introducing a central coordinator or privileged block authors would drastically change the security model, introducing central points of failure and undermine censorship resistance. This approach is prevalent in permissioned blockchains developed for various business use cases (and also for one of Bitcoin's test beds, the Signet).

Thanks. This gets to the heart of the question. I will look further into permissioned blockchains to get a good grasp of the concept.

What if there are competing chains that are valid according to the same rules? It could be as simple as 2 versions of next block: one has 1000 TXes, other has removed 1 and has 999 TXes, which one is "real"? Which one should the network extend?
Longest chain rule settles that, resolving which chain is real among competing chain tips that follow the same rules: the one with more chainwork is "real", while the other gets "reorged".

Basically what if only one chain is ever allowed to exist, is that possible?

That's what "reorgs" do, they eliminate other candidate chains that are built according to same rules. If rules are different then that results in multiple cryptocurrencies and nobody can prevent someone from running a network of other chain's nodes. Your node only specifies what you yourself will accept, it has no power over others. But then again, you can just ignore other chain's nodes, since they have no power over you.

Couldnt a chain be hardcoded in the bitcoin rules itself? Only so and so chain can be used

A chain is "hardcoded" into the bitcoin rules. The rules specify the chain with most "work". That's the only chain that can be used. Your "so and so chain" is the "longest chain" - in the bitcoin context meaning "chain with most work".
You are making an unusual use of the term hardcoded. Normally it brings to mind fixed data in the source code, but of course the blockchain is ever growing data and so can't be hardcoded as a fixed constant in the source code. I interpret your meaning as saying the choice of chain is unambiguously determined by the fixed rules built into every single copy of every Bitcoin wallet software.

with trusted people in the beginning

The primary goal of Bitcoin's creator was to create a system of cash where two people could transact without any need for a trusted third party. Bitcoin allows you to make a payment to a second person without any need to ever trust anyone else.

What problems might this face?

The problem with trust is betrayal. usually springing from lack of deep knowledge, understanding and rigorous monitoring of those trusted. Consider the fate of those who trusted Sam Bankman-Fried and had money in FTX, or those who trusted the owners of MtGox, Quadriga-Cx and many others.


text:
Wallet not getting loaded with Multibit
Why is it giving me this error and not receiving my bit coins?
The system cannot find the path specified ".org.multibit.file.WalletSaveException"
Cannot save wallet 'C:\Program Files\MultiBit-0.5.15\null\MultiBit\multibit.wallet'
Created wallet "C:\Program Files\MultiBit-0.5.15\null\MultiBit\multibit.wallet".
Could not load the wallet file "C:\Program Files\MultiBit-0.5.15\null\MultiBit\multibit.wallet".

Checkout pywallet. Its a python script that may be able to help you out by recovering your private key. I've had similar issues with Multibit in the past. Is your wallet encrypted?
https://github.com/jackjack-jj/pywallet

Check out the trouble shooting page. https://multibit.org/en/help/v0.5/help_troubleshooting.html
If you can get to the wallet file in terminal window or file browser, move it to a location that doesn't have null in it. null in a file path seems strange.


text:
What unusal behavior would alert school's system administrator from mining bitcoin?
I work in a lab and I have full access to the lab. I often leave my old laptop in this lab to do computational stuff (for lab or for my own stuff). If I want to mind bitcoin using this setup, what unusual behaviors will alert the administration of the school's network? Will there be a huge outgoing traffic? Does it require some ports to be opened?

I know it doesn't answer your question, but: don't do that.
Time to mine on regular computers, even with strong GPUs, is long gone. If you don't have powerful ASICs, forget mining at school computers.

What's the reason? Does this have any relation to the price?

It has a relation to the mining difficulty. More powerful computers are mining, the more hard it is to mine. Right now, ASICs - chips, that can do nothing else but mine bitcoins - are made by large numbers. You cannot compete with them with general purpose computers.


text:
How do difficulty, hashrate, and network hashrate fit together?
I understand that there are multiple terms for the idea of how hard it is to successfully mine BTC. The terms I have seen are "difficulty", "network hashrate" and "hashrate". I am not entirely sure what the differences between these are.
On my computer, I can call SHA256 on a string. How many such input strings would I need to try right now before I would get lucky enough to successfully propose a block? And this number of tries, how is it related to "difficulty", "network hashrate" and "hashrate"?

To create a new block, miners have to construct a block and, from that block, calculate a number using a mathematical function called a hashing function. The calculated number is called a hash. If the hash is bigger than the current network target, the miner changes the constructed block, for example by choosing a different number for  a part called a nonce, and recalculates.
The hashrate is the number of hashes that can be calculated in one second. There is a hashrate for each mining device and a total hashrate for the whole bitcoin network
If there is too much mining power, new blocks could be calculated too fast for the other bitcoin wallets to keep up. So the difficulty is increased by making the target smaller
To find a block whose hash is less than the target you might need to try hashing 9223372036854775807 different blocks on average or you might get lucky on the first try.

@claris: The current difficulty corresponds to a hashrate of 111.3 EH/s, which should put the average count of hashes per block at about 66.7*10^21.

@Murch thank you, that was a very useful comment


text:
Cheating ASICs and Mining Software
I've noticed the recently solved block hashes have started with a number of zeros (8 last time I checked). Couldn't we just tell our mining hardware/software to assume the first few digits are in fact zeros and give us a head start?

All block hashes start with a certain number of zeroes by design. The nature of a hash is that knowing something about the output does not help you figure out what the input is supposed to be (at least in theory). So in short, no.


text:
Move bitcoin data from Windows to Mac
Is it possible to move the Blockchain data from Windows to Mac? The wallet on windows is synced, the one on mac is not. The wallet on Mac has had some bitcoins sent to one of its addresses. Would it be safe to copy the blocks and chainstate folder to the mac from windows without losing the bitcoins?

The blocks, chains, and all that excessive data can be tossed. All you need is your wallet.dat which contains your private key.
I like to think of it this way... The bitcoin network is like a massive bank full of billions, trillions, and so on of vaults. You can put coins into any vault without needing a key to that vault. You can only take coins out of a vault IF you have a key to that vault (your wallet). Your coins are never stored on your actually computer. Only the KEY to the vault is stored on your computer. That key is used to access your coins. Downloading the blockchain is simply a way of letting your bitcoin client know how many coins you have, who you sent coins to, and who sent coins to you. Its like a virtual copy of those billions of vaults, which mostly all you don't have access to. Only that vault whose key you possess. Good luck!

If your goal is to avoid re-downloading the entire blockchain from the public internet, and you need a full node running/synced on a separate machine, then:
For the sake of example, machine1 is up-to-date and fully synced.
machine2 is not up-to-date, but you want to get it to a fully synced state ASAP over your network.
Ensure that TCP port 8333 is open on machine1's local firewall to, at the very least, the IP address of machine2.
The Bitcoin client should be running on machine1.
On machine2, start the Bitcoin client (e.g. bitcoin-qt) with the -connect parameter.  That parameter will cause the client to connect only to the IP address specified.  For example:
bitcoin-qt -connect=aaa.bbb.ccc.ddd

Where aaa.bbb.ccc.ddd is the IP address of machine1.  (Of course, specify any additional parameters that your configuration may require.)
Thus machine2 will catch up to machine1's state at LAN speeds (assuming you're connecting via a LAN;  It'll work equally well over any sort of connection that allows TCP port 8333, of course).
This seems to be best practice from what I gather, and obviates problems with mis-matched versions of Bitcoin clients, corrupt/partial copies, incorrect permissions, a lengthy chainstate index rebuild time, etc.
At any rate, I'm doing this right now and the "estimated time left until synced" from scratch is now 3 hours over the LAN instead of 11 days over the internet.
Edit:  To avoid losing any Bitcoins, backup wallet.dat on both machines.  That file is the key to your Bitcoins, as it were.  Without that file (or a copy), your BTCs are gone.
If your concern is merely to be able to use your Bitcoins on another machine, you can move wallet.dat between machines, and/or swap wallet files on the same machine.
Just ensure that if you have two wallets with currency in them you don't overwrite one with the other.
Before doing anything at all, backup both wallets to a couple of USB sticks and keep them somewhere very, very safe.


text:
How do nodes validate that a UTXO in a new transaction is unspent?
Does it check every block in between where the UTXO first appeared and the current time to make sure it didn't get spent then? Or is there some other caching or other method to make the check faster?

Does it check every block in between where the UTXO first appeared and the current time to make sure it didn't get spent then?

Yes, but this check is not done for each UTXO individually as transactions come in, it is an ongoing process that specifies the current state of the network.
A bitcoin node will independently work through the entire transaction history of the network, and while doing so it will build an index of unspent transaction outputs (UTXOs), which are, as the name suggests, transaction outputs which have not yet been spent, and thus are valid to be spent on the network. As new outputs are created, they are added to the UTXO set. Likewise, when a UTXO is consumed as input to a transaction, it is removed from the UTXO set. So any valid new transaction must specify one or more of these UTXOs as inputs (with the exception of coinbase transactions, which do not have any inputs).

Full node may build the UTXO set 6 blocks behind to cater for possible orphaning. 0.5% rate as off 2019 (I think). Example
Let said currently is Block 500,006
The full node will do the UXTO index from Block 1 till Block 500,000
Block 500,001 till 500,006 is left untouched because these blocks has a high probability of orphaning.
Once orphaned, it quite messy to redo the index. May as well just wait for it to be stabilized first with 6 blocks of PoW.
To search the UTXO set, it searches the UTXO index, if you cannot find it will search block 500,001 till 500,006. If still unfound, then the UXTO is non-existence yet.


text:
How to derive the Private key when the two the nonces are k and k*2
Is the same private key using k and k*2 respectively in two different signatures vulnerable?
If yes How to calculate the key in this case
Here is an example, Both signatures are valid and the nonce of r2,s2,z2 is double the first signature's nonce, how do I calculate private key from these two signatures?
r1 = 0xdcf17de661e280dbf62e03ef1655d1baaabc301da9fc6b29a63e52e7780c115d
s1 = 0x20be91ddd5598e22fa43014172df5312275fbdb462a2e9855c7a7433138a4a9c
z1 = 0xbb1e00d2027efd3085b83de2a3602a8ea49e0c9d5b821cd6291d5feefd410303
r2 = 0x5baeea47c4d1759efc2b4a6a1948727648a7f9d0db6c77c09b0a26a0ae22d4ad
s2 = 0x4f08689cd10e8fd5e9be108d18e2ee582774dc409176643800284669d6e787eb
z2 = 0x0fa25a9a0712366012de680bed93f8c94ffa2c119464d1e59b0a03b1c115b54f

Are you using the RFC6979 standard for deriving k?

How to do that ?

Read the RFC: https://datatracker.ietf.org/doc/html/rfc6979

I've rolled back the edit of the question post to return it to the question. Please refrain from disparaging other users in posts.

c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e is the nonce for the first rsz set.
a3c2dce777813dc3f0d7a105a5fd56d5894ba30ffa01ba79667cadba37a9d8df is the private key.

I don't see how you can compute this based on the information in the question. Can you elaborate on the technique you used?

I think someone put together this question or a challenge somewhere else to lead up to this kind of reveal. The "nonce" value c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e appears in multiple blog posts about "hacking bitcoin wallets".

The private key posted here previously appeared in this stack exchange post before: https://bitcoin.stackexchange.com/q/37740/5406

Assuming you're talking about ECDSA signing. For BIP340/Schnorr signatures, see this answer.
For valid signatures
Let:

d: the private key
P=d*G: the public key
k1: the (first) nonce
R1=k1*G: the public first nonce
r1=R1.x mod n: the public first nonce as it will be encoded in the signature.
k2=2*k1, R2=k2*G=2*R1, r2=R2.x mod n: the same for the second nonce
z1 and z2: the respective message hash

The two signatures will then be the pairs (r,s) and (r',s') for which:

s1 = (z1 + r1*d) / k1 mod n
s2 = (z2 + r2*d) / k2 mod n = (m2 + r2*d) / (2*k1) mod n

Multiplying both sides of the equations by their denominator on the right hand side:

s1*k1 = z1 + r1*d mod n
2*s2*k1 = z2 + r2*d mod n

Assuming 2*r1*s2 ≠ r2*s1, this is a set of two linear equations in two unknowns (k1 and d), with solution:

d = (z2*s1 - 2*z1*s2) / (2*r1*s2 - r2*s1) mod n
k1 = (z2*r1 - z1*r2) / (2*r1*s2 - r2*s1) mod n

Don't ever use related nonces for ECDSA (or Schnorr) signatures. Create a fresh, independent, nonce every time. The industry standard is to generate nonces using RFC6979.
For fake "signatures"
The values you've provided however do not correspond to real signatures, despite satisfying the equation. That's because for a signature to be valid, you have to give the messages which hash to the z values, not just the result. And you can't do that here, because z2 = (r2/r1)*z1. Such matching ratios will not (and cannot) occur for z values that are the result of hashing.
It turns out that given any ECDSA triplet (r,s,z), and integer a, another triplet can be found. Let R be an elliptic curve point whose X coordinate equals r (mod n), and R' = aR, and r' the X coordinate of R'. Then (r',r'*s/(a*r'),r'*z/r) is another ECDSA triplet, corresponding to multiplying k with a. However, again, this is not a valid signature because its z value will not be the hash of a computable message. And the formula above will also fail to retrieve the private key in this case, because the second "signature" wasn't created by using the private key.

Thanks for your answer, I edited the question and provided the example , Have a look and if you answer according to that it will be easy for me to understand

I've updated my answer. Your input values don't correspond to actual signatures, and you cannot recover the private key from them.

pk = ((k1 - modinv(s2, n)*k2 + modinv(s1,n)*k1) * (modinv(modinv(s2,n)*r2 - modinv(s1,n)*r1, n)) % n)
,Is it possible to rewrite it
based on the k and k*2 rule

Sure, just substitute k2=2*k1. But you'll find that for the specific numbers you've given above, the formula you get doesn't let you compute the private key (you get a division by zero).

but z can be just 2 or so. like in eth. say id of the method. then this becomes possible

authors: Алексей Неудачин


text:
Power outage during Bitcoin Core initial synchronization
I had a power outage when I was half way through my Bitcoin Core initial synchronization. Is there a way to pick up where it left off or do I need to start over?

What happened when you started Bitcoin Core again? Did you get any error messages?

The first time it wanted me to install bitcoin core again. I rebooted and started it again, this time it picked back up and seemed to be ok but I haven't checked it since last night.


text:
What tools can I use to create and replace RBF transactions?
I'd like to create transactions within my python application, that support replace-by-fee RBF (BIP125).
Apparently, if I want to be able to replace my transaction later on, I need to signal that already in the first transaction. I saw that I'd have to do something with the sequence field for that, but I didn't quite understand it.
Is there any library that would help me with that, or do I need to craft this transaction manually, and if yes, how?
Sorry for being so vague, but this RBF-stuff is giving me a hard time.
Reading the answer to the question What restrictions are there to the application of opt-in RBF?, is only confusing me more.
Why would setting the sequence number to MAX-1 mean 2 things at the same time (transaction uses locktime and transaction is replaceable)?
What if I don't want to use locktime but only make my transaction replaceable?


text:
Can we benefit from Collatz conjecture-based proof of work?
Can we benefit from Collatz conjecture proof of work to enhance bitcoin utility?
F Bocart 2018:"Inflation Propensity of Collatz Orbits: A New Proof-of-Work for Blockchain Application" argues that Collatz conjecture-based proof of work will provide a greater number of nonces than SHA256.
The paper also provides a python script example, based on the bitcoin Genesis block.
This script was the tested by H Mousa 2019 paper titled: "Performance Evaluation of Proof-of-Work and Collatz Conjecture Consensus Algorithms", the paper argues that the transaction using this method can "takes only (1/1000) th of the execution time that is required for PoW".
I think that a two-way pegged offchain utilising such a method can benefit the bitcoin network.

The second paper linked above seems to have a lot of inaccuracies/misunderstandings, and non-standard terminology. Its kind of tough to make sense of.

I believe that paper to be misguided.
The properties a good proof-of-work function needs are:

Committing to blocks. The contents of a block should be a parameter that goes into the PoW, in such a way that altering the blocks invalidates the PoW.
Cheap to verify. Just for performance of validators/nodes.
Configurable difficulty to create. The rate of blocks should be possible to regulate.
Progress-free. You want the rate of block finding to scale proportionally with the hashrate a miner has; if the fastest miner always wins, you introduce a centralization pressure. Any operation that consists of trying many inputs to a fast hash function and finding one whose outputs satisfies a condition is fine. However, if that hash function is slow (say, multiple seconds), a more than proportional benefit for faster miners is present.
Not dependent on a central entity. Obviously.
Not economically valuable. Proof of work only works when the work performed doesn't have monetary value beyond its function as PoW; if someone could be paid for their PoW (beyond subsidy/fee income from the chain it relates to) would alter the incentives. PoW is supposed to be an economic loss if no block is found/accepted; that is what drives miners to collaborate on the same chain, rather than trying to each work on their own fork.
No non-obvious optimizations. This is the hardest one. To have a playing field that is as level as possible, ideally no non-obvious optimizations to the mining algorithm are possible, as this might benefit only larger miners/manufacturers that are able to afford the research. Worse, inventors of such optimizations (if substantial) may try to patent their ideas, and sell exclusive access to them (e.g. see ASICBOOST). Such optimizations may come in many forms; for example, it may be sufficient that blocks with a certain structure (say, certain 0 bits in certain places) are faster to hash; if 50% of blocks are 3x faster to hash, a smart miner would only search those.

If you take all these properties together, you find that all PoW that consists of a simple, fast, hash function whose output must be below a certain controllable value, is basically ideal. Ultimately, PoW is about proving you have burned a real-world resource (energy) in order to bet on a certain block being included in the chain. It doesn't matter what that function is, apart from being obvious and simple.
I don't see any advantage of a PoW based on Collatz orbits. It's likely full of non-obvious optimizations due to its mathematical structure. I also don't really see how a two-way peg could make use of it, or what it would accomplish.

So far we have no optimizations due to Collatz sequences mathematical structure. But for sure we have documented mining optimization (“ASIC-BOOST”) that allowed to mine Bitcoin blocks faster than the network average by taking advantage of a technical flaw in SHA-256.

I see few advatages shown in cited papers:

PCC takes only (1/1000) th of the execution time that is required for PoW,
PCC has a nearly consistent execution time,
multiplication of proofs-of-work may help to mitigate some types of attack based on SHA-256,
algorithm is easy to implement in code since the underlying problem is made of simple arithmetic operations,
the geometric distribution allows a very convenient tailoring of the computational complexity.

In my opinion, this is an interesting and promising PoW method.


text:
Taproot: Multisig Keypath - different bech32 addresses for same keys
I have a keypath (which is a 2-of-2 multisig) and a tweak attached to it, this tweak is responsible for the scriptpath.
The scriptpath only has a backup public key (used rarely).
Alice + Bob's public keys form the multisig, which is then tweaked. After the tweak I derive a bech32 address.
How can I construct hundreds of different bech32 addresses without having to change any underlying keys?
I want to be able to spend UTXOs across addresses in a single transaction involving just Alice and Bob's single key (basically everything like derivation paths before Taproot).

If you cannot change the keys, then you can only change what they are tweaked with, i.e. the script path. Because the script path is a merkle tree, you could just add another script that contains just an unspendable script with a counter and increment it each time (the script needs to be unspendable as otherwise if anyone were to guess that path, they could potentially use it to steal your coins). That would be sufficient to change the merkle root so that the tweak is different.

Thank you very much! Next to the backup key I could add a leaf which contains a hardcoded public-key-like value. I would just perform basic addition with a counter to this "key". So this leaf/script should be unspendable, right? Or is there a better approach?

Yes, I think that is an appropriate approach.

@ByteFlowr: Using the tweaked public keys in the keypath spends would not be relatable due to the differing tweaks. However, if you ever need to spend multiple UTXOs per the backup key, you would reveal that those UTXOs share the same internal public key and use the same backup key in the scriptpath.


text:
How can I import the Mini Private Key of a physical coin?
I have a physical Litecoin based on a Casacius Bitcoin. I have the public key and see that the Litecoins are there.
Peeling back the seal/sticker revealed a Mini Private Key, but I'm having trouble importing it into Litecoin Core, importprivkey(…) gives me the error message Invalid private key encoding (code -5).
What do I need to do to import the Mini Private Key?

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

Litecoin & Bitcoin use the same core engine

@Anonymous: I disagree, because a) the new rules requiring applicability to Bitcoin are not in effect yet, b) the question and answer would be the same for Bitcoin, so I'd argue it would be on-topic even after that.

You must convert the mini-private-keys to regular private-key format before being able to import them in wallets such as Litecoin-core. If your keys are based on "Casascius" then you could use liteaddress.org (fork of bitaddress.org) to do the conversion. Follow these steps:

In order to be safe download the source code from https://github.com/litecoin-project/liteaddress.org and run it on an offline and clean computer. That way you can be sure that the code you are running is actually what was shown on GitHub and running offline helps to keep your private keys safe from malwares, keyloggers,...
Run the file called bitaddress.org.html (it is not renamed to liteaddress!)
Move your mouse around (you have to, then you can ignore the result)
Click on the tab called "Wallet Details" and paste your minikey in the first box can click "View Details" button.
Depending on which address has balance (compressed or uncompressed) copy the respective private key at the bottom and import that in litecoin-core

This answer could be improved by explaining why the website should be downloaded and what risks the user exposes themselves to by using it.


text:
How can I get all transaction for a specific address using Nbitcoin?
How can I get all transactions for a specific address using Nbitcoin?

I've edited your question to ask for "how", since I am assuming you're looking for instructions. Could you clarify whether you want all transactions sending to an address or also the ones that spend those funds later?

you can't get all the transactions done on an address using just Nbitcoin. you need a block explorer for that. you can check out qbi t, blockcypher etc.
However you can get that using Nbitcoin and Nbxplorer (a simple blockchain tracker that monitors your xpub and addresses) with easy to use api's like getTransactions,  getBalance etc.
https://github.com/dgarage/NBXplorer

var client = new QBitNinjaClient("http://api.qbit.ninja/", Network.Main);
var address1 = new BitcoinPubKeyAddress("your --Address", Network.Main);
var balance = await client.GetBalance(address1);

This does not answer the question because of "using Nbitcoin". Furthermore (meanwhile) QBit Ninja is not maintained anymore.


text:
litecoin mining
I'm a crypto currency newbie. I'm planning to mine lite coins. Is it possible to mine them using my Lenovo Y550 laptop? I have downloaded the wallet. I want to start with mining but im still in doubt if it is feasible with my laptop. Thanks already.

According to both Newegg and Notebook Review, your laptop, at least in its base configuration, has an NVIDIA GeForce GT 240M GPU. I will assume this is what you have.
According to the Litecoin Wiki's Mining Hardware Comparison (look it up on Google), you would be hashing at 15.4 kH/s. This is quite slow. dustcoin (dot) com shows that even if you left your computer on 24/7, you would only make 4.94$/month at current exchange rates. Assuming your computer is using 75W of electricity (this looks like a lot, but remember, it is running at full throttle 24/7), and your utility charges 12.5 cents per kilowatthour (U.S. average), your Litecoin miner will use 6.85$ of electricity each month. This leaves you with a loss of 1.91$ each month.
This is not the only problem. Laptops often have inferior cooling compared to desktop computers, and can easily overheat if they are running at full power all day long. This is a quick way to have component failure and turn your laptop into a 15 inch paperweight, not to mention the costs of repair or replacement, which will surely be higher than 4.94$.
Bottom line: it could work, but it's not worth it.

Thanks for the detailed answer. I think if it works I would like to give it a try before i quit. But while downloading the mining software, guiminer-scrypt.  It gave me error of not finding OpenCl.dll. Why I'm totally unaware about the hardware concepts, I'm sure this relates to GPU. Any suggestions?


text:
How does one prove total turingness of the bitcoin script using the Ackermann Functions?
In this Medium Article (https://medium.com/@craig_10243/bitcoin-a-total-turing-machine-5a6c3c68f5a7#_ftn2), C. Wright states:
"...It is known that all primitive recursive functions are total and computable, in this paper we also demonstrate using the Ackermann function that the Bitcoin script constructs include the ability to extend to total computable functions that are not primitive recursive. This demonstrates that Bitcoin can incorporate total computable functions that are simply “recursive” as well as primitive recursive."
What does this mean in mathematical terms?

Craig Wright is a known conman. There is no point in trying to decode his gibberish.

It’s also not turing complete, in any sense of the word. You can not prove it is because it simply isn’t. It has a execution tape with defined opcodes, which have a specific and well understood limit.

The meaningless article seems to be saying that with an infinitely sized execution tape you could run a program indefinitely, which while literally true assumes an infinitely sized transaction and infinitely long execution, which doesn’t exist in Bitcoin.

@PieterWuille I would like to give it a shot from the point of an aspiring academic simply aiming to resolve some questions.

@Anonymous Right got your point. I simply enquired about use of Ackermann functions in using proving Turingness of a Script.

Bitcoin Script isn't Turing complete in a single transaction scope for obvious reasons.
But is it Turing complete if we consider a transaction chain as the tape? Also no, because Bitcoin scripting language doesn't have transaction introspection opcodes, so there's no way for a program to carry the program state over to the next transaction to execute the next "CPU cycle". Even if it were, to execute an infinite program you'd need to pay infinite fees :)
Introspection opcodes would enable theoretical Turing-completeness of transaction chains, there's been some work discussing this: Self-Reproducing Coins as Universal Turing Machine, A. Chepurnoy, Vasily Kharin, D. Meshkov
Note that nodes wouldn't be automatically evolving the program. Some blockchain-external agent would have to construct the next transaction and broadcast it to the network. The program could code-in a reward for this and incentivize anyone to construct and post the next transaction, or external agents could do it for free. The program would halt when it runs out of money for the fees/incentives, but then again, other external agents could give it more money to continue evolving.


text:
How/where is the mapping of a transaction to a particular block stored?
According to the Bitcoin white paper, a block contains the fields "Previous Hash", "Nonce", and "Root Hash". The root hash is a merkle tree root node of all the transactions that have been confirmed in that particular block.
I read in the fifth paragraph of the top answer on What is the Merkle root?:

If we have a transaction that claims to have been from block #234133,
we can get the transactions for that block, verify the Merkle tree,
and know that the transaction is valid.

Say a block b somewhere in the blockchain holds t transactions. Where and how is the mapping of a particular set of transaction to a particular block stored? Because the blockchain itself only contains the root hash of all transactions to save space. So are there other hidden components that haven't been published in the white paper and are there resources to get a comprehensive idea about them?
Thanks.

The whitepaper is nothing like a statement of how the system is designed, it's at best an overview of the concepts. The actual implementation doesn't even strictly follow what is said, and you shouldn't expect a 9 page document to.

The merkle tree is dynamically recreated to validate it in a block, the order of transactions in the block implicitly describe what the merkle tree should look like when reconstructed. The transactions are stored as part of the block, quite literally the header, a number stating the number of transactions to follow, and then a list of all the transactions follows.

But how do you find a particular transaction or a block that has the particular transaction when you wish to verify the transaction as having taken place?

You either read all blocks and keep an index of the transactions, or you ask a service that does know.

The whitepaper just gives a conceptual overview of Bitcoin, but certainly isn't a full specification. Anyway, beyond the blockchain itself, keeping track of transactions and UTXOs is more of an implementation detail than a protocol concern. Various explorers, nodes, and wallets will differ in their approaches, but generally there are a few different mappings between transactions and blocks for different purposes:
Blockchain: block to transaction mapping
First and foremost, the blocks as included in the blockchain include the transactions they confirmed. The complete blockchain is retained in by archival full nodes. As Anonymous already explained, the merkle tree is only stored implicitly in the blockchain per each block simply listing its full set of transactions in order. Full nodes recreate the complete merkle tree on demand by rehashing the block's transactions during block validation as well as when a Merkle proof is requested from them.
Specific interests: Transaction to block mapping
Wallets generally retain copies of the transactions that involve their addresses. These transaction objects should generally keep the block height and the block hash, so that the wallet can deal with chain reorganizations and keep track of confirmation count. I would suspect that some wallet implementations may also keep the Merkle proof around if they e.g. want to be able to proof the existence of funds to other devices.
Bitcoin Core will keep a full transaction index around when configured with the start-up index -tindex=1.
UTXO set: Output to transaction/block mapping
Full nodes maintain the ledger of all Bitcoin funds in form of the Unspent Transaction Output (UTXO) set. UTXOs are uniquely identified via their outpoints ([txid:vout]) which means that they inherently reference the corresponding transaction. A UTXO object should generally also include a direct or indirect reference to the block that confirmed the transaction that created the UTXO.
Explorers
Explorers generally keep more comprehensive databases of transactions, blocks, addresses, and UTXOs.

I'm not sure u r asking as a human want to verify a certain transaction, or as a developer wants to write code to verify a certain transaction given its block no, address,...etc
1-In general, if user A had say "n Btc" as an UTXO which changed to "n' Btc" after transaction X in block B; then u want to validate the spending of the UTXO "n" (by checking Merkle proof/witness) & the creation of UTXO "n'" in block B.
2- Or as a user, without any coding, u may go to one of these sites
https://m.btc.com/
https://www.blockchain.com
https://blockchair.com
-either start by the block # ( if there's say more than 1000 TXs in the block it would be hard to check this way)
ex.
These photos show how did I checked that the coinbase UTXO of block 100,000 got spent in block 266,668

-or by the given user address, u get something like this
Then u search for the UTXO value in the given TX (whether it was input or ouput from the arrow direction & the color as u see here)

When u click on it, it will get u to the TX created it  with block no & all info; say I clicked on in the above link, I get the transaction details & the block no

(Yes these r probably wallet addresses, but maybe it would be easier to check from since there's a chronological order while inside one block u don't know what's the index/relative order of ur TX; I mean u didn't say it's given)
3-If u r asking as a developer, I guess this Bitcoin core code tells u how things r really stored
https://github.com/bitcoin/bitcoin/blob/398dd678338971d2189934713c83c184742f293f/src/coins.h#L60-L65
I happen to find it "coincidencly" yesterday when checking this
https://github.com/mit-dci/utreexo/issues/277
I hope this helps...


text:
I made a payment of bitcoin into escrow for services that were not delivered and bitcoin not returned
I made a payment of bitcoin into escrow for services that were not delivered. I requested that the funds be returned and they have been removed from escrow, but never returned to me. Can I do anything to recover my funds?

How did you choose the escrow service?

Hi, it was an escrow service which was approved through the vendor, so I unfortunately went with it. Appreciate your response.

You can contact the service provider, and the escrow agent to request a refund, but beyond that there is likely nothing that can be done. If you have lost a substantial amount of money, you could file reports with your local law enforcement agency, but understand that there is almost no chance they will be able to help you recover the funds.
Bitcoin transactions are not reversible, once confirmed several blocks deep in the blockchain history, the chance of that transaction being removed or replaced is basically zero. The only way those funds can be returned, is if the person who now controls them decides to send a transaction paying you back.
Sorry for your loss here, it is unfortunate to hear that even after employing an escrow agent, your trade did not go as planned.

Thanks for your comment and thoughts. It was my first involvement with bitcoin and a learning experience. If it comes back I’ll look at that as a bonus, as currently the vendor and escrow contacts are both ignoring any contact.

@Alrob01 I see in your other comment that the escrow was approved by the vendor, so that makes me wonder if the two were colluding (or perhaps, were the same person). If you employ an escrow agent, its best to find one yourself, that the vendor then also agrees with. In any case, I hope your funds are recovered!


text:
Is the minimum fee consensus, just policy, or both?
Intuitively, I think minRelayFee is policy while minBlockTxFee is validation, but DEFAULT_MIN_RELAY_TX_FEE is in validation.h while DEFAULT_BLOCK_MIN_TX_FEE is in policy.h.

Both are policy. Both are about the same rule, just concern different parts of the code.
DEFAULT_MIN_RELAY_TX_FEE is about transaction relay (don't relay transactions that pay less than 1000 satoshis per kilo-vbyte), while DEFAULT_BLOCK_MIN_TX_FEE is about block creation (don't include transactions  paying less than 1000 satoshis per kilo-vbyte in block templates).


text:
What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?
Normally, I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4MB, so we should say that the blocksize is 4MB, right? Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely? Thank you

Normally I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4mb, so we should say that the blocksize is 4MB, right?

Before the activation of segwit, the block was limited to 1,000,000 bytes. This limit got replaced by a blockweight limit of 4,000,000 weight units (WU) with the activation of segwit. A byte of witness data contributes 1 WU and a byte of non-witness data contributes 4 WU towards the limit. Theoretically, the block could therefore be up to 4,000,000 bytes if it was composed of witness data exclusively. In practice, even blocks consisting only of segwit transactions are expected to end up in the range of 2.1–2.7¹ MB because of the non-witness data that transactions always have. Blocksize is therefore no longer the correct term for the limit, rather we should say that "the blockweight limit is 4 MWU".

Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely?

The transaction id (txid) of segwit transactions is calculated from the stripped transaction, i.e. the transaction data excluding the witness data. This has two effects: One, legacy nodes use the same identifier for segwit transactions as full nodes. Two, the txid of an unsigned transaction is the same as from the signed transaction (useful for setting up smart contracts, e.g. LN channels). When a legacy node requests a segwit transaction, the other node recognizes that the requesting node is on an outdated version and provides them with the stripped transaction. Legacy nodes can relay the stripped transaction among each other as well. To cover the signatures, segwit transactions additionally have a witness transaction id (wtxid) which covers the full data of the signed transaction. Segwit blocks also need to commit to the signed transactions, though! To that end, a second Merkle tree is built from the wtxids. The Merkle root of the wtxid tree is stored as the "witness commitment" in an OP_RETURN output on the coinbase transaction. This is in addition to the regular Merkle root in the block header that commits to the txids of the transactions and remains readable to legacy nodes.
Legacy nodes arrive at the same UTXO set, because stripped transactions specify which UTXO get spent in the inputs, and which new UTXO get created. Since legacy nodes do not know about the witness data, they cannot check the signatures of segwit transactions. Therefore, legacy nodes are not fully validating nodes (full nodes) that enforce all rules of the Bitcoin protocol independently (specifically, they don't enforce segwit's rules). The segwit transactions appear as valid to the legacy nodes, since the inputs appear to be "anyone can spend" to their dated understanding of the Bitcoin protocol rules.

¹On 2022-08-11 block 748,918 achieved a size of 2,765,062 B, exceeding that estimated range for the first time by including a lot of 2-of-3 P2WSH inputs. H/T @bordalix for pointing this out.


text:
Where is the BitMEX Grafana?
I know there is a BitMEX Grafana, but always take so long in finding it because I can never remember the URL when I need to check something. Where is it?

txstats.com:

https://txstats.com/ (formerly p2sh.info) evolved from an independent project to a collaboration between BitMEX Research and Coin Metrics.


text:
Will the 3TH KNC Neptune Miner still be profitable in 2014?
I am seriously considering making an investment and buying a 3TH miner. The problem is whether they will still be profitable by the time they arrive...
At today's has rate calculation of 707,408,283 it is expected to return 2.1328 BTC in a 24hr period.
The question is how realistic is this and does anyone own a miner that can confirm whether this profit forcast is achievable?
http://www.bitcoinx.com/profit/

possible duplicate of How much Bitcoin will I mine right now with hardware X?

@Murch Why downvote

I feel that the question is useful only to a limited circle of persons and for a short frame of time. With the changes we see in mining difficulty any answer will literally be outdated next month. This sort of questions don't help to build a time-lasting comprehensive question and answer corpus. It might be a better fit for bitcointalk or /r/bitcoin, where there is a stronger focus on current issues.

Underlying, is the issue that there are very many questions on our SE, that are essentially localized variants of questions that have been answered before. These create so much background noise that (to experts) more interesting questions don't stand out: I am motivated to take a harder stance on questions I don't find useful, since I read this Jeff Atwood: Optimizing for Pears not Sand

@Murch but the question relates to the upcoming release of mining equipment that will potentially increase the difficulty factor. And many people will invest in the technology would like an answer to these questions from the people that know prior to investing. If people don't mine how will coins be created?

I am not suggesting that the topic isn't interesting, or your question is badly phrased. My point is that I feel that this question is a bad fit to Bitcoin.SE, because you are essentially asking people to predict the future in order to evaluate a product. Predicting the future is primarily opinion based (the SE format is not very good for discussion) and product recommendations are off-topic. Your question is well-phrased, but IMHO just not a good fit for Bitcoin.SE.

@Murch, I totally agree with you. There are to many questions regarding non-technical subjects, like investing money into the new generation ASIC-miners or the trustworthiness of some shady online wallet. I feel like we should do more to stop this and try to get the focus back on the more fascinating technology behind this cryptocurrency, but that's just my opinion...

@Jori Without investment in inoovation and technology it will be harder for this to succeed in the longer term. If we can provide advice that covers all aspects of this facinating and revolutionary technology we will all benefit. Things that will prevent mass adoption by the general non-technical public must be addressed by the community and that includes new investment into mining equipment, trading techniques and analysis or how to simply use bitcoin. If someone is unsure how to get involved at any level and cannot find answers to the simplest questions then we are creating a ringfence.

I sincerely doubt that there is a problem with the amount of investment in mining when I take a look at the difficulty/time chart.

Indeed Murch. Don't get me wrong, I too support the help of the non-technical public, but feel like that is not the task of this stackexchange. I don't know how the other active people here think about this, but perhaps its a good idea if we wrote some simple guidelines about subjects that are welcome here (i.e. in my opinion the technical site of bitcoin) and the subjects that are more suitable for a Internet discussion forum (like a quick starter guide for beginners), as this is a Q and A site.

@Jori: These things exists. Check out [about], [ask] and in general the [help].

Oh, thanks! That's very helpful. According to the help topic about asking, investment advice is not allowed. Like I said, the original focus of this stackexchange seems to be more technical.

The hard part about pre-ordering next generation hardware is to predict a logical expectation of  A) what will be the total network power (hashrate) be by the time your miner comes online which influences directly B) what will be the difficulty value at that time.
If you assume linear growth in the network vs exponential for example you will arrive at different conclusions. That is the real hard part.
At todays difficulty (now 908,350,862) a 2 THps miner at $1000/btc can expect to break-even in 5-6 days.
If looking backwards is any indication, the difficulty has increased by 945% in the past 90 days so if that is the same as the next 90 days and BTC values are fixed at $1000/btc you can expect to break even in 47 days.
IF you think that the next 90 days will grow faster (say 1.5x as fast) as the previous 90 days then you can expect a breakeven in 75 days.
What if your miner comes in 4 months from now instead of 3? What if a whole lot of people are buying one so that when they all come on line simultaneously the difficulty will spike beyond your projections?
And what if the price of BTC falls again from where it is now and stays lower?
A lot of what-ifs but you must know your variables before investing in mining capital.

I thought about it. But the experience with butterfly labs was enough. It looks to risky for me, kncminer are like 12000$ right? you can get 12-13 BTC and with that you can buy immediately 170-185 GH/s on cexio. On Cexio you can buy and sell GH/s for bitcoins so the risk of the investment is not as big as buying hardware, plus you get that GH/s working now not in a few months

The problem with that is the amount of Hashing power you recieve for your cash, 170-185 isn't going to generate much income and it will take months to break even on investment... its a difficult one

yeah that is true, that price is changing often like yesterday trading went from 0.07 to 0.058 and back. Many people try to get more by trading as there are no commission on trading.


text:
Do I need to join a pool if I have a 3TH mining rig?
I am thinking about purchasing a 3TH mining rig and would like to know if it is still worthwile me joining a mining pool to mine BitCoins?
Do I have enough power to go it alone?

You probably want to still join a pool. Even if you lose 1% or so to a pool, consider the cost of wasted time when down. Suppose you get ready to close down your mining rig and it has been mining for two weeks straight with no block. Hypothetically you could have received a block the following day. That means you just wasted those two weeks of computing for nothing. Had you joined a pool, you would have at least gotten paid for those two weeks. Pools will also be there for you when that two week block period turns into a two month period.

Thank you for your answer both are really good answers but I'll accept this one as it relates to the practicality of joining a mining pool vs solo mining.

It is hard to decide right now, knowing that till you will buy, and the company will deliver your hardware, the difficulty will change many times.
Right now with a current difficulty, solo mining with 3Th/s will give an estimation of mining a block in 2 weeks (during this two weeks the difficulty may change). So even right now I would rather have a steady 2 BTC per day then to risk. Especially if after buying this hardware, you need to break even as fast as possible.

@thanks you for your answer, I really appreciate it and will upvote this one.


text:
What should I consider when deciding to whether or not to mine?
I go here
http://www.alloscomp.com/bitcoin/calculator
I put in the amount of hashing power I am willing to purchase, EG: 100 GH/s. It tells me I will make $2,094.25 a month. I am aware that the exchange rate changes, difficulty rate rises. But what prevents me from making at least $1500. They say joining a pool is best, but even if I go it alone, what is the thing that will prevent me from making a reasonable amount of money based off of the information in this calculator. I cant be as simple as buying a miner and letting it run all day.

You really need to take into account some important factors, which that calculator is missing:

The current rate of increase in difficulty
The expected delivery of the mining hardware
The cost of the mining hardware
The cost of running the mining hardware (electricity cost)

I highlighted 2 of the most underestimated factors normally ignored by new miners.
Many mining hardware orders can have significant delays in shipping, due to high demand and low production volume. Sometimes you can wait months for a delivery, by which time the mining difficulty raised so high as to make the hardware unprofitable, even with the rise in BTC/USD price. This is especially true of new hardware pre-orders, be very careful about those (don't believe the expected shipping date).
I would recommend that you use this calculator instead.
Make sure you fill-in a realistic hardware lead time (1 unit for every 12 days wait).
Do your research otherwise you could end up not breaking even.


text:
GPU mining with Intel HD Graphics 4000
I am running Mac OS X 10.7 on a MBP and OS X 10.8 on a Mac Mini.  The Mini has a Intel HD Graphics 4000 GPU and the MBP has a 3000.
I know that I cannot mine with the MBP as the GPU does not support OpenCL.  The Mac Mini should be able to as the Intel HD 4000 supports OpenCL 1.2.
However when I run:
bfgminer -n
 [2013-12-04 15:35:22] 0 GPU devices max detected

My GPU is not detected.  I have the latest XCode installed as the well as command line tools and compiled bfgminer with the latest install of brew.
I just want to play around with mining and am not interested in buying an ASIC set up.
How can I get my GPU to be detected by bfgminer or cgminer?

Update:
When I run 'bfgminer --verbose' I get the following error:

[2013-12-04 17:30:57] JSON-RPC call failed: {    "code": -1,
  "message": "Unsupported method 'getblocktemplate'" }

What is the processor you are using on the Mac Mini ?

@Meterbuchus The GPU or the CPU? As I stated in the question on the Mini it is an Intel HD Graphics 4000 GPU. CPU is: 2.3 GHz Intel core i7

Do you know which generation of an i7 it is ? A specific model number would be helpful.

sysctl -n machdep.cpu.brand_string yields:
Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz

Your error indicates you have pointed your mining program at an unsuitable source of work.

The following program will show you the OpenCL-capable devices on a given Macintosh:
// clang -framework OpenCL dumpcl.c -o dumpcl && ./dumpcl

# include <stdio.h>
# include <stdlib.h>
# include <OpenCL/opencl.h>

int main(int argc, char* const argv[]) {
    cl_uint num_devices, i;
    clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, 0, NULL, &num_devices);

    cl_device_id* devices = calloc(sizeof(cl_device_id), num_devices);
    clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, num_devices, devices, NULL);

    char buf[128];
    for (i = 0; i < num_devices; i++) {
        clGetDeviceInfo(devices[i], CL_DEVICE_NAME, 128, buf, NULL);
        fprintf(stdout, "Device %s supports ", buf);

        clGetDeviceInfo(devices[i], CL_DEVICE_VERSION, 128, buf, NULL);
        fprintf(stdout, "%s\n", buf);
    }

    free(devices);
}

If it fails to show you your GPU then its a driver issue.If it succeeds then its some kind of a configuration error.

In order to compile the above the following has to be done cc dumpcl.c -o dumpcl -framework OpenCL.

Ok, it runs, so it is an configuration error.

Upgrade to OS X Mavericks and it should work. It's a driver issue.
At least on my Macbook, after I upgraded to Mavericks I can mine on both the GeForce and the Intel HD 4000. Not that it makes sense to do so. ASICs have taken over, and even before that AMD was the GPU for mining.

I have upgraded to OS X Maverics and it has made no difference.

Mine litecoins with GPU. @Deesbek

@Prof.Falken thanks for the tip, I have friends who do that and Dogiecoin as well but I specifically needed to compare performance changes over time with GPU.


text:
Can one infer that a bc1 address is multisig?
Studying privacy and security implications of revealing if a bc1 address belongs to a multisig wallet vs a regular wallet.
I do notice that multisig bc1 addresses are longer than regular ones… P2WSH (62 characters long) vs P2WPKH (42 characters long).
So length reveals an instance of “Pay-to-Witness-Script-Hash”, but what about multisig specifically?

No, you can only determine the output type, but not the encoded spending conditions from another user's address. Whether a *SH output is committing funds to a multisig script only becomes knowable once the corresponding p2sh/witness script is published per a corresponding input.
Native segwit outputs encode an amount, a witness version and a witness program. For Pay to Witness Public Key Hash (P2WPKH) the witness version is 0, and the witness program is a 20-byte hash of a public key. For Pay to Witness Script Hash (P2WSH) the witness version is also 0, and the witness program is a 32-byte hash of a witness script. The length is used to distinguish which rules to apply to these two different output types that share the same witness version.
As pointed out, P2WSH outputs commit funds to the hash of a witness script in the output script. Since sha256, the cryptographic hash function used here, produces fixed-length random-looking digests for data inputs of any length, the observer cannot learn anything about the content of the preimage by inspecting the hash. Thus, it's not possible to determine whether a P2WSH output encodes a multisig spending condition or another script¹ until the receiver reveals the script in a corresponding transaction input.
For Pay to Taproot (P2TR), the output script is composed of a witness version 1 followed by a 32-byte witness program that encodes a public key. Here, it's even more difficult to determine whether the output “is multisig” as the use of the Schnorr signature scheme drastically simplifies the implementation of key aggregation. This feature of P2TR outputs allows outputs to be controlled by multiple parties under the hood, but when all of them collaborate, to still be spent using an input that is indistinguishable from a single-sig input to third parties.

¹ Bitcoin's _Script_ is a bonafide programming language, and P2WSH outputs permit a receiver to code-up any sort of spending conditions in their witness script. While many smartcontracts may be broadly about determining how to assign funds among multiple parties, I would consider “multisig” to refer to a simple “m-of-n multisig”. Other popular applications include e.g. the scripts used to facilitate Lightning Network channels, escrow services, or encoding multiple different spending conditions in one output of which some become available only after an extended wait-time.

A hashed script with multisig in it is the same length as a hashed script without multisig in it. So it is only revealed that it was a multisig when the script is revealed at spending time.
As you say the address type is revealed by its length or its prefix before spending time.

Interesting… are there any other significant use cases for using hashed scripts when receiving Bitcoin? “revealed at spending time” Can you please elaborate on this? Would you happen to have an example that illustrates multisig being revealed? Is this something we can see on https://blockstream.info?

@sunknudsen: The output of a hash is the same length regardless of the length of its input. From a privacy perspective it is clearly better that the script is only revealed when Bitcoin are spent from that address rather than being visible on the blockchain as soon as that address receives Bitcoin. Fees for revealing a long script are also charged to the eventual spender rather than the sender. The sender is just sending Bitcoin to the address they were asked to by the eventual spender.

Re blockstream.info yeah there are lots of examples. The first Taproot multisig spend is here: https://blockstream.info/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530

Note Taproot is a little different in that the entire script doesn't need to be revealed on spending, only the particular spending condition it is meeting. But that's a different question

@MichaelFolkson I don't think there is much of a privacy benefit to hiding policies just at output time, if they get revealed at spending time anyway. The point of hashing scripts (or any kind of commitment) is so the sender doesn't need to know/care about what kind of policy the recipient is using. If you want a privacy gain, you need a way to not reveal the policy at all (which to some extent TR does, by only revealing the actually used branch).

In an attack scenario it is easier for the attacker to steal the funds if he knows the script pre spending time than if he doesn't :) I get your general point though.

That would be a security benefit, not a privacy benefit, though.


text:
Is it possible to generate SegWit bc1 public/private key pair using Electrum command line?
I am looking for a way to generate SegWit bc1 public/private key pair that one can use as a paper wallet.
Thanks for helping out!


text:
How to change device label in Electrum?
Say one has a multi-sig Electrum wallet created using Electrum and two Trezor devices… can one change Trezor labels to COLDCARD labels without connecting COLDCARD devices (referring to device labels, see example below)?


text:
How to get time left using command line during initial block download?
When using GUI version of Bitcoin Core, time left before initial block download has completed is displayed.
Using bitcoin-cli, one can see verificationprogress, but is there a way to get time left estimate?
Thanks for helping out!


text:
How do cloud hashing companies profit? (leasing hashing power)
I think I'm missing something. There are a bunch of cloud hashing companies that lease hashing power. Let's take cointellect for example. They have contracts from 10 days to 24 months. If I buy a 10 mH/s of hashing power from this company for 99 euros, they guarantee a minimum of 2.2 euro daily return which makes 180 euros in return for my initial investment of 99 euros in the 3 month contract. How is this profitable for both me and the company? What's the math behind this?

Maintenance fees are what they're in for. The 2.20 euros they promise to make for you might not what you're getting every day. They will take a hefty fee for electricity usage and pool fee. I'm not saying every cloud provider will do this, but some people even end up spending money on maintenance costs.

@MrJones: You seem to have done your research on this topic. It would be great if you could expand your comment to an answer, I've been wondering as well, how Cloud Mining is supposed to turn a profit for the operators.

This seems relevant: BCT: Cloudmining 101 (ponzi risk assessment)

10 mH/s??? Thats significantly low. You can achieve that by a GPU on your computer. Probably you mean 10gH/s

oftentimes by fraud…

When you're calculating the profit from Bitcoin mining, you take into account the current bitcoin price, how much hashpower you have, and the current difficulty.
Difficulty rises over time. (Generally speaking.) Between Jan '12 and Jan '13, difficulty rose by a factor of 2.9x.
Between Jan '13 and Jan '14, difficulty rose by 407.2x.
Between Jan '14 and now, difficulty has risen by 33.3x.
Unless they're guaranteeing 2.2 euros per day over the course of the contract, in which case they're either morons or liars. (If you really could guarantee that kind of return, investors would be all over you.)
Of course, as David Schwartz notes, it could also be a scam. They could give you good returns, then vanish after lots of people invest.

That's what I don't understand. How can they guarantee 2.2 euros daily while the difficulty always rises? Funny thing is, it's not a fraud, I have seen payouts of 600 euros for a 300 euro investment from a friend.

But how does the company make money? That's the part I don't get from the description.

The general consensus is that any such company that cannot actually prove that it is doing the mining it claims to be doing is a scam, most likely a Ponzi scam. This is a near certainty when the company promises an unreasonably high rate of return at a claim of low or no risk. If a business is either insanely, unreasonably generous to complete strangers based on their willingness to loan the company money or a scam, the latter is way more likely.

99.9% of such companies are frauds.. they simply gather money from new users and payoff the old users.
They repeat this to get enough trust among users.
To make it more lucrative they throw in affiliate or referral schemes.
That ensures people refer friends and family or simply go social in promoting these sites with a story that they have earned (which they really did).
People trust people when they see success stories. And have a tendency to go with the flow. Even if I knew its a scam, I would take a chance since the company initially pays off.
To top this, these companies provide a lot of revenue to other review sites.
These reviewers not only get money from ref links they post on their reviews but a direct income straight from the company for advertising their website.
At the end, eventually when this is all over.. The ones losing money are the ones who invested at the end. Many who invested first keep rolling the same money and if they did not exit in time, they lose all that was invested.
REST EVERYONE makes money from this. From the founder of the firm to the initial investors & investors who were smart to remove profits to the advertisers all make money. Ones who joined the party late lose out.
I mine myself, and have been doing so for some time now.
You can make the kind of money they promise in mining indeed. However there are ups and downs and you cannot keep getting the same income over and over.
There are huge fluctuations in the coin prices that sometimes work for you and sometimes are a huge setback. If you can afford to sit tight on your investments, go mine or even better trade with the money you would otherwise invest in mining. Trade alt coins and bitcoins. There is much more money to be made there. Its relatively easier and make more with trading alone compared to first mining and then trading what you have mined. Plus it saves a lot of time for you and you can operate on the go with nothing to strap you down to one place. Also, you then have nothing to do with the power costs or equipment upkeep or upgrades.
I started off with cloudmining. then moved to physically mine coins. Then realized trading gives you a head start over physically mining coins.
Now I do 90% trading and 10% mining - mining only unknown coins nothing specific. Keeps shifting depending on some factors.
In all, the returns from cloud mining companies are for a limited time.
If they are operating for a long time, its only about time they shut and run away with the money. They are not here to stay. Make most while they are here.
Stick to a strict ROI and take your initial investment out. Leave the rest in and let it build. You keep removing lets say 50% profits from there each month or whatever the timeframe is. Protect yourself from these cheaters.

My guess is like any business it's an interest loan that they take out.  It's a bit of a risk if the difficulty of mining does not rise, but maybe that's a win win for both of you.  Businesses sell bonds to people at interests rates where the people or the banks are guaranteed to make money.  They can invest in newer equipment today while you have to wait 6-9 months for your year contract to make a profit. I'm currently mining through bitcoin cloud mining service and at the rate they are paying me I will get a return on investment for my two year contract in 6 - 9 months.

So, did the ROI come to pass?

I find a summary the best way to explain this:
Company: +£99 from you.
The company do not pay out anything but costs for power. Bitcoin 'creates' the money.
You: +£All your earnings.
10Mh/s will not generate anything, 10Gh/s maybe...

The company must have had costs for initial investments though, so since they are paying back more to the investor than they got from him, how does it turn profit for them?


text:
mempool web app on pruned node
What would happen when running mempool web app on top a catched up pruned node and track back to old transactions no longer in persistent storage?
Would it behave buggy? If so, would be in scope not to be buggy? In other words, does this software require to be on a full node?
Don't have any pruned node at hand to check.

Running the Mempool blockexplorer software requires a full node with a complete transaction index as the data source. Operating a full node with txindex=1 requires a complete copy of the blockchain and is therefore inherently incompatible with the pruning mode. It stands to reason that operating a Mempool instance will not be compatible with a pruned node in the future either.


text:
Bitcoin-Core Wallet from 2013
Found old wallet.dat file /2013/ , and placed it in a last version Bitcoin-core wallet /synched/.
It shows transactions , but none of them are Confirmed. Are those funds lost forever , or there is smth  i can do about it ?  Thanks in Advance !

I would enter the transaction IDs into a blockchain explorer to discover their true state.

Could you describe in a bit more detail what you did? Did you use the loadwallet RPC, or did you place it in your bitcoin folder? Was your Bitcoin Core shut down while you did that? Did you call -rescan?

I found that wallet,dat file  , so i placed it in the bitcoin folder. My bitcoin Core was shut down during that time. I did the rescan twice. Most interesting part : today i placed it in Litecoin Core wallet , the same way i did it with Bitcoin one , and imagine........it shows again some funds in it - this time LTC !!!


text:
Getting "Unknown wallet records: 1" on loading wallet
I noticed that loading this wallet:
loadwallet ...wallet name...

The wallet is a 169900 legacy wallet.

2021-..-..T..:..:..Z [...wallet name...] Keys: 0 plaintext, 4355 encrypted, 4355 w/ metadata, 4355 total. Unknown wallet records: 1

Why an unknown record?
Would that one be the HD seed?
Any reason to worry?

Why an unknown record?

If you have used your wallet in a newer version of Bitcoin Core and then downgraded, you may see this message as sometimes new versions of Bitcoin Core will write new records. If your wallet is particularly old and has been upgraded over time, it is possible that your wallet contains records that are no longer being used and have since been removed from the codebase.
It is also possible that your wallet was somehow corrupted, but if so, it is unlikely that the wallet would be opened at all.

Would that one be the HD seed?

No. HD seeds are not unknown records.

Any reason to worry?

Generally no. In some versions, the wallet will perform a silent upgrade of various wallet data which can involve writing new records. These are designed to be backwards compatible so that such upgraded wallets can still be used in older software without issue. Other upgrades that break compatibility must be done explicitly by the user via the upgradewallet RPC. Such upgrades have downgrade protections by using either wallet flags or a new wallet version which indicate to older software that the wallet contains new critical information and should not be opened if that version does not know about those versions.
Old records are occasionally deprecated and are no longer used by the software. These are typically added to a list of known but unused records to avoid this warning, but it is possible that this was forgotten for some.


text:
Bitcoin Util Grind
What's "bitcoin-util grind" for?
  grind
       Perform proof of work on hex header string

It performs proof-of-work mining; given a block header, it finds a nonce such that the header with the nonce in it hashes to a value below the proof-of-work target.
Its purpose is assisting with signet creation. In signet, blocks have a small amount of proof-of-work (they're relatively low difficulty), but also require a signature by the (fixed) signers for the network. In order to assist these signers in their block-creation process, the grind command of bitcoin-util can be invoked.
To be clear, this feature is not useful for normal mainnet or even testnet mining:

It is CPU only, unable to take advantage of specific hardware like GPUs, FPGAs, or ASICs.
Even for a CPU-only mining tool, it is slow. It lacks optimizations that could speed it up, in order to improve maintainability and simplicity of the code.
It has no interface to interact with mining protocols like Stratum or GBT.


text:
how do you tell P2WSH invoice addresses apart from P2SH?
... and how do you tell P2WPKH invoice addresses apart from P2PKH?

P2PKH addresses are 33-34 characters long, use Base58Check encoding, and (on mainnet) start with "1".
P2SH addresses are 34 characters long, use Base58Check encoding, and (on mainnet) start with "3".
P2WPKH addresses are 42 characters long, use bech32 encoding, and (on mainnet) start with "bc1q".
P2WSH addresses are 62 characters long, use bech32 encoding, and (on mainnet) start with "bc1q".
P2TR addresses (coming in november) are 62 characters long, use bech32m encoding, and (on mainnet) start with "bc1p".

P2SH-wrapped P2WSH exists too. These cannot be distinguished from other P2SH addresses, until they are spent.