text:
Bitcoin core V22 Authorization failed: Incorrect rpcuser or rpcpassword
I have my full node connected through Tor. I ended up changing my onion service and now I'm getting error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/home/ubuntu/.bitcoin/bitcoin.conf)
So I open up my bitcoin.conf, there was no rpc password or user name set to begin with and added one in so my .conf looks like the following.
prune=15000
proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=BLANK.onion
rpcuser=me
rpcpassword=mypassword

Which results in the following:
./bitcoin-cli listdescriptors
error: Authorization failed: Incorrect rpcuser or rpcpassword

I also tried passing the -rpcuser and -rpcpassword directly without any luck.
I basically want to backup my wallets descriptors to Sparrow wallet since Electrum currently does not accept descriptors yet.
Any ideas on how to fix?

Did you restart Bitcoin Core after modifying the bitcoin.conf file?

results in either error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/home/ubuntu/.bitcoin/bitcoin.conf)
or
error: Authorization failed: Incorrect rpcuser or rpcpassword
upon adding or removing rpcuser and rpcpassword

You need to restart bitcoind; not just bitcoin-cli.

./bitcoind stop
Error: Command line contains unexpected token 'stop', see bitcoind -h for a list of options.
https://bitcoin.stackexchange.com/questions/13696/how-to-safely-shutdown-bitcoind

Just use killall bitcoind to stop it. You can't use bitcoin-cli to send the stop command, as that needs bitcoin-cli, which doesn't work.


text:
Can I use my "chainstate" folder for anything?
I've recently found an old folder called "chainstate" in my PC.
Can't remember why I saved it but inside it there's the following files:
"000003.log"
"CURRENT"
"LOCK"
"MANIFEST-000002"
Are these of any use at all? Could I access an old wallet using these? What does it mean?

The chainstate directory stores publicly available data, specifically unspent transaction outputs and some metadata at the time it was saved. It doesn't contain any private key material and so it can't be used to claim or send any funds.

source: Stack Exchange

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

sort: votes


