text:
Can someone explain how an HTLC is redeemed?
I'm looking at Bolt 3 in the Lightning rfc. My question is about how a HTLC is redeemed. Example HTLC script for reference:
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

My understanding is that it can be redeemed in two ways. The first way can be done if the revocation secret is known.
<revocation_sig> <revocationpubkey>

revocationpubkey will produce the correct hash, OP_EQUAL will return "1", the script goes into OP_IF, and the revocation_sig will be valid for OP_CHECKSIG.
The second way involves
<remotehtlcsig> <payment_preimage>

Can someone explain how this satisfies the script? For example, what OP_SWAP does or when it would go through OP_NOTIF/OP_ELSE?

There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout.
Redeemed using a valid pre-image by remote node:

The stack starts at <remotehtlcsig> <payment_preimage>
Since the HASH160 of <payment_preimage> is not equal to the HASH160 of revocationpubkey, the outer ELSE statement is triggered
<remote_htlcpubkey> is pushed to the stack. Stack is now <remotehtlcsig> <payment_preimage> <remote_htlcpubkey>.
OP_SWAP is pushed to the stack, which swaps the top two items on the stack.
Stack is now <remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
OP_SIZE 32 OP_EQUAL verifies that the payment_preimage is 32 bytes.
Since the payment_preimage is 32 bytes it will output 1. As a result OP_NOTIF will not be triggered, and hence OP_ELSE statement will be triggered.

OP_NOTIF is triggered is the value on the stack is 0
OP_ELSE is triggered if the preceding OP_IF, OP_NOTIF and OP_ELSE are not executed.

The stack is still <remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
The OP_HASH160 will hash the paymentpreimage. Since payment hash is SHA256 of the payment preimage, we need to hash it with RIPEMD160 so that it is equal to HASH160 of the paymentpreimage.
If the hash matches, then the stack will be <remotehtlcsig> <remote_htlcpubkey> OP_CHECKSIG
If the signature matches the remote_htlcpubkey then 1 will be returned to the stack and this offered HTLC output is successfully spent by the remote node.

Redeemed after time-out by the local node:

To trigger the HTLC timeout condition, the local node will use the witness: 0 <remotehtlcsig> <localhtlcsig> 0
The stack starts at 0 <remotehtlcsig> <localhtlcsig> 0
Since the HASH160 of 0 is not equal to the HASH160 of revocationpubkey, the outer ELSE statement is triggered
<remote_htlcpubkey> is pushed to the stack. Stack is now: 0 <remotehtlcsig> <localhtlcsig> 0 <remote_htlcpubkey>
OP_SWAP swaps the top two items on the stack. Stack is now: 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0
Since size of 0 is not 32 bytes it will return 0 on top of stack. This triggers the OP_NOTIF statement. Stack is still: 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0
OP_DROP drops the top item on the stack which is 0. Stack is now : 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey>
2 is pushed to the stack. Stack is 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 2
OP_SWAP swaps the top two items on the stac. Stack is: 0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey>
<local_htlcpubkey> 2 OP_CHECKMULTISIG is pushed to the stack. The stack is thus 0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey> <local_htlcpubkey> 2 OP_CHECKMULTISIG.
The above is a multisig output which can be spent only with valid signatures from the local and remote keys. These keys are exchanged when adding the HTLC. The output of the above transaction is sent to the local node using a to_self_delay using the time-out transactions.

Thanks, this clears up a lot. A couple of questions though. 1) Why is the OP_SIZE 32 check needed? Isn't it enough to check that OP_HASH160 gives the right value? 2) Why is OP_NOTIF used instead of OP_IF (and of course switching what goes into OP_ELSE)?

According to the BOLTs payment preimage HAS to be 32 bytes of data. Assume you generate an invoice with payment hash representing the SHA256 of a 40 byte data. Now when fulfilling the HTLC, you cannot send the 40 bytes of data and as a result would want to terminate the transaction on-chain. If the size counter was not there, the hash would be equal and you would get the bitcoins. But all the other nodes in the path will also have to terminate their channels on chain to get the funds as they won't be able to look get the preimage from the confirmed tx. The size keeps this behavior in check.

@Darius 2) The "Redeemed after time-out by local node case" that I mentioned in my answer is what triggers the OP_ELSE statement.

Check the Script wiki would be helpful. I once did this by hand, here's the process.
First, put the unlocking script on top of the locking script,
<remotehtlcsig> <payment_preimage>

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

If it helps, put them vertically,
<remotehtlcsig>
<payment_preimage>
OP_DUP
OP_HASH160
<RIPEMD160(SHA256(revocationpubkey))>
OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
...

Second, run them by hand. Keep in mind that, the instructions are read from top to bottom(or left to right), the stack grows as follows,

<remotehtlcsig>
<remotehtlcsig> <payment_preimage>
<remotehtlcsig> <payment_preimage> OP_DUP

OP_DUP, from wiki, duplicates the top stack item, so,

<remotehtlcsig> <payment_preimage> <payment_preimage>
<remotehtlcsig> <payment_preimage> <payment_preimage> OP_HASH160

OP_HASH160, from wiki, The input is hashed twice: first with SHA-256 and then with RIPEMD-160, so we hash,

<remotehtlcsig> <payment_preimage> <payment_preimage_hash160>
<remotehtlcsig> <payment_preimage> <payment_preimage_hash160> <RIPEMD160(SHA256(revocationpubkey))>
<remotehtlcsig> <payment_preimage> <payment_preimage_hash160> <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL

OP_EQUAL, from wiki, Returns 1 if the inputs are exactly equal, 0 otherwise. We check that <payment_preimage_hash160> != <RIPEMD160(SHA256(revocationpubkey))> and return 0,

<remotehtlcsig> <payment_preimage> 0
<remotehtlcsig> <payment_preimage> OP_IF OP_CHECKSIG OP_ELSE

OP_IF, OP_ELSE, and OP_NOTIF are flow controls, from wiki, we will jump into the OP_ELSE clause, which is,
...
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Now we keep working on the stack,

<remotehtlcsig> <payment_preimage> <remote_htlcpubkey>
<remotehtlcsig> <payment_preimage> <remote_htlcpubkey> OP_SWAP
OP_SWAP, from wiki, the top two items on the stack are swapped, so we swap <payment_preimage> and <remote_htlcpubkey>,
<remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> OP_SIZE

OP_SIZE, from wiki, pushes the string length of the top element of the stack (without popping it).

<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> <size of payment_preimage>

Notice that the size of a valid <payment_preimage> is 32,

<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> <size of payment_preimage> 32
<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> <size of payment_preimage> 32 OP_EQUAL
<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> 1

We have a 1 here, so we jump into the OP_ELSE section in the whole OP_NOTIF ... OP_ENDIF, to remind you, the script left is,
...
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> 1 OP_NOTIF ... OP_ELSE

Once jumped into the OP_ELSE, the rest is straightforward, step by step, we have,

<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> OP_HASH160
<remotehtlcsig> <remote_htlcpubkey> <hash160 of payment_preimage>
<remotehtlcsig> <remote_htlcpubkey> <hash160 of payment_preimage> <RIPEMD160(payment_hash)>
<remotehtlcsig> <remote_htlcpubkey> <hash160 of payment_preimage> <RIPEMD160(payment_hash)> OP_EQUALVERIFY
<remotehtlcsig> <remote_htlcpubkey>
<remotehtlcsig> <remote_htlcpubkey> OP_CHECKSIG

The final OP_CHECKSIG will check <remotehtlcsig> and <remote_htlcpubkey>, thus the HTLC will be spent via the unlocking script, <remotehtlcsig> <payment_preimage>.
The orders may not be strictly precise, but the general direction should be correct. Another tool is Bitcoin Script Debugger.
And yes, as pointed out by Ugam Kamat, there are three ways to redeem a HTCL.
Happy Lightning!


text:
Sent BCC to BTC wallet, read all treads, and still found no answer
I read all the threads but still no way to recover. I sent BCC from changelly to a BTC wallet.
I tried to import my BTC wallet on a BCC imported wallet by inputing BTC private key while importing a BCC wallet, but gives error.
Anyone can help me recover these lost BCC pleaaaaase?
Thanks

What wallet software are you using?

I sent BCC from changelly to a BTC wallet.

You can not send BCC/BTC to a wallet. You are sending them to an address.

I tried to import my BTC wallet on a BCC imported wallet

Never ever do things you do not fully understand

Anyone can help me recover these lost BCC pleaaaaase?

You should install bitcoin-abc and synchronize the blockchain to a different database folder. Next, you should import the BTC private key to this client.

Sorry I do not speak such an elaborated langage^^
I am so happy there is hope on this desperate case...!
Well, if I understood well:

I install abc (this is straight away easy)
I synchronize the blockchain to a different database folder (I did not understand anything in this one)
Import the BTC private key (I know what it is) to this client (what is a client?)

Can you explain a little bit more
Thank you very much

SO HAPPY TO WRITE HERE AND HELP BY GIVING WHAT WORKED FOR ME!!
I have a bitcoin.com wallet, and this was the answer of the support team that helped me recovering lost BCH
Hi there,
Please ensure that you set up a Bitcoin Cash sub-wallet within your Bitcoin.com wallet if you have not done so already; there is a video tutorial below for your convenience on youtube, after the adress: watch?v=MyQwUJjTcNY
You will then be able to retrieve the BCC sent to your Bitcoin.com BTC wallet using the following tool (note that you must enter your Bitcoin.com BTC wallet 12 word recovery phrase into this tool):
https://blog.bitpay.com/bitcoin-cash-recovery/
Please note that you will need to translate your receiving Bitcoin Cash address (from your Bitcoin.com BCC wallet) to an address beginning with the letter 'C' using the following tool:
https://jdonadio.github.io/address-translator/
In the second tool above, paste your Bitcoin Cash receiving address from your BCC wallet and copy the new address beginning with 'C'. Return to the first tool, and enter the new address beginning with 'C' as your receiving address. Once you complete the transfer your BCC will appear in your Bitcoin.com BCC wallet.
Regards,
ENjoyyyyy

source: Stack Exchange

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

sort: votes


text:
What percentage of Bitcoins are held by exchanges?
was wondering how much is held by exchanges vs. hard wallets (which I dont really understand) how does someone with a hard wallet sell their Bitcoin?

was wondering how much is held by exchanges vs. hard wallets

It's not possible to know for certain how much bitcoin is currently held by exchanges as it is trivial to create pseudo-anonymous addresses and it is generally good practice for an exchange to not disclose their addresses.

how does someone with a hard wallet sell their Bitcoin?

By "hard wallet", I assume you meant hardware wallet instead.
A hardware wallet is usually used to interface with software installed on an online machine to sign transactions. The key advantage with using a hardware wallet is that the private key (if properly implemented) never has to leave the device. Once the transaction is signed, then software on the machine connected to the internet may broadcast the transaction to the bitcoin network.

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


