text:
Determinant of confirmation time
There seems to be a lots of variations in confirmation time.
https://blockchain.info/charts/avg-confirmation-time
I would like to understand factors that affects the confirmation time.

First, let's start with the definition of confirmation:

After a transaction is broadcast to the Bitcoin network, it may be
  included in a block that is published to the network. When that
  happens it is said that the transaction has been mined at a depth of 1
  block. With each subsequent block that is found, the number of blocks
  deep is increased by one. To be secure against double spending, a
  transaction should not be considered as confirmed until it is a
  certain number of blocks deep.

See: Confirmation
What this means is that you can determine the number of confirmations before you consider the transaction "confirmed", and this number represents the number of blocks since the transaction was put in the blockchain (including it's block).
So, the question becomes what determines block time?  This is determined by the current difficulty assigned by the network.  This difficulty is adjusted every 2016 blocks (about every 2 weeks) to get a target block time of 10 minutes.  So, if the hashing power of all the miners on the network increases significantly, the difficulty will compensate by increasing as well (once the 2016 blocks have been mined since the last adjustment).  Then, if the network hashing power drops off significantly, block time will take a lot longer because there isn't as much mining power able to solve the high difficulty every 10 minutes.
Note: Difficulty determines the target hash value that the block hash must be less than in order for it to be counted as a valid block.

Thank you. But it does not seem to explain why the confirmation time significantly increased in Dec 17.

You didn't ask that.  But transaction volume is an important component. One potential theory was that exchanges like gdax were not using sendmany in the transactions, so that significantly increased transaction volume.

Confirmation time is effected by two things: the time to find a block, and the transaction fee paid by a transaction.
Since a confirmation means that a transaction has been included in a block, one factor in the time for a transaction to confirm is the amount of time it takes to find a block. This is, on average, 10 minutes. However the time between blocks is not always 10 minutes, it can vary quite a lot, typically from a few seconds to 2 hours. This means that if miners just happen to be really unlucky for a certain block, then the confirmation time for a transaction could be very long.
The other limiting factor is the transaction fee. For a transaction to be confirmed, a miner must select it for inclusion in their block. The selection is based by transaction fee (specifically the fee rate). Transactions that pay a higher fee rate will be selected first. If there happens to be a lot of unconfirmed transactions, transactions with lower fee rates will take longer to confirm as they have to wait for the transactions that pay higher fee rates to be confirmed first. This will also effect confirmation times.

Then how do you explain that the confirmation time significantly increased in Dec 17?

@171124 the number of transactions sent was very high around that time, so many transactions that paid lower fees took longer to confirm, as the higher fee transactions were confirmed first.

https://jochen-hoenicke.de/queue/#1,1y

Thank you. So is it that many people want to buy/sell bitcoin at that time, and the demand for confirmation outstripped the supply of mining powers?

You could think of it that way. It's really the demand for transacting Bitcoin (buy/sell volume is irrelevant) exceeds the supply of block space for transactions (mining power is irrelevant, more mining power does not effect this much).

True. "The minimum fee necessary for a transaction to confirm varies over time and arises from the intersection of supply and demand in Bitcoin's free market for block space.[3] On the supply size, Bitcoin has a maximum block size (currently one million vbytes) that limits the maximum amount of transaction data that can be added to a block."(https://en.bitcoin.it/wiki/Transaction_fees#The_market_for_block_space)


text:
Understanding "anonymous transaction"
I have read

In the original Satoshi whitepaper, it was recommended that Bitcoin
  users use a new address for each transaction to avoid the transactions
  being linked to a common owner.

But in reality, when A buys a bitcoin from B, A sends money to B to B's account in an exchange (or whatever account.) It seems that B can be identified via this dollar transaction by an exchange or the authority?

Anyone can stay anonymous if he wants to stay anonymous, bitcoin was designed to put banks aside peoples cant understand that, that can be understanded only from peoples wich understand the term "privacy", 2018 & peoples buy bitcoins from exchanges only if their have verify their identify verified, thoose peoples dont understand the term "privacy", if you want privacy hold & use p2p exchanges - localbitcoins instead of online exchanges services.
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.

The original Satoshi client (now called Bitcoin Core) was developed from the whitepaper. Exchanges, online hosted wallets and many other things requiring identification came later. You can still run Bitcoin Core or a similar wallet on your desktop and many people value the anonymity.
You are right that when you use an exchange or another service where you are required to identify yourself, link bank accounts or, other similar activities you can be identified.

Yes you are right that these identifications came later. But how can one anonymously handle these dollar exchanges?

@171124 Your best bet is a service like localbitcoins.com or similar.

Just try to understand the mechanism.

@171124 Added to answer.

source: Stack Exchange

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

sort: votes


text:
Proof of Work: email versus bitcoin
I have read
"Hashcash is a proof-of-work algorithm that requires a selectable amount of work to compute, but the proof can be verified efficiently. For email uses, a textual encoding of a hashcash stamp is added to the header of an email to prove the sender has expended a modest amount of CPU time calculating the stamp prior to sending the email. In other words, as the sender has taken a certain amount of time to generate the stamp and send the email, it is unlikely that they are a spammer. " (https://en.wikipedia.org/wiki/Hashcash)
Then, in bitcoin, it seems natural that the senders engage in the proof of work instead of miners. Why it is not so?

There are cryptocurrencies that operate like this, for example, I believe Nano requires the proof of work in the transaction itself, see Nano Whitepaper.
Transaction Spam Reduction
Bitcoin, however, instead of using proof of work to reduce transaction spamming, this is prevented with a miner fee.  Because miners can select transactions to put in the block they mine, they are incentivized to select transactions with higher fees.  Without a decent fee, your transaction may never get mined if the average fees are much higher, so it won't enter a block (thus spamming is reduced).
Proof of Work in Bitcoin
Proof of work is used to achieve consensus.  Instead of preventing transaction spamming, you could consider it as a block submission spam prevention.  Because a majority of nodes have to validate the blocks and all the transactions in them, you could see how without proof of work, this could be easily spammed and transaction validity could become difficult to prove.  See Proof of Work.
Another effect for proof of work in the block is to control the work required to mine a new block, thus regulating the release of Bitcoins.  The reasoning behind this in the Bitcoin Whitepaper was:

"To compensate for increasing hardware speed and varying interest in
  running nodes over time."

Is there any argument that bitcoin proof of work by miners is better than email type proof of work by sellers?

I think your answer is good overall, but it dances around the important point that POW provides transaction ordering, which is the more relevant issue being solved in the bitcoin system. In email, the issue being solved is spam messages.

Proof of work helps to solve the issue of transaction ordering: miners must create blocks that contain an order of transactions, and each block builds upon the last. Thus all bitcoin transactions are ordered, and this is required in order to resolve any potential transaction conflicts.
As an example: in the case of a double spend, which transaction is actually valid, and which should be discarded? A simple way to resolve this question is to say "the first transaction is valid, the second is not", but this solution requires the network to be in consensus regarding the ordering of all transactions.
In the case of email, ordering of messages is not critically important, so the inclusion of a POW has a slightly different primary function: to increase the cost of sending an email, in order to discourage spam messages.

Then, in bitcoin, it seems natural that the senders engage in the proof of work instead of miners. Why it is not so?

Transaction ordering is important, but keep in mind that it is not trivial to reliably keep a decentralized network in consensus. Each transaction could include a proof-of-work, but this alone is not enough to give the transactions a well-defined order. Proof-of-work establishes a way to ensure resources were spent, but on it's own is not sufficient to establish an ordering of data.
Bitcoin solves this by grouping transactions into blocks, and each block references the one before it. You can imagine this as a sort of 'decentralized clock', where the smallest increment of time is one block. For transactions to function similarly, each transaction would have to reference the one before it, thus establishing an order. This would lead to a whole host of latency issues, higher rates of 'orphan transactions', potential for spam and DOS attacks, etc.

Great point! That last sentence seems out of  place

True. But theoretically one can think of discouraging senders to engage in double spending by taxing senders for sending multiple spending messages?

@JBaczuk I see what you mean, but I think its simple enough to understand how 'every transaction being ordered' would lead to issues, and I'm not really interested in parsing out the exact details of such a theoretical system. So I settled for a vague description of risks, if someone wants to edit to add more info please feel free to. OPs question was "why can't we use POW in the same way email anti-spam uses it?", not "what would be the effect of ordering each individual transaction, instead of grouping them in ordered blocks".

@171124 double spending is only one issue, another example is that latency issues would be very critical. What if txA is the most recent, and two nodes that are not immediately connected try to publish their own txs at the same time (txB and txC)? The longest chain becomes valid, so in situations like this, only one of txB or txC will be accepted, and the other will be orphaned, which means the node that published it originally will need to re-try with a new POW attached (that references the now longest chain tip).

To understand, why would it be that "two nodes that are not immediately connected try to publish their own txs at the same time (txB and txC)"?

@chytrik sorry I read it wrong

@171124 my example is meant to be analogous to an 'orphan block' situation on the current btc network (wherein two miners find a block at the same time). Having each transaction basically be it's own block could lead to a very high orphan rate, since many nodes may want to publish transactions all at once. @ JBaczuk ahh, no worries :)

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


text:
bitcoin block size and etherenum gas limit
I understand that bitcoin has a fixed block size (1MB).
On the other hand, Etherenum does not seem to have a fixed gas limit.
(https://ethereum.stackexchange.com/questions/1106/is-there-a-limit-for-transaction-size/1110#1110)
What is the rationale that bitcoin block size is fixed unlike Etherenum?

What is the rationale that bitcoin block size is fixed unlike Etherenum?

The block size limit serves two purposes: to keep node operation costs low, and to create a fee market.
With a limited block size, there are only a limited number of transactions that can fit in a block and thus the blockchain grows linearly. This allows for blocks to have a limit on how much network bandwidth and disk space they take up, and also sets a limit on the computational work required to verify a block. Without these limits, blocks could be maliciously produced which are extremely large which take up large amounts of network bandwidth and disk space, and more importantly, potentially take down a node due to a large computational cost.
The limit not only helps with block relay, but also with syncing a new node for the same reasons as above. Comparing Bitcoin to Ethereum, you can sync a fully validating archival Bitcoin node in several hours on standard consumer hardware. It only takes up ~200 GB of disk space. Conversely, you cannot sync a fully validating archival Ethereum node on consumer hardware. Syncing one requires high end hardware (e.g. PCIe SSD) and the Ethereum blockchain also takes up over 1 TB of disk space.
The other reason for the block size limit is to create a fee market. Currently Bitcoin miners are paid through the block subsidy. However the block subsidy halves every 4 years and will quickly reach negligible amounts. In order to keep miners mining, we need to pay them in some other way, namely transaction fees. By having a block size limit, we can build a healthy fee market which organically grows over time so that by the time the block subsidy is negligible, there will be enough in transaction fees to cover the costs of mining.


text:
Comparison BTC and ETH uncomfirmed transactions queue
When I compare BTC mempool count and ETH transaction queues, ETH queues are much larger. I would appreciate explanations why it is so.
*BTC mempool count
https://blockchain.info/ja/charts/mempool-count
*ETH transaction queue
https://etherscan.io/chart/pendingtx

They are completely different networks, there's no real direct comparison. ETH just has a lot more going on

ETH has a shorter confirmation time and lower volume (correct?). Then why ETH has a higher number of transactions in queue?

ETH has a significantly higher transaction volume, much higher than the additional speed granted by a faster block time.

BTC: https://blockchain.info/charts/n-transactions ETH: https://etherscan.io/chart/tx Are these two charts fair comparison?

But Yahoo finance has the other way round: BTC https://finance.yahoo.com/quote/BTC-USD/history?p=BTC-USD ETH: https://finance.yahoo.com/quote/ETH-USD/history?p=ETH-USD why?

That's trade volume. You're looking at a comparison of transaction volume. Trading happens largely off chain, so does not reflect well in the transaction volume.

What does "off chain" mean? Mean "outside the exchanges"?

The ethereum chain has a far higher number of transactions than the BTC chain. This is mostly due to ethereum's faster block time, and the presence of many thousand smart contracts on ethereum, which all contribute to more transactions.
In the comments, it seems like you are comparing the transaction volume charts to the trade volume charts.
Trading of BTC and ETH happens largely on exchanges. These exchanges have trading engines that execute all trades within the exchange itself, and not on the blockchains. That is to say, if User A sells to User B, there is no corresponding blockchain transaction transferring those coins. Instead, both users have accounts on the exchange which are debited and credited. A blockchain transfer only takes place during deposits and withdrawals.
Through this process, many thousands of trades can take place without ever reflecting on the blockchain. However, interactions with smart contracts must happen on the blockchain, and contribute towards the total transaction volume.

Maybe I am confused. What is "blockchain transaction" in your explanation?

"If User A sells to User B," but these transactions need to be validated by proof of work to prevent double spending. Is this statement correct?

"For example, if Sean sends one bitcoin to John, this transaction will remain “unconfirmed” until the next block is created. " (https://www.buybitcoinworldwide.com/confirmations/)

That's only when sending bitcoin between people. On exchanges, you send your coins to the exchange. The exchange has an internal ledger. Trades are executed by updating the balances in this internal ledger. This part does not touch the blockchain at all, and involves no proof of work.

For example, Kraken says: "Bitcoin deposits should be credited after 6 network confirmations (normally about 1 hr but can be delayed when Bitcoin network is slow)".(https://www.reddit.com/r/ethtrader/comments/4e64k4/how_long_does_it_take_to_get_a_btc_transaction_on/)

That's about deposits (moving coins to the exchange), not trades. Trades inside an exchange is just flipping some database entries (incrementing an account balance for one person, decrementing for another), which aren't reflected on chain. From the blockchain's perspective, all exchange user's coins are owned (or at least controlled) by the exchange's keys.


text:
Definition of confirmation time in blockchain.info
What will be the definition of confirmation time and data used for
https://blockchain.info/charts ?
I would appreciate confirmation.

I believe the data presented on blockchain.info's site is collected by the following method:

a blockchain.info node hears about a new transaction. It is added to the node's mempool, and an entry that includes a timestamp is also recorded into a local database
when the node hears about a new block, it will check to see which transactions are included. It will then compare the time the transaction was first seen, with the time the block was first seen, and the difference between the two would be a 'time until confirmation'.

This chart reports the median time for transaction confirmation, but note that it excludes any transactions with zero fee.
It is potentially worth noting that some transactions are published with a low time preference, meaning the person initiating the transaction may intentionally include a low fee that will take a while to confirm, and this would drive the 'average confirmation time' up, even though the network is functioning well for it's users.

"It excludes any transactions with zero fee." Is it also true for average confirmation time? So it means that it underestimates the confirmation time in a sense that transactions with zero fee will take longer?

Some nodes will not even relay zero-fee txs, and some miners will not include them in blocks, so I suspect that ignoring them gives a better measure of the 'experience of the average user'. There is also no cost associated with sending zero-fee txs, so it would be easy to spam a huge number of them during times of tx backlog, and effectively raise the 'average confirmation time' a LOT.


text:
Definition of confirmation time in blockchain.info, Part 2
In my previous question (Determinant of confirmation time), I asked
"What will be the definition of confirmation time and data used for
https://blockchain.info/charts ?"
Now I read
"The classic bitcoin client will show a transaction as "n/unconfirmed" until the transaction is 6 blocks deep. " (https://en.bitcoin.it/wiki/Confirmation)
Then is it correct to say that, in a simplest approximation it takes 6 times the confirmation time in the graph to get a transaction done?

Sorry i still don't get what you try to ask, can u edit the question a bit and see if i can help u

Then is it correct to say that, in a simplest approximation it takes 6 times the confirmation time in the graph to get a transaction done?

Not quite, the first confirmation is different from all subsequent confirmations, I’ll explain how:
For the first confirmation, there are a couple of factors at play:

how long until the next block is mined
how high the tx fee is, relative to other transactions in the mempool

For all subsequent confirmations, there is just one factor:

how long until the next block is mined.

The average time between blocks varies, but usually averages just below 10 mins. So a simple approximation of time for 6 confirmations could be:
(Time for first confirmation) + 5*(average block time)
As an example, let’s say we have a tx where the first confirmation takes a while due to a low fee (let’s say, 40 minutes). The next block (next confirmation) will, on average, arrive 10 mins after that, and the next one 10 mins after that. So we might expect the time for 6 confirmations to be (40 + (5*10)) = 90 mins. Whereas under your assumption we would expect it to be (40*6) = 240 minutes.
It’s worth noting that 6 confirmations is often considered as being ‘fully confirmed’, to help mitigate the risk of a chain reorg happening after one or two confirmations. This number is calculated by considering the cost of an attack to reorg the chain, against the value of the transaction being sent. For high value transactions, you’d want to wait more confirmations, because eventually the cost of an attack to reorg the chain will outweigh the value of the transaction (so a miner would spend more resources attacking the chain than they would gain by reversing the transaction).


text:
How to deploy BTC blockchain on my Ubuntu17 VPS
I would like to setup Bitcoin nodes on my VPS so we can call balance API unlimited time. Actually we are launching ICO for that we are in need of this we have previously deployed ETH and NEO node on our VPS.
Can any share URL or document that can help me to deploy bitcoin Nodes on my VPS and it allows to RPC Call for getting balance of any address.

maybe this (using Bitcoin Core) - even though it is for Ubuntu 16:  https://bitcoin.org/en/full-node#ubuntu-1604

Thanks you, i have started deployment of BTC as per your url, Now i am struct at one point can you guide me. I have started bitcoin node using " bitcoind -daemon" but after 5 to 10 mins when i try to run bitcoin-cli command what we have to pass in parameter ? @pebwindkraft

Did you install full QT client, or daemon only? I assume you have had no errors after/during install (check log files?). Then the next step might be to prepare the bitcoin.conf file, in the home directory of the user running your bitcoin daemon (and this is not ‚root‘). You might need to set the user and password in this file. Hint: there is plenty of info here in the forum, just search for bitcoin.conf.


text:
How many change outputs are there in a Bitcoin transaction
I have been reading the following article:
https://coinmetrics.io/difficulty-estimating-chain-transaction-volume/
It mainly discusses how unreliable transaction volume on a UTXO blockchain such as Bicoin is due to factors like change outputs, exchanges making transactions and coin mixing.
My question is related to change outputs in particular. If one sends someone a 5 BTC output, from a 20 BTC input they would receive, there would be a 15 BTC change return to the address of the sender.
So what I ask is, for transactions with more than one output, can we assume that one of the outputs is always change? Wallets would not construct transactions where they split the change to multiple addresses of the sender, would they? Is the only concern then, whether the output is indeed change or it is value that is being sent over to another recipient?

So what I ask is, for transactions with more than one output, can we assume that one of the outputs is always change?

I think this is likely a safe assumption most of the time, but not always. For example, a transaction that pays two people, using an input that is exactly the sum of both payment (+ miner fee) would have two outputs, and no change address. Such a thing is probably rare, but possible.
As well, if you move coins around between two wallets you control, then the only real distinction between the ‘payment output’ and the ‘change output’ is in which wallet controls which key (since you own both).

Wallets would not construct transactions where they split the change to multiple addresses of the sender, would they?

Sure they could, I’ve seen wallets that are focused on user privacy advertise all sorts of unconventional spending habits, with the goal of making it hard to figure out metrics like this. As an example, check out samurai wallet.
Again though, most wallets are designed to be fee-efficient, so in most cases there will not be more than one change output.

Is the only concern then, whether the output is indeed change or it is value that is being sent over to another recipient?

That is definitely one issue with trying to estimate tx volume, but likely not the only one. Distinguishing payments between parties vs payments to oneself (eg moving you coins to a different wallet) is another. As you mentioned, off chain tx volume and coin mixers will also make it hard to figure out. Lightning network payments will similarly be difficult to quantify, since payments can be communicated off-band, and we will only see the channel opening/closing txs happen on chain.


text:
Do legacy nodes receive the witness fields of a Segwit transactions?
My question  comes from not understanding how BIP 144 works? Regarding the BIP what I ask is, whether legacy nodes support the new parser, so that they treat Segwit tranasctions as valid? There it is stated:

Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.

In relation to my main question, I could not understand how legacy nodes treat the witness fields of a segwit transaction?

I actually got the full answer I was looking for in one of the comments above! Please refer to the forum discussion, the very last post on the page gives an in-depth explanation to the the answer in the comment. Sadly I can't upvote it yet, so I am posting this as a separate answer.

But a segwit transaction is sent with the new serialisation, how do they parse it? How do they "skip" the witness part ? I hope my question makes sense. – Ifo0 Aug 1 at 20:07
Yes, it makes sense, it may just be, that you think the client requests a tx... before doing so, there is a handshake, which tells about the capabilities of a node. Based on this the nodes get or do not get segwit data. See a discussion held here: bitcointalk.org/index.php?topic=1682183.msg21389041#msg21389041 – pebwindkraft

Legacy nodes (that is, nodes before segwit) do not receive witness data.
Witness data is a separate data structure. It is only relayed if a node asks for it.
Older nodes don't know it exists, so they don't ask for it, and thus don't receive it.
Since segwit data does not contribute to the txid, old nodes can receive the regular block and still validate it as normal. They just interpret the segwit inputs as "anyone-can-spend" equivalents.

But a segwit transaction is sent with the new serialisation, how do they parse it? How do they "skip" the witness part ? I hope my question makes sense.

Yes, it makes sense, it may just be, that you think the client requests a tx... before doing so, there is a handshake, which tells about the capabilities of a node. Based on this the nodes get or do not get segwit data. See a discussion held here: https://bitcointalk.org/index.php?topic=1682183.msg21389041#msg21389041

Perfect! Now it makes sense, I was looking exactly for this in-depth explanation we get in the forum! Thank you @pebwindkraft !


text:
Get transaction after certain (tx, block, time or other) using insight-api Bitcoin CASH
Now i can get all transactions by address (Bitcoin Cash) using this request to api:
https://test-bch-insight.bitpay.com/api/txs/?address=qptaxxrqcz7qunclcvlcza9an6qlqqhzlya2d4e4fn
But i want to get transactions only after certain moment(tx,block,time..). Can you help me with this?

We can cheat and use the query for Multiple Addresses, where search is available in a certain range of transactions, specifying the parameters from and to.
https://github.com/bitpay/insight-api#transactions-for-multiple-addresses
https://test-bch-insight.bitpay.com/api/addrs/qptaxxrqcz7qunclcvlcza9an6qlqqhzlya2d4e4fn/txs?from=2
If I want last tx:
https://test-bch-insight.bitpay.com/api/addrs/qptaxxrqcz7qunclcvlcza9an6qlqqhzlya2d4e4fn/txs?to=1


text:
Why do we use CLTV instead of CSV in the HTLC output of the commitment transaction?
In lightning network commitment transactions, the HTLC offered/received outputs generally pay the offering node after a timeout which is scripted using CLTV. In other parts of the commitment transactions (such a to_self_delay) we use CSV to ensure it the output is unspendable until a certain time has passed. Why was CLTV chosen as the design choice for HTLC outputs?

When creating a commitment transaction, you consume the multi-sig output of the funding transaction as the input. CSV is a relative timelock opcode which means the time specified in the CSV is a function of when the funding transaction was mined. For example, if you create a 100 block CSV output, that output is only consumable after 100 blocks have passed since the funding transaction was created.
When sending a HTLC, the first node it passes through will be the one you have direct channel with. Since you and your channel counterparty are on the same page related to the funding transaction you can freely use CSV opcode when timelocking the to_self_delay for the local node output. However, from there on it will be sent to nodes you do not have direct open channels. These nodes have channel open with other nodes whose funding transaction time will be different from the one you had opened with your channel counterparty. Thus specifying CSV in a HTLC output, would create ambiguous timeouts from the point of view of different channel parties. To ensure consistency, you need to use absolute locktime, which is why CLTV is chosen.

This answer is muddled.  The funding transaction output is just a plain 2-of-2 multi-sig with no timelock.  Thus the timing of the funding transaction has nothing to do with anything here.  As someone else mentioned, you want the countdown to begin when a commitment transaction hits the blockchain, so CSV makes sense there.  The use of absolute time in HTLC is due to the timing coordination in routing, in the event that one party in-between commits the HTLC before another.

As you have said yourself, CSV is relative to when the transaction appears in the blockchain, while CLTV is absolute. They just have different meanings, which are useful for different things:
The RSMC timeout is meant to only start when someone pushes a commitment tx to the blockchain. So it needs to be relative.
The HTLC timeout, on the other hand, is meant to actually make an HTLC temporary, even if in most cases if will never hit the blockchain. So it needs to be absolute.


text:
How can my private key be revealed if I use the same nonce while generating the signature?
I know it is well understood that it is not a good practice to use the same nonce while generating the signatures, but I am not getting the math right.
Assume I have some UTXOs that are controlled by my private key Q. Say I have spent two of the UTXOs using nonce 'N' to generate my signature. Now the (R,S) components of the signature are public and the transactions are public so everyone has access to them.
S1 = N^(-1)*[hash(m1) + Q*R] mod p

S2 = N^(-1)*[hash(m2) + Q*R] mod p
S1 - S2 = N^(-1)*[hash(m1) - hash(m2)] mod p

Even though we know S1, S2, m1 and m2, isn't solving for N^(-1), and hence N, becomes equivalent to finding the solution to the discrete logarithm?

Possible duplicate of How do you derive the private key from two signatures that share the same k value?

Not necessarily. My question asks further expansion of the answer derived from that question, asking how solving for N^(-1) is not finding a solution to the discrete logarithm problem.

Let me rewrite your question in a different notation, where all lowercase values are integers and uppercase values are points.

The group generator is G (a known constant).
The private key is q, its corresponding public key is Q = qG.
The nonce is n, its corresponding point is R = nG.
The X coordinate of R is r.
The hash function is h(x).
A signature is (r,s), where s is computed as n-1(h(m) + qr).
A signature is valid iff r = x(s-1(h(m)G + rQ)) (where x() stands for "The X coordinate of point ...")

Now for the two signatures it holds that:

s1 = n-1(h(m1) + qr)
s2 = n-1(h(m2) + qr)
s1 - s2 = n-1(h(m1) - h(m2))
n = (s1 - s2)-1(h(m1) - h(m2))

As s1 and s2 are just integers, (s1 - s2)-1 can be trivially computed using a modular inverse; there are no elliptic curve points involved here (over which this problem would be hard).
Once you know n, you can find q by rewriting the first equation:

ns1 = h(m1) + qr
ns1 - h(m1) = qr
q = r-1(ns1 - h(m1))

Substituting this in the earlier equations gives you:

q = (r (s1 - s2))-1(m1s2 - m2s1)

Apologies for the no-no of asking for clarification but I think there is something missing here. I stumbled over the following line from PWuille: A signature is valid iff r = x(s-1(h(m)G + rQ)) Problem is: there is no definition for x in this statement.
Is it a typo, and you meant to say m (the message)? In that case the question would be: how would you multiply something with a (text) message (which might be a huge PDF file), so that can’t really be it, right? Or is it a function x(anything), in which case the question is: what function is it?
To prevent me wasting precious PWuille-time I ask

@Hare Brained Brian: Responding to your comment posted as an answer here: the x(...) above means "The X coordinate of the point ...".

isn't solving for N^(-1), and hence N, becomes equivalent to finding the solution to the discrete logarithm?

No, it is not. This does not require finding the discrete logarithm at all. Solving the discrete logarithm is finding the exponent to a known base. However in this problem we are trying to find the base and know what the exponent is. Furthermore, this known exponent is -1 for which finding the base of something raise to -1 is to raise the result to -1 again, i.e. taking the inverse of the inverse.
There are algorithms that exist to find the modular inverse of a number which is how N^(-1) is found in the first place. To find N, you just need to take the inverse of N^(-1) because of the identity that an inverse an inverse is the element itself.

Isn't the order of how the equation is written same as the public key generation? You have [hash(m1) - hash(m2)] as the base and N^(-1) as the exponent?

No. [hash(m1) - hash(m2)] is an integer, not a elliptic curve point. N^(-1) is also an integer. So this formula is just integer multiplication. It is not exponentiation nor is it curve point multiplication (the two things that have discrete log problems). Thus it is not solving any discrete logarithm.

That's what I was looking for. So since N^(-1)*[hash(m1) - hash(m2)] is just integer multiplication modulo p vs curve point addition.


text:
How can I create HTLCs below dust_limit_satoshi in Lightning Network?
BOLT#2 documentation for open_channel message has two points (dust_limit_satoshi and htlc_min_msat) in the data message that I found confusing. Below is the statement related to dust_limit_satoshi:

dust_limit_satoshis is the threshold below which outputs should not be generated for this node's commitment or HTLC transactions (i.e. HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain)

and for htlc_minimum_msat

htlc_minimum_msat indicates the smallest value HTLC this node will accept.

My question is how will I be able to accept a htlc with value that is in sub-satoshi, if my dust_limit_satoshi is in Satoshis? As per my understanding and the first statement in quotes, my node will not accept HTLC transactions that are below the dust_limit. If that is the case why not enforce that htlc_minimum_msat > dust_limit_satoshi?

The dust limit is an externality to lightning wich the protocol has to respect. In fact if a commitment transaction would encode an htlc below the dustlimit you could not force close the channel as the Bitcoin network would not accept that particular transaction.
When it comes to htlcs below the dustlevel we work with a little trust in the payment channel. This means that offering an htlc means that we remove some bslance from our side of the channel. Instead of making it an htlc output we just add it to the fees of the commitment transaction. Technically our channel partner could harm us by force closing now and our htlc amount would be lost forever if we don't find the preimage. Only upon delivery of the preimage a new commitment tx is negotiated in which the fee is reduced by the htlc amount and added to your channel partners balance.
That being said. For fee calculations of small payments we even allow subsatoshi amounts which again are not enforceable and will be added to the fees by rounding down the actual balance in the commitment tx. Any routing nodes could implement (actually just configure) a rule like the one you suggested. This would enforce the effect that the channel can be operated fully trustless.
I can't tell you why this is not encoded to the protocol. I think because people wanted to allow micro transactions


text:
What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?
There has been a lot of discussion and articles around how the implementation of AMP is going to benefit the routing capabilities of Lightning Network. What is the exact issue in the current implementation of Lightning that AMP is solving? How does AMP really work? and how is it going to be implemented?

The Current Problem
The major challenge in the current routing mechanism is finding channels with sufficient balance on one side of a node to forward an incoming payment. To be more descriptive, the channel_announcement or the channel_update messages that are broadcasted contains the short_channel_id through which lightning nodes can look up the transaction in the Bitcoin blockchain and find out how many bitcoins are locked in that channel. However, one does not know how much each node of the channel holds. This creates an issue in terms of routing a payment as one side of the channel may not have enough balance to forward the transaction resulting in a routing failure and the origin node has to retry the payment using a different route.
The second issue is with origin node channel balances. Say I am buying a cup of coffee from Starbucks that costs me 20,000 satoshis. Now I have three open channels in the lightning network with my balance equal to 9,000 satoshi in each channel. Neglecting channel reserve balance and transaction fees for now, I can only make payments of 9,000 satoshis in each channel, which makes me incapable of buying that cup of coffee in a single payment. The get around would be to make three payments to the same payment invoice that Starbucks offers me when buying that cup of coffee across all three channels. But this renders security issues, from hash re-use. A node having channels across the paths can use the pre-image it learnt from one path to fulfill a payment along the other path. Also, if only a partial payment went through then I would be at the mercy of Starbucks to refund me the partial payments I did earlier.
The third issue is that at the moment (although temporary) we have a limit of 232 milli-satoshi (~0.0429 BTC) on a single payment size. Payments above this limit needs to be done via multiple payments. But this again brings the risk of one payment going through and subsequent payments failing to reach the receiver. You are then left to ask the receiver to process a refund to you.

The Solution
Conner Fromknecht and Olaoluwa Osuntokun proposed Atomic Multi Path (AMP)  payments in order to solve both the above issues by breaking a larger payment into smaller ones while at the same time not re-using any payment hashes across all the smaller payment flows, and adding a strong guarantee that the receiver won't be paid at all until all partial payment flows are completed (atomicity).
Their proposal required the sender to send some secret s_i to the receiver in each smaller payment i. When all payments have been received by the receiver, it will then construct the base payment (BP) secret by taking XOR of all the partial secrets that were sent by the sender, such that BP = s_1 ^ s_2 ^ ... ^ s_n. Now each payment pre-image is SHA256(BP || i). This had the advantage that the receiver could not create the pre-image until all partial payments have been received, thus solving the partial payment as well as the hash re-use issue.
This form of payment proposal is really helpful if done between friends, however, for business usage this proposal has a weakness. We consider the receipt of a pre-image as a cryptographic proof that a successful payment has occurred. If the sender knows and can calculate the pre-images in advance, this destroys the whole principle of a cryptographic receipt that you will get from the receiver of the payment. Since the proposal required the sender to create the shared secrets and the payment_hash, the sender knew the pre-images in advance.
To solve this issue, Basic MPP (multi-path payments) was proposed. Basic MPPs use the same payment_hash for all paths through which the payment will be made. The receiver however, does not release the payment pre-image until all successful payments have been received to thwart the possibility of an intermediate node using the pre-image from one leg of the payment and satisfying the other branch. Since proof-of-payment is valuable then no rational payee will accept partial payments until all parts of the payment have arrived and as a result will not release a pre-image. However, if it releases pre-image along one path, it is in the economic interest of the payee to release the pre-image along all the paths.

Implementation
A new type-length-value (TLV) format is now being followed in the Lightning Network protocol as compared to a fixed length byte stream in earlier versions. The use of TLV permits a space saving, potentially leaving more space for application data over the wire or in an onion payload. Nodes supporting such variable payload routing onions indicate it by setting the global_features flag, bits 8/9 (var_onion_optin). Moreover, the lightning invoice generated needs to set the basic_mpp feature.
Base AMPs uses the same payment_hash for all paths through which the payment will be made. If the final node receives an onion packet which includes a basic_mpp field, then the payment MAY be a "base" AMP. Setting the basic_mpp flag is a promise by the sender that the rest of the payments will follow in succeeding HTLCs. All the HTLCs that will be received that fulfills the payments having the same payment pre-image are called as "htlcset".
Upon receiving an onion with basic_mpp, the receiver should wait at least 60 seconds for all other payments to come through. If the payments are not received in sufficient period of time, the final node must fail all the htlcs in the htlcset. However, if it fulfills any HTLCs in the htlset, it must fulfill ALL of them. This subset restriction prevents the pre-image from being released before all the partial payments have arrived: that would allow any intermediate node to immediately claim any outstanding partial payments.

Future Releases
Work is being currently done on High AMPs. It combines both the original proposals of AMP and the current Base MPP, retaining proof-of-payment (which was sacrificed by the original proposal) and ensuring cryptographically-secure waiting for all parts (rather than the mere economically-incentivized of Base AMP).
This however, requires that we switch to points and scalars instead of hashes and pre-images. An invoice will now contain a payment point which is basically generated by  multiplying a scalar (equivalent to private key) with the standard generator point on secp256k1. Proof-of-payment does not require revelation of the scalar, but a signature using the scalar behind the public key is sufficient to provide proof-of-payment. This also allows support for payment de-correlation (additional scalars are added at each hop, and the sum total scalar is told to the payee), while not requiring either proof-of-payment or spontaneous payments (it can work with either). This is basically Scriptless Script usage on Lightning. Instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).
However, implementation of this would require Schnorr implementation on the Bitcoin mainchain which might be couple of years out.

I like your idea of sharing knowledge in this way and great research. You might want to add link-AMP and how it is basically JIT routing but with a protocol change. In link-AMP Routing nodes forward the onion with and update_add_htlc message that is below the onion value promising to send a different htlc with a student onion on another path. Also it might be nice to emphasize on what was discussed in the last spec meeting and how AMP is currently supposed to evolve. Also naming the obvious downsides (more expensive, slower higher on chain footprint) might be an idea.

@RenePickhardt Thanks! I pinged you in the chat, but then I was brought to the attention that since you weren't there in the room for 24 hours, my message wouldn't send you a notification. So, I liked the idea of including the disadvantages of MPP, and including the last spec meeting details. However, I did not find anything related to link-AMP with a google search also, is there any other proposal on MPP apart from the high AMP?

So the original AMP from Osuntokun-Fromknetch was abandoned and now we'll have Basic MPP and wait for Taproot for other forms of high AMP?

@fiatjaf I'm unsure if the OG AMP is abandoned. Probably LND will implement it more as a feature in the software rather than consensus that works across implementations. For High AMP, you will have to wait for Taproot softforks, as it is works on Point Locked Time Locked contracts (PTLCs) which cannot be settled on-chain right now.


text:
Import watch-only address to 0.18 core wallet, addresses missing
I am running new bitcond server
$bitcoin-cli importaddress '32om7Xx7GnwxkiAQjpp3hhayDX4mSNLmR1' 'label' false
$

it seems added.
Then I try to list all addresses in wallet it return empty list.
$bitcoin-cli listaddressgroupings
[
]

here my bitcoind.conf
server=1
rpcuser=uname
rpcpassword=pass
rpcallowip=127.0.0.1
rpcbind=127.0.0.1
rpcport=18332
daemon=1
addresstype=p2sh-segwit

$ bitcoin-cli listwallets
[
  ""
]

You're using on incorrect bitcoin-cli method to list your addresses.
The command you're looking for is:
bitcoin-cli listreceivedbyaddress 0 true

The 0 parameter means you're requesting information on any address and the true flag means you want empty addresses included.
The original command you were attempting, listaddressgroupings, is described here.


text:
Import bitcoin core generated multisig public address to electrum multisig wallet for watch(2/3) and sign(1/3)
I have 3 Machines, and I want to create (2/3)multisig wallet. Sign with other machines safely.
I have;
xpub1, xpub2, xpub3
xpriv1, xpriv2, xpriv3
Machine-1: In electrum:
New/restore->Multisig Wallet->Use a master key->2/3->Cosigner1: xpriv1, cosigner2: xpub2, cosigner3: xpub3,
for watching (2/3)multisig wallet and partially sign(1/3).
How to import machine-2 generated public addresses to Machine-1 for watch(2/3) and partially sign(1/3)?
The electrum wallet database is look like json formatted. Am I need manually enter there(json["addresses"->"receiving"]) or any other way to import a corresponded addresses

As you were told on bitcoin talk forum you can't import arbitrary private or public keys and create a multisig setup with them using electrum. It only supports using extended private and public keys or seed words for this functionality.
If you just want to create a watch only wallet with the address itself then you can do that. Go to file > new/restore, enter a unique filename and click next and when asked what type of wallet you want to create choose the option to "import bitcoin addresses or private keys". Then paste in the address in the next step and proceed with on-screen instructions for the rest. This will let you watch transactions relevant to this address but you won't be able to sign any outgoing transactions.

as a first part of your answer; I used xpubs, and xpriv not arbitrary it is BIP32 standart.
for second part; It's already explained on electrum guides.
I am tried to achieve to watch and (1/3)sign a (2/3)multisig wallet.

Then restore the wallet using one xpriv and the two xpubs from the remaining cosigners.


text:
What stops miners from no longer submitting failed hashes to the network, to reduce the difficulty and block time?
As I understand it, the difficulty adjusts based on the hashrate to keep the block times at 10 minute intervals. But if Alice and Bob are the only ones mining on the network, what's to stop Alice from only broadcasting the correct hash that she finds, effectively reducing the seen hashrate by 2 and making blocks 5 minutes instead?

Miners don't broadcast failed hashes to the network.  They don't do anything at all with them, they simply ignore them and try again.  Nobody else ever sees them.
The way we know the network hash rate is not from observing all the hashes that were performed.  Rather, when we see a successful hash, the network difficulty allows us to infer the number of unsuccessful hashes that, on average, must have been performed to get it.
For example, the network difficulty is currently about 6.07e12.  This means, roughly, that a successful hash is required to start with about 74 zero bits, so the probability of any given hash being successful is about 2.6e22.  Thus, each time a single successful hash is broadcast to the network, we infer that about 2.6e22 hashes must have been performed throughout the entire network.  Since success is random, the actual number of hashes performed since the previous successful hash may have been significantly more or less.  But when we average over many blocks, we can come up with a reasonable estimate of the overall rate at which the network is performing hashes, even though we only ever see the successful ones.
Likewise, adjustments to the network difficulty aren't directly based on the overall hash rate.  Rather, they're simply based on the rate at which successful hashes have been observed; specifically, how long it has taken for the  last 2016 successful hashes to show up.  From the discussion above, this is correlated to the overall hash rate, but the overall hash rate isn't actually used in the difficulty adjustment calculation.
In your example, Alice's decision to broadcast failed hashes or not plays no role in the Bitcoin protocol.  If she broadcasts a failed hash (i.e. a block with an incorrect proof-of-work), it will simply be ignored.  In fact, other nodes on the Bitcoin peer-to-peer network will likely disconnect from her (a so-called "ban"), because she's cluttering up the net with useless junk.


text:
Can Phoenix wallet steal my funds?
Phoenix wallet is a great UX Lightning Wallet, and they're able to deliver that UX by making a few different tradeoffs. None of those tradeoffs involve them owning your private key, but in their 2019 blogpost they write:

Phoenix only connects to ACINQ nodes. This allows us to modify/enrich the Lightning protocol at the immediate peer level, while staying 100% LN compliant at the network level.

Since I'm only connecting to ACINQ nodes, could ACINQ (the corporation) theoretically use their nodes to say I'm "cheating", thereby forfeiting my LN BTC?
Thanks!

If you can verify that Phoenix is running the code that you expect - the open source eclair implementation of the Lightning Network and Phoenix wallet - then they will not be able to use their node to "say that you're cheating". This is because they do not have signatures for your unique commitment transaction, so there's no chance that they can broadcast your commitment and then claim the penalty for themselves.
More generally, mobile wallets that depend on their channel peer for blocks could theoretically cheat their peers by broadcasting old state and then withholding blocks until the time that your node has to claim the penalty output. Phoenix has an option to connect to your own electrum server, which would protect you against this (unlikely) attack if you chose to enable it.

Since this is a hypothetical question it is hard to give a definite answer. So unfortunately I have to write both yes and no. But let me elaborate:
Yes, because if you use phoenix which is software by ACINQ and connect to their node controlled by them. Very theoretically there could be a deliberate problem with phoenix wallet trying to cheat if connected to acinq node so that acinq could punish you. That would however mean that the wallet on your phone is deliberately malicious. Of course any software vendor hast the ability to inject malicious code into the software they provide. As far as I know Phoenix is open source so such a malicious code should be detected by the community.
No, because they way how you ask is not how the penalty mechanism works: You don't get the funds by saying that you are cheating. (If that was the case the protocol would be very unsafe as any node could on any channel just claim the partner has cheated and get the money) You're wallet would actually have to verifiably cheated for the ACINQ node to be able to make that claim successfully. The protocol adoptions that phoenix wallet makes - to the best of my knowledge - are nowhere close to cheating attempts.
Thus as long as phoenix is not malicious I don't think the node that you connect to can forfeit your Bitcoin by making a claim that you cheated.


text:
How do I know that the majority of bitcoin miners are not XYZ government's facilities?
Even if "Satoshi Nakamoto" is/was actually a real person, how can I be sure that XYZ government (XYZ can be US, or China, or ...) does not have now (or will not have in the future) 51% of the hashing power to mess with the bitcoin network transactions when the right time, in their opinion, comes?

Your answer is Incentives.
Let's imagine a bad guy, called Mallory, has an interest in attacking Bitcoin and has either created for himself, or desires to, 51% of the hashing power required to start shenanigans. (Start, because he has to maintain and grow that hashing power for sufficiently long to outpace the 'good guys'.)
To start with, there's no technical or legal way to prove that Mallory hasn't, or cannot, obtain that 51% any more than than there's a technical or legal way to prove Mallory hasn't, or cannot, obtain nuclear devices to hold the world to ransom like a James Bond villain.
Instead, you're relying on incentives. Assuming Mallory has spent $1 billion to marshal his forces, you have to wonder - would it make sense to destroy Bitcoin? If he does, his $1 billion is lost. True, perhaps he plans to make $1.1 billion from the chaos, and so the cost - to him - is "worth it". Or is the cost now so high that even Mallory stops and thinks "Hey - I'm making $0.1 billion a year from securing the network. It's actually more profitable to keep doing that, even though I'm a bad guy."
It's also worth pointing out his 51% only allows him to double-spend money he's already spent.
You specifically suggested that Mallory is a Government. We can look again at the incentives above: if his interest is to destroy Bitcoin as an alternative, then he'll quickly run into trouble: everyone will rapidly know that the 51% was achieved and so everyone will know that someone (Mallory will not likely reveal himself) has mining resources previously unknown. Perhaps a more efficient SHA-breaking algorithm. Even if Bitcoin itself is flown into the ground by him, alternate algorithms can be put into place such that a Bitcoin2 is immune to his attack. So: Mallory has now spent huge amounts of his resources, revealed something that would be of interest to his existing adversaries (that he has a means to break an encryption algorithm they use) AND has found himself back at step 1: Bitcoin2 is up and going without him. What attacker deliberately makes his own position worse?

What if the imcentive is to lure a party PQR to invest heavily in bitcoin, and then crash it? After all, several billion dollars is pocket money for US (since 2008 it stamped trillions) but for PQR this may not be so (yes, I do think that if Mallory is a government, it is most likely the US government).

What does PQR stand for?

Then my point still stands: would the US Government reveal that they have broken SHA in order to destroy a Mafia? I suggest to you they would not: hiding they have broken it is more valuable than destroying a Mafia whose base is the people within it, not the bitcoins in their wallet.

Does US government really have to break SHA-256 for that? It needs only to have a larger hashing power than the rest of the miners.

Larger hashing power only lets them double-spend funds they've just spent. How much would they get before people noticed? Very, very little, and not enough to bring down Bitcoin. Why reveal you have that capacity when you can just print off the dollars needed?


text:
Non-spend Blockchain.com
A bitcoin trader opened a blockchain wallet for me and then sent me my profit but it is non-spendable. I know they can no longer get into my account because I changed the password and I have two-step verification. I don't have the private key. How can I get the private key?

If you don't have the private key, you don't own the funds. Why do you say it is non-spendable, was it added as a watch-only address? If so you were scammed.

As said, this was very likely a scam. The trader sent you nothing, but gave you credentials for a wallet that contains no money.

I'm sorry to say this is a common scam, I'll give some more info below:

A bitcoin trader opened a blockchain wallet for me and then sent me my profit but it is non-spendable.

That is called a 'watch-only' address in your wallet, meaning you can only watch it, but not spend the coins held by it. The Bitcoin blockchain is an open database, so anybody can watch any address they want to.

I know they can no longer get into my account because I changed the password and I have two-step verification.

From this, it sounds like the scammer had access to your account in the past. If this is true, then your account is 100% compromised, there is no way to make it secure again. Make a new wallet, move all funds to it, and do no ever use that account again.
The reason you MUST abandon that wallet is that while logged in, the scammer likely copied down your wallet's mnemonic seed phrase (a series of 12 or 24 words). With that seed phrase, they can recreate your wallet on a different device, or using different software. The seed phrase is the current industry standard for making a wallet backup, it is used to derive your bitcoin private keys and addresses. The password/2FA are just used to unlock your 'blockchain.info' account (which has used that seed phrase to create your wallet), so if you put the same seed phrase into a different device, it will recreate your wallet, without needing a password (since blockchain.info isn't involved at all).
For this reason, it doesn't matter if you change the password, or the 2FA. Once the scammer has your seed phrase, any funds sent to that wallet will also be under their control.

I don't have the private key. How can I get the private key?

You cannot. The only way, would be to find the person who does own that private key, and ask them for it (but they probably won't give it to you). The scammer is likely trying to 'sell you the private key', or 'unlock it', or some other nonsense. That is the scam, so please beware and do not send any more BTC to them.
In the future, do NOT EVER give your wallet details, login, passphrase, seed phrase, 2FA, private keys, etc, to anyone that you do not trust 100%. If you ignore this warning, you are much more likely to have your bitcoins stolen.


text:
Reset or backup from a blockchain possible?
i have a coin for my own interests.
With this i will learn how works all.
So i have install the daemon on a vps
All works fine.
Mining works. And the first 300 blocks i have created.
Now i will back to block 100 or 200.
But i don't know how?
It is only one node (1vps) and 1 windows wallet.
Is it enough to delete all files and directorys except the coin.conf and wallet.dat on the vps and in windows?
Or how i can back to block 200?
Many thanks
Mark

invalidateblock "blockhash"

Permanently marks a block as invalid, as if it violated a consensus rule.
Arguments:

"blockhash"   (string, required) the hash of the block to mark as invalid

Don't delete the blocks manually, you'll harm the database.

Thanks MCCCS for your reply. Understand I correct this works for me when i input the hash from block 201? Then I'm at block 200?

Yes, that's how it works.

OK, thanks. And when I setup 2 vps then I must insert this in all XXX-cli or only by one? And restart number 2?

You should do that for both.


text:
how connecting lnd to btcpayserver
status:
lnd on raspberry pi / daily changing ip-address / btcpayserver on vps
problem:
i want to connect my lnd-node to my btcpayserver.
i have to put my url with https in the required field, so i choose a https-domain of mine linked it to a dyndns-server and this one links to my node
i pasted the macaroons as required but the node or the server did connect.
can anybody help?

do you have ssl certificates for your dyndns? can't you use an IP-address instead of dyndns? Can you also access some log files (of lnd to see if there was a connection) and from the BTC Payserver (if they exist). Also did you enable the REST proxy of lnd? (not sure if that has to be done manually in that case can you share the relevant parts of your config file? Don't forget to obfuscate credentials)

no, the dyndns has no ssl certificate available. this would be really expensive. 2. i can't use an ip-address because the ip address changes nearly every 24 hours. 3. i think there are no logfiles at least, i don't know where to find them. 4 i don't no if the rest proxy of lnd is enabled but it should be


text:
how to find p2sh/p2wsh in utxo set after wallet recovery
i'm trying to understand how wallets remember a redeem script for p2sh/p2wsh for spending, after recovering from their seed, because the utxo set only has the hash in it, right? there are a nearly infinite number of script possibilities, aren't there? what do i miss?

It depends on what your scripts are. If you are for example talking about a single-sig wrapped segwit address, the redeemscript can be recalculated from the corresponding public key. The wallet would derive some number of keys from the backup, then derive the corresponding redeemscripts and addresses. As the wallet is scanning the blockchain, whenever it gets a hit for any of the addresses, it will backfill the wallet with more "unused addresses" beyond the used address. The count of the unused addresses to scan for is defined by something usually called the "gap limit".
To regenerate redeemscripts of multisig addresses, the backup needs to include the full set and order of the involved public keys! Even if you have a sufficient quorum of the keys to spend, you cannot craft a valid transaction without the remaining keys due to the missing redeemscript. Most wallets today are set up using hierarchical deterministic key derivation, so again, the wallet would be able to regenerate as many addresses as needed from the original tuple of extended pubkeys. Of course that also requires the backup to store which derivation path was used.
If you are talking about arbitrary scripts, the backup better have the full redeemscript, otherwise you'll likely be out of luck.


text:
How does proof of work inspire trust when the work is just guessing?
I'm struggling to understand the value added by machines guessing at inputs to create a hash below a target value in order to produce a proof of work. I understand the proof of work is somehow supposed to inspire trust in the distributed record of transactions. How? Why should someone winning a lottery cause me to have trust in a blockchain?

Forget PoW for a second: lets instead imagine that you have a box, and you've placed a lock on it, in order to secure its contents.
Now, if someone asks you how secure the contents are, then the size and type of lock is fairly important. Tying the box closed with a bit of string isn't very good security, at least compared to a heavy-duty padlock. For an attacker to get into the box and alter its contents, they will need to work much harder to get past the padlock, compared to the string. We can use the word 'work' here in the thermodynamic sense: energy being used to perform an action. In order to break into the box, there is a minimum amount of work we would expect the assailant to have done. The minimum amount of work to break the padlock is obviously higher than the string, so we consider the padlock more secure.
Keep that point in mind: breaking into a more secure box requires more work. You cannot fake the work, you either have the resources to cut the lock, or not.
So let's go back to Bitcoin mining: when a miner is hashing to find a valid PoW, they are doing work by expending energy as computational cycles. The PoW function is devised such that we can expect a certain amount of work to be done (on average), in order for the miner to find a valid block. You can think of this PoW as the 'lock' that has been put on the block: in order for an attacker to alter the history of transactions, they will have to perform (on average) this same amount of work (spending energy, a real resource) in order to find a new, valid PoW and replace the block ('breaking the lock', as in our example from above).
Thus, the history of transactions is secured by miners spending energy to create the PoW that is required for a block to be valid. More energy spent mining creates a 'more secure lock', since a malicious miner would be expected to spend an equal amount of energy in order to break it. Miners are incentivized to continue building upon old blocks, thus piling one lock on top of another lock, on top of another lock... and it is this mechanism which allows the history of Bitcoin transactions to be considered secure.

The minimum amount of work for bitcoin mining is very low. you just have to randomly get the number right each time. The average amount of work is more important.

@Qwertie thats true, and its why I added the caveat "(on average)" in several places. The lock example isn't absolutely perfect, since cutting a padlock requires a ~deterministic amount of work to be spent, whereas bitcoin mining requires a probabilistic amount of work-- but I thought the example was best kept simple. To be more accurate, the lock example could be altered to describe two different combination locks: one with a 1-number code, and one with a 3-number code. The 1-number code lock would require less work to crack, but only on average.

If you can squeeze in the fact that verifying PoW is relatively cheap then that would really add to your answer.

It is because of the nature of the hashing algorithms and one-way functions in general. The amount of work to get an input that hashes below a certain value is directly related to how low that value is.
This is because there is no known way to reverse calculate the input of SHA256 that will result in a valid hash. The work is basically the number of guesses, on average, that it will take to get a valid hash at a given difficulty. While it is true that it is random chance to get a valid hash, the probability decreases with a lower value, so more work must be done (on average). It's important to think of it in terms of probabilities and average number of attempts required.
It inspires trust because in order to reverse the transactions, one must redo the work (or execute the same number of guesses - on average) in order for replacement blocks to be accepted in place of blocks in the existing chain. This is called a 51% attack.

It not just a lottery. It is a lottery that you also need to rush to be the first winner or else you lose it
And you don't trust the winner. You only need to trust the winner only when it conflict
In blockchain everyone just trust the blockchain itself. You can trace the transaction from the first to the last block in the chain. You can calculate the whole block by your computer relatively easily that it was numerically corrected account, A send money to B and then B has more money while A has less money in the same amount. And all of it was stamped by private key of each person, proven by public key. No need for PoW (aka lottery) anywhere here
The problem just arise when someone try to do malicious things in the chain. Such as double spending. Suppose they have 100$ and send this while 100$ to 2 people at the same time, to pay debt, or something like that. You can see that it's a problem and we need to solve by trusting only one transaction and discard another
But then, which one?
So this is the point that the lottery came in. The PoW machine is the one who will select which block they trust. And work on that block by winning the lottery as you might called. And people will have more trust in that block (given that that block is also valid, not have any false data in it)
And it was economically benefit to not cheat the system. PoW require energy and that would be electricity bills. So the PoW machine that try to cheat will be detected by other people and they just waste their energy on a block that no one will trust. So it more benefit to work and be honest. That's why it trustworthy because cheater won't gain benefit. They will lose the lottery race and waste money
My explanation is not all correct in the real world blockchain. But I think it make things more simpler to grasp the point. There also many implementation variety. But basically, you can just trust the public blockchain because you can trace the transaction. And you just need to trust someone when there was a conflict that both correct. And the easiest way to find trustworthy is the one who put the hardest work into the system

It's not "a" lottery. Bitcoin transactions are considered reliable only after half a dozen or so blocks. Suppose someone wins the sixth lottery (lottery6). This results in block6, and it was built off of block5, which resulted from someone winning lottery5, and so on. Suppose you have a transaction in block1 where someone sent you some Bitcoin. If someone wanted to go back to back and insert a transaction into the blockchain where those Bitcoin instead go to someone else, they would have to go back to block0 and make an alternative block1b from that block with the new transaction. Block1b would then be in a shorter blockchain than the one where you received the Bitcoin. For that alternative transaction to be considered authoritative, at least five more blocks would have to be mined in that blockchain (five to tie the current blockchain and six to beat it), and all before any more blocks are added to the original blockchain. Not only would that take a tremendous amount of work, but miners would generally not have an incentive to work on that blockchain; if someone were to win the lottery and get block2b in the new blockchain, their mining reward wouldn't be secure until four more blocks are mined on that blockchain.
So a single person winning a lottery doesn't mean a transaction is secured, especially right after the block is found and hasn't propagated to all the nodes. But once a transaction is several blocks back in the blockchain, anyone who wants to nullify that transaction would have to basically either win lottery after lottery, or somehow get a majority of miners to participate in a massive conspiracy.


text:
The transaction is still 0confirmation
When is the miner checking the first transaction?
Why is not it confirmed?
network: testnet
tx: 6d1410de07627e8effdee58625be3c32962bfa7baec69a92ec12c125ed58e9e3
https://www.blocktrail.com/tBCC/tx/6d1410de07627e8effdee58625be3c32962bfa7baec69a92ec12c125ed58e9e3

More than 1 day passed. Who knows the cause?

Yes, the BCH testnet has miners unwilling to accept others' transactions.

JBaczuk 58
Thank you, I will check that question

MCCCS
Thank you very much
Why do not you want to accept other's transactions?

As I understand it, there are no usable mining rewards in the testnet because testnet coins are worthless.
To test transactions you may need to mine your own blocks.


text:
About insufficient priority error
The input of UTXO transaction being used is 10 pieces, total 0.0082 BTC.
Broadcasting the fee at 0.000012 BTC (sendrawtransaction), the following error occurs.
insufficient priority

Is the fee setting not good?
I do not know the cause.

That error means you did not provide a high enough transaction fee on your transaction.

Thank you for your comment, I am using bitcoin abc client, how can I calculate the fee?

Using the transaction you have now, get its size in kb. Then you can use the estimatesmartfee command (read the help text for that command so you can use the correct arguments) to get a feerate in BCH/kb. Using that feerate, multiply it by the transaction size in kb that you got earlier. That's the fee you should pay. Then remake your transaction using that fee.

Since we are using bitcoin-abc client vertion 0.18.5 and there is no estimatesmartfee, i use estimatefee to calculate it.
Is it better to use use estimatefee?
After calculating the fee using estimatefee, it  insufficient priority error

Also, the calculation formula I use is below
` (estimatefee result * transaction size) / 1000 = fee (btc) `
Is this calculation wrong?


text:
getnewaddress won't generate bech32 or p2sh-segwit addresses
We are only able to generate "legacy" addresses that begin with a "1". This is a long standing problem generating new addresses using bitcoind and has persisted through a few recent versions of bitcoin core.
This might be a possible bug in bitcoind 64-bit linux.
We are currently running core 19.1 taken from here: https://bitcoincore.org/bin/bitcoin-core-0.19.1/
And our linux version is: Ubuntu 18.04.3 LTS x86_64
We have "addresstype=bech32" set in our bitcoin.conf.
Has anyone else seen this problem before?
Here is our bitcoin.conf:
addnode=**.***.***.***

server=1

rpcport=****

walletnotify=/btc_notify.sh %s

# OpenSSL settings used when rpcssl=1
rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
rpcsslcertificatechainfile=server.cert
rpcsslprivatekeyfile=server.pem

gen=0

keypool=100

paytxfee=0.00005000

addresstype=bech32

And here is an example of how the problem manifests itself:

How old is the wallet file? As in, when was it first created?

Also, can you post the output of the getwalletinfo command (specifically, its walletversion field).

And as a side-note, the rpcssl settings have been removed years ago, you might be best off removing them from your config as well.

As for the age of the wallet file, we had to restart bitcoind today, and when we run "stat wallet.dat" we are getting access and modification dates for today. However, this full node has been running since at least 2013 and that's when it was likely originally created.

{
"walletname": "",
"walletversion": 10500,
"balance": 0.00000000,
"unconfirmed_balance": 0.00000000,
"immature_balance": 0.00000000,
"txcount": 2019,
"keypoololdest": 1583432175,
"keypoolsize": 99,
"paytxfee": 0.00005000,
"private_keys_enabled": true,
"avoid_reuse": false,
"scanning": false
}

The problem is that your wallet version is extremely old - it predates support for compressed public keys (which was added in v0.6.0, released in March 2012). As segwit addresses require compressed public keys, Bitcoin Core is failing with the keys you have, and defaulting to legacy addresses instead.
The solution is restart with -upgradewallet (just once), which will update the wallet to the latest version but break compatibility with old Bitcoin Core versions. Note that you'll need a new backup after doing so.

Thank you, Pieter. We have restarted with '-upgradewallet' and now the 'getwalletinfo' command returns this: {
"walletname": "",
"walletversion": 169900,
"balance": 0.00000000,
"unconfirmed_balance": 0.00000000,
"immature_balance": 0.00000000,
"txcount": 2019,
"keypoololdest": 1584640664,
"keypoolsize": 195,
"keypoolsize_hd_internal": 5,
"paytxfee": 0.00005000,
"hdseedid": "f68ec1b30d87a265effc2735fcc0bc4aabbbc5f8",
"private_keys_enabled": true,
"avoid_reuse": false,
"scanning": false
}

However, we are still only able to generate addresses that begin with a "1"

And is the problem solved?

Ah, it may be the case that your keypool still has uncompressed public keys which you need to cycle through (running getnewaddress 100 times should do it). Make backups of wallet.dat frequently

Hello Pieter - you were right. We had to run 'getnewaddress' about 85 times and then the bech32 address just started to appear. Thank you you are a true hero of Bitcoin.


text:
C-lightning Implementation password protect hsm while maintaing node access
I was wondering if there was a way to encrypt the folder that contains the hsm_secret (and a lot of other operational files necessary for constant operation of a C-lightning node) without cutting it off from normal access required by an operational lightning network node?

In theory, the way that Lightning works allows for the use of a Hardware Security module to perform a lot of the logic which would allow for secret material to be stored externally on a secure device similar to a Trezor. However none exists at the time of writing, and persistent access to many of the files is likely required in the current software. The balance of a Lightning wallet should be for the moment considered to be an extremely hot wallet, rather than long term storage for this reason.


text:
Setting up and running multiple C-lightning nodes on same machine
I have successfully setup a C-lightning node on ubuntu using the tutorial.  The problem I am having is trying to setup a second node that DOESN'T utilize the same .lightning hidden directory to run which means I can only run 1 node at a time.  How do I clone and setup a second c-lightning node on the same machine and run it in it's own hidden directory?  I am aware that both nodes need to direct to their own config files located in different paths.

you can run lightningd --help and get a list of arguments you can use to start lightning from the output there ist:
--lightning-dir=<dir>                Set working directory. All other files are
                                     relative to this
                                      (default: "/home/user/.lightning")

this means that you can set your own lightning-dir by calling lightningd --lightning-dir=/some/path/to/some/directory
now you can either put all the config values as additional arguments to your call or you put a config file into /some/path/to/some/directory/ which sets everything. the default is to call it config but you can also use the command line argument --conf=/path/to/some/conffile from lightningd to set a different one in a different location.
One thing you need to remember that both lightning nodes need to run on different tcp/ip ports. you do this by setting the port in your accounce addr in the config  file announce-addr=IP-ADDR:PORT you need to replacei IP-ADDR with your address and the port with the port.
obviously when interacting with each of the nodes you need to tell lightning-cli which one. again the --help command helps (:
lightning-cli --help
Usage: lightning-cli <command> [<params>...]
--lightning-dir=<dir>  Set working directory. All other files are relative to this (default: "/home/user/.lightning")
...

this means you can for example do lightning-cli --lightning-dir=/some/path/to/somedir/ getinfo

I have setup both nodes in their respective config files with their own ports and directories:  i.e....
announce-addr=x.x.x.x:9900
bind-addr=0.0.0.0:9900
ligtning-dir=/home/array/.lightning
announce-addr=x.x.x.x:9902
bind-addr=0.0.0.0:9902
ligtning-dir=/home/array/.lightning2
but when I run…  lightningd --network=bitcoin --log-level=debug  on either folder…they both startup in the .lightning folder where only one can run at a time…

perhaps i am installing and configuring c-lightning wrong....when I setup the second c-lightning....I just used git clone https://github.com/ElementsProject/lightning.git lightning2
cd lightning2

Although helpful, this doesn't solve the problem of running both at the same time. As soon as I activate the first node, the second one cannot be initiated.

It just says "We seem to be missing gossip messages"

you don't need to clone the source code twice! it is sufficient to download, compile and install the software once and then you can run two nodes exactly in the way how I wrote it. The error message "we seem to be missing gossip messages" seems to be a different problem (for example each node needs to peer with at least one public node in order to retrieve information about the network)


text:
How do I install a second independent C-lightning node on the same machine as one with an already operational node?
I have followed the steps to install a C-lightning node on my Ubuntu machine.  I wanted to know if I could install configure and make a second node on the same machine where both could run in tandem?

I am well aware that I would need to use a seperate lightning directory and port for the second node, but when I try to clone the github, it just clones the 2nd instance inside the folder of the first instance and only one lightningd can be active at a time.  When I try to activate the second node, it just says "We seem to be missing some gossip messages" in the second terminal.

Are you trying to run two separate versions of lightningd? If not you will not need to check the source out again, and you can run all instances with the same binary (but with different ports and different --lightning-dir parameters as you correctly pointed out).

Unless you want to test multiple versions of the lightningd binary, there is no need to check the source code out multiple times, since the binaries can be shared among multiple instances.
Assuming you are in the root directory of the source code, and you've executed ./configure and make, you can start multiple instances like this:
$ lightningd/lightningd --log-level=debug \
                        --lightning-dir=/path/to/lightning-dir1 \
                        --addr=0.0.0.0:1111 &

$ lightningd/lightningd --log-level=debug \
                        --lightning-dir=/path/to/lightning-dir2 \
                        --addr=0.0.0.0:2222 &

$ lightningd/lightningd --log-level=debug \
                        --lightning-dir=/path/to/lightning-dir3
                        --addr=0.0.0.0:3333 &

Each of these commands will start a new node with its own directory and with its own port.
Notice that you'll also need to tell lightning-cli where to find the various instances you're trying to talk to. For example the following will run the help command on the second instance:
$ lightning-cli --lightning-dir=/path/to/lightning-dir2 help

I usually will set up a couple of aliases for each instance that I run:
alias lcli1="lightning-cli --lightning-dir=/path/to/lightning-dir1"
alias lcli2="lightning-cli --lightning-dir=/path/to/lightning-dir2"
alias lcli3="lightning-cli --lightning-dir=/path/to/lightning-dir3"

Then you can just use lcli1 help to talk to the first instance.
If you'd like to run multiple versions, the procedure is identical, with the key difference that you need to compile and run these in the source code directory of the corresponding version that you are trying to run.


text:
Checking whether lightning node is online/visible
I just created my first lightning node and already have one active connection. My problem is however, that I do not see my node in any lightning network explorer. Is it possible to somehow check whether my node is truly online/visible?

For your node to appear in one of the explorers you have to have at least one open channel and once the channel is open you have to wait a little bit since the information that your node exist has to propagate through the gossip protocol. The gossip protocol requires an active channel to prevent spam and denial of service attacks.
To check if your node is online you can however peer to any node. (in clightning with the command lightning-cli connect) if that command is successful your node is online.


text:
Why is there a finite amount of bitcoin addresses and how is the range of possible addresses determined
My first question is what the precise logical/theoretical reason is that there are only a fixed amount of possible bitcoin addresses. Secondly, I can generate a bitcoin address by using address(sha256("Passphrase")). If it is even possible to determine, what would be the "Passphrase" in order to calculate the first and last possible address? Is for example address(sha256(0)) the first address?
I am trying to understand how the "range" of possible addresses works or how it is bounded.

My first question is what the precise logical/theoretical reason is that there are only a fixed amount of possible bitcoin addresses.

Because physics doesn't allow us to do anything that is infinite.
But even though there are a finite number of addresses, the number of possible addresses is so large that it might as well be infinite. There's no way that we could exhaust all possible addresses; there's just too many of them.

Secondly, I can generate a bitcoin address by using address(sha256("Passphrase")). If it is even possible to determine, what would be the "Passphrase" in order to calculate the first and last possible address?

That's not how addresses work. It's not an ordered list and addresses aren't generated in any order. Addresses are not generated by hashing some password; nor would they be ordered by that password.
Addresses are generated by hashing a public key with SHA256, then that hash with RIPEMD160. The resulting hash is then encoded with Base58 Check encoding. These hash functions are irreversible so given their output, you cannot find their input. So no, it would not be possible to find out what public key an address is the hash of given just the address.
If you really wanted to order addresses, then the first address is the Base58 check encoding of 0000000000000000000000000000000000000000 and the last address is the Base58 check encoding of ffffffffffffffffffffffffffffffffffffffff. The range of possible addresses is just the range of all possible 160 bit (20 byte) values. That is because that is the range of all possible values that RIPEMD160 can output.

Thanks for the explanation! Kind of interesting that ffffffffffffffffffffffffffffffffffffffff & 0000000000000000000000000000000000000000 are in use.

Not really. They are only "in use" because the range of RIPEMD160's output is all possible 160 bit values which are between those two numbers inclusive.

The range of addresses is greater than the range of possible key pairs in elliptic curve secp256k1 (because there are more than 1 address type). This range is any 256 bit number from 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140. In other words, there is a finite limit, but it is about 1E77 so it's enormous.
See Bitcoin Wiki - Private Key

There are more key pairs than addresses. A private key is a 256-bit number (yes, with limited range, but not very limited), while an address is a 160-bit number. Even if you consider there to be twice as many addresses because there are 2 types (P2PKH and P2SH), that's still only 2 * 2^160 = 2^161.

That's true, good point


text:
Some general questions about blockchain consistency
I basically understand the principles of a blockchain, nodes and miners. I also basically understand how transactions are hashed/calculated to be added to the chain but i doesnt understand the dezentralized part.

For example bitcoin has a huge amount of nodes so its impossible to
be connected to all nodes. Is there some kind of
connection broker, root node thats always online or broadcasting that holds a list of nodes?
If a transaction is sucessfully hashed and published, how does it
reach all nodes so that nobody will work on an already added
transaction because he think its not finished yet? Ii think in some businesses its like on the wall street to fight about milliseconds.

For example bitcoin has a huge amount of nodes so its impossible to be connected to all nodes. Is there some kind of connection broker, root node thats always online or broadcasting that holds a list of nodes?

No, there is no hierarchy to the nodes. There is no reason to be connected to all nodes, messages are flooded to the network by peers.
There is a list of DNS seeds that will help a new node find peers to download the blockchain from when they don’t know any peers to connect to, read more here.

If a transaction is sucessfully hashed and published, how does it reach all nodes so that nobody will work on an already added transaction because he think its not finished yet? Ii think in some businesses its like on the wall street to fight about milliseconds.

The FIBRE network allows miners to have exceptional connectivity, we can see the success of this in the low orphan block rate on the network.


text:
What is the current state of the Hashcash protocol that is cited in the Bitcoin whitepaper?
I have been reading the Hashcash paper which is referenced in the Bitcoin whitepaper. I would like to know what is the current state of the Hashcash protocol and what are the services that are actively using it?

There is no serious usage, and has never been, of Hashcash.
Most obviously, the disparity between the resources of a spammer (who can rent a botnet of stolen compute resources, or use high powered servers and GPUs) is no match for a user sending an email from their phone with limited power available . This simply means that the difficulty of generating a "stamp" has to be so high that only spammers are able to send messages, which defeats the purpose.


text:
How does the Bitcoin network maintain the chains created when two nodes generate different versions of the same block?
I came across these lines from the Bitcoin whitepaper:

If two nodes broadcast different versions of the next block
  simultaneously, some nodes may receive one or the other first. In that
  case, they work on the first one they received, but save the other
  branch in case it becomes longer.

Does that mean two chains are maintained in parallel in each node? If yes, how do the nodes actually maintain it in implementation level of the Bitcoin network?

Both blocks are indexed and stored. The extending block which was received first is represented as an array element with links/pointers to the headers of the strong chain: Chains are represented as arrays with links pointing to headers in the store.
The second block is now considered part of a “candidate chain”, of which there can be many with different heights. The tip of each branch emanating from the strong chain is the tip of a candidate chain. A candidate chain can be potentially extended to form the strong chain if it accumulates the most POW. At this point, the strong chain array elements are popped to the forking height, and the new candidate chain headers/blocks are pushed on the strong chain array/stack. The popped elements of the strong chain are pushed to a candidate chain array in respective order.
Since the number of candidate chains is unbounded, it may not make sense to organize them individually to store, but keep a them as a separate data structure (tree). Furthermore, given the cost of auch branches at current chain heights, they tend to be short. The risk of reorg is most likely with the “2nd” highest chain, so keeping this in persistent store can optimize for faster reorgs if the node is restarted (other indexed candidate chains in memory are lost and need to be rebuilt, but less likely to overtake strong chain). Of course, an implementation can persistently index an arbitrary bounded number of candidate chains depending on design objective.


text:
Blcokchain corrupt ledger
What happen to the node if we find that node on blockchain has corrupt ledger?
Is the ledger sync with other ledger or get discard.

The node will never be in sync with its peers. Synchronization process will stop as soon as it find the corruptd data

Then what happen to corrupt node, is it terminate from block chain or something..

Since its not accepted by peers its rejected from blockchain. You can imagine it a way like that of Uncle blocks


text:
Trying to understand why hash value is more secure from hash algorithm
I am currently studying in college in the US and was actually curious about bitcoin and cryptocurrencies as a whole. I started looking on free university sites like Stanford university and New York University and even attempted to do questions of their past papers. I answered most of the questions, but I am stuck on one of the questions:
Suppose your professor wants to award each student in the class a random priority for office hours help by giving them a number H(studentID||Bi)
where Bi is the ith block header in the Bitcoin blockchain.Would the scheme be me more secure if you instead used H(studentID||Bi-1|| Bi)? (https://cs.nyu.edu/courses/fall17/CSCI-GA.3033-019/assignments/practice_final.pdf)
I get that it maybe more secure if you use the Bi-1 because you have more inputs to generate an output, but I feel like that is not the reason.

giving them a number H(studentID||Bi) where Bi is the ith block header in the Bitcoin blockchain.Would the scheme be me more secure if you instead used H(studentID||Bi-1|| Bi)?

For this purposes of this question, the bitcoin header Bi = H(Bi-1 || other stuff).  Under a black box assumption of H()'s behavior, the two schemes are practically equivalent.
You can't really argue that H(id || Bi-1 || H(bi-1||stuff)) is more secure than H(id || H(Bi-1||stuff)) on the basis of 'more data' because H() might well have an internally bottleneck E.g. it could be implemented H(bytes[0 .. n]) = H(H(...H(H(H(bytes[0])||bytes[1])||bytes[2])...||bytes[n])  (and, in fact, sha256 does work kind of like this, though not one byte at a time).
Without out a more formal definition of "security" I don't think it's possible to just answer the question.  But guessing at a meaning "could someone more easily rig their office hours under one instead of the other"-- the answer would be no.

A hash is just a way to summarize things into an unique ID.
The more elements the hashing contains the harder it is to break it, if you reverse a hash it would cause a preimage attack and the algorithm  of the hash would be useless because you would’ve broken its main concept which is hashing (not encrypting)
If everyone knows the way the hash is computed then everyone could fake the hash (In bitcoin, everyone knows the way it is computed because that’s how the nodes can verify whether a hash is valid or not and thus know whether the blockchain was modified). Having said that, you might want to consider the secret of the order for the hashing in order to make it “secure”.
A hash safety itself is measured by how hard it is to break it. Sha256 is one of the most powerful hashes because it’s almost impossible to generare a preimage attack, but if you need to make it safer, you could hash the hash, H(H1(H0))
Where H0 is the first hash.
That way it would get harder exponentially to break it, (the more rounds you use to hash information, the harder it gets by an exponent number).
I hope that works for you to understand.


text:
BIP44: What's the use of internal addresses?
I've read other questions (and their answers) on this but I still don't see the use for internal addresses. I get that you're supposed to send the change of a transaction there but I don't see how this benefits you, all it does is move your remaining funds on an address, right? And you could just as easily move your funds to a new external address. I understand that the point is to use an address only once, but that can also be done with external addresses.
I hope that somebody can explain what benefits internal addresses have,
Thanks in advance!

The separation between internal and external addresses comes from BIP32.
Using a different chain for each permits you to give out an xpub for just the external ones to an auditor. They would then be able to observe your incoming payments, but not your spending.

Another question: when sending some BTC to somebody should you prioritize internal or external funds? My guess would be external because then you'd get more internal funds making your transaction history more private, but I'm not certain

In order to keep track of who sent you how much money you make sure to hand out an address only once and make a note of who you handed out the address to in your wallet software. This way all funds sent to a particular address are attributed to a particular party. Now if your wallet was using external chain addresses for change you wouldn't be able to track who sent you how much.
As for why there is change at all it's because unspent outputs can only be spent in their entirety so if you don't want to send the entire amount to the recipient you have to receive the excess as change back to yourself. There are two related articles on the wiki about this called change and coin analogy that you might want to read.

Ah, so you mean that you give one receiving address to one person that they will use whenever they need to send you money so you have addresses per person that sends you money instead of an address per transaction (receive + send)?

@timgfx ideally it's per transaction. The point is that you attribute payments based on the address where they are sent so if your wallet starts sending change to external addresses that'll only confuse things for you.