text:
Are miners advertised hash rate single or double hash speeds?
Modern miners on the market have up to 110 TH/s. Is this the true hash rate (singular SHA-256 hashes per second) or the net hashes relating to Bitcoin specifically (since Bitcoin involves double hashes 'SHA256(SHA256(x))'. If so, that would set its true hash rate of 220TH/s.
Thanks

Modern miners on the market have up to 110 TH/s. Is this the true hash rate (singular SHA-256 hashes per second) or the net hashes relating to Bitcoin specifically (since Bitcoin involves double hashes 'SHA256(SHA256(x))'.

It refers to the number of block hash candidates the miners can try per second. While you can think of those as double SHA256, that is actually very far from what the hardware does.
It doesn't actually compute two hashes, in the sense that:

it cannot take as input anything but a block header (with some specific structure, of which some parts are precomputed, in the case of ASICBoost),
it doesn't output the result of the first hash,
it doesn't actually even compute the full second hash result (only whether or not it has a certain number of zero bits up front)

If so, that would set its true hash rate of 220TH/s.

You could say that, but it's a meaningless metric. The hardware cannot actually perform 220 tera-SHA256's per second, for the reasons above.
The only thing it can do is try 110 tera-Bitcoin-block-candidates per second.

do you have some details about HW optimizations for hashes with leading zeros? Do mining HW implementations take advantage of the fact that for valid proof of work block hashes the first N bits are zero? If they skip part of the second hash computation they can save a few % of transistor and thus have better efficiency. Or do they actually compute only the first N bits to be able to decide if they have certain number of zeroes?

I stopped paying attention to mining internals probably somewhere around 2011, but even back then, (GPU) mining implementations had lots of optimizations to skip bits of computation here and there. I can only imagine that's become a lot of extensive since then. ASICBoost is one particular impactful example.

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


text:
How to calculate the version (eg. in Python)?
I'm working through this medium post that describes all header fields of a block. The explanation of the version field is a little unclear for me.
For starters I'm trying to consider version = 1, as in the very beginning of the chain:
version_int = 1
version_hex = hex(version_int)
# from my understanding I need to add value 0x100000000 to the version
# though I do not understand why, currently I'm just taking this as a given fact
version_hex_min = hex(int(0x100000000) + version_int)[-8:]
# of course I need the little endian notation:
version_hex_min_le = binascii.hexlify(binascii.unhexlify(version_hex)[::-1])

This gives me the little-endian based hex value:
0x01000000

That I can obviously use to calculate the header hash for version 1.
When I check the latest block headers, I see a version like that:
0x20002000

That would result in the big endian hex representation:
0x00200020

And to an decimal int:
2097184

How does that number refers to the actual and current version and how do I extract the extra information that the miner used for this so called "overt ASIC boost"?

While the answer of @Davidson Souza lead me into the right direction, he probably accidentally confirmed a wrong assumption. And I still found it difficult to apply this to reality. So I want to answer my question thinking this is a little more descriptive:
First you should start seeing the version field as a 32 bit integer. The protocol says, that the last (most left) 4 bits have to be 0010. So the version field should at least look like this:

Now a miner can signal readiness for a soft fork proposal by just flipping specific bits. The protocol allows the first (most right) 13 bits to be used for that. For example there's a soft fork BIPn0 that says, that the first (0 -> first in binary is the most right, remember? ;)) may be flipped to show readiness. In reality that looks like this:

That is pretty smart. Why? A miner can individually signal readiness for independent soft fork proposals. Image there are 12 soft forks out there, but the miner only supports 4 of them - I'm just randomly picking here - that's how it would look like:

Eventually, that leaves 16 bits open. That's the space the miner can use as additional search space to find a header hash below the target. So that gives you 2^16 additional values (not 2^24 as I assumed):

BIP-034 defined block version 2, so blocks should have versions greater or equal than 2, since it's little-endian, we expect something like 0x02000000. However, miners can change the following values with almost no restrictions, so they may use it as entropy source for new nonce cycles without recomputing a Merkle root. Ideally, everything beyond the 0x02 is ASIC-BOOST or whatever crazy change in version bits. Moreover, some soft-fork methods like BIP-008 and BIP-009 use the version as a bit field. Taproot uses the bit 2, so every taproot signaling block ends with a 0x04.

Thank you, so in other words: The actual version is defined by one byte, it can go up to 0xFF (0d255). And there are three bytes left to increase the additional search space by 2^24 possible variations?

As currently is, yes! But may change in the future.

You may have a look at may answer https://bitcoin.stackexchange.com/a/112909/116982 :)


text:
What are MATT opcodes?
There is plenty of discussion in the Bitcoin-dev mailing list about MATT opcodes, and I would like to know what these are.

Disclosure: I'm the author of the proposal called MATT.
MATT is an acronym for Merkleize All The Things, and is a research project for an approach to bitcoin smart contracts that only require relatively minimal changes, while allowing very general constructions.
Rather than going into the technicalities of the current proposal, let me try to explain just the core idea, with links for more in-depth reading.
Key concept: Covenants
In Bitcoin, coins are locked in UTXOs (short for Unspent Transaction Outputs). A UTXO contains the Script that specifies the conditions to spend those coins ("Alice can spend", or "Alice can spend, or Bob can spend after a month", etc.).
Today, there is no way in Bitcoin to add constraints on where coins can be spent, if the conditions in the Script are satisfied.
A script that adds such restriction is called a covenant, and that is not possible in Bitcoin today, at least not within the Script language. Adding the capability to do so in Script is an increasingly active area of research.
The covenant introduced in MATT
The core idea in MATT is to introduce the following capability to be accessible within Script:

force an output to have a certain Script (and their amounts)
attach a piece of data to an output
read the data of the current input (or another one)

The first is common to many other covenant proposals, for example OP_CHECKTEMPLATEVERIFY is a long-discussed proposal that can constrain all the outputs at the same time.
In short, covenants will allow to enforce constraints on the future of those coins!
The part relative to the data is more specific: this data can be as short as a 32-byte hash, but the key is that the data of an output is not decided when the UTXO is first created, but it is dynamically computed in Script (and therefore it can depend on "parameters" that are passed by the spender). This is extremely powerful, as it allows to create some sort of "state machines" where the execution can decide:

what is the next "state" of the state machine (by constraining the Script of the outputs)
what is the "data" attached to the next state

I posted the precise details and implementation of the covenant opcode that allows what's described in this section, OP_CHECKCONTRACTVERIFY. The exact specs and implementation are still subject to changes at this stage.
(1) Merkleizing the data
Here we come to the second core idea: if we can only attach a single piece of data (32 bytes), how can we execute more complex "contracts" that require accessing/storing more data?
The solution is to use the 32-byte data as a commitment to a larger collection containing all the required data of the contract. This can be done with Merkle trees, which are not currently possible in Script, but become possible by adding a simple opcode like OP_CAT, that takes two stack elements and concatenates them.
It is not difficult to convince oneself that the capabilities of the covenant described above, together with the ability to compress arbitrary data in a single hash, allows chains of transactions to be programmed to perform arbitrary computation. More on this below.
(2) Merkleizing the Script
The concept of this section is not really anything new in MATT, as it was introduced in the Taproot soft fork, which is active in bitcoin since November 2021.
When you represent a contract as a Finite State Machine, you often have situations where a certain state can transition to multiple other states of the FSM.
For example, if the smart contract is encoding a game of Tic-Tac-Toe between Alice and Bob, and it's Alice's turn, one transition encodes "Alice plays her move". However, Alice might stop playing, so you likely want to allow Bob to automatically win the game if Alice doesn't play her move within 1 day. So a second "state transition" in the node that represents Alice's turn could be "After 1 day, Bob can take the money".
More complicated contracts can have many possible transitions from the same node, and taproot makes it possible by using - you guessed it - a Merkle tree of all the possible transition. Each leaf of this Merkle tree contains a bitcoin Script, as usual.
(3) Merkleizing the Execution
This section describes some more advanced applications of the ideas described above; unavoidably, this section will be the hardest to read.
What we said above is already enough to represent some very interesting smart contracts, like vaults, Rock-Paper-Scissors, and a lot more.
However, there are smart contracts that are way too expensive to execute in the way described above, simply because bitcoin Script is not powerful enough to execute complex computations (this is by design, as it helps to keep the validation efficient and cheap, which is crucial for people to be able to run bitcoin full nodes!).
Sure, one could decompose the computation in a chain of hundreds, or thousands of little state-machine updates − but this certainly does not scale!
The full writeup of the MATT proposal drafts an interesting solution to this problem, by using an idea known as fraud proofs.
It goes like this: suppose that a transition from a certain state to another state is only allowed if Alice produces an input x that satisfies a certain complicated condition. For example, x must be a prime number.
Script does not have any opcode to check if a number is prime!
Therefore, we modify the contract as follows:

Alice posts the number x (unconditionally), and the contract moves to a "Challenge phase"
During the challenge phase, if Bob verifies that x is not prime, Bob can challenge the assertion.
Otherwise, after some time (say, 1 day), Alice can continue as normal: she produced an x that Bob did not challenge, so it is probably a prime!

What happens if Bob does start a challenge? In that case, the contract enters a different stage: a fraud proof protocol. The protocol involves multiple transaction from both parties, but it guarantees the following: if Alice was lying, she will be exposed and lose her money; vice-versa, if she wasn't lying, Bob will lose his money. Lying is not profitable!
The details are not simple enough to attempt an explanation here, so please refer to the full write-up if interested. A simplified example of a complete fraud proof protocol and how its execution might look like within a series of bitcoin transaction was presented in this post on the bitcoin-dev mailing list.
And yes... there is another Merkle tree involved in this protocol!
Hence the meme Merkleize All The Things that became attached to the proposal.
Summing up
This research aims to find an approach to bitcoin smart contracts that is compatible with bitcoin's ethos and design goals. The new proposed opcodes are quite simple and easy to audit. Yet, they allow to create very expressive smart contracts, in a way that adds little to no additional burden to bitcoin nodes. The structure of the proposal incentivizes the construction of systems where the management of the smart contract, their storage, and (potentially) their execution are generally handled off-chain.
I hope this serves as a gentle introduction to the world of Merkle trees and bitcoin smart contracts.

Hi Salvatore, many thanks for that lengthy contribution. After you Merklize the UTXO set, what happens next? You end up with a single hash that represents the entire UTXO set, what do you do with this? And how do you get from there to new opcodes?

Hi Eoin, thanks for asking the question!
Merkleizing the UTXO set is not part of MATT (that's instead what utreexo does, another project heavily relying on Merkle trees!).
In most cases, a smart contract in MATT would live entirely within one (or a few) UTXOs.
If you have a contract that requires storing multiple pieces of data, then you can use a Merkle tree to represent these different pieces of data as a single 32-byte hash, which is all the opcodes allow to store inside the UTXO.

So you are looking for a new opcode(CCV) which will facilitate the functioning of covenants in Bitcoin?

Yes, it's a proposal to add a new opcode that adds a covenant to bitcoin Script.

Could covenants be done off-chain, on layer 2?

As far as I know, not in any way that I would consider interesting; in particular, one of my primary goals in researching covenants in layer 1 is precisely to allow layer 2 constructions that are not possible today.

MATT stands for "Merklize All The Things" referring to the usage of Merkle trees in current and possibly future covenant proposals (opcodes, fraud proofs etc). There are three aspects that could theoretically use Merkle trees: state, state transitions and arbitrary computations.
At the time of writing (August 2023) an opcode proposal (OP_CHECKCONTRACTVERIFY) has been formalized and implemented but earlier proposals included multiple different opcodes e.g. OP_CHECK{IN,OUT}CONTRACTVERIFY, OP_CHECK{INPUT,OUTPUT}COVENANTVERIFY, OP_PUSH_ANNEX_RECORD.
More information and a collection of links related to these covenant proposals is here.

Where in the Bitcoin core github repo can I find usage of these opcodes, or are they just used in the Bitcoin-cli?

@EoinMcQuinn: They are early soft fork proposals and don't yet have a BIP PR or BIP number. So there is nothing in the Bitcoin Core repo or the bitcoin-cli for them. The implementation is in a fork of bitcoin-inquisition so it is possible they could be merged into the default signet at some point in the future but not the main Core repo.

So why were the opcodes created in the first place? Who created them? What is Bitcoin Script without opcodes?

These are new proposed opcodes. Bitcoin Script already has other opcodes

Where are the existing opcodes of Bitcoin Script used (not the new proposed opcodes)?

What do you mean by "where"? In pretty much every transaction or in the Bitcoin Core repo

So opcodes are in the Bitcoin Core source code? Could you give an example of an opcode being used in the source code?

CHECKLOCKTIMEVERIFY https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L521

Are MATT opcodes related to MAST (merklized abstract syntax tree)?

It is from proposal by Salvatore Ingala regarding MATT opcodes and it is not part of the Bitcoin protocol, there are two resoures may be helpful

[1] https://github.com/Merkleize/bitcoin/tree/checkcontractverify

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021827.html

Also https://merkle.fun/


text:
How do I use Bitnode API?
I just started running a full node and was wondering how to use these commands to verify my node: https://getaddr.bitnodes.io/api/
Specifically, what command line or IDE do I need to type these commands into? Very new at this, sorry

If you are on MacOS or Linux use
curl https://getaddr.bitnodes.io/api/v1/nodes/SERVER-ADDRESS/

in Terminal or iTerm2
e.g.
curl https://getaddr.bitnodes.io/api/v1/nodes/107.3.158.6-8333/

will return to you
{"detail": "Not found"}

because it's not a running node address and port
and
curl https://getaddr.bitnodes.io/api/v1/nodes/80.56.212.9-8333/

will return to you
{"status": "UP", "data": [70002, "/Satoshi:0.10.0/", 1431732528, 1, 356844, "f212009.upc-f.chello.nl", null, "NL", 52.3667, 4.9, "Europe/Amsterdam", "AS6830", "Liberty Global Operations B.V."], "bitcoin_address": "", "url": "", "verified": false}r

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


text:
How to validate bitcoin address
How I can validate a standard bitcoin address?

If it is the format and the checksum then that can be easily done. Specifically you can use steps 4 to 9 in the technical description of Addresses to check for typos. Beyond that however it gets difficult
If you want to access blockchain information such as the current balance you cannot unless you have a copy of the blockchain somewhere, and on a phone or tablet disk space is still too precious for that. For that you'll need to rely on some external service or sacrifice disk space to track the blockchain in its entirety.
Notice that Andreas' Bitcoin Wallet only selectively tracks addresses that were known while synchronizing with the network, so if the addresses you'll eventually be interested in are known in advance you could also selectively sync those.
EDIT: as requested here is the reversed example from the documentation, as python code:
import hashlib

# Take the address as input, using the sample address from the
# technical description to follow along
address = "16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM"

# Decode into 25 bytes (0x00 for the network identifier, 20 byte
# RIPE-160 hash and 4 byte checksum
decoded_address = b58decode(address,25)

# Print as hex, should match step 8 in the docs
print decoded_address.encode("hex")

# Slice into its components
network_id = decoded_address[0]
private_key_hash = decoded_address[1:21]
checksum = decoded_address[-4:]

if network_id != chr(0):
    print "ERROR: not a Bitcoin Main Net address"

# Print the private key hash as hex, matches step 4 in the docs
print private_key_hash.encode("hex")

# Print the checksum as hex, matches step 7 from the docs
print checksum.encode("hex")

# Now we can check the checksum to reduce chances of typos
# Print first round of hashing (docs step 5)
hash1 = hashlib.sha256(network_id + private_key_hash).digest()
print hash1.encode("hex")

# Print second round of hashing (docs step 6)
hash2 = hashlib.sha256(hash1).digest()
print hash2.encode("hex")

# And finally verify that the checksum we extracted from the address
# and the one we just calculated match

if checksum == hash2[:4]:
    print "Everything ok, checksums match"
else:
    print "The end is nigh"

Sadly we can't go any further in verifying without further information, like the actual public key.

Do you have any code which implement  steps 4 to 9 ?

I assume this would not work with a SegWit address (starting with a "3") or a Bech32 address (starting with a "bc1")?

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


text:
Best Hashing Algorithm to mine in 2017? SHA? Scrypt?
I have always been interested in mining cryptocurrency and I am wondering what the best hashing algorithm to mine is? I've looked at the list of the most popular crypto currencies and it seems they all use different hashing algorithms. I know I'm a few years late in the game and bitcoins will all be mined out soon. I think I might be able to jump in. I don't assume it's possible to have a miner that can mine multiple hashing algorithms but if that is, please tell me! Basically I'm looking into buying a miner but I don't know which hashing algorithms is still viable in 2017. Thanks so much for any answers!
-Todd

"I just found out that I don't pay electricity" – You mean, you either pay indirectly for it or it's subsidized by your neighbors? ;)

I pay for it it my rent but because they don't have meters on the individual apartments, you can use as much electronics as you want

Yes, that's what I've said: you're privatizing profits but socializing costs.

wow, who knew that such a bad question could get so many views. Thanks internet.

When your landlord sees his electric bill go out of sight your rent will go up. Nothing is free

Using below table, you can check how profitable it is to mine XY coin:
https://whattomine.com/

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.

The market prices change daily, so posting the answer here is useless.

That's probably true, but that's because it's not a good question to begin with. Answers on Stack Exchange should not depend solely on external content, links should only be for additional information. I don't think you're affiliated with this site, but this answer conforms to patterns used by spammers to promote their websites.

@Böhmermann, an answer on this site should be valid even if it is years old and the references linked in the answer are long defunct.  This answer doesn't fit that description.  It's a bad question to begin with, but that doesn't mean we should be providing bad answers as well.  In this case, you should explain the factors that go into mining profitability rather than simply providing a link that calculates for you.


text:
Is lightning network limited by the 'size' of channels?
Imagine we start with multiple channels which eventually link two individuals, Alice and Rob: (the BTC amounts is the total locked in their multisig address for their channels between each other)
Alice --- 100 BTC ---> David --- 50 BTC ---> Rob

Now - suppose Alice wants to send 100 BTC to Rob. Alice is connected to Rob via David but there's only 50 BTC available to be distributed between David and Rob. Therefore Rob cannot trust a payment of 100 BTC from David.
How does Alice deal with this?
Assuming Alice does not have another 100 BTC sitting around outside of lightning - she has to close out her channel with David; wait for confirmation of this; and then send Rob a traditional transaction to make payment (or open a channel with him). Is this correct? Or is there a better way of dealing with this? Some way of passing value between channels?
If not - is this a problem for lightning network? It would seem that routing across channels is only as useful as the smallest connecting channel. And users have every incentive to keep channels as small as possible to minimise 'committed' BTC. If users have to wait for confirmation to close out a channel, their ability to make fast payments over the original bitcoin network is vastly slowed down by having to wait for confirmation of a channel closure before being able to conduct a transaction on the main network.

In fact, it's worse: payment channels can only transfer the balance that belongs to the sender in it. So, if David and Rob each paid 25BTC into the channel, David can at most send 25 BTC to Rob.— However, there could actually be multiple paths from Alice to Rob which could in parallel allocate 100BTC to Rob.
There's an interesting trade-off here: the Bitcoin blockchain scales easily in the amounts to be settled, but is limited in transaction throughput. Lightning Network on the other hand is practically unlimited in the transaction throughput, however limited in the amounts to be sent. This is why transactions on the blockchain are priced by the cost of including them in the block, i.e. the primary bottleneck, and transactions in the Lightning Network will probably be priced mostly relative to the value they transfer. Obviously, this favors larger value transfers on the blockchain and smaller payments to move to the Lightning Network. However, sending smaller payments requires both a smaller locked-in amount, and will make it easier to find routes.
So, it may actually just work out.— We'll see when it goes live on the Bitcoin blockchain.

Very interesting. Although in your David and Rob example it would depend on the state of the channel at the moment I wish to push my payment through? Thinking this through, though - assuming David and Rob establish their channel because they actively transact between themselves, I suppose there could be cases where David and Rob don't want a third party transaction to be routed through their channel to skew the current balance one particular way, either.

Building on the original point - it would seem that there's a massive issue of committing BTC into channels. Generalising this it would seem to be the case that if everyone is on average n channels away from each other and the network is to handle x BTC per day in transaction volume, there must be at a minimum xn BTC committed to channels in the network. But likely much more to cope with what you are saying. Even if everyone centralises around one node that node would have a massive capital requirements (even for micropayments) for a minimal return with fees.

@Joe: I've updated my answer to include a couple mor ethoughts.

Couldn't Alice just send 10 payments of 10btc (or 5 payments of 20btc)  in this scenario?  These are off chain transactions right? So I imagine the total cost of doing this would be smaller than one on chain txn.

@dimsumcode: Alice can only send as much as the sum of her balances across all of her channels. She could send that much if she has that much.

@Murch thanks.  I think in reality there would be many routes from Alice to Bob. And like you said they should cumulatively be able to handle her 100 btc payment.  We'll surely find out soon.

@Murch does that mean the answer is "yes" to dimsumcode's question?

@CaseyHarrils: Yes, you could split up the payments into smaller chunks, but I don't think that payments of more than a few millibitcoins will be practical for the near future.

@Murch "a few millibitcoins" - can you convert to dollar value? For example, are you saying payments like $6 or 6 cents would not be practical?

1 mBTC = 0.001 BTC ~ $9.4 USD today. I think that currently most payment channels have very thin capacities and payments of more than ~$100 might have an issue finding routes.

The problem here is you are treating the LN as though its for single payments. If Alice is going to send Rob all the Bitcoin she has in a payment channel, why would she have opened up the payment channel in the first place. There would be no reason. She would just make the transaction on-chain. Remember that the point of the LN is to be able to make a bunch of payments. So you are never going to fund a payment channel only with enough coin to make a single transaction. The LN will be used for many small transactions. So you'll say put $500 worth of Bitcoin into a payment channel in order to use it to buy everyday things a bunch of times. The throughput of a typical node (amount in the node) is going to be much larger than the typical transaction amount, otherwise there would be no reason to use the LN over on-chain transactions if you were just opening up a channel for one-off or two-off transactions.
Now yes if you put a ton of bitcoin into a payment channel and at some later point in time you wanted to send a significant portion of that in a single transaction you may find it hard to route to the destination. But even in this scenario you could just send it in several smaller transactions, and obviously a well designed LN node would handle this automatically if your payment was too large, so the end user wouldn't even have any idea about this.
Finally, your statement "And users have every incentive to keep channels as small as possible to minimise 'committed' BTC." is just simply not true. In fact it is the opposite. If you keep a channel as small as possible that means you are doing less txs through the LN and more opening and closing channels on-chain, meaning it is costing you more money. So actually, users have every incentive to maximize (within reason) the size of their channels so as to avoid on-chain fees. Remember 'committed' BTC isn't in some place you can't access it, in fact it is much more accessible because its on the LN (once the LN grows to a sufficient size so that the network effects are strong). The LN is for the use case of using Bitcoin as a payment network, and LN will be far superior to on-chain in terms of speed and fees. So it's not like coins in a payment channel are locked away, they are in fact simply stored in a way that makes them much more efficiently used.


text:
How can I find out what happened to my transaction?
I have not received a 0.1777776 BTC transaction to my Coinbase wallet that was sent from Gladiacoin on 6/3/2017. Is there anyway I can find out where this payment went?
According to Bitcoin info part of the money was transferred from my coin base address to address another bit coin address and then immediately transferred to a third account.  I did not authorize any of this so do I have any recourse to get my money back


text:
A problem on difficulty equation
When I read this book Master Bitcoin, I have a problem in understanding the "Difficulty" in Chapter 8.
There is a equation of difficulty:
New Difficulty = Old Difficulty * (Actual Time of Last 2016 Blocks / 20160 minutes)
I feel confused.
According to the formula, if Actual Time was longer than 20160 minutes, the New Difficulty would be bigger than Old Difficulty, and then Actual Time would be longer and longer.
It looks very strange. For me the equation should be:
New Difficulty = Old Difficulty * (20160 minutes / Actual Time of Last 2016 Blocks)
However, I found this fomula is consistent with that in bitcoin code.
unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
{
    if (params.fPowNoRetargeting)
        return pindexLast->nBits;

    // Limit adjustment step
    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
    if (nActualTimespan < params.nPowTargetTimespan/4)
        nActualTimespan = params.nPowTargetTimespan/4;
    if (nActualTimespan > params.nPowTargetTimespan*4)
        nActualTimespan = params.nPowTargetTimespan*4;

    // Retarget
    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
    arith_uint256 bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= params.nPowTargetTimespan;

    if (bnNew > bnPowLimit)
        bnNew = bnPowLimit;

    return bnNew.GetCompact();
}

Then I found this answer.
This is what I understand, but why it is different from the equation of the book and the code.
update
I think this was just an ambiguous expression.
The better expression should be:
New Difficulty Target = Old Difficulty Target * (Actual Time of Last 2016 Blocks / 20160 minutes)

The code you're citing does not actually deal with difficulty. It deals with targets. The target is the maximum 256-bit value than the block hash is allowed to have.
The difficulty is defined as 2^208 * 65535 / target.
As for the book, that looks wrong indeed.

Thanks for answer, as you said, the description of the book is wrong?

The book is wrong.


text:
How can I change the bitcoin core version within an already installed blockchain?
I want to change the version in the corresponding
directory with git tag and git checkout vx.y.z.
But when I type git tag there's no output.
How can I change the version without installing the blockchain again? Clone the git repo in the already existing directory?
I also tried to fetch the git tag but this didn't work either...

Just don’t run them with the same directory at the same time.
— Did you install from the source code?

@Murch yes I did. But now, looking up the git tags, only versions until v0.11.0rc2 are shown and no further versions.

Are you perhaps pulling from your own fork of the repository?

@Murch I don't know how can I check? Sorry, I'm new to this.

Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on [meta], or in [chat]. Comments continuing discussion may be removed.

In case it’s not clear, you should be able to join the chat by clicking the link in the previous comment, so that we can walk you through figuring out what the issue is. Since there is very little information in your question so far, and it seems more of a git issue than a Bitcoin problem, that seemed more likely to get you help.


text:
Bitcoin node GUI shutting down right away
My node was running fine until I decided to change the setting under the network tab, I checked the box for "Use separate SOCKS5 proxy to reach peers via Tor onion services" and on Proxy IP box I put 127.0.0.1:9150, on Port box 9150. When I tried to restart the node it wont start anymore, it gives me "Error 127.0.0.1:9150 incorrect Proxy" and it shuts down immediately. What can I do to get the node to start again? The GUI is not even starting. I just stared exploring with bitcoin nodes and I'm not knowledgeable at all, any help will be greatly appreciated. I'm running the node on Debian Linux.

I would
Navigate to the Bitcoin data directory. Usually %APPDATA%\Bitcoin\ on Windows.

Have a look at the end of the log file (debug.log)
Rename the configuration file (bitcoin.conf), if it then starts OK, reconfigure.

Related questions:

What to look for in Bitcoin-core logfile when something bad happens

Other useful references

https://achow101.com/2016/07/Bitcoin-Core-Troubleshooting


text:
Why wasn't P2SH-wrapped P2WPK added to any BIP?
Pieter Wuille wrote this:

There is no such thing as P2WPK; the only valid witness v0 programs are P2WPKH (OP_0 + hash160 of pubkey) or P2WSH (OP_0 + sha256 of script).

But I don't understand the reason why. If P2SH-wrapped P2WPK would be hash-protected by P2SH already, didn't back in the day made sense to offer that script combination for the sake of shorter script and smaller fees?

I do not think that a wrapped segwit version of P2PK would have been attractive regarding weight in comparison.
The wrapped segwit outputs work by putting the witness program in the P2SH-redeemscript in the input script and a hash of the redeemscript in the output script. In the case of a P2SH-P2WPK, a witness program in the style of P2SH-P2WPKH could perhaps have been <version> <pubkey> (OP_CHECKSIG implied, like with the other segwit output constructions) and then just a signature instead of signature and public key in the witness stack.
A P2SH-P2WPKH redeemscript is 22 B long. The hypothetical P2SH-P2WPK redeemscript would work out to be 35 B instead—13 B more. On the other hand, the witness stack would have been 34 B shorter because the public key is not appearing there, but because of the witness discount, this only saves 8.5 vB.
So, P2SH-P2WPK would have been 21 B less data on the wire, but 4.5 vB more expensive for the receiver to spend.
P2TR now is a spiritual successor of P2PK: it locks funds directly to a key and only requires a signature to spend the funds. Since P2TR was packaged with the more compactly serialized Schnorr signatures, the reduced input weight can almost balance out the increased cost of storing the whole public key instead of a 20-byte hash. The combination with the Schnorr signatures made it a lot more attractive by simplifying key aggregation.
There was no wrapped variant of P2TR offered because 1) the P2SH-wrapper uses additional data increasing cost and blockspace footprint, 2) having only one output type leads to better privacy and homogeneity of transactions in the long term. The main reason to provide the wrapped variants when segwit came out was to provide forwards-compatibility for old wallets, so that they would be able to send to non-malleable segwit outputs immediately. Since many wallets can now send to bech32(m) addresses, this is no longer as pressing.


text:
What's coming to Bitcoin in 2022 and beyond?
Taproot is coming, Core is going to continue stepping the way to finally phasing out Berkeley DB at last.
Any other new soft fork in the works?
Is Bitcoin done with improvements yet?
At some point, almost all new development should be done in sidechains instead of in Bitcoin, right? There's already more development in sidechains than in Bitcoin.

The question is hard to answer, as obviously nobody knows what actually will be adopted, but today's Optech newsletter has a list of soft fork ideas that are being discussed: https://bitcoinops.org/en/newsletters/2021/10/27/


text:
Bitcoin ETF - Press releases
On 11th of March 2017 the U.S. Securities and Exchange Commision will decide whether the Bitcoin Exchange Traded Fund (ETF) will be approved or not.
The decision will almost certainly have massive influence on the market as soon as the first press release gets published. So the question is where the first official and reliable statement on the outcome of the decision will be published. The SEC homepage has a RSS feed for press releases. However it is not certain that the outcome will be published there first. Are there any other reliable services / official news pages where news like this may be released first?

I have a news feed from https://news.bitcoin.com/ . It sends me news articles in a pop-up window similar to Facebook. I'm assuming that they'll know as soon as the decision occurrs.
For the moment I'm in a watch and see, I'd like to buy more but at what price. The BTCs I now own were bought much lower. If the ETF decision is positive we may never see lower again, if negative or ambiguous who knows where the price will go. Down I suppose, in which case I'll buy more when it settles.


text:
Was the addition of OP_NOP codes in Bitcoin 0.3.6 a hard or soft fork?
I'm doing some deeper research into historical consensus changes and it seems like most folks consider the addition of the OP_NOP codes to be a hard fork. Here's the diff for their addition: https://github.com/bitcoin/bitcoin/commit/a75560d828464c3f1138f52cf247e956fc8f937d#
However, some time ago gmax mentioned to me that it was effectively a soft fork because older clients ignored unknown opcodes. After perusing the code I can see why that might be the case, but I could use some input to gain consensus from people with superior C++ skills.

When the script interpreter encounters an unknown opcode (the default: case inside the switch statement), it returns false. That aborts verification and considers the transaction to be invalid. This was the case before 0.3.6, in 0.3.6, and still today.
Thus, certain transactions could have been created which pre-0.3.6 clients consider invalid, and post-0.3.6 clients consider valid - a backward incompatible consensus change or hardfork. However, as far as we know, no such transactions were ever mined (or even created), so while it is a backward incompatible change, without such transactions, the incompatibility wasn't actually observable.

"However, as far as we know, no such transactions were ever mined (or even created)" Can you expand upon this? Are you saying that in the entire blockchain history, no one ever spent a transaction from a locking script that included OP_NOP2 or OP_NOP3? I see that OP_NOP1 was never used because OP_EVAL was abandoned. But it looks like OP_NOP2 became OP_CLTV and started being used on December 8, 2015. As I understand it, the first OP_CLTV spend should have triggered a hard fork condition for pre-v0.3.6 clients.

No, I meant: there were no two competing chains that we know of. And no failed attempts by miners to get transactions with the then-new OP_NOPn opcodes into blocks (failing due to other miners/nodes not having upgraded). AFAIK, the first usage of OP_NOPn was long (possibly years, but I haven't checked) after the entire network had migrated to 0.3.6+, meaning that while there was a hardforking change, there was no actual fork.

There is nothing to suggest in the code diff you linked to that older clients ignored unknown opcodes in script execution and effectively treated them as OP_NOPs. That doesn't guarantee they didn't of course without looking through the code of all older clients.
However, it wouldn't make much sense to have all unknown opcodes treated as OP_NOPs and then later specify that 10 particular opcodes were OP_NOPs (OP_NOP1 through OP_NOP10). OP_SUCCESS hadn't been implemented at this time so the only two options for unknown opcodes were treat them as OP_NOPs or fail the script. Going from failing the script to being treated as a OP_NOP is a relaxation (rather than restriction) of the consensus rules and hence would be a hard fork.
(Of course in 2010 the terms soft fork and hard fork hadn't been invented so it wouldn't have been a conscious decision to "hard fork" the protocol!)


text:
How probable is a sybil attack?
I'd like to know what's the probability of a sybil attack and if there are mechanisms built in to prevent this kind of attack?

It is impossible to say what the probability of a sybil attack is as (as far as I'm aware) there are no public data sources on how many users/nodes have been subject to sybil attacks and no reliable reporting when occurrences happen.
However, I think it is safe to say the probability of a normal user being subject to a sybil attack is pretty low as it is hard for the attacker to prevent you connecting to a single honest node and there is very little for an attacker to gain unless they have significant hash power and can compete in the mining of blocks. Without significant hash power all they can do is prevent you from receiving the latest blocks and latest transactions. There is more to gain from sybil attacking mining pools as in theory the attacker could prevent mined blocks from being propagated across the network and prevent them from receiving block reward(s).
With regards to mechanisms in say Bitcoin Core, it is impossible to identify ahead of time which peers are malicious and controlled by the same party. All nodes are treated the same on the network unless and until they start misbehaving (e.g. propagate invalid transactions, blocks). There is some ongoing work (asmap) to ensure greater diversification of peer selection through stronger bucketing. There are also various things you can do proactively as a user. If there is a node you trust you can connect to this peer manually. If you haven't been receiving blocks for a number of hours (and you have peers) you can check a block explorer (mempool.space, blockstream.info etc) to see if there have been blocks mined in this time. Although you generally shouldn't need to, doing out of band checks can give you the assurance that your node isn't subject to a sybil attack.

Probability is the wrong thing to ask about. Attacks don't happen randomly; they happen deliberately. The question to ask is what the attack costs, and what someone stands to gain from it (this is more a comment on the question than on the answer, just pointing out that it's inherently unanswerable).

@PieterWuille: I agree the attack costs are highly relevant. The higher the cost the more out of reach the attack is from most potential perpetuators. I'm skeptical on trying to assess "what someone stands to gain from it". It could be anyone from a Western state actor to a rogue state actor to an altcoin advocate to just a well resourced bored hacker. If an attack is possible and affordable it could be carried out for multiple reasons. That's why I think probability factors in. If you just want to cause disruption you are going to pick the lowest hanging (most probable to succeed) fruit first

Admittedly this isn't an exact science and you may have given this much more thought than me! But that's my current thinking anyway :)

One cool thing about Bitcoin is that coins are inherently scarse and this is by itself a huge protection from sybil attacks. In other P2P systems, sybil attacks are much harder to prevent because there's no such concept of scarcity. In Bitcoin, a sybil attack would be achieved if one has lot of coins, by sending tons of transactions, and therefore spending such coins.
There are other types of sybil attacks such as overloading nodes connections, and the recent one of filling up the memory pool of specific nodes with really tiny transactions. A way to prevent these would be for example to increase the fees.

How does coin distribution have anything to do with a Sybil attack?

because the transaction, which is what might be sent across the network to produce a sybil attack, represents a transfer of value and therefore cannot be simulated by a gazillion simulated peers to disrupt such network: the size of his attack is always proportional to the amount of transferable coins he owns.


text:
What is the function of LOCK(cs_main)?
Does LOCK(cs_main) pause and branach the program in order to do some necessary job before going on?
I'm trying to publish blocks reactively (as a selfish miner) upon receipt of inventory message from pfrom and react to it after *pfrom* catches up with the  height of my secret block.
Following lines didn't help/there was no reaction on selfish node's side:
added following lines in main.cpp: after l. 3662
   ...
        {
            LOCK(cs_main);
            pfrom->PushMessage("inv", pfrom->vPrivateInv);
        }
   ...

LOCK(cs_main) causes the thread to stop execution until a lock can be obtained on cs_main. cs_main is an object representing a type/class/scope of lock. Once the lock is obtained, it lasts until the end of the LOCK statement's scope. (The LOCK macro creates an object on the stack, the destruction of which releases the lock.)
cs_main is already locked in that place, and LOCK uses recursive locks, so your LOCK doesn't do anything.

Ok thanks. How do I release lock after completion of following task? Is lock(cs_main) the correct lock to use at this place

It's automatically released at the end of the scope in which the LOCK is declared. It works similar to a boost::lock, but has some extra debugging logic that can be enabled.

Theymos: LOCK uses recursive locks, so locking twice should just be a no-op.

@PieterWuille so does a lock pause all other tasks / threads? Or just database writes ?

@pinhead It pauses the thread it was invoked from, until the requested lock can be grabbed.

@PieterWuille but what is locked?

@pinhead I don't know what that means. There are a number of locks (cs_main being one of them), and each lock can be held by at most one thread at a time. If the lock is already held by another thread, LOCK(cs_main) will pause until the lock becomes available. In any case, the code being executed will not progress past the LOCK(cs_main) statement without holding the cs_main lock.

@PieterWuille thanks that answers my question


text:
Why are some bc1 addresses 42 characters and others 62 characters in Base58?
The length of bc1 Bitcoin addresses varies between 42 and 62 characters in Base58 encoding. What causes this difference in character count?

P2WPKH (pay-to-witness-public-key-hash) addresses are 42 characters in length and P2WSH (pay-to-witness-script-hash) addresses are 62 characters in length (see here). bc1 addresses also use bech32 encoding rather than base58.
For an explanation of why P2WSH addresses use larger hashes (256 bits) than P2WPKH addresses (160 bits) see this post.
As Pieter states:

P2PKH, P2WPKH, and P2SH addresses have 160-bit hashes in their addresses. For P2PKH and P2WPKH this is fine, as it only supports single-party construction. However, as P2SH supports multisig and other multi-party constructions, it means an ~280 attack is possible(*). Bitcoin typically has a 2128 security target for attacks, so this is insufficient. That doesn't mean such a collision attack is practical - it's just far weaker than what the rest of the system provides, and as computing performance increases it may become feasible for well-funded parties.
To address this, P2WSH introduced a multi-party-capable address that contains a 256-bit hash, so it has ~2128 collision security.

There are as of today 3 types of native segwit outputs:

P2WPKH (pay to witness public key hash), where the output (and thus address) contains a 160-bit public key hash.
P2WSH (pay to witness script hash), where the output (and thus address) contains a 256-bit script hash.
P2TR (pay to taproot), where the output (and thus address) contains a 256-bit public key (not a hash!).

Addresses that contain a 256-bit value need 62 characters, while ones that contain a 160-bit value need just 42 characters, in bech32(m) encoding. Note that base58 is only used in P2PKH and P2SH addresses, which predate segwit (bc1) addresses.

P2WPKH addresses have 42 characters, while P2WSH addresses have 62 characters.
This difference is due to the fact that P2WPKH bc1 addresses include a hash of the public key that is 20 bytes long, and P2WSH bc1 addresses include a hash of, let's call it, the redeem script that is 32 bytes long.

nit: It isn't encoded in hexadecimal (0-9 and a-f). A bech32 address contains letters beyond f e.g. x, y and z

@MichaelFolkson Totally agree. I accidentally wrote "hexadecimal characters". Thanks for the correction.

Those starting with bc1q are SegWit (42),
Those that start with the name bc1p are Taproot (62),
SegWit addresses are common and Taproot addresses are new

This is not entirely correct; P2WSH addresses are also 62 characters.


text:
multiple multisigs with minimal cold devices
I want to maximize security but minimize complexity. Let's say I have large enough sums of BTC that need to be secured into three buckets:

KYC Personal BTC
Non KYC Personal BTC (mined)
KYC Company BTC (maybe uses Lightening/BTC as a merchant for business purposes)

I don't want these commingled for privacy, security, but also accounting and taxation purposes. The goal is to have a 2 of 3 multi sig for each category with a hardware signer for two of the private keys with one hot wallet as the third private key. For Example:

Is it possible for each hardware device to have three distinct (seeds) private keys one for each BTC category? In the scenario above I have two hardware devices to manage and nine private keys that need to be physically secured.
If not then my only option us to have a different hardware signer for each private key for each multisig, for example:

In this case, I still have the same amount of private keys to manage (nine) but now I also have six hardware devices to manage. Seems to be getting out of hand.

You could give this a little love by replacing the figures for texts.

Is it possible for each hardware device to have three distinct (seeds) private keys one for each BTC category?

Every hardware device that supports HD (hierarchical deterministic) wallets will be able to generate multiple child private keys (and public keys) from a single seed and master private key. Hardware devices generally don't support multiple seeds/mnemonics in parallel. But for what you want to do generating multiple private keys from a single seed is sufficient.


text:
Is there any on-block exchanges?
I'm new to bitcoin and just learned that most (or maybe all) of the exchanges are working off-block, meaning that they don't really push data to blockchain most of the time.
Is there any altcoins or exchanges that store data in blockchains ? I'm doing researched project on the matter and trying to find exchange that have some of it's trading public.
As I understood from this outdated article, Kraken might been on-block exchange in the past.
BitSquare might be something I'm looking for, but I'm not sure exactly how does it work.

Generally speaking, decentralized markets such as LocalBitcoins and BitSquare have the money onchain as they facilitate exchanges directly between users, and centralized markets that take custody of the money prior to trading have the funds offchain as otherwise the transaction fees they're spending would be much higher.
I think that in the past Coinbase and Kraken both kept user deposits in separate addresses for each customer.


text:
How is the lightning network secured against hacking and double spends?
As I understand payment-channels, like the lightning network, they are working off chain (no record in the blockchain). The only record to the blockchain is the deposit transaction to open the payment-channel and by closing the payment channel. But later all the transactions inside the payment-channel running on centralized servers, like traditional bank transfers. This is very fast, and could be very cheap if there is competition. But how the banks, who would run such payment-channels can secure that inside the payment-channel the transactions are not hacked and safe? And how the bank guarantee the customers that they dont double spend the funds if inside the channel all transaction are totally anonymous?

All transactions that are sent between the two parties in a channel are valid bitcoin transactions, and they can be used to close the channel at any time by either party.
When a channel is opened, those bitcoins are locked up in that channel until it is closed with a spending transaction, sending an agreed amount of bitcoin to each party in the channel. Initially this spending transaction is created to return the same amount of bitcoin that each party put in to the channel. But 'transactions' are made, which is really just each party agreeing to create new spending transactions to replace the old one, giving each party a different amount.
If each party, for example, locks in 1 BTC to a channel, they will also create a spending transaction at the same time returning that 1 BTC to each person. Then let's say person A wants to send 0.2 BTC to person B. To do this, they simply work together to create a new valid spending transaction to replace the old one, the new one would pay A 0.8 BTC and B 1.2 BTC, effectively transferring that 0.2 BTC from A to B. New transactions like this are continually created every time either person wants to send coins, until finally one of the two participants wishes to close the channel and actually get their BTC back. This also happens if one party stops responding/cooperating. The final transaction they agreed upon is broadcast to the actual blockchain, closing the channel and paying both participants.
Thus, at all times, the transactions are valid and the actual bitcoins being exchanged are locked up in the blockchain, so there is no way for anyone to double-spend the transactions.

But what is the news here? who guarantees that the concluding transaction in the channel will be added to the blockchain in a timely manner? and what if in 2020 it takes 10 months to get 3 approval (even for lightning channels as it seems to be yet another client of the network)?

Some hope is in the fact that with fewer on-chain transactions (more lightning adoption), there will be less congestion and so transactions will confirm faster. But it is likely some more on-chain scaling will take place too in the coming years

So that means: You have to block your coins for a channel. So, you can't use them for other things. So basically: I can't work with my coin. I can't trade them, I can't spend them. They stock in this channel. Is that correct?

@PhilippBlum no! You trade them within the lightning network! You just don't update the blockchain until the channel closes

@MeshCollider I understand this. But you can only spend this to one party. Let's say, you have something where you have 20 transactions per month. So, but it is to low to spend everytime transaction fees. So, you open a channel. So now you have to block some coins to this channel. You cannot use this coins for another channel or the blockchain, right? So they are blocked for one month.

Once locked in a channel, they can only be used on the lightning network yes, until the channel is closed (which can happy at any time if users cooperate, normally you don't need to wait 1 month). But you can send them anywhere on the network by routing payments through other channels created by other users, you aren't limited to sending to just the other user in the channel

But that one party may then relay the payment to a third aprty. Generally assume that you will lock up "significant" funds with one hub (significant: not a coffe but your hot wallet) and the hub will then have many channels open to many users and other hubs. And also assume you do NOT regularly close the channel every other week. You can spend them - on lightning. You can trade - because it is assumed that guess what, exchanges will accept lightining transfers. Basically: a LN channels "is" a hot wallet.

Transactions in a payment channel are still real Bitcoin transactions. They require the cooperation of both parties in the channel, so there is no bank and no central party that can rewrite history or double spend anything in a channel.
In order to change one party's balance in a payment channel, both parties must agree to it and sign the commitment transaction that changes the balances. So neither party can double spend nor can they change the transaction history without the other party agreeing to it.
To avoid a malicious party from broadcasting an old commitment transaction where they had a higher balance, such commitment transactions have a revocation key where the other party that would be defrauded is allowed to take ALL of the Bitcoin in the channel. This is an incentive for people to not broadcast old commitments as they would lose all of their money in the channel.

At one point, sidechain channels have to be closed and a real transaction will happen on the bitcoin blockchain. When the channel close, it is the responsibility of both banks to make sure that everything is fine and they were not hacked. They have no incentive to allow double spend from any of their clients since it will result in a loss of money for them.
Banks agree on the direction and the amount of the bitcoin transaction, then they send the transaction. If there is any disagreement between them or if one of the bank is not honest, no bitcoin transfer will take place and each bank keep the same amount of bitcoins it had before the channel started.
One important point to note is that no individual client transactions ever took place on the bitcoin blockchain. Only a transaction between Bank 1 and Bank 2 will be recorded. The blockchain is not involved in the details of the client transactions between both banks, only the aggregation of all transactions will be recorded on the blockchain.
Example:
Bank 1 send payments to Bank 2: A + B + C

Bank 1 receive payments from Bank 2: D, E

Sum_TX = A + B + C - D - E

When the channel is closed, if Sum_TX > 0:

 * Bank 1 will send Sum_TX bitcoins to Bank 2
 * Bank 2 will send Sum_TX bitcoins to Bank 1

Thanks for your explication, but if responsibiliy and trust between the partys inside Lightning network, are the only things who garanty that there will be no doble spend inside the channel, than whats the differents between lightning and the banking system today, wich also is based on trust ... and how that goes out ... you know. And perhaps the banks dont cheat each other , but there is a big incentive for them to cheat the client, as they do today, with fractional reserve banking etc ... i prefer Bitcoin a trustless peer to peer digital cash as Satoshi Nakamoto point out in his white paper

Actually no. There is a financial incentitive not to try to cheap and it is part of the protocol specs. The cheating party looses their money in the channel.

How do you know who cheated? What if both parties claim they were cheated by the other, but one of them actually was. How does the network know who is telling the truth?

authors: ايمن عبدالله علي غالب الحمزي

authors: بشار الزايدي


text:
How is Zclassic's pszTimeStamp generated, and what does it mean?
How is pszTimestamp from Zclassic generated, and what does it mean ?
Zclassic860413afe207aa173afee4fcfa9166dc745651c754a41ea8f155646f5aa828ac

Any idea?
Same encryption is used in BTCP and Zcash.

The derivation is given in the Zclassic codebase:
from pyblake2 import blake2s
'Zclassic' + blake2s(b'No taxation without representation. BTC #437541 - 00000000000000000397f175a94dd3f530b957182eb2a9f7b79a44a94a5e0450').hexdigest()

The reason they generate it in this way is because Zcash generates its pszTimestamp like so:
from pyblake2 import blake2s
'Zcash' + blake2s(b'The Economist 2016-10-29 Known unknown: Another crypto-currency is born. BTC#436254 0000000000000000044f321997f336d2908cf8c8d6893e88dbf067e2d949487d ETH#2521903 483039a6b6bd8bd05f0584f9a078d075e454925eb71c1f13eaff59b405a721bb DJIA close on 27 Oct 2016: 18,169.68').hexdigest()

And the reason Zcash generates it in this way is because there is a consensus rule (inherited from Bitcoin) that limits the size of a coinbase scriptSig to a maximum of 100 bytes.


text:
Why do wallets use multiple private keys instead of one each?
I am learning about Bitcoin and when I was about to export my private key from a single electrum wallet, I found that there  were in fact a lot more than one. Why is that so, don't you only need 1 private key to hold all bitcoins and manage them?

Possible duplicate of Should I use a different address for every transaction?

Why is that so, don't you only need 1 private key to hold all bitcoins and manage them?

Sure you could use only one private key and its associated address, but that is not recommended. It is more secure and more private to not reuse addresses. Instead you should use a new address for every transaction you receive and for every change output you make. Thus your wallet will have multiple private keys for the multiple addresses that you are using.
Most modern Bitcoin wallets support a feature known as Hierarchical Deterministic addressing, which generates new private keys and corresponding public keys each time you receive cryptocurrency, providing far better privacy.

I think, you should consider this example:
I know you maybe join more than one group (example: coffee group, friend group, or study group).
If you want to make some transactions to one of those group, if you use only one address, you will be captured or somebody in some group can know that there is a person in the coffee group who are in study group too.
And someday, somebody can detect who you are.

authors: Наталья Шулакова


text:
Is supply reduction consider as a hard or soft fork?
I'm writing an article about current Minergate Dashcoin hard fork. From all the bitcoin hard fork talks I get the impression only when block size increases will result in a hard fork. How about coin reduction(for example, 10000 to 1) Is it considered as a hard fork? or not a fork at all? Assume the chain didn't split.

What do you mean with "coin deduction"? Are you talking about a reduction of the block reward? Alternatively, your title makes me think you meant a blocksize reduction?

Sorry, I meant Coin Reduction, I've changed the title. Thanks for the comment.

So, each coin value will simply be divided by 10k and rounded down?

Yes, and all pools need to be upgraded.thread community update #3.


text:
Access Bitcoin Blockchain to analyze transfer patterns
I am interested in analysing patterns in transfers between bitcoin users. Is it possible to extract the following data from the bitcoin ledger:

time
sender
amount
receiver

I don't need the real identity of sender/receiver. I understand that the address can be used to approximate unique users? Is this correct?

Welcome to Bitcoin SE!  Is your question about how to get the blockchain?  How to read it?  How to understand transactions?  It's unclear, which makes this question grounds for closing.  Please revise to ask a specific question.  Also feel free to ask multiple questions, since that makes the site better for everyone.

Jestin- hope my q is more specific now

Thanks.  Ultimately, it's up to the community to decide if it's specific enough.  Otherwise, it will be closed.

You may read the following article on visualizing bitcoin transactions as well as blocks. There are few very good websites enlisted which have helped me to learn a lot as well. https://datalion.com/visualizing-blockchain-7-beautiful-informative-bitcoin-visualizations/

Is it possible to extract the following data from the bitcoin ledger: (time, sender, amount, receiver)?

Something like that would be possible, you could run your own bitcoin node and query the data from that, or use an API from a site like blockchain.info, which provides transaction data. Here's an example of a transaction from blockchain.info:
https://blockchain.info/rawtx/a196032e52c0a9d7a9737ffa212f029bceb9618d0bff5c6dde99ecac4e28bf06
Note that transactions do not have times encoded into them, the time such a site gives would just be the time that site received the transaction first.

the address can be used to approximate unique users? Is this correct?

This is not correct in general, while some users may reuse the same address for every transaction (one-to-one), other users generate new addresses for every transaction they receive, so there is a many-to-one relationship between addresses and users. In the more uncommon case, there are also multisignature addresses, which often involve more than one person approving any spends from that address, so that you sometimes have a one-to-many relationship between the address and the users. All addresses of that type start with a '3' or 'bc1' though. So its a lot more complicated to make assumptions about users than it is to just look at addresses.

authors: Евгений Шевченко


text:
Bitcoin mining, do you do the work or does the computer?
Assuming you have the appropriate hardware and software, does mining involve the person mining to sit at the computer to mine or do you fire it up and just let the software run and check back later to see the results?

Bitcoin "mining" is essentially solving difficult math problems.

You can do it by hand. See: https://www.youtube.com/watch?v=y3dqhixzGVo

The extent of human involvement in mining is to get the software and hardware and then run the software on the hardware. No one actually has to sit at a computer and do anything in mining. They don't even have to come back and check on anything as all aspects of mining are automatic save for computer setup and maintenance.

Thanks MeshCollider and Andrew Chow, are you both miners?  Is there decent profit in mining?

I do not mine, but it is easy to understand how mining works without being a miner. There is profit in mining if you can sink a lot of money initially into ASIC miners.

I do not mine either, agree with what Andrew said :)

The latter, the person doesn't have to do anything. The computer/ASIC will usually be running software which creates a block candidate automatically after it receives each new block (or in pool mining, when it receives a candidate block from the pool server), and will then hash the block repeatedly with different nonces/extra data in the coinbase transaction until it finds a valid hash. If it does so, it will automatically send it to the network/pool server and begin working on the next block. Its mostly completely independent unless something crashes and requires a person to restart it

Thanks MeshCollider and Andrew Chow, are you both miners? Is there decent profit in mining?

You just have to fire it up and wait for the result.
The only human involvement is at the beginning of the process to select the hardware (ASIC, SSD Drive, etc) the best way (solo mining or pool mining), the best pools, if you choose pool mining, and things like that.
Unless and until there is a power outage or hardware failure or network issue, you don't have anything to worry about.


text:
stop on alertnotify
  -alertnotify=<cmd>
       Execute command when a relevant alert is received or we see a really
       long fork (%s in cmd is replaced by message)

How to stop Bitcoin Core on a really long fork?
-alertnotify=stop?
-alertnotify="bitcoin-cli stop"? (assume valid bitcoin-cli can be found in $PATH)

bitcoin-cli stop. All these *notify interfaces accept some cmd as argument.


text:
Can a descriptors wallet be encrypted?
Bitcoin Core provides a builtin feature by which Berkeley DB Bitcoin Core legacy wallet files can be encrypted with a passphrase.
Can the same or similar be done to Bitcoin Core descriptors wallet files?

I'm assuming you are asking if there are instructions to be able to encrypt descriptor wallet files? I'm assuming you know that any data of any form can be encrypted?

I suspect OP is asking whether Bitcoin Core supports encrypting private keys in a wallet file, not about file-level encryption in general.

@MichaelFolkson edited :D

Yes, descriptor wallets can be encrypted using Bitcoin Core's passphrase encryption feature, just like legacy wallets.
It encrypts just the private keys, so encrypted wallets can be used normally for most purposes without access to the passphrase, but sending/signing do need it.


text:
Cannot build circuits because we don't have enough directory information
I'm developing a bitcoin wallet app using BitcoinJ framework. While deploying the app using Tomcat 8, I get the following stack of errors,
12-Jun-2017 14:18:12.511 INFO [PeerGroup Thread] com.subgraph.orchid.TorClient.start Starting Orchid (version: 1.0.0)

12-Jun-2017 14:18:12.514 INFO [Thread-12] com.subgraph.orchid.directory.DirectoryImpl.loadFromStore
Loading cached network information from disk

12-Jun-2017 14:18:12.516 INFO [Thread-12] com.subgraph.orchid.directory.DirectoryImpl.loadFromStore Loading certificates

12-Jun-2017 14:18:12.518 INFO [CircuitManager worker-0] com.subgraph.orchid.circuits.CircuitCreationTask.checkCircuitsForCreation
Cannot build circuits because we don't have enough directory information

12-Jun-2017 14:18:12.601 INFO [Thread-12] com.subgraph.orchid.directory.DirectoryImpl.loadFromStore Loading consensus

12-Jun-2017 14:18:12.917 WARNING [Thread-12] com.subgraph.orchid.directory.consensus.ConsensusDocumentImpl.verifySingleAuthority
Consensus signed by unrecognized directory authority: 0232af901c31a04ee9848595af9bb7620d4c5b2e

12-Jun-2017 14:18:12.943 INFO [Thread-12] com.subgraph.orchid.directory.DirectoryImpl.loadFromStore Loading
microdescriptor cache

12-Jun-2017 14:18:13.160 INFO [Thread-12] com.subgraph.orchid.directory.DirectoryImpl.loadFromStore loading state file

12-Jun-2017 14:18:15.662 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying
web application directory [/Applications/Tomcat-8.5.15/webapps/manager]

The last 2 lines of the stack,
org.bitcoinj.core.PeerGroup: 06/12/2017 14:53:36 - Tor ready
org.bitcoinj.core.PeerGroup: 06/12/2017 14:53:36 - Localhost peer not detected.

I believe Tomcat deployment is fine and one of the errors is crucial informing -com.subgraph.orchid.circuits.CircuitCreationTask.checkCircuitsForCreation Cannot build circuits because we don't have enough directory information
I use maven as the build tool and get the RELEASE version of the BitcoinJ as dependency in the project.
<dependency>
    <groupId>org.bitcoinj</groupId>
    <artifactId>bitcoinj-core</artifactId>
    <version>RELEASE</version>
</dependency>

I recently loaded RAM in the system and upgraded to the OS Sierra. I had the surprise, I couldn't use maven from the terminal afterwards and set that up manually. Current Maven information,
$ mvn -version

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-04T01:39:06+06:00)
Maven home: /Users/Chaklader/apache-maven-3.5.0
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.4", arch: "x86_64", family: "mac"