text:
How much Bitcoin did I mine in December 2013?
I just realized I had a bitcoin mining program installed back in November/December 2013.
I am trying to figure out if it's worth going through all my backups to see if I can still find the wallet file.
I assume that based on the duration, the date and my MacBook Pro specs, I should be able to get a rough estimate on how much I had mined. Maybe someone can help me figure out, what the difficulty was back then, and based on the MacBook Pro specs, how much I could have mined.
Starting date: 25. November
Ending date: 22 December
Hardware: MacBook Pro (Mid 2012) - 2.5 GHz (3210M) Intel Core i5 Ivy Bridge -  Nvidia GeForce GT 650M with 512 MB
I had my MacBook on pretty much 24/7.
I am just looking for a rough estimate.

Were you mining for a pool, or solo mining?

You can go to https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison for a table of mining performance of many different CPUs and GPUs.  The GT650M is reported as doing 17.8 Mhash/s; let's round it up to 20.  There is a range of values for various Core i5 CPUs from 5 to 20 Mhash/s; let's be generous and call it 20 also.  So you were mining at a combined rate of say 40 Mhash/s; in scientific notation that's 4.0e7 hash per second.  You mined for 28 days which is 2.4e6 seconds, so you performed a total of 9.6e13 hashes.
Next we need to know the mining difficulty around that time.  There is a chart at Blockchain.info.  It was increasing rapidly during that time but in early December it was around 707,000,000, or 7.1e8.  Each 1 unit of difficulty corresponds to 2^32 = 4.3e9 hashes needed to mine one block.  So at that time, it took about 3.0e18 hashes to mine one block.
As such, you would expect to have mined 9.6e13 / 3.0e18 = 3.2e-5 blocks.  The block reward at that time was 25 BTC per block (see https://en.bitcoin.it/wiki/Controlled_supply) and so you would have earned, on average,  BTC 8e-4, or in other words BTC 0.0008.
At today's exchange rate of USD 6149 per bitcoin, that is worth just under USD 5.00.
This is of course an average, or expected value.  If you were mining for a pool, this may or may not have been enough to actually earn a payout.  If you were solo mining, you would have had to mine a full block worth BTC 25; the probability that you did so is about 3.2e-5.


text:
What additional considerations are there for dual-funded payment channels?
Naively, it seems like a dual-funded channel should not be much more complicated than a single funded channel; You'd just have an extra input from Bob and it would be reflected in the balances of the first commitment tx.
I'm guessing dual-funded channels are more complicated though, since it's not currently specified in the BOLTS.
Is it because for a dual-funded channel there is the additional risk of one peer not sending over their signature for their input to the funding tx? Presumably this would force Alice to either wait, or consume their input in another tx in order to invalidate Bob's dual-funded funding tx. Is that an issue? And if so is there a solution for it?
Are there any other complicating factors for dual-funded compared to single-funded payment channels?

The issue of waiting for signatures also holds true in the single funded channel.
Let us assume Alice wants to open a single funded channel. As long as she has not gotten signatures for the commitment transaction via commitment_signed message she cannot publish the funding tx.
In the dual funded case there need to be two rounds of signature exchanges (one for the input of the funding tx and one for the commitment tx) but from a risk perspective of an unresponsive peer this is not worse than the situation we already have in single funded channels.
The real difficulties emerge since in the case of dual funded channels it is not so clear who should pay the onchain fees and why (also there is some additional communication overhead (see below))? Remember in the case of single funded channels all fees are paid by the initiator in every case as it was the initiator who had the interest of opening the channel.
Let us look at dual funded channels: Some might argue that this is a service to the purchase inbound liquidity and there should be a service fee. This is discussed in this thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001631.html along this line goes the question and discussion of how to make sure that the channel is not closed again right away: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html
In general there was a nice post on the ML about the initial dual funded protocol. I can't sum this up to quickly but I guess you will find some of the challanges in the thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001682.html

Thanks!! RE the risk of an unresponsive peer during establish: What I am talking about are the signatures for the (dual) funding tx itself. In the single funded channel (by Alice), if Alice decides to pull out, she could just never broadcast the funding tx and not worry any further. In the dual-funded case, if Alice sends the signature for her inputs of the dual-funded tx to Bob, and if Bob is unresponsive, Alice would either wait until Bob signs his inputs and broadcasts it, or if Alice wanted to pull out, she would have to double spend her input so that Bob cannot broadcast the funding tx?

Does Alice have to send her signatures? I guess they can agree on tx Id before and exchange signatures for the commitment tx before exchanging signatures for the funding TX (isn't that exactly what segwit was created for?). This would mean that either one can double spend the inputs of the funding TX or publish the commitment tx after the funding TX is broadcasted. I don't see any problem but maybe I am missing something

A dual funded funding tx would need two signatures right? One from Alice for her input, and from Bob for his input. Let's say they agree on the details of the channel and have exchanged signatures for the first commitment tx. Then at some point, at least one of them will have to send the other their signature for their input in the dual-funding tx. Unless there's a way for both to exchange these signatures atomically, there'll be the possibility that only one sends the other their signature, and is in limbo until the other peer broadcasts it. I think it is similar to the 'free option' problem.

Maybe there's a clever solution for this, but I thought it might be an issue for establishing dual funded channels.

I don't think refusing to send funding TX stuff is a p problem. You can doublespeak the input of your funding TX input without the help of your partner if the partner becomes unresponsive. If the partner however broadcasts the funding TX at the same time you can directly force close the channel in case the funding TX gets mined. I don't see the relation to the free option Problem. There seems so economic benefit in holding back a signature

The relation was just as far as one peer ends up having total control over whether the transaction goes through. There's no economic benefit for the one withholding, but there is an economic loss for the peer who would end up having to double spend their input. I guess if that was a big enough concern for the peer, they could decide not to be the first one to send their funding signature. In that case there's no extra risk for them so it's fine. Good to know!

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


text:
Can a coinbase transaction have a segwit output?
And more generally speaking, are there any restrictions on the output of a coinbase transaction?

Other than the total value needing to be correct (no more than the block reward plus fees), the outputs of a coinbase transaction are completely unrestricted and act the same as any other transaction.

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


text:
What does the 'n' in nLockTime and nSequence stand for?
I know what nLockTime and nSequence do, but I'm just curious about where the 'n' comes from. Thanks

It stand for a number, it is commonly used in programming to designate a variable that gonna hold an amount of something see: https://en.bitcoin.it/wiki/NLockTime and https://en.bitcoinwiki.org/wiki/NSequence

The concept of prefixing variable names with information about their type is called Hungarian notation. It was common in Windows programming in the '90s, and now is generally considered a bad idea.


text:
Is it possible to set an overall seed for generating blocks on regtest mode?
I am using bitcoin core on regtest mode to simulate sending transactions.
Is it possible to set an seed for things like generating blocks or signing transactions, so that you can recreate an exact chain of events with the same block hashes and signatures?

I'm not sure I understand the question completely..
In the current version you generate blocks to an address.
What would you set a seed for

Right now if i start up bitcoind in regtest mode, and the first thing I do is generate a block so that the block height is 1, the block hash will be unique. Is there any way of starting up bitcoind so that it would give me exactly the same block hash each time? (I realize now it would probably mean setting the time to something fixed).

Generation of blocks uses the proof of work algorithm that includes a nonce that ensures randomness, if we could somehow recreate all these things the whole system of cryptocurrency would break down. The short answer is no.

Downvoted. I don't see how this is related to the question.


text:
Is the dust output limit the same for p2wpkh and p2wsh?
I've seen mentioned in a few places that the dust limit for an output to be considered standard is minRelayTxFee*3. Based on this, I would expect the dust limit for a p2wsh output to be larger than for a p2wpkh, since CTxOut for p2wsh is larger (43 bytes versus 31 bytes).
However, when I look at the code in policy.cpp, it seems to only care about whether the output follows a witness program, and not whether it is p2wpkh or p2wsh. So does that mean the dust limit for a p2wsh output is also 294 satoshis?

I just realized that there are in fact these two lines which takes into account the size of CTxOut:
size_t nSize = GetSerializeSize(txout);
...
...
nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);

so based on this, a p2wsh output (43 bytes) would have a dust limit of:
= 43 + (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4)
= 110 bytes
then using the current dust_relay_tx_fee of 3000 sat/kilobyte (or 3 sat/byte),
110 bytes * 3 sat/byte = 330 satoshis
Therefore, p2wsh outputs with less than 330 satoshis will be considered non-standard and will be rejected.


text:
Whats the difference between funding to mutisig address and general address start with '1'?
I build raw transaction: '0100000001b0e1a9cc83fbe8918a1cf20e0c72cf2fe3af252f228a3a0223943c2732f69bd8010000006b483045022100cf98600ba4f4d7bc748e36e4bb7eed48a26d7eab45bb813f65781ca7921a163702204f857a25574ba50c54373dc9fcdbba51ac1653b1007832b8314a7ccc2224d927012102534fd869124dff1cc99c430b97a5b6817b1f8343ce1e1de3ff71d4a3fc6c1592ffffffff02307500000000000017a9146cf00a2686081c15e931f7413b0f07561388c9c18764000000000000001976a914e093b1e8185d6b8136a80c8ab02e2f0bbfaf15c288ac00000000'
but it failed to boardcast , are there some difference between funding to multisig address and normal address when building raw transaction and signing transaction?
You can also find both of two kinds of address appear in my outputs, does bitcoin network support this?

I tried to broadcast your transaction, but it's rejected due to dust outputs (you have a 100 sat output, which costs more in fees to spend than it's worth at the lowest fee levels).

thank you very much, I tried anthor transaction without dust outputs, successfully transfer.


text:
Why my Bitcoin Cash coins moved to another wallet if i did it on original Bitcoin on 12/12/2017?
I have very old Bitcoin wallet from 2012 year. The last operation was 12/12/2017 - this was movement all sum to my another wallet.
I was very surprised today when i first time load this wallet into Bitcoin-ABC (bitcoin cash) and see this transaction inside it!!! I see exactly same transaction (moving same sum to same wallet alias on same date 12/12/2017) inside Bitcoin Cash blockchain.
Can you explain me how is it possible? As I understand Bitcoin Cash has separate blockchain from August 2017 so i should not see the last operation on December 2017.
I used this command to load my wallet into Bitcoin-ABC (bitcoin cash)
bitcoin-abc-0.16.1/bin/bitcoin-qt -wallet=my_bitcoin_wallet.dat -datadir=path_to_bitcoin_cash_blockchain

yes, the btc-blockchain and the bch-blockchain are running independently of each other. the most probable cause is: your wallet was hacked or you did an mistake. if you send a transaction to the btc-network it is absolutely impossible that this transaction will be executed on the bch-blockchain -> accept you (or somebody else who knows your private key) send the transaction to the bch-network

@anion I'm sure it was not hacked. Because hacker should move all sum to his own wallet but not into my. And another reason is hacker can do it any date but bth-transaction was done exactly 12/12/2017

"hacker should move all sum to his own wallet" that is obviously correct, i thought the same when i have written it :D

@anion I found very interesting info. It is unconfirmed as i can see. So I think this is bitcoin-qt bug or some behaviour which i can't understand when it show this transaction from original btc-blockchain. I see this info when double click on the last tran
Status: 0/unconfirmed, not in memory pool
Date: 12/12/17 13:13
To:
Debit:
Transaction fee:
....

Would you be willing to share the transaction ID?

I see exactly same transaction (moving same sum to same wallet alias
  on same date 12/12/2017) inside Bitcoin Cash blockchain. Can you
  explain me how is it possible?

Bitcoin and BitcoinCash have the same history before August'17

i know. That is my question why can I see transaction which was on December'17

You should use separate wallet.dat file for BCH network. Make a backup file, put wallet_for_bch.dat to BCH folder and run client with -zapwallettxes=2 parameter (and all other command-line arguments also!) to rescan the blockchain


text:
How to start Bitcoin-qt with Bitcoin Cash?
First of all I do not trust online wallets so I download full blockchain with Bitcoin-ABC. Unfortunaly bitcoin-abc does not contain bitcoin-qt binary. So my question is it possible to start original Bitcoin-QT with bitcoin-abc?
if this is not possible, what is the other way to use my wallet under bitcoin-abc?
Thanks!

Bitcoin ABC 0.16.1 binaries for linux have a QT GUI:
https://download.bitcoinabc.org/0.16.1/linux/ - I have not checked the other platforms, but I assume they do too.
They kept the same binary names (bitcoin-qt, bitcoind, etc) when they forked Bitcoin Core, which is a bit confusing because it is a seperate network with its own consensus rules.
The standard bitcoin-qt (Bitcoin Core) only works for bitcoin, not bcash.

I downloaded this package https://download.bitcoinabc.org/0.16.1/linux/bitcoin-abc-0.16.1-aarch64-linux-gnu.tar.gz and did not find bitcoin-qt inside bin folder. Can you submit this?

I downloaded another dist and found bitcoin-qt there


text:
How to open new wallet into Bitcoin Core and switch between?
I have my old wallet which private key is compromised. So my reasonable way is to open new wallet and move all bitcoins from compromised wallet to new wallet.
I use Bitcoin Core. I do not trust any online wallets because private key stored into remote store.
So how can i open new wallet and move all bitcoin to it using Bitcoin Core only?

the best way is

close bitcoin-core
2.rename wallet.dat file to wallet-old.dat
3.start bitcoin-core (it creates new wallet and new wallet.dat file)
user bitecoin-core --wallet parameter to switch between new and old wallets

the funds are linked to your "compromised" keys. They are not in your wallet. So you can generate a new set of keys (as you mentioned, by creating a new wallet), and then transfer from old address to new address. Before you start anything, think of backups! Procedure might be like this (attention: wallet dirs on Windows, Unix and OSX locations differ, depending on your OS, you may want to adopt):
0.) stop bitcoind or UI
1.) backup of old (compromised) wallet to USB stick
2.) rename bitcoin wallet directory to s.th. like "OLD_bitcoin_dir"
3.) start bitcoin (it will create new wallet and keys, get one of the public keys via MENU->FILE->RECEIVE ADDRESSES, cut&paste or write it down)
4.) stop bitcoind or UI
5.) rename wallet directory to s.th. like "NEW_bitcoin_dir"
6.) rename wallet directory "OLD_bitcoin_dir" to your original name
7.) start bitcoin
8.) transfer your funds to your new address from step 3
9.) wait until you "see" in a block explorer your funds on the new address
10.) stop bitcoin
11.) delete wallet dir
12.) rename wallet directory "NEW_bitcoin_dir" to your original name
13.) check if funds are all there
14.) don't forget to backup again :-)

Hope this is the way to go, if there is an easier way within Bitcoin Core, I'd be happy to hear from the experts...

Note: you can also use the -wallet command line parameter when you start bitcoin to specify which wallet to load rather than having to rename them each time :)

I use Windows OS. What is the "bitcoin wallet directory" on Windows and where can i find it?
i have "bitcoin-data" directory on separate hard drive and few subfolders inside it ("blocks", "chainstate", "testnet3"). And wallet.dat file inside "bitcoin-data".

ugh, Windows, I don't know. Usually, the "bitcoin wallet directory" is were your wallet.dat file is. Look at the comment from MeshCollider. You may want to go into the help menu, and choose "commandline options", and search for -wallet. This tells you how to provide a parameter to your folders or subfolders, where the file "wallet.dat" resides. Have a backup already? :-)


text:
How do you calculate a taproot sighash?
I'm having trouble manually recreating the taproot sighash from the example below.
I used btcdeb to pass in an input transaction (with a P2TR output), and a valid tx that spends from it. In the logs it shows the components of the sighash message, but when I concatenate them and hash it with sha256 I'm not getting the same sighash. What am I missing?
Also, what is the epoch? I've tried with and without this value and neither worked.
$ btcdeb --txin='02000000000101c7eb56c02553b5fe29c16b458960ba21be0ef1fb020972fde15324b1f725f0480000000000fdffffff027c9c181e010000002251204a0cd40b4984a107334966b266bdc8134bcba9f23f039ed9ddc3f99d6c99c03fa048ed0b000000002251204f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa024730440220077e71f9276149475ecb27e68374712f43e0af6f61ca0e0c9a74483c07bd08d902206f0befdcbc047b0a9a59eff49e011f81644ba0e179a6fa4a90bb19f7765d165c012103d31501fa2dd221b0d40eead3961afd65bdfa986f2577327d1400fa82691cc69965000000' --tx='02000000000101d0a3e1a6c730355abefa376f9b5d3ca9325b153475becc8402e3b4a98d393ed20100000000ffffffff0280d1f00800000000160014fc7250a211deddc70ee5a2738de5f07817351cef80f0fa0200000000160014531260aa2a199e228c537dfa42c82bea2c7c1f4d01404d22f94e5d1787eecf712b14b0c8fb57242633616d50ca5b77f31dad9ad43d0a6786b1e5467dc20494a08e5862821834675f91f897f0e568b417430b07ba100b00000000'
btcdeb 0.4.22 -- type `btcdeb -h` for start up options
LOG: sighash signing segwit taproot
notice: btcdeb has gotten quieter; use --verbose if necessary (this message is temporary)
input tx index = 0; tx input vout = 1; value = 200100000
got witness stack of size 1
34 bytes (v0=P2WSH, v1=taproot/tapscript)
valid script
- generating prevout hash from 1 ins
[+] COutPoint(d23e398da9, 1)
note: there is a for-clarity preamble (use --verbose for details)
2 op script loaded. type `help` for usage information
script                                                           |                                                             stack
-----------------------------------------------------------------+-------------------------------------------------------------------
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa | 4d22f94e5d1787eecf712b14b0c8fb57242633616d50ca5b77f31dad9ad43d0...
OP_CHECKSIG                                                      |
#0000 4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
btcdeb> step
        <> PUSH stack 4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
script                                                           |                                                             stack
-----------------------------------------------------------------+-------------------------------------------------------------------
OP_CHECKSIG                                                      |   4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
                                                                 | 4d22f94e5d1787eecf712b14b0c8fb57242633616d50ca5b77f31dad9ad43d0...
#0001 OP_CHECKSIG
btcdeb> step
EvalChecksig() sigversion=2
GenericTransactionSignatureChecker::CheckSchnorrSignature(64 len sig, 32 len pubkey, sigversion=2)
  sig         = 4d22f94e5d1787eecf712b14b0c8fb57242633616d50ca5b77f31dad9ad43d0a6786b1e5467dc20494a08e5862821834675f91f897f0e568b417430b07ba100b
  pub key     = 4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
SignatureHashSchnorr(in_pos=0, hash_type=00)
- taproot sighash
 << epoch
#001 00
 << hash type
#001 00
 << tx_to.nVersion
#004 02000000
 << tx_to.nLockTime
#004 00000000
input type != anyone can pay:
 << cache prevouts single hash
#032 e186179664b38e58723ba1ac8d5915f97023f6afc2f2be94459fe9868cf953eb
 << cache spent amounts single hash
#032 646b3ee05dcdae994f2d99d94a878d1ad40c3f4b536b76a6a730b4e28b29c385
 << cache spent scripts single hash
#032 e00e0a53937928e143c165df361096d6f607d8fe35aa63f4adfe2e73b56cd324
 << cache sequences single hash
#032 ad95131bc0b799c0b1af477fb14fcf26a6a9f76079e48bf090acb7e8367bfd0e
output type == sighash_all
 << cache outputs single hash
#032 5ac2b429009184588bf78341f4692a02303a6a3110c2f1a914f3dba9cea091cb
 << spend type
#001 00
 << in_pos
#004 00000000
- schnorr sighash = 1eaaf5f3228e6aa087cf9620ac86f8bc5458261b074b7cb6d78c20f358d6fc1f
  pubkey.VerifySchnorrSignature(sig=4d22f94e5d1787eecf712b14b0c8fb57242633616d50ca5b77f31dad9ad43d0a6786b1e5467dc20494a08e5862821834675f91f897f0e568b417430b07ba100b, sighash=1eaaf5f3228e6aa087cf9620ac86f8bc5458261b074b7cb6d78c20f358d6fc1f):
  result: success

And here is my python script to try and create the same sighash:
import hashlib

sig_msg = (
    "00" # epoch
    + "00" # hash_type
    + "02000000" # nVersion
    + "00000000" # nLockTime
    + "e186179664b38e58723ba1ac8d5915f97023f6afc2f2be94459fe9868cf953eb" # sha_prevouts
    + "646b3ee05dcdae994f2d99d94a878d1ad40c3f4b536b76a6a730b4e28b29c385" # sha_amounts
    + "e00e0a53937928e143c165df361096d6f607d8fe35aa63f4adfe2e73b56cd324" # sha_scriptpubkeys
    + "ad95131bc0b799c0b1af477fb14fcf26a6a9f76079e48bf090acb7e8367bfd0e" # sha_sequences
    + "5ac2b429009184588bf78341f4692a02303a6a3110c2f1a914f3dba9cea091cb" # sha_outputs
    + "00" # spend_type
    + "00000000" # input_index
)

sig_msg = bytes.fromhex(sig_msg)

hashlib.sha256(sig_msg).digest().hex()
# returns 4c1f7ef4d927d34de60599d334fe26cfb03090c5672e01019bf5da54b9cb5446