How to approach to the problem properly ?

Cannot build circuits because we don't have enough directory information

This is an exact duplicate of a standard Tor error message usually only seen for brief periods after Tor node startup.

Solved by itself. I guess the info Localhost peer not detected was behind the scene. Now, after finding the peers I have the app synchronized to the blockchain


text:
Error help! "A fatal error occurred. Bitcoin can no longer continue safely and will quit."
I synchronized fully, replaced the wallet.dat file, rescanned and this happened.
My debug log:
https://drive.google.com/file/d/0B7me4XCWsORySzdMMEpYWU5Lakk/view?usp=sharing
Screenshot of Error:

Your wallet is currently corrupted. DO NOT START BITCOIN CORE WITH -salvagewallet, THAT WILL ONLY MAKE THINGS WORSE. From your log file, I see that you have already done that and it is in fact the current source of your problems. What version of Bitcoin Core was this wallet created in?

I have no idea its been sitting unused since around 2014 ish i think. but i still have the original copy of my wallet. I downloaded the copy that I used -salvagewallet on. but it was causing crashes before I tried the salvagewallet command on it.

Try using a copy of the original wallet.dat file. Don't do -salvagewallet, just load it in and see what happens.

@AndrewChow tried that it went through the reindex and even showed the last transactions (which were from like 2014) But when i tried to send it too a different address it crashed as soon as i entered my password to unlock my wallet.  here is the new debug.log link  and the db.log file link