I believe you're missing the fact that the hash function used in BIP341/BIP342 is not SHA256 directly, but a tagged hash "hashTapSighash()".
From the BIP:

hashtag(x) notation to refer to SHA256(SHA256(tag) || SHA256(tag) || x).

So you have to prefix your message with SHA256("TapSighash") twice.

Thank you! It worked. And for anyone reading you can use the tagged hash function from here: https://github.com/bitcoin/bips/blob/master/bip-0340/reference.py#L25

From Pieter Wuille's answer, here's what the correct hash function from BIP340 should be:
import hashlib

def tagged_hash(tag: str, msg: bytes) -> bytes:
    tag_hash = hashlib.sha256(tag.encode()).digest()
    return hashlib.sha256(tag_hash + tag_hash + msg).digest()

sig_msg = (
    "00" # epoch
    + "00" # hash_type
    + "02000000" # nVersion
    + "00000000" # nLockTime
    + "e186179664b38e58723ba1ac8d5915f97023f6afc2f2be94459fe9868cf953eb" # sha_prevouts
    + "646b3ee05dcdae994f2d99d94a878d1ad40c3f4b536b76a6a730b4e28b29c385" # sha_amounts
    + "e00e0a53937928e143c165df361096d6f607d8fe35aa63f4adfe2e73b56cd324" # sha_scriptpubkeys
    + "ad95131bc0b799c0b1af477fb14fcf26a6a9f76079e48bf090acb7e8367bfd0e" # sha_sequences
    + "5ac2b429009184588bf78341f4692a02303a6a3110c2f1a914f3dba9cea091cb" # sha_outputs
    + "00" # spend_type
    + "00000000" # input_index
)

sig_msg = bytes.fromhex(sig_msg)

tagged_hash("TapSighash", sig_msg)

# returns 1ffcd658f3208cd7b67c4b071b265854bcf886ac2096cf87a06a8e22f3f5aa1e
# which is the same as btcdeb (little endian)

Also, an explanation for the sighash epoch can be found here in BIP341.

Why is the input to hashTapSighash prefixed with 0x00? This prefix is called the sighash epoch, and allows reusing the hashTapSighash tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ext_flag mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.


text:
What are the last bytes for in a taproot script-path sighash?
I am trying to follow BIP341 to understand the signature hash calculation for taproot script path spends.
From the bitcoin testing framework code, I see that if the transaction is spending from a script path (as opposed to a key path spend), the sighash needs these additional bytes appended.
    if (scriptpath):
        ss += TaggedHash("TapLeaf", bytes([leaf_ver]) + ser_string(script))
        ss += bytes([0])
        ss += struct.pack("<i", codeseparator_pos)

Where are these bytes described in the BIP?
And in case it's not clear from the BIP, what is the purpose for the last two lines: 0x00 and struct.pack("<i", codeseparator_pos)?

You'll find this in BIP342, under common signature message extension. BIP342 signatures reuse most of the BIP341 signature hash structure, but add a few fields of their own, as well as changing a flag bit:

The tapleaf hash: spending using a BIP342 script requires committing to the actual script's hash (the "tapleaf") to make sure a signature created for one leaf can't be reused in other leaves. This makes it safe to to reuse the same keys multiple times in separate scripts of the same output.
The key version: since BIP342 allows the introduction of new public key types (without new witness version, leaf version, or new opcodes), there is one reserved byte for indicating what public key type is used for this signature. This is always 0 for now.
The code separator position: to enable (one of) the uses of OP_CODESEPARATOR to remain in this new model, its semantics were changed. Instead of truncating the "scriptCode" (a concept that no longer exists in taproot scripts), it just records when (in number of executed and/or skipped opcodes) the last OP_CODESEPARATOR was executed, and that number is included in the sighash. If no such opcode was ever executed, the number is 0xffffffff instead. The purpose of this is allowing someone to construct a script that defeats some form of malleability: a signature for a checksig operation before and after an executed OP_CODESEPARATOR cannot be reused in the other position, even if they use the same public key.

BIP341 describes the general structure of taproot outputs and spending, and the key path spending rules. It describes what script path spending is, but the actual script semantics that apply in this case are left for future extensions. BIP342 specifically describes the script semantics for taproot leaf scripts with leaf version 0xc0. Other leaf versions could be described by future BIPs.


text:
Using bitcoind, is it possible to set a specific fee with sendtoaddress?
For example, setting the fee to exactly 1000 sats or 300 sat/kw?

You cannot set an absolute fee, however you can use the settxfee RPC to set the fee rate for the wallet before you make the transaction. Note that this isn't persisted in the wallet and is only held in memory, so you will need to do it again if you restart Bitcoin Core or reload the wallet.

In the next major release of Bitcoin Core, version 0.21, you will be able to set the fee rate in sendtoaddress itself.


text:
Is it possible to reference an input outpoint more than once in a transaction?
For example, could you have the following transaction:
A --> B
A --> C
Where A is an input txid and index, and B and C are outputs? The reason I'm asking is because I believe with SIGHASH_SINGLE you can only sign one input and one output, so this would be a way to use the same input to spend to two outputs. It would be the equivalent of sighash 'double', if it existed.
For example, to have a transaction like this:
A --> B
A --> C
D --> E
Where the D --> E input and output could be added after the first two inputs had been signed. Is there any other way to achieve this?

No, this is not possible - once an outpoint is consumed by a transaction, it is considered spent, including within the same transaction.
Your only option here would be to have an intermediary transaction splitting A (or using another input), and then using the two outputs from that as inputs along with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for your flags.
A -> A1
 \-> A2

A1 -> B
A2 -> C
D  -> E

Note that SIGHASH_SINGLE signs a single output and all of the inputs. If you want someone else to be able to add inputs, you need the ANYONECANPAY flag as well


text:
Dogecoin: No wallet has been loaded
I downloaded many [X] core software, including Bitcoin, Litecoin and others, and they all worked fine, except for Dogecoin Core. It keeps saying "No wallet has been loaded". There was a wallet.dat file there, but I got the same error when it was there (it's an empty wallet, btw). Now I moved that file somewhere else, and Dogecoin core is not creating a new wallet, and keeps giving the same error. How can I fix this? Please advise.

I think I know the reason now... the problem is that on the official dogecoin website, the version to download is 1.1.0, which is the one I downloaded, but is not the latest. The latest now is 1.8.0 (apparently, according to github). I switched to the new version and the problem was solved.
If the devs of the Dogecoin website are here, please upgrade it.


text:
Is the bitcoin blockchain really non-corruptible?
Some people say that proof of work is better than proof of stake, because it's not possible to rewrite the whole blockchain on-spot. One would need to "re-mine" everything.
But I think this is not true! A hypothetical attacker can rewrite the whole bitcoin blockchain and make the timestamps make the block-time exactly 10 minutes, and this way the difficulty of mining will remain at minimum, and no real mining is required. The mining effort is minimal.
The way I understand it, is that such a problem is practically solved by check-pointing the blockchain in the source code. The devs hard-code block-hashes in the source code so that no one could do that. Is my description of the situation correct?
In other words: Without check-pointing, the bitcoin blockchain is inherently corruptible and can be destroyed. What am I missing here?
PS: This is not about PoW vs PoS. This is basically about the claim that PoW is non-corruptible. If my conclusions are true, we can just do the same with PoS blockchains and use check-pointing to prevent corruptibility.

Several incorrect assumptions here: by "longest chain" we refer to the chain with most work (not just most blocks), and checkpoints were a historical way to optimize synchronization speed which is being abolisbed (one of the reasons for abolishing it is actually due to it being prone to cause misunderstandings in Bitcoin's security model, like your question). If a checkpoint ever prevents an actual chain reorganization, PoW is completely broken.

@PieterWuille The bitcoin whitepaper says longest chain and doesn't say most work. Can you please provide references (or code) that confirm that longest chain = most work?

The whitepaper only describes the rough idea behind Bitcoin's design, and the practical implementation differs and extends it in many ways (for example, the whitepaper doesn't say the coin supply is finite!). As for proof: https://github.com/bitcoin/bitcoin/blob/v0.16.0/src/validation.cpp#L2586 is where the code decides which branch to attempt to validate, and calls a function that finds the most work chain. But really, this is a very fundamental design property, and you'll see it described in many places (including in dozens of answers on this site).

@PieterWuille Thanks. The code is enough evidence. Cheers!

Your attack wouldn't work because nodes take the most-work chain as leading, the number of blocks is irrelevant. Any attacking chain needs to spend at least as much work as was done for the original. This actually used to be a bug in the whitepaper and the initial bitcoin software implementation: it checked for the longest chain instead of most-work. It was fixed very early on.
Checkpoints are centralizing as they give devs power. They're no longer done in Bitcoin.

Could you provide proof/evidence that "most work" wins in bitcoin, and not the longest chain? I never seen this anywhere.


text:
Why is the output address a list in RPC/console?
Vout contains a list of addresses, which I noticed to be always with size = 1, if it exists. The following is an example from Bitcoin Testnet:
{
      "value": 0.91840581,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 1416b8f3a1c1c7e3e73a05046f002e66004accc3 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9141416b8f3a1c1c7e3e73a05046f002e66004accc388ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mhMB2g88n42ghQ5p1VA7Mt9VgTp9QvpDXU"
        ]
      }
    }

Why is the "addresses" (address) field a list? Are there any cases when this can take more than one address? Who can spend that then?

This is due to historical confusion between addresses and keys.
The original goal of this field was reporting the public keys involved in raw multisig outputs. However, those public keys were referred to by the P2PKH address corresponding to them.
This is confusing because obviously every output only corresponds to a single address. The feature is also useless now due to the introduction of P2SH, where instead of putting all public keys in the output, just a hash of script involving all those keys is stored.
EDIT: Since Bitcoin Core 23.0, the "addresses" field doesn't exist anymore, together with several other fields (like "reqSigs") that are only relevant (but confusing) for bare multisigs.

So it's never used now? It's safe to just take element number 0?

Raw multisig isn't used; there is no way for common wallet software to send to it. For anything but raw multisig, only a single address will be present.


text:
Would restricting channels to a maximum make LN more decentralized?
Currently LN seems a bit centralized - few central, well funded nodes seem to route transactions and make profits. I was wondering if limiting the number of channels a node can open to a certain max number, would make the LN more decentralized, in a sense that big central nodes won’t be able to have hundreds of channels and the routing action will spread more evenly to the network. Does this make sense?

Do you have any research results supporting your claims behind your question?

Absolutely not. Just wondering

Short answer: Such rule would not change anything people could split their funds across several nodes similar to LNBIG.


text:
Is it possible, with bitcoin-core or btcd, to manually set the scriptSig field in a coinbase transaction?
I am talking about when using regtest or simnet modes.
For context, it is so that I can create coinbase transactions with reproducible txids.

By "reproducible txids" do you mean that you want to know the txid before the transaction is created, or you want the same coinbase txid in multiple blocks?