It appears that your wallet.dat file is corrupted. From your log files with the original copy of the wallet, it looks like you made that copy of the wallet before Bitcoin Core closed the wallet database (which actually includes more than the wallet.dat file but those other files are temporary and only exist when the database is open) which has resulted in corruption.
Since you have already used -salvagewallet on a different wallet file, just use that wallet.dat file. Note -salvagewallet has some issues and is not guaranteed to fix corruption. Because your wallet is old enough, it does not use HD keys, so the following workaround should work: start Bitcoin Core with the -usehd=0 option or add usehd=0 to your bitcoin.conf file.
This is a workaround and should allow you to open your wallet and retrieve your private keys. Your wallet.dat file is still corrupted and you should stop using it immediately. You should move your coins out of that wallet file ASAP by following the instructions here.

so are you saying to use the copy of my wallet that i used the -salvagewallet command on? or use the copy that i did not use the command on?

Use the copy that you used -salvagewallet on.


text:
Found an old wallet with transaction history with coins (unconfirmed), but no balance
I have found an old bitcoin wallet in my files. I can see there are old transactions but they aren't confirmed. But there should be more BTC received than was sent, so there should be a balance. Is there anyway to get those transactions confirmed from 2013. And how do I check those addresses to see if there is any balance in those wallets?

Is your wallet fully synchronized?

To check balance, just use this link: https://blockchain.info/address/your-wallet-address-here to check the balance of any wallet. You can also see all the transactions happened through that link.

Yes it's fully synced up. Let it run for a few days also,
How could I have the old transaction history but it's not ever on the block chain?

It can be a double spend, so over time,the transactions which was just broadcasted, but confirmed can revert.


text:
How i can delete last block from blockchain? altcoin
How can I delete the last block from blockchain to be ready for hardfork.
What I mean is, in blockchain last block is with error's. I want to delete those blocks, for the new blockchain is disabled from the last block.

How can I mine new block if last block would be 1 day old? How do I understand that the daemon does not start giving work to pool/miner, if last block is very old? They will be trying to find new block's from peer, even if it does not exist ?

You can't delete a block, just mine a new block on top of the previous block, creating a fork. Just reference the parent block as the parent of your new block, and if you mine more on top of your new chain, it will become the accepted chain.
The age of the block shouldn't matter.

where i can read about it with more detail's, i little not understand how i can reference if it's need to bee based on previous block( mined ). About age block.
before daemon start say ( 100% searchen for new block's on network , getblocktemplate start after by sync...)

i to think its shouldn't matter.

First sync up your client with the latest blocks. And then you can continue from there. But blocks are irreversible. That's how the blockchain is designed.
https://en.wikipedia.org/wiki/Bitcoin

authors: سینا بهرامی نژاد


text:
I want to know how can get back my bch
I have incorrectly sent bitcoincash to bitcoin wallet address. (from upbit exchange in korea to kucoin exchange in hongkong)
Is there any way to get my bitcoincash back?


text:
What are the exact steps for creating a transaction and having a valid block?
I have read all kind of the articles and I understand almost all the concept from cryptocurrency. What I still don't understand is, what are the steps from transactions to a valid block.
On a post on this SE I found this:

Collects transactions from the network
Validates them, and doesn't allow conflicting ones
Puts them into large bundles called blocks
Computes cryptographic hashes over and over until if finds one "good enough to count"
Then submits the block to the network, adding it to the blockchain and earning a reward in return.

Let's take a practical example and please correct me if I make some wrong steps:

I send 10BTC to Batman.
Because I have send BTC, a transaction is created in system.
This transaction is send to all nodes from network (all users)
After transaction arrives to all users, the transaction is added in a queue where the miners take take their transactions.
A miner take transaction, process it (proof of work) and creates a block with more transactions.
After all the transactions are validated by miner, the new block is send in the network for check.

Now, questions:

How does each user check this blockchain (divide the blockchain and check each transaction if the transaction from the blockchain is the same with the one that he has (because first transactions are send to all the users from p2p network and after that are send in the queue to be process by the miner. This is how user is able to compare the transactions))?

I send 10BTC to Batman.
Because I have send BTC, a transaction is created in system.
This transaction is send to all nodes from network (all users)

That is correct so far

After transaction arrives to all users, the transaction is added in a queue where the miners take take their transactions.

Yep, although its not really a queue because miners don't necessarily have to take the first transactions first. Its called the mempool, and its just a bit collection of them, with no enforced order.

A miner take transaction, process it (proof of work) and creates a block with more transactions.

I'd just like to make it clearer that the proof of work is the name given to the hashing of the entire block, proof of work is not the verification of the transaction. Verifying the transaction doesn't take much work, only creating the block does.

After all the transactions are validated by miner, the new block is send in the network for check.

After all the transactions are validated by the miner and the miner has found a valid proof of work block, that new block is sent to the rest of the network. Just valid transactions alone does not make a valid block. You are missing the idea of "Computes cryptographic hashes over and over until if finds one 'good enough to count'" that you mentioned. That is the proof of work.

How does each user check this blockchain (divide the blockchain and check each transaction if the transaction from the blockchain is the same with the one that he has (because first transactions are send to all the users from p2p network and after that are send in the queue to be process by the miner. This is how user is able to compare the transactions))?

Users can just compare the transaction hash with the ones in the blockchain, because the hash is a deterministic "summary" or digest of the transaction. The same transaction will always have the same hash, but two different transactions will have different hashes. Full nodes always validate all the transactions in the new block when they receive it anyway, they don't just trust the miners.

As a node (user, when i receive a new block) how can i say that transaction inside that block are valid and not tamper by the miner if is the first time when i see that transaction? I can understand this if before a transaction is send in mempool also to be send to each node from p2p network and to store this transaction. When a new block arrives i can compare my local transactions with those from block. If a local transaction match with one from block is declare as valid else i not valid. This is how i see the things but i don't thing is write.

@Adrian a transaction has to be signed by the sender, if the transaction was modified the signature would not be valid. So as long as the signature is valid, you know the transaction is not tampered with

One more question. How can i know that signature was not tampered? I guess this signature is a hash on date or something like this.
How can I know(me as a node) that the transaction I am looking at has a valid signature and was not tempered? Thanks

If the signature was tampered with, it would be invalid

I think i understand. Is something like..each transaction has a flag when i create the transaction this is set to true (sig is ok) if someone will change in any way this signature this flag will be false.(this is a way to see things, there maybe is more complicated way to validate transactions). What i am trying to say is that each transaction has a mechanism that will reveal if a transaction has been tempered or not. I am right @MeshCollider? :)