I want to be able to start the blockchain from scratch, mine a block with just one coinbase transaction that has a specific scriptSig and address, so that it will produce the same txid each time. Thanks

It is not possible to do this in Bitcoin Core. If you want to have control over the coinbase transaction, you will need to use external mining software that allows you to do that.
Since the difficulty on regtest is so low, you could have a simple python script that produces blocks with your specific coinbase. You don't need actual mining software as the difficulty is low enough to be found almost instantaneously with a naive mining implementation.


text:
Getting root pub key form derived public keys
Hello I have a lot of derived public keys and derivation path to them how can I get root public key which was used to generate this pub keys?

You cannot. It is impossible to get the parent public key from the child public keys. This is because a hashing algorithm is used in deriving the child keys and hashing algorithms are not reversible.


text:
Are there any downsides to banning node crawlers?
There are multiple entities and open-source software that crawl the Bitcoin P2P network to discover and monitor nodes for various purposes (statistics, surveys, academic papers etc.)
Some of those I am aware of:

btc_node_scanner
dsn.tm.kit.edu
nodes.multiven.io
bitnodes.earn.com
bitnodes.io

Banning such nodes would free my connection slots for real useful nodes that actually provide consensus sourcing.
But, is there any downside to banning such crawler nodes?

Also, what about banning btc-seeder nodes? Would that affect negatively the health of the P2P network?

I think the ideal answer could provide the effects to two cases:

banning done by one user and how they are affected
banning done by a grand/meaningful number of users and how the overall network would be affected

Thank you

Do they actually stay connected as a peer for any significant length of time?  I would have though they just came and went.  Anyway, maybe you could just up your number of slots?  Because I doubt these monitoring nodes use that much network bandwidth ... or do they?

It would be hard to specifically ban crawlers as a practical matter because there is no reliable way to differentiate them from other normal nodes. They can, in fact, just be normal nodes that are instrumented with code to collect the desired data and report it back to an aggregation system.
So then you are left with banning normal nodes. Since all of the value of running a node comes from its connectivity to the P2P network via other nodes, this would not make sense.

The groups of nodes I mentioned (bitnodes, dsn.tm.kit.edu etc.), all have public user-agents (named subver in getpeerinfo), so you can (currently) ban them easily. Although it's possible that they could (start to) pretend to be normal nodes and use Bitcoin Core's subvers instead, the core question still remains.

Crawlers will most definitely start imitating real nodes if they'd be banned in this way.


text:
Is the transactions in one block effect the hash of the next block? How?
What I understand about blockchain is that:
Blocks are secured by the hash.
Transactions are secured by the markle-tree.
What i'm asking is, does the contents -transactions- of one block effect the hash of the next block? if so, how it happens?
If not, doesn't this mean that we can manipulate the transactions inside a block? because if we do so, the next block will have no idea what happens the previous block.
For example, lets say that we mined 10 blocks.
Then, we hacked block number 5 and changed the transactions.
How is this going to effect blocks number 6, 7,....?
I understand that if the majority of the nodes have the same values then the blockchain will be safe.
But what about a small blockchain owned by one node. In theory, does this mean that the block contents can be manipulated very easily?
Thank you

What i'm asking is, does the contents -transactions- of one block effect the hash of the next block? if so, how it happens?

Yes. The block hash of block X is explicitly included in the header of block X+1. So if you change the transactions in block X, it will affect the hash of block X, and that would change block X +1 as well.

For example, lets say that we mined 10 blocks. Then, we hacked block number 5 and changed the transactions.

The nodes on the network that already know about block 10 would not accept your new block 5 because it is a shorter chain (less work than the chain that is at block 10). They can recognize the new block 5 as being altered because the longer chain does not include it.


text:
How the blockchain knows that its been tampered with?
I know that the transactions stay in the block and hashed alongside few other things and that hash is stored in the next block. And I understand that if you try to tamper with one of the transactions, the hash will change and it will affect all the blocks that come after it.
However, how does a block know that its transactions have tampered with in the first place?
Assume that block #1000 has 10 transactions.
Now, the hash has been calculated and stored in block #1001
so, if I go back to block #1000 and add one more transaction, this will change the hash and it wont be the same one stored in #1001.
However, how the hash of block #1000 changes in the first place if it was already calculated? does this mean that the hash of each block is recalculated regularly?

what makes you think you can "add" a transaction to a block? the miner chooses what goes in the block. a miner can mine with your transaction included or excluded, but if he includes it, he can get the fees. somebody might find another block at the same height, that doesn't include your transaction but has high enough difficulty. but the security assumption is that it's hash will be different.

Related: https://bitcoin.stackexchange.com/q/95564/5406

If I go back to block #1000 and add one more transaction, this will change the hash and it wont be the same one stored in #1001. However, how the hash of block #1000 changes in the first place if it was already calculated?

Once a block has been mined and accepted as part of the longest valid chain (ie, several confirmations deep), it will not ever change (which means the block's contents, and thus hash, will not change).
In order to change it, you would have to also change every block that comes after it, all the way up until the current chain tip. This would take a huge amount of computational power to pull off, you would basically need to 51% attack the network, to re-write the blockchain history. This sort of attack is extremely expensive, and ignores the incentives for mining honestly, you can read more about it here.
Otherwise, if you just changed block #1000, and then attempted to broadcast the changed block to your peers, they will all reject that block, since it is not part of the longest valid chain (assuming they have already heard about the original block #1000, and all of the blocks that came after it).

does this mean that the hash of each block is recalculated regularly?

A block's hash will be calculated in order to determine its validity, but we would never expect the hash to change for a block that has a sufficient number of confirmations on the network.

Hashes don't actually 'change'. When you add a transaction to a block you are creating another block.
It's like an author published a book and then next year printed a new edition with an extra comma in the page 36 and the fans said he released a 'new' book. It doesn't make sense for books but for blockchain every bit counts.

I think you are referring to consensus..if you try to go back and add something to a prior block and transmit it to the network the other nodes will reject it..

This doesn't answer the question

Sure it does, if its rejected you know

how does a block know that its transactions have tampered with in the
  first place?

It is not the block that knows this; it is the nodes which verify that.
To quote the bitcoin whitepaper:

When a node finds a proof-of-work, it broadcasts the block to all
  nodes. Nodes accept the block only if all transactions in it are valid
  and not already spent.

and

[...] network nodes can verify transactions for themselves

So, the nodes verify the transactions upon receiving a new block. This adds to the blocks confirmation counter (you can see it in here, for example), hence making it more trustworthy.
To answer your question directly, yes, the blocks get recalculated regularly.
This is not much of a problem for a node however, since it needs only one hash (the nonce is already known) to verify a block, which is vastly easier than calculating a proof-of-work. Same goes for verifying transactions. Exactly how many transactions are verified is something which I don't know myself, might be a topic for another question.
When a node "notices" that a block is invalid, it discards it and can even

[prompt] user's   software   to   download   the   full   block   and
  alerted transactions to confirm the inconsistency.

You might also find this thread quite informative: Bitcoin transactions validation process

I know I'm late to this thread, but do you have any source on "yes, the blocks get recalculated regularly"? I haven't seen it mentioned on the thread you linked


text:
can we make a blockchain that works like torrent?
Is it possible to make a blockchain system that allows you to download specific blocks from the blockchain instead of the whole blockchain?
In my case for example, I only need 1 giga of the whole chain, so why do I have to download all the blocks? I understand that this is done to make sure that the chain doesn't get tampered with and so on...
But is it possible to make it like a torrent file? where you can download only the files that you need, and no need to download everything with it.

...you can download only the files that you need, and no need to download everything with it.

To do this, you would need to trust that you are receiving the correct files (blocks) from your peers. If they lie to you and serve a false history, how will you know?
A full node downloads the blockchain so that it can independently validate the current state of the network, starting from the genesis block. By working through the network's history, the full node can verify for itself what the current state of the network is, without needing to trust any peers to not lie.
A lightwallet can download just the block headers (80 bytes per block) and use them to help verify that the wallet's transactions are authentic Bitcoin transactions.
But in both cases the node/wallet must have a full history of blocks/headers in order to not be trivially taken advantage of. So I think that an application which only downloads parts of the blockchain history is likely of little use, due to the potential for abuse of trust.

I'm aware that a node might lie, and also aware of the light node concept. But, just like downloading a torrent file, you download it from different random users, therefor, if one node tried to give you a fake block, other nodes will also have to give you the exact fake block. which a very unlikely situation to happen, right?

“Unlikely to happen” generally isn’t the sort of security guarantee I’d want for my money. Why open yourself up to targeted attacks?

Really? because this is the model that blockchain uses as a security mechanism. An example of that is 51% attack, although it's a possibility, but it's unlikely to happen.

A 51% attack has a huge monetary cost, whereas an eclipse attack does not. So these two attacks are not analogous in this way; a 51% attack is EXTREMELY more unlikely.


text:
Will Bitcoin mining stop?
According to this site there are 3,260,162.5 bitcoins left to be mined. Do you know if eventually Bitcoin mining will stop after that? If yes which other cryptocurrency can be mined for ever?
Thank you

The discontinuation of newly mined bitcoins does not mean that there will be no block rewards. Block rewards come from confirmed transaction fees also.


text:
spend founds from p2wsh address,non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)
i want spent coin from p2wsh address on btc testnet3 network, i use bitcoinj 0.15.2 build transaction and sign it, use 2/3 multiSig
when i send raw transaction by bitcoin core 0.17.0 command line by use ./bitcoin-cli sendrawtransaction, i get error
error code: -26
error message:non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)

For now, I don't known why my signed tx broadcast fali?
please help me,Thanks in advance.
relevant information
private_key1:cUkNoCzNXMXzN4JhYYbgiWAaKQEwfgUAzW2kogRNhUqGaiZ2AdUh
private_key2:cUpdkS6ekPkQj1RJWtjbLbYyDwszb3nEBbRkeRf9QHVkBBijEdgv
private_key3:cU4tWJk3BGymoJgbGbxNA6NJapTwrbfWWaPsz1bCZBzkoeszb4ML

p2wsh address:tb1qrgwja0j7447fz66gufzuj4awed63xm5xpgs57qwpmm0ujc0x7vusdrjmw6

witness script str:2 PUSHDATA(33)[037a5929bacc6251ace6fb688c7de760b047f03ef1d23f86bbbf61c152c16a4409] PUSHDATA(33)[02764c145abc62bf1c3786136c7020b4cef227102f458aa607afc6afda7b578ce6] PUSHDATA(33)[02f06485529af46c93b4bd6ab68f44dc58241176a989cca77fe052644a7602d048] 3 CHECKMULTISIG

witness script encode str:5221037a5929bacc6251ace6fb688c7de760b047f03ef1d23f86bbbf61c152c16a44092102764c145abc62bf1c3786136c7020b4cef227102f458aa607afc6afda7b578ce62102f06485529af46c93b4bd6ab68f44dc58241176a989cca77fe052644a7602d04853ae

witness hash:0 PUSHDATA(32)[1a1d2ebe5ead7c916b48e245c957aecb75136e860a214f01c1dedfc961e6f339]

witness hash encode str:00201a1d2ebe5ead7c916b48e245c957aecb75136e860a214f01c1dedfc961e6f339

signed transaction
01000000000101282f723b362a588f35fee66719c8d739779942b3401995e8e7b3b1f062188c390000000000ffffffff01c8af0000000000002200201a1d2ebe5ead7c916b48e245c957aecb75136e860a214f01c1dedfc961e6f3390400483045022100d6373e87fcebb273c08496e042856acf8068c8685ab3f387151caffb957a828802206ee1488853578b58bdeaba3d47470e2bf58d5a3592b610e505fb31c6cc0f1e780147304402202e9b5c156fef699d9d1c60a22be863a4eb08f01fe86592ade3847d7e7ff9d6b9022077557ce221915b3e2b7c995ba994737f7214a68a0accf6ebb4a259224bc778d601695221037a5929bacc6251ace6fb688c7de760b047f03ef1d23f86bbbf61c152c16a44092102764c145abc62bf1c3786136c7020b4cef227102f458aa607afc6afda7b578ce62102f06485529af46c93b4bd6ab68f44dc58241176a989cca77fe052644a7602d04853ae00000000

the decode raw transaction
{
"txid": "45bb61b82eb70f8d1d52edde904b3402d677910ffdcb987264ec58b44eac525a",
"hash": "4b818b6745f45fdd79f0f54222206ee35de27eb103b8974046e6f6b8a323d2b4",
"version": 1,
"size": 349,
"vsize": 158,
"weight": 631,
"locktime": 0,
"vin": [
{
"txid": "398c1862f0b1b3e7e8951940b342997739d7c81967e6fe358f582a363b722f28",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"",
"3045022100d6373e87fcebb273c08496e042856acf8068c8685ab3f387151caffb957a828802206ee1488853578b58bdeaba3d47470e2bf58d5a3592b610e505fb31c6cc0f1e7801",
"304402202e9b5c156fef699d9d1c60a22be863a4eb08f01fe86592ade3847d7e7ff9d6b9022077557ce221915b3e2b7c995ba994737f7214a68a0accf6ebb4a259224bc778d601",
"5221037a5929bacc6251ace6fb688c7de760b047f03ef1d23f86bbbf61c152c16a44092102764c145abc62bf1c3786136c7020b4cef227102f458aa607afc6afda7b578ce62102f06485529af46c93b4bd6ab68f44dc58241176a989cca77fe052644a7602d04853ae"
],
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.00045000,
"n": 0,
"scriptPubKey": {
"asm": "0 1a1d2ebe5ead7c916b48e245c957aecb75136e860a214f01c1dedfc961e6f339",
"hex": "00201a1d2ebe5ead7c916b48e245c957aecb75136e860a214f01c1dedfc961e6f339",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"tb1qrgwja0j7447fz66gufzuj4awed63xm5xpgs57qwpmm0ujc0x7vusdrjmw6"
]
}
}
]
}

the sign code
public void sign() {
NetworkParameters params = TestNet3Params.get();
Coin fee = Coin.SATOSHI.times(5000L);
Coin fundAmount = Coin.SATOSHI.times(50000L);

List<ECKey> ecKeyList = Arrays.asList(
    DumpedPrivateKey.fromBase58(params, "cUkNoCzNXMXzN4JhYYbgiWAaKQEwfgUAzW2kogRNhUqGaiZ2AdUh").getKey(),
    DumpedPrivateKey.fromBase58(params, "cUpdkS6ekPkQj1RJWtjbLbYyDwszb3nEBbRkeRf9QHVkBBijEdgv").getKey(),
    DumpedPrivateKey.fromBase58(params, "cU4tWJk3BGymoJgbGbxNA6NJapTwrbfWWaPsz1bCZBzkoeszb4ML").getKey()
);

List<String> inTxidList = Arrays.asList(
    "398c1862f0b1b3e7e8951940b342997739d7c81967e6fe358f582a363b722f28"
);

List<Integer> inTxIndexList = Arrays.asList(
    0
);

String redeemScriptStr = "5221037a5929bacc6251ace6fb688c7de760b047f03ef1d23f86bbbf61c152c16a44092102764c145abc62bf1c3786136c7020b4cef227102f458aa607afc6afda7b578ce62102f06485529af46c93b4bd6ab68f44dc58241176a989cca77fe052644a7602d04853ae";

Script script = new Script(Utils.HEX.decode(redeemScriptStr));
Script p2wshScript = ScriptBuilder.createP2WSHOutputScript(script);

Transaction tx = new Transaction(params);
for (int i = 0; i < inTxidList.size(); i++) {
    TransactionWitness witness = new TransactionWitness(3);

    tx.addInput(Sha256Hash.wrap(inTxidList.get(i)), inTxIndexList.get(i), new Script(new byte[0]));

    Sha256Hash sigHash = tx.hashForWitnessSignature(i, p2wshScript, fundAmount, Transaction.SigHash.ALL, false);

    for (int j = 1; j < ecKeyList.size(); j++) {
        ECKey.ECDSASignature sig = ecKeyList.get(j).sign(sigHash);
        TransactionSignature txSig = new TransactionSignature(sig, Transaction.SigHash.ALL, false);

        witness.setPush(j, txSig.encodeToBitcoin());
    }
    witness.setPush(ecKeyList.size(), script.getProgram());

    tx.getInput(i).setWitness(witness);
}

Address sendTo = Address.fromString(params, "tb1qrgwja0j7447fz66gufzuj4awed63xm5xpgs57qwpmm0ujc0x7vusdrjmw6");
Coin outAmount = fundAmount.minus(fee);
Script outPkScript = ScriptBuilder.createOutputScript(sendTo);
tx.addOutput(outAmount, outPkScript);

log.info("signed tx:{}",Utils.HEX.encode(tx.bitcoinSerialize()));
}


text:
+Accidently sent my BCH from my ledger nano S to a BTC address in Coinbase how can i get it back?
+Accidently sent my BCH from my ledger nano S to a BTC address in Coinbase and it went thru but never got to my Coinbase account, how can i get it back?

You would need to contact Coinbase to retrieve the coins back, because Coinbase hold the private keys on behalf of the users.


text:
How do I restore use of my wallet.dat file, last used in 2013?
I found a wallet.dat file in my backup folder, which I recall last using in 2013. I'm curious to see what the BTC contents are, which I recall being a really small fraction of BTC.
In any case, is there anything preventing me from just installing Bitcoin Core and replacing the default wallet.dat to recover my backed-up wallet? What is the recommended way to recover such an old wallet.dat file?

In any case, is there anything preventing me from just installing Bitcoin Core and replacing the default wallet.dat to recover my backed-up wallet? What is the recommended way to recover such an old wallet.dat file?

You can do just that. In fact, that's exactly the way to restore a backup.


text:
Please guide what should i do
Am new in bitcoin world and didn't started it yet...
A man from USA saying to create blockchain wallet n top up then share ur email n wallet address not login not password to connect my wallet to a s9 machine for mining i 'll keep my money with me in my wallet he will create a node address to connect s9 ...I want know is it safe should I do it and if it's scam what is the real way to do it another question is mining profitable ?

connect my wallet to a s9 machine for mining ... is it safe

No. You will lose all your money. He will use your fear of losing your money to trick you into giving him more money (e.g. private-key release fees) and more money and more money until you have nothing left to give. Then he will tell you to borrow more money from your family, from the bank, from loan sharks ...

if it's scam

It is a scam

what is the real way to do it

Spend a long time (at least an hour a day for a couple of weeks) researching Bitcoin and mining. Don't proceed until you understand private-keys, public-keys, seed-phrases, recovery, different types of wallet, watch-only wallets, principles of mining and so on.
Read the answers to all these questions to innoculate yourself against scammers
Then buy a hardware wallet or download a good stand-alone wallet.
Buy a small amount of Bitcoin from a well-known exchange
Practice recovery of your wallet as if your hardware-wallet or computer is stolen. Don't proceed until you have proven you can recover full control of your bitcoin only using the recovery phrase without touching your existing wallet hardware or computer or  mobile-phone.
Write down instructions for your family to recover your money if anything happens to you. Make them follow your written instructions without any help from you and see if they really can. If necessary create a new wallet with new keys and transfer all your Bitcoin to the new wallet. Update your saved recovery phrase etc.
Never share your wallet-password, recovery phrase or private-key with anyone (unless they are someone you'd be happy for them to walk away with everything you own tomorrow). Never let anyone else log in or remotely access your computer or your wallet to help you, even if they seem to be the most honest person in the world, especially if they suggest you can secure your wallet afterwards by changing a password.
After becoming comfortable buying and using bitcoin for several months, re-think about mining, if you have a few thousand dollars you can afford to lose totally, you are probably ready to consider whether the process is for you.

is mining profitable ?

Not unless you already have several thousand dollars to invest in ASIC mining equipment and a good source of cheap electricity in a building with very good air-conditioning and where noise does not matter. This isn't suitable for people new to Bitcoin. You must be prepared to lose that money without hardship.

A man from USA saying to create blockchain wallet n top up then share ur email n wallet address not login not password to connect my wallet to a s9 machine for mining i 'll keep my money with me in my wallet he will create a node address to connect s9

To be clear: this is absolute nonsense, what he is describing has NOTHING to do with how mining actually works. He is just trying to scam you by gaining access to your wallet.
I suggest taking a look at this question: I am new to Bitcoin, how can I get started?


text:
Creating multiple clients inside a single lnd node
I am trying to create hot wallets using the lightning network but I don't want to create a new node for each user. Is there a way to have multiple users be able to use a single lnd node?

Yes absolutely. Many users can use / share one lightning node. You might have to create some accounting sodtware if you want every user to have their own funds. This is a classical custodial wallet solution. I am not aware of open source solutions but I build one on top of the clightning api. This solution should work in a. Very similar way for lnd.
Start by looking at the grpc api and macaroons so that you can create such a software on top of your lightning node


text:
BlockChain.Com Wallet - Why transaction FEE Is very HIGH
I have two wallets in BlockChain.Com web site.
When i want to transfer bitcoin from one of them situation is like this :

Money for transfer : $1000
Transaction Fee = Priority = $26

In another wallet situation is like this :

Money for transfer : $1000
Transaction Fee = Priority = $210

I am so confused!!!!!!!!!!!!!
Why does BlockChain.Com act like this?
How can i reduce second wallet's fee?

Did you receive a lot of separate payments in the second wallet? The transaction costs could differ because the second wallet requires more inputs for a transaction paying $1000. Other than that, you'd have to provide us more information, there isn't much to go on here.

Yes, Wallet number 2 has some transactions (each one 30$) every day.
How can i reduce that strange fee?
What information do you need about wallet number 2?

If you are using default suggested fee and the total fee of your transaction (TX) is very high, then the reason is per my understanding either that
A) the Bitcoin has currently too many transactions to confirm (so the fees are high). You may check it at https://bitcoinfees.net
B) your TX size (in bytes) is high thanks to for example high number of unspent transaction outputs (UTXO) that are going to be spend in your new TX. One can customize and decrease Satoshi/byte fee of the TX and wait longer time for the confirmation. If you can afford sending lower amount and send the rest later, then other option is to minimize number of mentioned UTXO that will be used in your TX (lowering total TX byte size which will decrease the fee that depends on it). In Electrum wallet app, it is Coins tab and Coin control option, selecting low number of bigger UTXO). Yet if you want to sweep all funds, you may need to spend all UTXO anyway soon or later - but maybe schedule it for the time when network will be utilized lower: https://jochen-hoenicke.de/queue/#BTC%20(default%20mempool),1y,count - it may help to estimate how often there are periods of low fees. Btw. some BTC servers has limit of minimum accepted sat/byte, though you may change used server in many wallet apps.