@Adrian yes, you can always tell if its been tampered with :)


text:
Help needed with upgrading bitcoin ABC
I'm running my own bitcoin cash node. However, I'm getting stuck on the block where the network hard forked for the May 15th 32mb blocksize update. I believe the version of bitcoin abc I have installed is out of date, hence why it is stuck at block 530361. Here is the version with getinfo:
{
  "version": 160200,
  "protocolversion": 70015,
}

Is my node out of date? How can I upgrade my bitcoin abc node?
I tried:
sudo apt-get update
sudo apt-get upgrade

but nothing changes in the version or protocol version with getinfo. What should I do?

How did you install bitcoin-abc in the first place?

@NateEldredge I forgot how I originally installed it, awhile ago.

you can try apt list --installed | grep bitcoin to see if it was installed by apt-get. If not, then apt-get upgrade won't work. chances are you downloaded from https://download.bitcoinabc.org/ or built it from source. you should back up your wallet data file before any upgrade though.

For future readers: the Bitcoin-ABC client is (confusingly) not a Bitcoin client.

Yes, you need to upgrade.  You have version 0.16.2, and the 32MB block support was added in 0.17.0.  The latest release version is 0.17.2.
Your apt-get commands will only work if you originally installed bitcoin-abc from the apt package repository.  It sounds like you didn't.
You can check if you installed from a package at all with dpkg -l bitcoinabc.  If so then you can remove the package with dpkg -r bitcoinabc.  Otherwise you can figure out where the bitcoin-abc binaries are installed (using which or similar) and delete them manually.  Then install a new copy from scratch, either from the above-linked repository or any other way you choose.  (But this time make a note of what you did!)