text:
Blockchain.com wallet | 1178$ transaction with low fee = 10 satoshi | How fix unconfirmed issue
I have a blockchain.com wallet.
yesterday i did a big mistake :
I customized transaction fee and set it to 10 satoshi.
Here is the tx link of that transaction.
Now after 1 day it has n't confirm.

Did i lose my bitcoin?
How many days should i wait for confirm?
Does it back to my wallet if it fail for confirmation?
is there a way to change it's fee?


text:
Online Store in Cheyenne, Wyoming Accepting Bitcoin for Payment
Can an online store located in Cheyenne, Wyoming accept bitcoin as payment for goods from customers in either Wyoming, or other states or countries, without collecting every customers Social Security Number, or other KYC and AML type identifying information, without the possibility of being prosecuted for money laundering by either Wyoming or the US Federal Government?

I'm voting to close this question as off-topic because it can only be answered by a lawyer familiar with that jurisdiction

For absolute clarity, you should consult the appropriate lawyer / tax professional in your jurisdiction.
However, in general, accepting bitcoin for payment should be no different than accepting any other form of payment. Think of it like accepting a foreign currency, and apply the appropriate accounting practices. There are even services out there which allow you to accept payment from customers in bitcoin, but will then pay you out in your local currency.
KYC/AML type stuff usually applies to businesses that are money transmitters, trading one form of currency for another. But as I mentioned above, if you are truly worried, then you shouldn't take the advice of a stranger on the internet, you should hire the appropriate professional to advise you on the matter.


text:
Armory wallet and bitcoin - newbie questions
I made a transaction into my armory wallet but I didnt downloaded blockchain before. What happened to my bitcoin?
Can I access my bitcoins when ill be able to get the wallet online?


text:
can cryptocurrencies be energy efficient?
Is there an intrinsic reason why cryptocurrencies currently take a lot of energy to keep working? Is there a way to make a cryptocurrency still widely used but make it energy efficient?

Related: https://bitcoin.stackexchange.com/q/95356/5406, https://bitcoin.stackexchange.com/q/331/5406

As the answer for this question, we have the Proof of Stake approach, firstly implemented by Peercoin (PPC). I think other coins as Ethereum have as well a proof of stake mining/minting approach
links: https://peercoin.net/minting and https://github.com/peercoin/peercoin/wiki/FAQ

PoS is not an equivalent replacement of PoW. In PPC, the project founder essentially decided the best chain, ETH has been promising to switch to PoS for five years, but is always a year away from it.

As another post says, we currently rely on PoW. This needs energy. Maybe other consensus algorithms (like PoW), also need (more) energy. BUT: There are also consensus algorithms, we need less energy. Its that simple. The only thing here is: coins e.g. BTC need to switch to another one which needs less energy.

Hi Erhard, I'm not sure I follow your answer. The start of your third sentence makes me think that you meant to mention a different concept, but both the first and third sentence mention PoW.—The main hurdle to switching to a less energy intensive consensus algorithm is to find one which 1) is compatible to the network's incentive system, 2) has similarly attractive security properties as PoW, 3) uses less energy.

It would seem so.
Ethereum has partly switched from Proof of Work to Proof of Stake: https://en.wikipedia.org/wiki/Proof_of_stake
... and we may well look back on energy expenditure of Proof of Work as almost all total waste:
https://stuart-reynolds.medium.com/is-bitcoins-energy-consumption-a-problem-for-the-world-ff213cc2136a

Hi user48956, the cited wikipedia article is labeled as unreliable, and that blog post has multiple factual errors. Unfortunately, PoS is "non-trivial", which is a polite expression for "so far unachievable to make work without trusted third party even allowing pretty lousy trade-offs". You may want to read e.g. https://download.wpsoftware.net/bitcoin/pos.pdf to learn about its limitations.

authors: Игорь Мальцев


text:
Querying UTXOs with random key pairs
As the number of transactions in the bitcoin network grows, the number of addresses with bitcoin will also grow. Is it possible for someone to “scavenge” for bitcoin by generating random key pairs and checking if the derived bitcoin address has any coins ? Is this likely to be profitable at any time in the future?
Even if the profitability of this attack is low, it could impact confidence in the bitcoin network, if a few bitcoin were stolen in this manner.

Is it possible for someone to “scavenge” for bitcoin by generating random key pairs and checking if the derived bitcoin address has any coins ?

Yes.

Is this likely to be profitable at any time in the future?

No.
The number of possible addresses is extremely massive, much much too large for the human brain to comprehend.
For starters, there are 2^160 possible P2PKH addresses. Then there are 2^160 possible P2SH addresses. There are also 2^160 possible P2WPKH addresses and 2^256 P2WSH addresses. This means that the current total address space is 3(2^160)+2^256. The probability that you would randomly choose generate an address that has Bitcoin associated with it is so small that it is basically zero.
If we were to assume that 100 billion addresses have Bitcoin associated with them or will be in the future (that's an extremely generous estimate), then the probability that you would be able to find one of those is 8.636 × 10^-67. This probability is so small and so unlikely that it will never be profitable or have any probability of an address collision ever occurring.

If bitcoin were to equal visas processing rate ( someday) ,it would consume 100 billion addresses in 579 days (100e9/(2000360024) . Assume 1 trillion addresses and 2^96 possible private keys, the number of trials required to encounter any one used address is 2^96/1e12 =7.92e16 trials . The current bitcoin hashrate is 7.3e21 H/s . If that hashrate were diverted to scavenging bitcoin, it would find bitcoin in 1.08e-5 s for 1 trillion addresses and 1.08e-2 s for 1 billion addresses. Do we need to trust that the network will follow the honour code for miners?

Your math is wrong. There are 2^256 possible private keys, not 2^96, where did you get that number? Because of the hash functions used in Bitcoin, the 2^256 is reduced to 2^160 possible addresses. With 2^160 possible P2PKH addresses, it would require 1.46e36 trials, assuming that 1 trillion had Bitcoin. Using your hashrate number, it would actually take 2e14 seconds to find a collision. Lastly, hashrate is not directly convertible to generating addresses. Mining ASICs can only do one thing, sha256d. They cannot be converted to do anything else like searching addresses.

The number of BIP39 addresses is close to 2^132. The current utxo set size is close to 60 mill. The number of trials required to encounter any one used address is 2^132/60e6 =9e31 trials. With current hashrate it would find bitcoin in 12.4 trillion seconds ~ 400 years to find non-empty address if the hashrate could be diverted to lookup the utxo set.


text:
"private" agreement between two c-lightning nodes on channel closure fee
When i was at LNConf, one of the devs of c-lightning (IIRC) told me that there is a custom, manual way to agree between two nodes on channel closing fees.
Can anyone elaborate how this is possible? I am operator of two cln nodes, i would like to close channel between these nodes with minimum possible fee, because i am not in hurry.
Are there some side-effects of doing so?

Just use lightning-cli close id the implementation will first try to do a mutual close. Both lightning nodes will use the fee estimator from Bitcoind to suggest fees. If they don't agree there is a communication protocol defined in the BOLTs that they will eventually find a local agreement between themselves. This protocol is described under the section closing negotiation in BOLT 02 c.f.: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed
Obviously both nodes need to be online and peered before you call the close command otherwise the node will do an expensive force close. Also it makes sense to wait until fees in the mempool are low if you can do that.

Hi, Rene! Thank you for fast answer! But this is not the option i am looking for. I want to avoid the use of bitcoind fee estimator and force let's say 1sat/b fee. As mentioned dev told me there is no way to do so with default calls (to be precise he said "this is not implemented in default setup"). I am looking for that custom configuration of node so i can force specific fee as i can do when lightning-cli fundchannel id amount fee

the point of doing so is exactly what you described, but in reverse order. I dont want to wait until mempool clears to perform tx. i just want to broadcast it and lay back, so it will be included, when mempool clears. so i dont need to monitor state of mempool

just some additional info: when you open a channel, your node is the only side involved in opening tx, so you can choose the fee yourself. When closing channel, there's multisig tx, that is the reason why you cannot set custom fee (because other part may not agree on low fee). But in case both nodes are co-operative, this should be possible.

Then I guess you should open a feature request in the clightning github and potentially also on the lightning-rfc. It should be possible to just agree on a low fee but I guess it also needs an amendment to the fee negotiation. Technically the fee is paid by the funder but unfortunately that won't help

https://github.com/ElementsProject/lightning/issues/3270
https://github.com/lightningnetwork/lightning-rfc/issues/702


text:
Question regarding MultiSig outputs
Just saw good question on Telegram:
So I working on an algorithm that would download and process bitcoin blocks, specifically the transactions in them. I want to take every output address of every transaction in a block and query my database if any users own this address as their deposit address. Initially I thought an output can only have one address and so I can just credit the person who owns it with the amount of that output. But now I found out that an output can actually have multiple addresses to it and thats called multisig. I don’t really understand the concept of this. So what if a person uses his deposit address that I’ve given them as first address and they also use another address of their own as second address in a single output? Can they use that output with their address to waste it so then so I lose the money they deposited?

I would like to contact you. My email address is in my profile, you can reach me there. Thank you for your time.

Addresses are just a shorthand to encode a locking script. When a locking script requires multiple signatures to be unlocked, it's still a single address. So, when you're writing an indexer, you can likely get away with simply not distinguishing singlesig and multisig addresses in the first iteration.

Take a look at this transaction
055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9 (Bitcoin mainnet)
(https://www.blockchain.com/btc/tx/055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9)
However, the web explorers fail to present these properly, so here's what you get if you decode it with your own node:
{
    "txid": "055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9",
    "version": 1,
    "locktime": 0,
    "vin": [
        {
            "txid": "b187426f2fdd5a7ac2f49d822f68e07f48486ee53a8a45de2494f12acb37a0d8",
            "vout": 3,
            "scriptSig": {
                "asm": "3046022100d78c31a20fa11533475be893b229eb4d252e600dcc2a0735d360c541b6aec813022100e3eaa72c915ef47d94ccbd18c2ba6d9ae5b98be6e9fbf968d4bbbb003e06d68701 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc"
            },
            "sequence": 4294967295,
            "n": 0,
            "addr": "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
            "valueSat": 1114144,
            "value": 0.01114144,
            "doubleSpentTxID": null
        }
    ],
    "vout": [
        {
            "value": "0.00010860",
            "n": 0,
            "scriptPubKey": {
                "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 20434e545250525459000000140001a9e0e85838b5000000174876e800010053b6 2 OP_CHECKMULTISIG",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
                    "1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E"
                ]
            }
        },
        {
            "value": "0.00010860",
            "n": 1,
            "scriptPubKey": {
                "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 20a3c3000000000000000000000000000000000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
                    "1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E"
                ]
            }
        },
        {
            "value": "0.00010860",
            "n": 2,
            "scriptPubKey": {
                "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 100000000000000000000000000000000000000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
                    "1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E"
                ]
            }
        },
        {
            "value": "0.01061564",
            "n": 3,
            "scriptPubKey": {
                "asm": "OP_DUP OP_HASH160 a2f2d251cc06ec1e789800127e3fa6ed9e515651 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs": 1,
                "type": "pubkeyhash",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao"
                ]
            }
        }
    ],
    "blockhash": "0000000000000000491fdff68a1c99de7798278a791e461b8d5bebdd9df9de46",
    "confirmations": 1,
    "time": 1401911255,
    "blocktime": 1401911255,
    "valueOut": 0.01094144,
    "size": 433,
    "valueIn": 0.01114144,
    "fees": 0.0002
}

I'm actually the person who asked this question and after lots of research, I'm pretty sure this kind of transaction can not occur in a scenario when you give your users unique bitcoin addresses for deposits. I think this will only happen when the addresses were intentionally made multisig, however, I'm not sure how and why.
I've done a small experiment where I've made a testnet multisig address and sent some funds to it. I were expecting it to act exactly like in the transaction above, however, it didn't. I think the reason for it is because there has to be a different type of script and I want to know what is it and how to work with it.
Here's what I did:
First I've created 2 new addresses.
index@LAPTOP-QHUBB7MI:~$ btc getnewaddress
2MsTYs9Ymsh332Ctou3dyxVe5PoTW4fLp2o
index@LAPTOP-QHUBB7MI:~$ btc getnewaddress
2N2yDtoRTChgrD675GJ12JE3wXzk3hMzgoP

Then I got their public keys using the getaddressinfo rpc.
index@LAPTOP-QHUBB7MI:~$ btc getaddressinfo 2MsTYs9Ymsh332Ctou3dyxVe5PoTW4fLp2o
{
  "address": "2MsTYs9Ymsh332Ctou3dyxVe5PoTW4fLp2o",
  "scriptPubKey": "a9140254bfce5627cc6267eb2aaa75dce00f03bc13dc87",
  "ismine": true,
  "solvable": true,
  ...
  "pubkey": "02d01d8e315567fb3571f31d86eb53d21729c6072751276d0c2617d787d48b2af8",
  ...

}
index@LAPTOP-QHUBB7MI:~$ btc getaddressinfo 2N2yDtoRTChgrD675GJ12JE3wXzk3hMzgoP
{
  "address": "2N2yDtoRTChgrD675GJ12JE3wXzk3hMzgoP",
  "scriptPubKey": "a9146aaa8606a93804de00e4e91c683dbfd5e1caa7d887",
  "ismine": true,
  "solvable": true,
  ...
  "pubkey": "0236240c39790e770bc0c378bebb1a86d2ac24f835b6e81e69c623262b1f0e0326",
  ...
}

Then I created the multisig address.
index@LAPTOP-QHUBB7MI:~$ btc createmultisig 1 '["0236240c39790e770bc0c378bebb1a86d2ac24f835b6e81e69c623262b1f0e0326", "02d01d8e315567fb3571f31d86eb53d21729c6072751276d0c2617d787d48b2af8"]'
{
  "address": "2Mu6J8iXwzCgWxJzVNkzfQ8yZwJ92YWW6es",
  "redeemScript": "51210236240c39790e770bc0c378bebb1a86d2ac24f835b6e81e69c623262b1f0e03262102d01d8e315567fb3571f31d86eb53d21729c6072751276d0c2617d787d48b2af852ae"
}

Finally, I sent some bitcoin to the address.
index@LAPTOP-QHUBB7MI:~$ btc sendtoaddress 2Mu6J8iXwzCgWxJzVNkzfQ8yZwJ92YWW6es 0.00999744
1373fd7a2da3199e0f4ead0a5456266b52263356a86b726882dbc03da1625ed1

I decoded that transaction (Testnet) and got this
{
  "txid": "1373fd7a2da3199e0f4ead0a5456266b52263356a86b726882dbc03da1625ed1",
  "hash": "290a0ec0c306a4485a7099c1f7813d9f9a741a9b4fcc68c5decc68de5ddb1b14",
  "version": 2,
  "size": 338,
  "vsize": 173,
  "weight": 692,
  "locktime": 1572217,
  "vin": [
    {
      "txid": "7e57de9ce9797e8c5face7c3ed7ce89eb3107b05e00c129f336cebc1b1113dcb",
      "vout": 1,
      "scriptSig": {
        "asm": "00205a010c52d33bfac812f62f2cb7f917a3b84f67c66c1ac9ac1701c7caa4e5da7c",
        "hex": "2200205a010c52d33bfac812f62f2cb7f917a3b84f67c66c1ac9ac1701c7caa4e5da7c"
      },
      "txinwitness": [
        "",
        "304402206b7f9fcdf972a2aaa6a734e921d1f76b3da3a0f7a98e2bf3657241ed0cc4433a022040b1f0f31b6231ff73465986c3379ce15cbf2b33e28b09460aac8812d8e9826801",
        "304402200ffeeb246535a312f33c05652f9ef5d696fd26883659e6429731e5f0416be9fc022067a5852e99f96c5def0f7288b9a7ba567e3df258fd79071a60694580ac3de1fc01",
        "522103a8f863c198bfa005273ae53d9db239e3be2cabcd5cbf34f52318795166f5cdff2102cff91271435f4f121aa90f3babc5551090f862575e5eb12429acb8e6daf4d8cd52ae"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.00999744,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 143ff7e3677973ecd914d8d134efde5adff4a96b OP_EQUAL",
        "hex": "a914143ff7e3677973ecd914d8d134efde5adff4a96b87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2Mu6J8iXwzCgWxJzVNkzfQ8yZwJ92YWW6es"
        ]
      }
    }
  ]
}

Which is a totally normal-looking one.
Even though I'm almost certain this won't happen in the scenario I described, I want I final confirmation from someone who understands how these transaction work and explain.


text:
What will happen to my bitcoin if my Ledger or any bitcoin hardware wallet will damaged?
I want to buy a hardware wallet for storing bitcoin because it is safe than an online wallet but at the same time, I am thinking that what will happen to my stored bitcoin if my hardware wallet damaged. Can I recover my bitcoin?

Yes you can recover if you have a backup.

How plz tell me

Every hardware wallet have own backup guides.

I am answering this based on Ledger Nano S:
Source
Considering a scenario where you have configured your hardware wallet and have been using it for some time. And unfortunately, it got burnt or drowned or destroyed or lost.
You will still have your backup phrase which you made while setting up your Ledger Nano S. Your backup phrase is a 24 word list, which you can use to restore your previous account.
So, if you have another Ledger Nano S or any other wallet which support BIP39 deterministic keys, you can simply input these words and restore your wallet.
Another helpful source to restore your Ledger wallet is here
Hope this assures you to buy a hardware wallet.

Assuming the Ledger Nano S implements BIP 39, your hardware wallet probably showed you a 12/24/36 word Mnemonic code. If you wrote these mnemonic code words down, then you can restore your corrupted hardware wallet with just these words. Also, you can use these words to restore any wallet that supports BIP 39. This includes many mobile phone wallets and other hardware wallets. If you did not write these code words down, then you are probably out of luck for recovering your wallet keys.


text:
Is there are written code for mapping public address to an user?
I read about 2 theoretical ways we can do it
1) When a single transaction has multiple input addresses, we can assume that those addresses belong to the same wallet, thus to the same user. We should bear in mind that users do not share private keys. In fact many users may use web wallets which have pools, so those services will be treated as a single user.
2) Secondly, you can exploit the change mechanism in transactions. The entire value of unspent output should be sent back to the user as change. Bitcoin, in order to improve anonymity, produces a shadow address which collects back the change that results from any transaction. So when a single transaction has 2 outputs, you have to predict which one of the output addresses is actually belonging to the same user that initiated the transaction. If one of those two outputs has never appeared before in the blockchain, while the other has, then we can assume that the one that never appeared before is the shadow address.
But is there any public code available which is able to achieve this in an optimum and optimise algorithm, I wrote an algorithm but its O(n^2), and the dataset currently is just too huge for such algo to work.

You can write both of those queries in a way that takes nearly linear time and space.

Make a hash table that maps addresses to "neighbor addresses." A neighbor address is an address that was used as an input alongside another address. To find the addresses a user owns, query the hash table for the address. Add all of the addresses that are neighbors of that address. Recurse for all of the neighbors.
This can be created in O(n*k) time and space. (n = number of transactions, k = average number of inputs from distinct addresses per transaction)

Make a hash table that maps addresses to the block they were first seen in. For each address of each transaction, you check the hash table to see if it has been seen yet. If not, you create an entry for it, pointing to the current block and transaction. Then, while querying, you can quickly tell if a transaction contains addresses that have been seen for the first time.
This can be created in O(n) time and space. (n = number of inputs)

(It doesn't need to be a hash table specifically. Other approaches would work too.)


text:
Ripple ledger hash generation efficiency. How hard is it to generate the ledger hash?
According to Ripple, at every round, validating nodes generate the ledger hash, which contains the account_hash, which is the hash of the state tree, which contains all the ledger objects, including settings and balances.
This article says that it is a very disk-intensive process, because the whole tree for the account state consists of hundreds of thousands of inner nodes which change when any of their descendants change. The amount of change depends on the depth of the affected leaf nodes.
Being so, I wonder how hard it is and much harder it will get, as the amount of nodes increase over time.
How Ripples solves this problem now and how it plans to deal with it as it grows?