dpkg -l bitcoinabc finds no packages, so yes I believe I installed from source. I want to install new copy from the repo, so I added ppa:bitcoin-abc/ppa. How can I specify the package I want though? apt-get install (name), but it says not found for every name I try. (already ran apt-get update after adding the repo)

Should just be called bitcoinabc, as far as I can tell.

@2523454: What Linux distribution / version is this?

0.14.04, I'm trying 0.16 now

No package found when running apt-get install bitcoinabc on both versions.

Hm.  What exactly got added to /etc/apt/sources.list.d?  When you did apt-get update, did you see it fetching the Packages file for the repo?  Any error messages?

Taking a look at sudo nano /etc/apt/sources.list, I see nothing bitcoin related. Here is my console after adding the repo: https://imgur.com/a/tIhYyx5

I have updated by manually compiling and installing the latest source code.

add-apt-repository normally adds a new file in the /etc/apt/sources.list.d subdirectory instead of modifying  /etc/apt/sources.list.  Anyway, glad you got it working.


text:
Are electrum's private keys 512 bits or 256 bits long?
I have recently been going through the python source code for electrum and encountered the following lines of code at the mneumonic.py file starting from line 130:
def mnemonic_to_seed(self, mnemonic, passphrase):
        PBKDF2_ROUNDS = 2048
        mnemonic = normalize_text(mnemonic)
        passphrase = normalize_text(passphrase)
        return pbkdf2.PBKDF2(mnemonic, 'electrum' + passphrase, iterations =
              PBKDF2_ROUNDS, macmodule = hmac, digestmodule =
               hashlib.sha512).read(64)

We see clearly that it returns a 64 bytes or 512 bit seed instead of what we all know a bitcoin priv key should be - 256 bits.
Is this the final function to be called for priv key generation or are there steps or functions that I missed?

The seed phrase created by Electrum has 132 bits of entropy. This means that it provides the same level of security as a Bitcoin private key (of length 256 bits). Indeed, an elliptic curve key of length n provides n/2 bits of security.

That's the key stretching function that adds a little bit of entropy to the seed. The mnemonic goes through that function and then the output of that goes through bip32_root() which runs it through sha512 again. BIP32 kinda requires 512 bits so that there are enough bits for the chain code and master private key.
Anyway the electrum seed is 135 bits effectively.

Is this the final function to be called for priv key generation or are there steps or functions that I missed?

You are missing a lot of steps.
The seed value is 512 bits because more bits is more secure, and BIP 32 specifies that a seed value between 128 and 512 bits should be used. It does not matter what the length of the seed value is because it will get hashed anyways and the result is 512 bits.
BIP 32 uses 512 bits because the value is split in half for two 256 bit values. One of those is the private key, the other is the chaincode.


text:
Why Bitcoin Mining requires "Hash Guessing" problems, even though Consensus algorithm exists to tackle BFTP?
This post on CoinText explains Purpose of Hashing in Bitcoin Mining:

The purpose of all the extra work is to prevent the traitors from sending false messages but serves no other purpose.

The idea seems to make the false/rogue attempts of Byzantinian nodes more difficult.
Since I am researching on this, would like the community's view(s) on:

We have Consensus algorithm in place to deal with false/rogue messages, then why is there a need to make the process more difficult by adding hash guessing work?
If we skip hash guessing work, how will it impact the resiliency or reliability of Blockchain?
Since hash guessing tries to make further rogue attempts costly and there is no value-add from the computation, can we route some other difficult problems to Miners to keep the message attempt difficult and still utilize resources to compute something of value?

"we have consensus algorithm"... what algorithm?  I know of no algorithm without a central trust, with the kind of resilience against bad actors that Blockchain has.

He means consensus rules for rejecting invalid (already spent) transactions.

@abelenky Blockchain has inherent rule/algorithm for invalidating transactions if consensus is not reached. This is being referred in the question.

For 1. And 2. check How proof of work prevents double spend. Removing the solving of difficult problems would allow double spending attacks as per cited thread.

I don't know but seems like an interesting idea.
EDIT: I thought of the same idea before. But the problem miners solve must have some specific properties.
In my opinion it must:

be randomly chosen (unpredictable) so that miners don't know the problem until previous one is solved (otherwise they would mine some block in advance and get a coin ahead of others). This is solved by including hash of previous block in the problem.
Be linked somehow to transactions it confirms so that transactions cannot be altered afterwards. This is solved by including hash of transactions (Merkle root) in the problem.

I think it is hard (or impossible) for the problem with these properties to be useful somewhere else.
Check also: Is there a way to set up proof-of-work systems so they would be even more useful?

Thanks croraf, PoW essentially makes it difficult to do double-spends and/or rogue attacks, but is not immune to it. I see a lot of opportunity to utilize miners compute power for solving real compute problems, and not just limited to adding a difficulty step for miners.

Adding my opinions about 3. in the edit.

answer should also add a reference to https://bitcoin.stackexchange.com/questions/331/is-there-a-way-to-set-up-proof-of-work-systems-so-they-would-be-even-more-useful for the 3rd item

The "consensus algorithm" you are referring to is predicated on the "hash guessing" you are trying to eliminate.
If we skipped "hash guessing," the resiliency and reliability of the blockchain would be completely destroyed.
This question assumes at least 2 false premises and cannot be meaningfully answered.

authors: Людвиг Попеко


text:
How to find the private key of blockchain wallet?
How to find the private key of blockchain wallet of this address 1DkyBEKt5S2GDtv7aQw6rQepAvnsRyHoYM

Without more information (did you ever have it, what wallet/service did you use, ...), the answer is "you don't".

Possible duplicate of I don't know how to export a private key from blockchain.info

I am hoping you are talking about blockchain.info
If yes, then I am again hoping that the above address you have posted is a wallet address in your blockchain.info
If again, the answer is yes, please follow the below steps:

Go to settings, then click addresses as shown below:

Click on more options aside your address whose private key you require as shown below:

In 'More Options' you will find "Private Key", please click it:

They will show you a warning as below, please click continue:

You can see your private key for the corresponding wallet address:

Hope this helps you!

Be aware that I was able to partially recover the private key from the QR code in your screenshot, so you probably want to edit that out (and contact Stack Exchange to have the original version purged).

I know people will do that mate, it's an empty wallet, and I don't use that ;)


text:
I lose my private key on my blockchain wallet
Can you please tell me how can I get my blockchain private key. I want to sell my coins. Please help me.

Did you make a backup of your wallet?

Welcome to Bitcoin.SE! If you have a blockchain.info wallet you should contact their customer support, otherwise please see the linked answer above your question.

look through all your devices that you accessed the wallet with- surely you made a copy of your private key somewhere
Only you had control of that ...
what service diod you use initially?
MEW or ? an exchange ?


text:
Uspent unconfirmed and stuck transaction
My transaction is stuck and unspent, not sure what to do next, can any one help?
https://blockchain.info/tx/65ebc1410a65222f88f703b9bde14defc0014deafb4c2909abce3b21cbf6df66
Address it was going to
https://blockchain.info/address/1CxuudZouS6TKRo9kmSNgCbxnimVtjHgqr
It was sent from Alt trader, I am happy to pay more fees, though not sure how, as the exchange did the transfer.

accelerated. this transaction will be confirmed shortly. if you are willing to pay - my address is in profile

How much should I pay.

Hi, how much should I pay to accelerate the transaction ?

@AleksRudy wait for confirmation. For more info email me.

Please drop me a email with your address my email is aleksrudysa@gmail.com

alistermaclin@mail.ru

According to blockchain.info, the transaction has a fee of 20 satoshis/byte. If you look at https://bitcoinfees.21.co/ you can see a summary of outstanding transactions and their fees, which currently shows there's higher fee/byte transactions for miners to include other transactions in their blocks before they get around to yours.
It will almost certainly confirm eventually. Otherwise, follow the link to the duplicate question, and there are some other suggestions.


text:
What happens if the power goes out during bitcoin mining process and system shuts off?
I am in an area where there is power outage. I want to know, what will happen to bitcoin or my wallet or anything. Just need the basic information here.

The wallet will be safe. (Unless your drive becomes corrupt and you have no backup of the wallet anywhere else)
Nothing happens to the BTC you already have.
The Blockchain will be out of sync until you sync it again.
If you were about to find the block, it will be lost and the reward will not be awarded.

I think it's fair to assume a properly backed-up wallet.  Otherwise it changes the question to something like "if I lose my wallet, do I lose my wallet?".  This question is about the mining process and power loss.  Whether data loss can cause bitcoin loss is a different question.

@abelenky added the additional info.

If you are not running a full node then it doesn't matter. Since you are asking you probably are not running a full node.

Although your bitcoin is completely safe on the decentralized storage of the blockchain, the real risk is losing the private keys in your wallet due to hard drive corruption or failure during a power outage.
Once private keys are gone, they are gone forever.
It would be prudent to make a backup copy of your wallet, or your private keys that you can keep safe if your hard drive is lost for any reason.