text:
Solo mining on created altcoin: not able to create block
I have forked the code of an altcoin to play with the param and understand the process Source here.
Now I want to solo mine to create the blocks. The miner is on my PC and the server on a Ubuntu 16.04 VM.
 RPC connection seems to work:
http://MyUser:MyPassword@192.168.1.13:25553/    return
{"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}

but I'm not able to generate block (with NSG).
Mycoind is launched with :
rpcallowip=*
rpcuser=MyUser
rpcpassword=MyPassword
rpcport=25553
port=25552
server=1
listen=1
gen=1
daemon=1
externalip=192.168.1.13

But nsgminer does not generate me the blocks, I do something wrong ?
From the PC:
nsgminer -o http://192.168.1.13:25553 -u MyUser -p MyPassword

Give me the return:
 [12:34:12] Probing for an alive pool
 [12:34:12] blktmpl error: Unrecognized block version, and not allowed to reduce or force it
 [12:34:12] The network difficulty has been set to 0
 [12:34:12] No suitable long-poll found for http://192.168.1.13:25553
 [12:34:16] Found block for pool 0!
 [12:34:16] Found block for pool 0!
 [12:34:16] Pool 0 communication failure, caching submissions
 [12:34:18] Found block for pool 0!
 [12:36:13] Pool 0 share became stale during submission failure, will retry as user requested
 [12:36:13] Pool 0 share became stale during submission failure, will retry as user requested
 [12:41:10] Started at [2018-03-21 12:34:12]
 [12:41:10] Pool: http://192.168.1.13:25553
 [12:41:10] Run time: 0 hrs 6 mins 58 secs
 [12:41:10] Average hash rate: 0.0069 MH/s
 [12:41:10] Solved blocks: 44
 [12:41:10] Best share difficulty: 0
 [12:41:10] Queued work requests: 13
 [12:41:10] Share submissions: 0
 [12:41:10] Accepted shares: 0
 [12:41:10] Rejected shares: 0
 [12:41:10] Accepted diff1 shares: 0
 [12:41:10] Rejected diff1 shares: 0
 [12:41:10] Hardware errors: 0
 [12:41:10] Efficiency (accepted shares * difficulty / 2 KB): 0.00
 [12:41:10] Utility (accepted shares / min): 0.00/min
 [12:41:10] Work Utility (diff1 shares accepted / min): 0.00/min

 [12:41:10] Discarded work due to new blocks: 3
 [12:41:10] Stale submissions discarded due to new blocks: 0
 [12:41:10] Unable to get work from server occasions: 0
 [12:41:10] Work items generated locally: 0
 [12:41:10] Submitting work remotely delay occasions: 1
 [12:41:10] New blocks detected on network: 1

Thanks for your help and time.

You should run instance of node in atlest two diffrent machine and both of the need to get connected via blockchain.The reason behind need of atlest two diffrent machine is consensus protocol.
To add another node,

Run same instance of code on second machine add following line in conf
  file:

addnode=*ipOfSecondMachine*

To check if node is conneceted

getpeerinfo

is what you need
Then go with normal  steps of minning,
ps: if you are trying to mine srypt based coins like ltc then i recommend sgminer


text:
Why is the intersection of two quorums must be greater than N/3 when proving streamlet?
Why is the intersection of two quorums must be greater than N/3 when proving Streamlet, a blockchain consensus protocol [BY Chan, Elaine Shi, 2020]?

In Streamlet, honest node vote for proposed block in every round. When a block gain vote for more than 2N/3 distinct node, it's notarized. In this context, quorum is the set of distinct votes on a notarized block
Following statement confuses me: The quorum size have to be more than 2N/3 to ensure at most one block can be notarized in a round if the malicious node is less than N/3, because the intersection of two quorums must be greater than N/3 and only malicious block will equivocate.
This intersection greater than N/3 seems come out of nowhere or do I miss something? why can't it be smaller? like N/5 or something else?
This statement and picture are from the material of streamlet in principles of blockchains (ECE 598PV) from illinois and also from the lecture (14:47) given by the author.

This is just an application of the inclusion exclusion principle. Otherwise, the total number of nodes will be 2n/3+2n/3-(something <1/3) > n.

source: Stack Exchange

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

sort: votes


text:
Where to look for the lost BTC
My Tx on btc-testnet seems not transact all the BTC, but there's no UTXO back to my address.
How to find the rest of the BTC?
Tx
7e0cc1e5c944355e6d448de19a67421eef2a6b4ca4ed58fcd990ce75f66d07a9
1 Input Consumed
0.001 BTC from
mqrNP3qtb6zrphFAkwi9caY8f8v65VbZXx (output)
1 Output Created
0.000007 BTC to
zJEMNc1JksFTjvvWH2cy97khBgbz5rNYj4 (spent)

Possible duplicate of https://bitcoin.stackexchange.com/q/736/5406

The difference between total of inputs and total of outputs is the transaction fee that can be claimed by the miner.
It looks as though the software that created the transaction omitted the change output.

Related

How are fees specified in a TX?

In another Tx: 3fc1def4614c767bd64f0b202b0842f4701035eb3c6c97185cc54fdbec235c55
I also made the same amount of transaction, but miners charge more. Where can I find the relationship between fee and transaction amount?

There is no relationship between fee and transaction amount. You offer the fee you think will get the transaction included in whatever time suits you.

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


text:
How can I recover my private key?
I have a part of an UNCOMPRESSED private key. Starts at 5, missing 10 characters at the end. I saw the code on this forum and used it in python. But when working with my key, it gives out 2 incorrect options. I think the thing is that the code is written for a compressed key, since I checked on a compressed private key and it worked. What can I do?

import base58, sys

partial = sys.argv[1]

if len(partial) != 45:
    print("partial key should be 45 characters")
    sys.exit(1)

results = {}
for c in '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz':
    wif = base58.b58encode_check(base58.b58decode(partial + c*7)[:33] + b'\x01').decode('ascii')
    if wif[:45] == partial: results[wif] = True

for k in results.keys(): print(k)

What do you mean it gives 2 incorrect options? It will probably give you lots of incorrect guesses. When you are missing 10 characters from a base58 key the number of possible combinations to check is very large.

when I run this script with my UNCOMPRESSED key, it gives 2 incorrect options. But when I take the COMPRESSED KEY, this script gives 2 options, 1 of which is completely suitable. @m1xolyd1an

What makes the options "incorrect"?

The source-code is from How can I recover the missing end of my private key? - it would have been best to include this link in the question. From the detailed answer there you should be able to make the necessary changes.

If you lost last 10 characters from uncompressed private key. The number of possible combinations to check is around 585, not just 58 keys like that code above. You need another Python libs to convert all possible uncompressed private key to Bitcoin legacy address until it find your 'missing key' address.

More exact:  58^10 / 2^32 -> 26.6 bits.  So computationally that is certainly doable, probably something like an hour of cpu time or so.


text:
A query regarding Bitcoin Header Format
I am new to Bitcoins and still learning thus please bear with me. As I read Bitcoin Block header (on which the Block Hash is computed) is supposed to be:

hash - 32 Bytes
ver  - 4 Bytes
prev_block - 32 Bytes
mrkl_root  - 32 Bytes
time  - 4 Bytes
bits  - 4 Bytes
nonce - 4 Bytes

(source: https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html)
Now when I check one of the latest Blocks the fields are:

Hash   :
00000000000000000009ec0aa4de1488fa1ea7a5196447016b2fe1638df99e62

Version :  545259524

Previous Block : 000000000000000000073a6f31ebaeeaaf09e21331450e424426818699356c54

Merkel Root    : 09f73d4315fcff0f7ef126a321e8ea478a9bab26c6aa6d45c187a0fcb313fab8

Time  :  1629026224

Bits  :  387061771

Nonce :  1150639194

(source: https://blockchain.info/rawblock/695877)
The Version, Time, Bits and Nonce fields don't seem to match in size. What am I interpreting wrong here.
And I am unclear about the Version field. What are the various options. And hypothetically as a miner if one runs a tailor made self coded program what should be its value and how does it matter to a miner who will simply mine a new Block? Is there a default safe value for this field?
It would be helpful if someone can point to a explained for version (something that is easy and comprehensive enough for beginning miners)?

The number 545259524 for version is in base-10 (decimal) format, you need to convert it to base-16 (hexadecimal, ie 20800004) and then reverse the order of bytes (04008020) to compose the header.  You can use an online tool to convert decimal to hexadecimal numbers.

I would start with

https://developer.bitcoin.org/reference/block_chain.html and
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki and
https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/

The first reference above says

As of this writing, a newer method called version bits is being designed to manage future soft forking changes, although it’s not known whether version 4 will be the last soft fork to use the IsSuperMajority() function. Draft BIP9 describes the version bits design as of this writing, although it is still being actively edited and may substantially change while in the draft state.

The second reference starts

This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

The third reference explains this in a simpler way. AFAIK each bit signals miner readiness for a current soft-fork proposal.
You example decimal 545259524 is Hex 0x20800004 or binary 00100000100000000000000000000100
So there are extra two bits set (the first one in 0x20 is standard AIUI) and therefore readiness for two soft-forks being signalled.
I don't know of a web-page that tracks current bit meanings, linking a bit to relevant BIPs. https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki seems out of date to me.

thank you. But I am unsure what all that means for a miner. I mean all that he/she is doing is creating a Block that passes the difficulty. So how is the future fork protocol etc. relevant to the current block being mined? Unless the structure of the Block depend on the Block Version? And is there a default value one can use so that the block structure is automatically correct?

The block needs to be valid, as well as meeting the proof of work requirements.

The Version, Time, Bits and Nonce fields don't seem to match in size. What am I interpreting wrong here.

The quoted example is a numerical (base 10) representation, which is not the way that numbers are stored in the binary format.


text:
Some questions about specifics on bitcoin mining
Most people mine bitcoin by launching a software on their PC or buying a special miner, both of which abstract out the nitty-gritty of how the mining process work. I am curious however about some potential issues with the nitty-gritty of the mining process. Feel free to skip to my question if you already know how it works:
As far as I know, this is how it works:
Given a string of hex values that is 1024 bit (or 256 hex values, or 128 bytes), let's say
0x000000020597ba1f0cd423b2a3abb0259a54ee5f783077a4ad45fb6200000218000000008348d1339e6797e2b15e9a3f2fb7da08768e99f02727e4227e02903e43a42b31511553101a051f3c00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000

And a 256 bit (or 64 hex values, or 32 bytes) value known as the target
0x00000000FFFF0000000000000000000000000000000000000000000000000000

We first byteswap each 32-bit chunk, so we end up with
0x020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad180200000000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e312ba443105315513c1f051a00000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000280

We read the last 64 bits (or 16 hex values or 8 bytes)
0x0000000000000280

Which equals to 640 bits, or 80 bytes.
So we grab the first 640 bits (or 160 hex values, or 80 bytes) of byte-swapped string of hex
values
0x020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad180200000000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e312ba443105315513c1f051a00000000

We do not change the first 608 bits, but we keep on changing the last 32 bits (or also known as the nonce value) and put the new string of hex values into the SHA256 function
#scroll to right to see the last 8 bits incrementing
    new_hash = SHA256('0x020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad180200000000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e312ba443105315513c1f051a00000000')

    new_hash = SHA256('0x020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad180200000000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e312ba443105315513c1f051a00000001')

    new_hash = SHA256('0x020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad180200000000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e312ba443105315513c1f051a00000002')

#    .. so on

If we find a new_hash that is lower or equal to the target,
# one of the new_hash is
new_hash = 0x00000000fffe0000000000000000000000000000000000000000000000000000
# which is is lower than target

then we have successfully found a nonce value (the 32 bits that we are changing) that satisfies the requirement, so we can submit it and earn a share, which I understand is a small chunk of reward to the miner when the actual full requirements are satisfied.
Where I read this: https://en.bitcoin.it/wiki/Getwork
Skip down to here if you already know how bitcoin mining works under the hood.
When I learn about this, however, I have 3 questions about it:
To be able to get a value lower than that target randomly, there will be a 1 in 4295032833 (4.3 billion) chance of succeeding.
The nonce value which we can change is 32 bit or 4294967296.
So the expected value of getting it right after trying every nonce value is (4294967296/4295032833), or basically 1.
But that is the expected value, there will be cases where every nonce value is tried and we still do not get to the target.
Question 1. How does software like NiceHash miner or other mining tools handle situations like this under the hood?
Here is another issue, it is going to take computers some time to try out every nonce value because there are 4 billion of them.
Question 2: Is there a time limit to how long a miner can take to guess and check before the given work is no longer "accepted"?
And here is my 3rd one, the given target is not exactly sufficient in mining a full block, attaining it will instead earn miners a share. The system is implemented like this so that miners can share their reward proportional to the amount of computation they have performed.
Question 3: How much, usually, is each share reward is in US dollars? I am guessing it varies from pool to pool, but what would the financial value usually be at?
Also if there is something wrong with my own re-articulation of how bitcoin mining works, please let me know as well.

Not a real answer, but just FYI, NiceHash does not mine BTC. It mines various altcoins (which can be mined without specialized hardware; the process is different for each) for the pool, credits your account for it after converting to BTC, and then lets you withdraw the BTC. Bitcoin itself cannot realistically be mined with generic-purpose hardware since 2013 or so. It's all specialized ASICs now.

Question 1. How does software like NiceHash miner or other mining tools handle situations like this under the hood?

There's literally nothing to do in this case. If you don't find a nonce that works, then you have to try a new block.

Here is another issue, it is going to take computers some time to try out every nonce value because there are 4 billion of them. Question 2: Is there a time limit to how long a miner can take to guess and check before the given work is no longer "accepted"?

Realistic miners take a very tiny fraction of a second to try every possible nonce. It's so fast that working on a single block at a time is completely unrealistic and real miners will try several possible blocks at a time.
Typical mining pools will accept a share so long as it is turned into the pool before a new block is mined. That means that on average you have a ten minute window. A share turned in after a block is mined is called a "stale share". Under realistic conditions, they should be rare. Every ten minutes, right after a block is found, there's a window of a second or two in which a stale share might be turned in even if nothing goes wrong.

Question 3: How much, usually, is each share reward is in US dollars? I am guessing it varies from pool to pool, but what would the financial value usually be at?

A difficulty one share is essentially worthless. It takes only 4 billion hashes or so to generate a difficulty one share and realistic miners would generate so many of these that there is no way they could keep up and have to use much lower targets to generate a realistic number of shares. A single Bitmain S19 Pro miner produces 110 trillion hashes per second -- that's thousands of difficulty one shares per second.
The bitcoin network is currently getting around 100 quintillion hashes per second. Total mining revenue is about $56 million per day. That makes the value of 4 billion hashes approximately 0.0000025 cents.


text:
Bitcoin qt 4.8.3
Hi I recently tried to make a transaction to a coinbase btc wallet from my bitcoin qt 4.8.3 node/wallet.  In a hurry I didn't add a transaction fee.  So the fee is zero.  I see on my end the transaction is unconfirmed.  Blockchain Explorer does not recognize the transaction ID either. I assume the block is waiting in the mempool and no miner wants to touch it.  I've contacted coinbase's customer support and don't have too much faith they even understand what is going on (sry for the negativity, just keeping it real).  It has been 6 days so far.  Any suggestions?  I would still like the transaction to go through.  Maybe a "pay for parent protocol".  But if it doesn't could someone walk me through the process of retrieving my transaction/block back.  There is a lot of support out their on the internet but not that much for a bitcoin qt 4.8.3 node/wallet.  Any help would be appreciated.  Thanks.

When you add a very small fee or no fee at all, as in your case, you'll need to ask for a special favor from a mining pool in order to get your TX in.
It is possible to request, on exceptional basis, for a mining pool to include your transaction into one of their less busy blocks.
They call this service "transaction accelerators".
For instance, ViaBTC offers an accelerator.
If you search Google you'll find several similar services from other pools. Some of them are paid: you send someone a small reward and they'll get the TX into a mining pool queue for you.
This service has worked for me in the past, especially during the November 2017 mempool explosion when low fee transactions weren't going through.
Keep in mind, though, that this is a courtesy service and there are no guarantees. I recall that, in 2017, you'd need to submit during late night or less busy hours to succeed.


text:
Metamask-like web3 inject for bitcoin
Is there a browser extension that works similarly to Ethereum's Metamask? I am wondering that if there isn't one, is it because of some technical limitation, or that just no one has gotten around to developing one.

What functionality are you looking for, specifically?

There is a Bitcoin wallet extension for Chrome. It's apparently used by 1500 people and has 3.5 stars average review. Still, I would not trust this extension without first auditing its source code. I cannot find its code on its author's Github profile.
CoinSpace is a web-based Bitcoin wallet. It's not exactly an extension but if you understand what Metamask does you'll see that it isn't really different.
Metamask loads up an Ethereum javascript library and offers a front-end to it using HTML. This is exactly what other similar wallets do, e.g. myetherwallet.
Brave Browser used to have a Metamask-like wallet for Bitcoin. I don't know what happened to the code when they moved to BAT tokens but it should be out there. It was basically a Bitcoin wallet in a Chrome extension, so the javascript for Bitcoin functions could probably be refactored out of the extension.


text:
Do local nodes work across crypto types?
Newbie to all of this, hoping you can help with what is probably a "duh" question. I'll keep it brief, though: if I download the blockchain using the instructions given for the Bitcoin GUI, will I be able to use it as a local node for my Monero GUI wallet, as well?
Thanks so much! :)

No, while there are some wallets that support multiple coins, the full nodes of each cryptocurrency network generally have their own distinct node software. In particular Monero and Bitcoin will require separate software.

Ah, shoot. I guess that does explain the vastly differing size estimates I was hearing for the blockchain. Thanks for your help!


text:
Lost Transaction from Blockchain.com to Electrum
This link, https://www.blockchain.com/btc/tx/a081d03519bc0f1dcf4ac391da6f54d4d6091c458530b620f96eca5c1c5a3511, shows the transaction was delivered to the address "1Mv4fi8UdVhbfm9iLx2Bf8xhDrMv9sZSyD" of my Electrum wallet, but my Electrum wallet doesn't show the transfer. Please teach me what is wrong. how I can find the truth? Thank you for your help in advance

In the Electrum window, on bottom right do you see a red circle or green circle?

Green. I have an Electrum wallet 3.3.8, latest version.


text:
why is bitcoind daemon occasionally stuck at `Opening LevelDB in .../.bitcoin/chainstate`despite clean shutdown
My bitcoind daemon sometimes takes an hour to go past Opening LevelDB in .../.bitcoin/chainstate
After googling a bit, i thought it was simply an unclean daemon stop causing a leveldb corruption. But then this happened again this week despite having been stopped correctly (as indicated by Shutdown: done log entries). I was using systemctl stop, not bitcoin-cli stop if that makes any difference.
$ journalctl -u snap.bitcoind.daemon --since "1 week ago" | grep -B1 -E "Opened LevelDB successfully|Shutdown: done"
...
Nov 12 02:09:34 localhost bitcoind.daemon[13878]: 2019-11-12T07:09:34Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/blocks/index
Nov 12 02:09:34 localhost bitcoind.daemon[13878]: 2019-11-12T07:09:34Z Opened LevelDB successfully
--
Nov 12 02:09:39 localhost bitcoind.daemon[13878]: 2019-11-12T07:09:39Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/chainstate
Nov 12 02:09:39 localhost bitcoind.daemon[13878]: 2019-11-12T07:09:39Z Opened LevelDB successfully
--
Nov 12 02:28:16 localhost bitcoind.daemon[13878]: 2019-11-12T07:28:16Z scheduler thread interrupt
Nov 12 02:28:17 localhost bitcoind.daemon[13878]: 2019-11-12T07:28:17Z Shutdown: done
--
Nov 12 02:28:18 localhost bitcoind.daemon[14353]: 2019-11-12T07:28:18Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/blocks/index
Nov 12 02:28:18 localhost bitcoind.daemon[14353]: 2019-11-12T07:28:18Z Opened LevelDB successfully
--
Nov 12 02:28:25 localhost bitcoind.daemon[14353]: 2019-11-12T07:28:25Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/chainstate
Nov 12 02:28:25 localhost bitcoind.daemon[14353]: 2019-11-12T07:28:25Z Opened LevelDB successfully
--
Nov 12 06:57:36 localhost bitcoind.daemon[14353]: 2019-11-12T11:57:36Z scheduler thread interrupt
Nov 12 06:57:37 localhost bitcoind.daemon[14353]: 2019-11-12T11:57:37Z Shutdown: done
--
Nov 12 06:57:39 localhost bitcoind.daemon[18691]: 2019-11-12T11:57:39Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/blocks/index
Nov 12 06:57:39 localhost bitcoind.daemon[18691]: 2019-11-12T11:57:39Z Opened LevelDB successfully
--
Nov 12 06:57:51 localhost bitcoind.daemon[18691]: 2019-11-12T11:57:51Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/chainstate
Nov 12 06:57:52 localhost bitcoind.daemon[18691]: 2019-11-12T11:57:52Z Opened LevelDB successfully
--
Nov 17 13:27:36 localhost bitcoind.daemon[18691]: 2019-11-17T18:27:36Z scheduler thread interrupt
Nov 17 13:27:38 localhost bitcoind.daemon[18691]: 2019-11-17T18:27:38Z Shutdown: done
--
Nov 17 13:31:00 localhost bitcoind.daemon[18236]: 2019-11-17T18:31:00Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/blocks/index
Nov 17 13:31:00 localhost bitcoind.daemon[18236]: 2019-11-17T18:31:00Z Opened LevelDB successfully
--
Nov 17 13:31:11 localhost bitcoind.daemon[18236]: 2019-11-17T18:31:11Z Opening LevelDB in /root/snap/bitcoind/common/.bitcoin/chainstate
Nov 17 14:32:53 localhost bitcoind.daemon[18236]: 2019-11-17T19:32:53Z Opened LevelDB successfully

This delay coincides with a spike in memory usage that i only experience in this situation. Otherwise, the daemon runs happily with 512M RAM and no swapping, albeit slowly of course.
# swapon --show=NAME,USED,PRIO
NAME        USED PRIO
/dev/vda2 511.2M    1
/dev/dm-2 441.4M   -2

It is not a tragic situation since the daemon eventually starts. But I'd like to understand whether this is happening because of something I'm doing wrong. I'm happy to enable debug logs to provide more info if needed.

Mh the your machine is a raspberry?

can you provide the debug.log?


text:
How to calculate Tapscript sigops budget?
Sigops limits have been changed to budget in Tapscript. BIP341 defines the budget calculation method as follows.

The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the CompactSize prefix). Executing a signature opcode (OP_CHECKSIG, OP_CHECKSIGVERIFY, or OP_CHECKSIGADD) with a non-empty signature decrements the budget by 50.

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#Resource_limits
This CompactSize prefix include the number of witness elements at the beginning?
For example, if I have the following 5 sizes of witness data,

compact size
witness size

1
65

1
64

1
91

3
257

3
563

The total size including the above Compact Size is 1049. In addition to this, do I need to add the number of bytes(1) of CompactSize for the number of elements(5)?
That's because the above data output by Bitcoin Core feature_taproot.py is 1050. The final budget will be 1100, which is 50 added to this.

The total size including the above Compact Size is 1049. In addition to this, do I need to add the number of bytes(1) of CompactSize for the number of elements(5)?

Indeed.
What matters is the total number of bytes of witness data for that input (i.e., all bytes subject to the witness discount). That also includes the encoding of the number of witness stack elements.


text:
Why does the musig() descriptor accept the pk descriptor as an argument?
In the following test vector described in BIP390, the musig() descriptor takes a pk() descriptor as an argument:

tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*,pk(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9))

In the specification, the musig() descriptor takes a Key expression as an argument. I think that the pk descriptor itself is not the Key expression itself. Is this a mistake with the Test Vector?

The pk() is part of the tr() as a script expression. The musig() component is completed at the first comma.

oh, it was my mistake. thanks!


text:
Old Blockchain Wallet App Not Working (android)
I have the Blockchain wallet app most recent version (yet, years old) everytime I try to login it says "error connecting to server" And I have the internet and 4 digit pin, and this app is not available anymorr om play store (they changed app name and apk) i have tons of btc i dont have phrase, please help if you know how to access old blockchain app wallet, regards amanda.

If the app is a custodial wallet the only people who can help are the wallet's custodians (blockchain.com).
If the app is a non-custodial wallet (arguably the safest kind) - you should restore from backups or seed phrase or use seed-phrase or master private keys in a different still-supported non-custodial wallet app. If you didn't make a safe copy of the seed-phrase or master private key and have no backups then all money is lost and cannot ever be retrieved.


text:
Can I read blockchain's information from Electrum's python console?
I wanted to use Electrum's python console, but the documentation just gives a few examples.
Is there a more complete documentation about python commands inside Electrum ?
Main tasks I currently want to do are blockchain reading, it includes :

the current block height(it is in the GUI, in "tools" -> "network", but is there a CLI way to do it ?)
informations about a given block, like POW and Merkle root(I don't know at all if there is a way to get them inside the console)(there is a file named ~/.electrum/blockchain_headers, but it's not human-readable).

Is there a way to do that ?
(this is my main question)
(I'm currently using Electrum 3.3.8.)

You can get all the available commands with help(). This is not much of a help as it just lists all the commands without any other documentation. The full list of commands and arguments for those commands can be found in the commands.py file. For example, to get the current block height you can use getinfo()

Did you try your solution first ?
I don't see the getinfo command inside the list I got with help().
And when I type getinfo or getinfo() in the console, I just receive an error message :
"Traceback (most recent call last):
NameError: name 'getinfo' is not defined".
How am I supposed to use the function getinfo() to make it work, please ?

Yes I did try it. Looks like getinfo() has been present at least from version 4.0.1 Is there a reason you need to use 3.3.8? It is almost 5 years old. You are right, your version does not have the getinfo command and looking at the code from your version, there is no command that returns the block height https://github.com/spesmilo/electrum/blob/3.3.8/electrum/commands.py

ok, thank you. I tried with version 4.5.4, and the getinfo() command is available. I can see the current blockchain's height with this. But how can I see more "advanced" infos from blockchain headers (on any block), like POW or merkle root ?

Electrum is a wallet and the commands reflect that. The commands are intended for handling the wallet and wallet related tasks, so they have limitations. You might not be able to get all the info you want with Electrum. Would it be possible for you to use Bitcoin Core? It has an RPC command interface (can be called with Python) that can be used from a console just like Electrum. Here is an example of a block related command https://developer.bitcoin.org/reference/rpc/getblock.html

The reason why I chose to use Electrum is that I don't want to have to download a complete copy of the blockchain. Now, I want to read as much datas as possible just from the headers. If I just need the POW and Merkle roots (they are very small), it makes no sense for me to download ~200GB of datas. If Electrum downloads the headers, I think it means Electrum "understand" the headers.

Ok, I "accept" your ansrwer, considering it's the only answer, and you at least partially gave me the solution with getinfo(). I also saw other useful commands like get_merkle(). Other stuff I asked for are probably impossible inside the Electrum's console. Best I've found now for my needs is this script to convert blockchain headers : https://bitcoin.stackexchange.com/questions/66873/do-you-know-any-download-site-for-full-blockchain-header-data-6-in-csv-ascii-f/73987#73987 (outside of the Electrum console, but good enough. May be improved to avoid re-converting everything everytime).


text:
Can someone explain *simply*, but precisely, how the mnemonic seed phrase is used to produce the bip39 seed
Im referencing https://iancoleman.io/bip39/
I understand how the words are generated ("bip39 mnemonic" at the link).  But Im not quite clear on how the words give rise to "bip39 seed" two sections later.
Ive followed a variety of youtubers who demonstrate the calculation in python, but my computations are not coming out the same.  Im not sure why.  Clearly Im missing something about how certain strings/values are being constructed prior to the sha512.

These pictures are from Mastering bitcoin and were so insightful for me.
How the mnemonic words are generated:

How they are used to generates master seed of your wallet:

From BIP39:

To create a binary seed from the mnemonic, we use the PBKDF2 function
with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.
The iteration count is set to 2048 and HMAC-SHA512 is used as the
pseudo-random function. The length of the derived key is 512 bits (=
64 bytes).
If a passphrase is not present, an empty string "" is used instead.

When I try to generate a random mnemonic on https://iancoleman.io/bip39/, the derived BIP39 seed is the same as when I manually calculate it with https://stuff.birkenstab.de/pbkdf2/ using the steps above.

To complement Vojtěch's answer James Chiang explained how the seed is derived from the mnemonic during his TeachBitcoin class in 2019:

When I generate the seed for my HD wallet I do not go back to the secret entropy. I don’t decode my mnemonic word phrase to obtain the entropy. Instead I join all my words into a sentence, I concatenate a string mnemonic, there is an optional passphrase that you can introduce. Then through the password-based key derivation function 2. What is that? That is basically many (2048) rounds of HMAC-SHA512. That takes as an argument the sentence and as a salt, the mnemonic and the passphrase concatenated. The many rounds are equivalent to a length extension. It makes it more expensive to brute force. Adding more rounds is the equivalent to adding key length if you will. Then we finally end up with a 512 bit seed. This is the seed that we use to derive the rest of our wallet.

I made this video to show exactly how it works. Not to teach, but so I could learn myself.
https://youtu.be/lc9ys9PzO0k
Basically the bip39 passphrase is a standardized way of submitting a big string of lower case characters and spaces for hashing through a PBKDF2 512 algorithm 2048 times. Your passphrase (25th word)is nothing more than customized salt for this otherwise standard input.  The resulting 512 bit hash will become your bip39 seed which is used to derive all the private and public keys for your wallet.  Watch the video though, a picture is worth 1000 words.

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

Understood. Thank you.


text:
Additional instructions in TX

Would it be possibile to add additional  information in TX?

I would like to add time of transaction in it.

Would hash of TX change if hostile node would change that time ?

You could add an extra output with a locking script that uses OP_RETURN to embed an arbitrary timestamp.
Obviously this increases the size and therefore likely increases the cost in required transaction fee to get the transaction confirmed promptly.
This would be time of transaction creation, not time of confirmation.

Related:

Explanation of what an OP_RETURN transaction looks like


text:
Is it possible (not feasible) to mine bitcoins with Bitcoin Core v0.21.1?
Before you tell me, yes, I'm aware CPU mining is dead in 2021 and attempting to do so will likely just burn CPU time for no good reason.
However, my question is not whether mining is feasible, but whether it is possible with the (currently) latest version of Bitcoin Core, v0.21.1. From my understanding, it was possible in 2016, but the internal miner was "removed" in v0.13.0. Looking at the code, it's unclear to me whether it's still possible; miner.cpp is still present, for example. All that seems to remain is the "-generate" option. Does this option actually allow mining on mainnet?
If the answer is no: Isn't Bitcoin Core meant to be the reference implementation of Bitcoin? And given that, isn't it a bit odd that the reference implementation does contain one of the core components of Bitcoin, that is, the mining system? I understand it's pointless to do so, but as the reference implementation, shouldn't Bitcoin Core provide this feature regardless?

I heard once the native mining feature on Bitcoin Core was removed in some of the previous versions, so right now the native mining is not supported anymore.

The setgenerate built-in background miner was removed.
There is however still a test-only on-demand miner, which will try to mine N blocks whenever requested by RPC (see generatetoaddress /generatetodescriptor/generateblock RPCs in recent Bitcoin Core versions). It is many times less efficient than even the built-in CPU miner was. Its only purpose is in functional tests (which use the "regtest" network that is permanently at very low difficulty).
The code you see in miner.cpp is additionally used as a backend for the getblocktemplate RPC, which is how pools and external miners communicate with bitcoind. It doesn't actually do any mining (as in hashing) itself, but provides block templates for others to do so, based on transactions in the mempool and the chain's tip block hash.
The -generate option to bitcoin-cli is just a wrapper around the internal generatetoaddress RPC, which is slightly more convenient (it requests an address from the wallet, and then miner to it). It is in theory usable on mainnet, but it obviously won't ever actually find anything (except with extremely small probability).

Thanks Pieter, appreciate your response. Just for my curiosity, if someone was still running Bitcoin Core v0.12.1 (the last version with setgenerate), and they ran setgenerate, could the software still theoretically mine a block (again, theoretically; I'm aware the chance is effectively zero), or is that version of the software too old to mine blocks for the current blockchain?

I believe it still could, but I'd need to think harder about all the changes since then to know for sure.

With setgenerate true you can't.
But yes, it's possible, just you need to configure your Bitcoin.conf to receive RPC command, then you can communicate with your bitcoin client to get information from and send information to when you find a valid block for exemple


text:
Recovering from an old Wallet
I have recovered my wallet from an old data file using Bitcoin Core. The wallet has synchronized without issues. I have tried to send BTC to at least two exchanges and neither transaction has completed. After the first transaction (going to the Coinbase Wallet) I waited 10 days and then tried increasing the transaction fee - no change. The returned stats code says "Status: 0/unconfirmed, not in memory pool, abandoned."
I then cancelled that send and tried sending to Kraken and it's still processing after six days. The status code for this one says "Status: 0/unconfirmed, not in memory pool?
Any ideas? Am I just SOL?

As a workaround for the problem that you are facing - instead of using Bitcoin Core to send BTC to your account with the exchange, you might want to try exporting your wallet's private key from Bitcoin Core, then importing the private key to your account at the exchange.  See https://wallet.coinbase.com/faq/ (under 'Can I switch from my existing wallet app like Metamask, MyEtherWallet, etc.?') for information on how this is done with Coinbase.  Then, your BTC will be available in your account at the exchange.


text:
What does bitcoin do that prevents someone from using your coins by just generating a key pair and saying "you" sent those coins?
I think I'm missing and understanding about the current process of how your wallet works and how the transactions are signed.
For example, if I'm user "A" and there exists a transaction from user "B" where I received 10 BTC that has been written into a block. Then for me to use it I just generate a random public/private key pair and sign the transaction with the private key.
What is stopping user "B" from generating a public/private key pair then creating and signing a transaction saying that I, user "A" sent them 10 BTC?
I've read that some wallet implementations generate a list of public/private key pairs that can somehow be associated with the wallet address? I'm not sure how this would come into play if this is the case or if I'm misunderstanding this bit of information.

When you spend Bitcoin, you are not just using a new randomly generated keypair. You are using a specific keypair generated before. In order for you to have been sent Bitcoin, you have to give the sender a Bitcoin address. This Bitcoin address contains the hash of your public key. When you want to spend those Bitcoin, you put your public key into the transaction and verifiers will check that that public key hashes to the hash specified in the transaction that sent those Bitcoin to you. If you just put a newly generated public key there, it would not match the hash and so the spending transaction would not be valid.

If I'm understanding correctly, my Bitcoin address that I sent to the payer will be: hash(my address + my (public key that is generated from my wallet) pk)?
Then to spend it I will put that pk into the transaction. Then verifiers will check that hash(pk) == hash(transaction sent to me before)?

Your address is just hash(pk). This is placed into the transaction sent to you. When you spend, you put pk into your transaction, and verifiers will check hash(pk) == hash from previous tx.

Oh ok I think I get it now. Then once my pk is in the transaction and verified, the verifiers will also check that my pk can verify the signed message created with my sk. And I can assume that the life span of using that sk/pk pair is done and next time I use or receive a token, it will be with a different pair?

@AndrewQ There's no expiration per se. You can reuse addresses (and thus reuse keypairs) if you want, however this is not advised because it reduces your privacy.


text:
Trace fund flows between Bitcon addresses using transaction data
I wonder if there is a way to trace fund flows in the Bitcoin network using transaction data. I'm using Google BigQuery public data and their Bitcoin transaction dataset has following columns:

I've been trying to trace fund flows among Bitcoin addresses by extracting input and output addresses in a transaction from the inputs_addresses and output_addresses columns and the corresponding input and output amounts from the value columns. However, many transactions have multiple inputs and multiple outputs and it's hard to tell which input address paid what amount to a certain output address.
For example, let's say there is a transaction that has two inputs and two outputs. Address A paid 0.5 BTC and Address B paid 0.5 BTC in the transaction and Address C received 0.8 BTC and Address D received 0.2 BTC. I can tell how much each Address paid/received in the transaction but can't really say how much Address A paid Address C. Is there any way to find out how much each input address paid to each output address using any of the existing columns like spent_output_index and script_hex?
If that's not possible, can I at least assume the connections/fund flows among addresses based on the following logic?
Let's say Address A paid 1 BTC and Address B paid 2 BTC in a transaction. Address C received 3 BTC in the same transaction. If I want to trace where this 3 BTC Address C received went after this transaction, should I look for transactions whose "input" is from Address C? Since Address C was an "output" address in the first transaction, I wonder if I can trace where this 3 BTC went by looking at transactions whose "input" address is Address C.

Is there any way to find out how much each input address paid to each output address using any of the existing columns like spent_output_index and script_hex?

No.

can I at least assume the connections/fund flows among addresses based on the following logic?

Not reliably (or in short: no).

Say I sell surplus Apples from my garden. Person A buys a bag of apples and gives me a $5 banknote. B buys a bag of apples and gives me a $5 banknote. Next day I buy a sandwich for $5. I don't care which $5 banknote I use and you would be foolish to ascribe any meaning to my choice of banknote.
With Bitcoin it is harder, I can use two "coins" of 3 kSat and 7 kSat to buy a 5 kSat sandwich from C and a 4 kSat cake from D in a single transaction and you have no way to tell which coin was used for which purchase. The notion is meaningless.
It isn't hard to find transactions with hundreds of inputs and hundreds of outputs. The transaction data does not record any correspondence between individual inputs and outputs.
You can also find transactions with one input and one or two outputs. In that case you can trace a flow of money. However you cannot tell if it represents a transfer of money between two people or just someone moving money from their hot wallet to their cold wallet.
You can look for patterns and make guesses as to the underlying meaning but, in general, this eventually relies on access to external information about ownership of addresses, information that isn't recorded in the blockchain.


text:
Decoding Bitcoin transaction data
I've recently learned that some cryptocurrencies allow the users to attach additional input data to their transaction and would like to know if it's true for Bitcoin as well.
For example, Ethereum allows its users to attach "input" data to a transaction and the senders can hide the actual transaction information inside the "input" data in a hexadecimal format. In Ethereum transaction data, there are many cases where a transaction's input amount is 0 but if you look at its input data, it has a hexadecimal string that has the actual transaction amount and the actual output address.
I wonder whether Bitcoin has a similar function. If so, which column in the Bitcoin transaction data should I look at to get the hidden information? Here's the list of columns in the transaction data.

Bitcoin does not have freely defined input fields of the sort that you describe. In Bitcoin, each input must reference a specific UTXO that is spent, and satisfy the locking conditions that were specified when the output was created. There is one exception which is the coinbase field in the transaction that pays out the block reward, however, this transaction type can only appear once per block and is authored by the miner that found a block.
There is however the "null data" (OP_RETURN) output type that allows a sender to attach one output with up to 83 bytes of data. Null data outputs for example find use to anchor timestamps and by colored coin-style networks such as the Omni Layer.


text:
Can you program a transaction to automatically run once fees are low?
Can i program a bitcoin transaction to run when the network is not as busy or when fees are low? If you are not in a rush to complete trx.

I mean, you can just create the transaction with a low feerate and it will get confirmed when the feerates go that low?

If fee rate was too low it might not make it into mempools. You could certainly program a Bitcoin transaction to be broadcast once fees reach a certain level but that would be external to the actual transaction.

This is not something you can do at the protocol level, but you probably don't need it. Once you broadcast a transaction, each bitcoin node will hold it in its memory pool until the transaction is confirmed or until the node decides to drop it from its mempool.
Nodes can drop your transaction when maximum mempool size is reached and transactions below a certain fee rate need to be pruned away, or after a certain amount of time passes without the transaction getting confirmed. In Bitcoin Core by default the maximum mempool size is 300 MB and transaction expire time is 2 weeks, although each node can set this to whatever they like.
This means that if your transaction fee is high enough to get your transaction confirmed within 2 weeks and the network congestion isn't at a level where your transaction would get pruned from the mempool, you can simply broadcast your transaction and wait for it to be confirmed. Of course, if this isn't enough for you, there's nothing preventing you from writing a script that would periodically check the network fee rate and broadcast your transaction when fees are low.


text:
Bitcoin Wallet Question
I have a nice sum of bitcoins in a particular account. The account is with a "bank" that does cryptocurrency conversion. This place is charging me $$$ for codes (IMF, COT, Tax, etc.).
I need a bitcoin wallet to access my cash without paying these ridiculous fees. Is the bitcoin wallet universal? I mean, can I obtain a bitcoin wallet from a third party; like through this site? Or, can I only get the bitcoin wallet from the "bank" where I have the account? I ask, because I need to access the bitcoins through bitcoin atm... Thanks.

Some services only allow you to trade exposure to Bitcoin, while others allow you to purchase bitcoins. The latter will let you withdraw to any Bitcoin wallet. You can find some pointers to pick a wallet on https://bitcoin.stackexchange.com/q/4178/5406

Does this answer your question? I am new to Bitcoin, how can I get started?


text:
In what cases is FindAndDelete useful?
In the non-segwit case, FindAndDelete removes signature data from scriptCode.
In P2PKH, the signature is not included in the scriptPubKey, so I think the only thing that may actually have signature data removed by FindAndDelete is redeemScript for P2SH.
But is there actually a useful use case for including a valid signature within a redeemScript? What was the intention behind introducing the FindAndDelete process?
In the following Bitcoin Core's FindAndDelete test case, the public key is recovered from the signature and set to scriptSig.
https://github.com/bitcoin/bitcoin/blob/v28.0/src/test/data/tx_valid.json#L496


text:
I use Litecoin Core wallet on my PC and need to have it on laptop to take away on holiday
I am using Litecoin Core wallet on my PC,  and I need daily access to it.
I am travelling away from home at Easter and taking my laptop with me.
I downloaded Litecoin Core Wallet to my laptop,  but there is no balance showing up.  Is there a way to sync the two wallets?
Or if not,  can I transfer the balance to a Receive Wallet on the Laptop Wallet?
Thank you
Margaret.

Yes.  You'll need to backup the wallet.dat file from litecoin core on your PC, transfer it to your laptop, then replace the wallet.dat file in your laptop with the one you grabbed from your PC.
How to Backup Litecoin Core

Open Litecoin-QT
File-> Backup Wallet
Save it
Grab a USB
Drop the newly saved wallet.dat file into the USB

How to Insert wallet.dat into New Litecoin Core

Download Litecoin Core but do not open it.
Open your file explorer and type the following line:
C:\Users\YourUserName\Appdata\Roaming\Litecoin
Delete the wallet.dat file in the Litecoin folder. Rename your wallet.dat file from your PC to "wallet.dat" if you need to.  Drop it in the Litecoin folder.
Open Core and if you see unconfirmed tx it worked.

Another Option
You can dump priv keys to the addresses that received LTC and sweep it into Electrum-LTC.  Only download this from Electrum-LTC.org.  Electrum-LTC is a light-weight client that references other Full Nodes so you don't have to use your own.  This means you don't have to keep your laptop on to stay up to date with the most recent blocks in order to send LTC.  But if you want to keep supporting the LTC network by running Litecoin Core, then kudos to you!
How to Dump Priv Keys from Litecoin Core

Go to console in Litecoin-QT
type: walletpassphrase "your walletpassphrase here" 600
type: dumpprivkey [your Litecoin address here]

Sweep into Electrum-LTC

Open Electrum-ltc. Go to Wallet-> Private Keys-> Sweep.
Input the private key and an LTC address you want to send it to. Often times, Electrum-LTC provides one for you.

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


text:
What resources are required for bitcoin mining?
What resources do I need to mine for bitcoins?
Do I need a computer and computer software?
Do I need a license to mine for bitcoins?

I'm not sure it's worth the bother any more - there's no point at all mining bitcoin with a computer, or even a bunch of graphics cards. It's now done by dedicated mining machines like an Antminer S9 - mining farms have thousands, maybe even tens of thousands of these things in warehouses plugging away at getttibg hashes. You could buy one, join a pool of other people who also have them, and get paid a share of the pools winnings if one member finds a block, based on how much computing power you represent to the pool..
.. but then there's the question of whether your pool will ever find a block, as the only way your machine will return on its investment is if it does, and it's not a sure thing. And maybe the antminer s11 will come along and be 50 TH and the same price as your s9.. and then it makes it a whole lot harder as mining farms get 4x more processing power.. they're much more likely to find a block than you are..
Hmm, so.. look into it some more. The conclusion I came to is that it's just not worth mining bitcoin any more. Maybe some altcoins, but work out how they're best mined and mine them with the best value method
Side pondering: If only satoshi nakamoto had made the work-done something like protein folding, cancer cure calcs, something useful (instead of trying to find a number smaller than another number) all that electricity burnt on this huge distributed computing effort would have had some great benefits

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


text:
How does a miner’s pubkey get passed into miner.cpp?
I understand that a miner using an application like pooler’s cpuminer can set a Coinbase-txn address where new coins that are generated to. I’m trying to override this setting in the code of the core client for an academic project to demonstrate bitcoin’s consensus mechanism. When I try to set a fixed address in the core client, the miner is still being paid out to the address they set rather than the hardcoded one in the miner.cpp file
How does the address get sent for a miner’s Coinbase transaction payout? Having some insight into where the logic is would allow me to further try and troubleshoot my project.
Thank you

Bitcoin Core does not set the payout address. It can only do that when you use the internal miner (i.e. use the generatetoaddress command, but only on regtest). Otherwise, external mining software sets the address. This is because Bitcoin Core does not just send a complete block that the mining software just works on.
Rather, those mining software use the getblocktemplate RPC which returns a block template. This template does not include a coinbase transaction. It just includes information necessary to construct the coinbase (such as amounts) as well as the transaction data to include in the block. But it is not a block itself and the external miner still has to construct their own coinbase transaction and block given the information in the block template.
So Bitcoin Core cannot force an external mining software to use a particular output script in the coinbase transaction. You have to configure your mining software to do that.

Thanks for the insight, Andrew. I understand that the mining software would submit a block with transactions via RPC to the Core software, which gets validated and checked. My goal is to override the Coinbase transaction during validation. My aim is to prove that in a distributed consensus system like bitcoin, this type of override should fork the network and leave the attacker/overrider on a different chain than the rest of the network - since consensus on the transaction was to the miner; not to the attacker. With that in mind, can you describe where these checks would take place?

There is none because what you are suggesting is not how Bitcoin works. The miner's "pubkey" is not part of validation and there is no consensus on who the miner is or who gets paid for a block except what is given in the coinbase transaction. The miner can choose to pay someone else if he wanted to. And immediately in the next block pay himself. There is nowhere where miners are identified nor their blocks identified and tied to them.


text:
Need help with (Script failed an OP_EQUALVERIFY operation)
This is a repost of a question which i posted directly on the repository of bitcoinjs-lib, which you can see here
I'm getting the following error when trying to push transactions:
Err: sendrawtransaction RPC error: {"code":-26,"message":"mandatory-script-verify-flag-failed (Script failed an OP_EQUALVERIFY operation)"}
I've done quite a bit of Googling and the only thing that it says is that my public and private keys do not match... which I'm not sure exactly how to remedy.
Here's debug information + code:
Debug Information
WIF: cN7j9B1H1YrZBufP5B43WcyX8U16XvJgeTdwLsS1ZrEkTEguy4FQ
Public: 036c99325f518d75088ed1ac950f0c37df0bf064e781f957c71d8f37e59f10cf83
Private: 0ff5f8231a280ab64d7498f27d0a49c736f710045aabe76ecc96b2f4758aa8ca
Example Transaction HEX: 020000000130a7c7195c23710e96e91f06ff87e264d98a5f9dbe4e34f89d6385b01dd2016c010000007000483045022100ae4b9bf764ecd9a54dd5cce1ff7092c6efda194789a632ebce0e5bc57f10e6d102207d3a1b68a3fb16c6ec86d74be2b825b298ce0c85dbbf05c5ed8084336c773dff01255121036c99325f518d75088ed1ac950f0c37df0bf064e781f957c71d8f37e59f10cf8351aeffffffff02a0860100000000001976a914344a0f48ca150ec2b903817660b9b68b13a6702688ac1be11200000000001976a9141c779cb2d3e6519d17fe1b8de8f7770765708ee888ac00000000

Decoded Transaction
{
    "addresses": [
        "mi7UWDi7iVB9GMXkRthjfTMv5UNybxmSJN",
        "mkHS9ne12qx9pS9VojpwU5xtRd4T7X7ZUt"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 250,
    "hash": "b43c7e23e58f40523555174f1d78147587729b5b320964b6157d5d737b60a510",
    "inputs": [
        {
            "addresses": [
                "mi7UWDi7iVB9GMXkRthjfTMv5UNybxmSJN"
            ],
            "age": 1977677,
            "output_index": 1,
            "output_value": 1337525,
            "prev_hash": "6c01d21db085639df8344ebe9d5f8ad964e287ff061fe9960e71235c19c7a730",
            "script": "00483045022100ae4b9bf764ecd9a54dd5cce1ff7092c6efda194789a632ebce0e5bc57f10e6d102207d3a1b68a3fb16c6ec86d74be2b825b298ce0c85dbbf05c5ed8084336c773dff01255121036c99325f518d75088ed1ac950f0c37df0bf064e781f957c71d8f37e59f10cf8351ae",
            "script_type": "pay-to-pubkey-hash",
            "sequence": 4294967295
        }
    ],
    "outputs": [
        {
            "addresses": [
                "mkHS9ne12qx9pS9VojpwU5xtRd4T7X7ZUt"
            ],
            "script": "76a914344a0f48ca150ec2b903817660b9b68b13a6702688ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 100000
        },
        {
            "addresses": [
                "mi7UWDi7iVB9GMXkRthjfTMv5UNybxmSJN"
            ],
            "script": "76a9141c779cb2d3e6519d17fe1b8de8f7770765708ee888ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 1237275
        }
    ],
    "preference": "low",
    "received": "2021-06-02T07:52:39.261650267Z",
    "relayed_by": "18.209.161.247",
    "size": 231,
    "total": 1337275,
    "ver": 2,
    "vin_sz": 1,
    "vout_sz": 2,
    "vsize": 231
}

Code
import * as bitcoin from 'bitcoinjs-lib';
import axios from 'axios';

const getAddress = async (node, network) => {
    return bitcoin.payments.p2pkh({ pubkey: node.publicKey, network }).address;
}

class BTCIntegration {
    #axios;
    constructor() {
        this.#axios = axios.create({
            baseURL: 'https://blockstream.info/testnet/api',
        })
    }

    async sendFunds(destination, amount, speed, wif) {
        const network = bitcoin.networks.testnet;
        const key = bitcoin.ECPair.fromWIF(wif, network);
        const fee = 250;
        const send = (amount * 100000000);
        const total = send + fee;
        const address = await getAddress(key, network);
        const txb = new bitcoin.Psbt({network});
        let txs = [];
        try {
            const {data} = await this.#axios.get(`/address/${address}/utxo`);
            txs = await Promise.all(data.filter((v) => {
                return (v.status.confirmed == true)
            }).map(async (v) => {
                const txr = await this.#axios.get(`/tx/${v.txid}/hex`);
                v.hex = txr.data;
                return v;
            }));
        }
        catch (err) {
            throw new Error('errors.unableToFetchAvailableFunds');
        }
        let input = 0;
        let available = 0;
        for (let i = 0; i < txs.length; i++) {
            const tx = txs[i];
            available += tx.value;
            if (input < send) {
                const pubkeys = [key.publicKey].map(hex => Buffer.from(hex, 'hex'));
                const p2shObj = bitcoin.payments.p2sh({ redeem: bitcoin.payments.p2ms({ m: 1, pubkeys, network })});
                const redeemScript = p2shObj.redeem.output;
                txb.addInput({
                    hash: tx.txid,
                    index: tx.vout,
                    nonWitnessUtxo: Buffer.from(tx.hex, 'hex'),
                    redeemScript,
                });
                input += tx.value;
            }
        }
        const change = input - total;
        if (send > available) {
            throw new Error('errors.insufficientFunds');
        }
        txb.addOutput({
            address: destination,
            value: send,
        });
        if (change > 0) {
            txb.addOutput({
                address,
                value: change,
            });
        }
        txb.signInput(0, key);
        txb.validateSignaturesOfAllInputs();
        txb.finalizeAllInputs();
        const ftx = txb.extractTransaction();
        const hex = ftx.toHex();

        let debug = '';
        debug += 'WIF: ' + wif + "\n";
        debug += 'Public: ' + Buffer.from(key.publicKey).toString('hex') + "\n";
        debug += 'Private: ' + Buffer.from(key.privateKey).toString('hex') + "\n";
        debug += 'THex: ' + hex + "\n";
        console.log(debug);

        try {
            const {data} = await this.#axios.post('/tx', hex);
            console.log(data);
        }
        catch (error) {
            if (error.response) {
                console.log('Err: ' + error.response.data)
                throw new Error(error.response.data);
            }
            console.error(error);
            throw new Error('errors.unableToSend');
        }
    }
}

export default BTCIntegration;

Where have I gone wrong?
I suspect that my issue is probably related to this:
const pubkeys = [key.publicKey].map(hex => Buffer.from(hex, 'hex'));
const p2shObj = bitcoin.payments.p2sh({ redeem: bitcoin.payments.p2ms({ m: 1, pubkeys, network })});
const redeemScript = p2shObj.redeem.output;
txb.addInput({
    hash: tx.txid,
    index: tx.vout,
    nonWitnessUtxo: Buffer.from(tx.hex, 'hex'),
    redeemScript,
});

But I honestly have no idea what I'm doing at this point.

You are spending a P2PKH output but the signature you've provided is for spending a P2SH output.

Thanks. That actually helped me quite a bit.


text:
Is it possible to import a LN snapshot into the regtest network (possibly pruned version)?
I am currently writing a bachelor thesis where I plan to conduct some experiments on regtest network to evaluate how effective a particular rebalancing algorithm performs compared to currently used rebalancing solutions. Previously, during the research phase, I had in mind to run it on the testnet, but then I realized that it wouldn't make a lot of sense because of unfair circumstances (I would not be able to rebalance on the same network/graph states). This led me to the idea of using regtest to be able to simulate and experiment with networks under the same conditions. But this is not a perfect environment either, as it is a sandbox environment, and I have to monitor the state of the whole network myself. I use the regtest workbench and it makes my job a lot easier in many ways, but now I'm faced with an important question, the answer to which would help me bring my local network closer to the real setup. Namely, is there any way to import a lightning network snapshot into the regtest local network?
As far as I understand, this question has already been answered here, but perhaps something has changed.
Do you think I have taken the right approach to do the needed experiments? I would like to play with my rebalancing method on testnet as well, but as I see it now, I would not be able to draw any conclusions as I would not have a comparative factor. In that case, I don't see any contribution a bachelor's work could have made. Maybe you could advise something useful for this vector of work in the context of the libraries and projects?
Thanks in advance for the answers!

The short answer is no. It is not and will never be possible to start a regtest emulating the live lightning network one to one.
Take for example the node_id that each node has in the network. It is the public key to a corresponding private key that only the operator of that node knows, and much of our protocols rely on being able to either prove that you are a given node (signatures) or be able to establish confidential communication with that node. So your network will have to differ when it comes to node_ids. Furthermore transactions that fund channels on the mainnet also use signatures to prove ownership, and there is little point in replicating 100M transactions on regtest (which btw has different block intervals and subsidies) to get the exact same short_channel_ids used to refer to channels.
That being said, you can get close, if you're ok with having a mapping of regtest_node_id -> mainnet_node_id and the same for short_channel_ids. So structurally replicating the network to perform experiments on the network is possible, but you might need tooling to help.
That is for the visible part of the network, but keep in mind that not all the network participants announce their channels and nodes, so be sure that whatever you want to test mainly considers the core routing network and doesn't rely heavily on endpoint behavior.
One last thing: emulating the real network is but the first step, you'll also have to characterise how nodes behave (who initiates a payment to whom at what time?). That will likely be a major part of your research as imbalances that you try to compensate by looking into rebalancing strategies is essentially what you want to simulate, and that's where user behavior as well as higher level concepts such as source-subgraphs and sink-subgraphs come into play. Simple assumptions (e.g., all-pairs equal source-destination) may help you here, but be sure to point out this assumption explicitly so people don't try to transfer the result to cases where this assumption is not true.

Thank you very much for your reply! I was expecting that response and now see the big picture better. I also understand the importance of having assumptions to limit the range of my conclusions and their correctness. But could you specify what exactly you mean by all-pairs equal source destination? Do you suggest considering only zero-hop payments?

It essentially just means that to simulate a payment you pick a random sender and a random recipient out of all the nodes in the network. It's the least specific assumption you can make, and likely wrong, but a good approximation given that we don't really know if and where clusters of senders / recipients are on the network. This can (and should) be refined as we learn more about user behavior on the network.


text:
Private key (hex) from public key
Guys who know how to get private key (hex) if I know public key (hex) ?Thx for support

One of the core principle of bitcoin security is to hide the private key from the public key.

It is practically impossible. The idea of a public/private key pair is that you can publish your public key without anyone being able to efficiently deduce your private key from it. That's why you can only spend bitcoin from addresses that you have the private key for.
There are two ways that come to my mind how to obtain a private key given the public key, however both are (currently) unfeasible:

Brute force: generate random private keys and test if they are by chance the one private keys for your public key. But this process will take unimaginably long.
Shor's algorithm: which is a quantum computer algorithm for integer factorization that allows you to calculate the private key given the public key, however we don't have quantum computers with the required number of qubits yet.

The most practical algorithm on traditional (non-quantum) hardware is Pollard's Rho for Discrete Logarithms. It only needs ~2^128 group operations to find the private key on average, while brute force needs ~2^256: https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm_for_logarithms


text:
Bitcoin transaction stuck
I sent a bitcoin transaction and after sending it I realized that the fee was too low.
https://www.blockchain.com/btc/tx/a398c4a2db165bd35435e381a6d185a14aa7a3df40aeca157dd89e4efd2e20d1
in an attempt to correct it, later on, I sent another transaction to the same address with a higher fee.
https://www.blockchain.com/btc/tx/92b33d498a35d47f03eee14f258cf9b3f015a5d12856eb05e47534e664344239
as I read about Child pays for Parent, but still it didn't work. The second transaction went through and the first one is still there. Did I do something wrong? Is there anything I can do to correct it?

A child pays for parent (CPFP) transaction is based on the assumption that the child actually spends the output created by the first transaction.
In your case, your second transaction does not actually spend the output of the first transaction - this allows it to be confirmed without any relation to the previous one.
That said, your fee is not so low that it will never confirm - transactions with that feerate are cleared out every day or two, usually. You will likely be fine if you just wait.
If you are in a hurry, you can use your wallet to make another transaction spending the unconfirmed output - note that this is not an option if the address you sent the coins to belongs to an exchange or hosted wallet where you cannot control which outputs/keys are used for a new transaction.

I see, so basically, I just spent unnecessary fee money in the second transaction lol. Thank you!


text:
HELP BITCOIN SENT CONFIRMED BUT I NEVER RECIEVED BEEN 2 DAYS
help im not sure what to do i sent from Pax, bitcoin like i have done many times and it shows up as confirmed, but yet i dont see it at all heres the id 7581e42bf71df4b81fdb233542f3e0baeddeb60bd5e11361b1f8cb7ccb3553a5
is anyone able to help me recover this? or is it gone for good?

What do you mean "I don't see it"?  Where do you not see it?

BITCOIN SENT CONFIRMED BUT I NEVER RECIEVED BEEN 2 DAYS

In reality Bitcoins are not actually sent or received. Those are not two separate events. They both really refer to the same event. If the Blockchain shows unspent bitcoins (unspent transaction outputs) associated with an address you control, you have "received" them - regardless of what your wallet says. This is easily checked using a blockchain explorer

heres the id 7581e42bf71df4b81fdb233542f3e0baeddeb60bd5e11361b1f8cb7ccb3553a5

That transaction currently has 450 confirmations. It also has 12 inputs and 52 outputs. Presumably Pax have batched up their customer transactions and one of those 52 outputs is an address you gave to "Pax" (Paxful.com?).
If that address was generated by a desktop or mobile wallet, it's failure to show the amount expected could be due to a number of reasons - for example maybe it isn't fully synchronised for some reason?

is anyone able to help me recover this?

Only the person or organisation who has the private keys from which the relevant output "address" was generated. Normally that would be you alone.
It may be that this isn't a question of "recovery" in the sense of recovering money transmitted somewhere. Perhaps you just need help finding out why your wallet doesn't show the expected amount associated with the relevant receiving address you gave "Pax". That would be a different question and depends on what wallet you use.

is it gone for good?

The transaction is final. If you know who "received" the output in question, you can ask them for help. You could start with "Pax"


text:
Seed Phrase checksum
I have a program that I'm working on, in plain old-fashioned C, where I get the user to flip a coin 128 times. This provides my 128 bits to run through SHA256.  The first byte of that hash (leftmost character?) should convert back to binary and append to the initial entropy.  This will provide 132 bits to form the 12 seed words.  But the last word is never right.  Something is wrong with my logic.  Can somebody please spot it and let me know what I need to do??  Here is an example.  Say the user flipped heads 128 times.  That would be 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111.  When I run that through the hash, I get 5ac6a5945f16500911219129984ba8b387a06f24fe383ce4e81a73294065461b.  The first (leftmost) character is a hex '5' so I convert that back to binary and get 0101.  That makes the now 132 bits 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110101.  That should give me a seed phrase of "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrist" but that is not right.  Ian Coleman's web page says the correct answer is not "wrist" and Sparrow Wallet says "wrist" is not a valid checksum.  Where have I swerved off the road?

Your last word is wrong (pun intended)
Everything is correct, except you took the wrong word for 11111110101 (2037). Remember bip39 words list starts with 0, but normally lists are presented starting with 1, so you must compensate.
zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong

Wow, I would not have thunk that.  Since the index starts at zero and the list starts at one, I knew I had to shift the answer by one.  I just went the wrong direction.  It still is not obvious.  But I was so WRONG lol.  Thanks.


text:
GREP help: Bitcoin address/key buried as text somewhere on hdd
So in a drunken moment of genius I had forgotten about, I bought some bitcoin way back.  And I buried the address and key in some file... I was being tricky lol. That likely also led me to abandon a wallet.dat completely.

I'm learning to use grep to hunt it down, but the one time I know I got it to work, it returned TONS of files.

I know the address starts with 1F or.. f .. or D.. or d, maybe E/e lol.  But one of those.  The original parameters from stackoverflow for finding the address are:
[^13][a-km-zA-HJ-NP-Z1-9]{25,34}$.
I've attempted to adjust it to remove the 3 and have been attempting to add the first letter, but I'm trying a grep search with each and as I see no results after 20-30 minutes, I just ctrl-c the thing.

I'm trying

I removed the ^ and $ from the ends after when I realized that there is no reason to think it's at the beginning or end of a line (if I properly understand what that even means).
The search area is for where I've recovered the files from these drives to, I'm hoping my "genius" drunken drive mapping attempts and subconscious file preservation impulse kept the file(s) from being overwritten.
Any help would be very appreciated, thank you.

[^13][a-km-zA-HJ-NP-Z1-9]{25,34}$.

...

I removed the ^ and $ from the ends after when I realized that there is no reason to think it's at the beginning or end of a line ...

As you noted, the trailing dollar sign ($) anchors the search expression to an end-of-line (e.g. LF on Linux) - you probably do not want to do that.
However the [^13] does not anchor the search to start of line, inside square-brackets, the caret ^ means not. So [^13] means look for a string whose first 8-bit character is not a 1 nor a 3. It would match strings that begin with any other character - that is probably not what you want. If you want a string that begins with a 1 or a 3 just use [13]. If you wanted to anchor that to the start of a line you'd use ^[13] not [^13].

... (if I properly understand what that even means).

The expression ^[13][a-zA-Z0-9]{25,34} matches these lines:
1234567890123456789012345 is my secret code
3aklsdjlajkjvcnbxuxcjvhhkjhgtresds

where the 1 or 3 immediately follow a prior LF character (or are the first character in a file).
but does not match either of
my secret code is 1234567890123456789012345
    3aklsdjlajkjvcnbxuxcjvhhkjhgtresds


text:
How to check a signature on an arbitrary message?
I'm looking to have a p2sh transaction that inside the redeem script there is OP_CHECKSIG (or any other op-code) that verifies a signature on an arbitrary message (not a transaction).
I have been looking, but all I could find is that OP_CHECKSIG only verifies signatures on transaction. I need a signature verification that I'm able to give the message (hash of message) to the verification procedure.
Something similar to ecrecover that takes in a signature, verificationKey and the message. Is this even possible using the existing op-codes?

No, this is not possible. There are no opcodes that allow you to check a signature on an arbitrary message.

Is there any BIP for this? Do you know of any fork that has done this?
I don't need it to be in production, I'm doing a research project that I'm fine with having it locally. Thanks


text:
How to monitor specific derived addresses from xpub
I've exported my xpub from bluewallet and generated a few derived addresses from it using invoice numbers as derivation indexes. Then I sent a few sats to one of those address as a test. As I'm new learning this technology, I got surprised because the wallet didn't show the balance. I made a small research and realized that the wallet doesn't monitor all the addresses derived from my xpub, it only tracks incoming transactions for 20 addresses by default.
Said that I have a few questions:
1- To maintain a record of the real balance, should I request a Bitcoin/API node asking for info related to each derived addresses?
2- There's any wallet I can use to monitor specific derived addresses and allows me to spend that balance?
3- How can I spend that balance without a wallet or compromising my seed?
Context: I'm learning how to process Bitcoin payments with nodejs.
Thanks so much in advance!

How can I import a specific address?

I have spent many hours learning about this and now I have the answers for all my questions.
1- To maintain a real balance of how many sats I have, I needed to make calls to an API as I'm not running a full Bitcoin node. The API requires an address and gives you UTXOs for each address (Unspent transactions outputs). I had to collect all the addresses, make an API call for each address, and sum the value of all those UTXOs to obtain my real balance.
2- At the moment I haven't found a wallet that monitor a large number of addresses. In my case addresses are derived using invoice numbers as derivation index. Just imagine that a client that make a purchase in my website generates the order_id number 2567, this means that if he/she chooses to pay with Bitcoin I will use BIP84 to generate an address from my extended public key using 2567 as derivation index. So the wallet should be able to monitor thousands of addresses, and I haven't seen that so far.
3- Finally, without a wallet to monitor all the required address and spend sats received on them, I had to learn how to create PSBT by myself. That allows me to use specific addresses as inputs, outputs, define optimum fees based in the Blockchain information and also define a new address to receive change. And the most important, I can create this PSTB offline and sign it without compromising my private keys, and then just broadcast the transition hex.
All these three points may be obvious for many devs here, but I'm a newbie so I'm very happy to learn new things and answer my own questions...


text:
Preventing workers bad behavior
In a mining pool where rewards are distributed according to the fraction of hashrate contributed to the pool, could a miner misbehave trying cheating in some way? And are there strategies to prevent this?
I can think of one example:
Bad behavior 1
A miner with 1TH/s could pretend to be mining at 2TH/s by sending to the pool at regular time intervals the block headers (here I am not sure what the miner actually sends to the pool if the header or just the nonce) he is discovering plus a bunch of other headers already found in previous iterations.
Solution 1
This behavior does not affect the the ability of the pool to mine a block, but just inflates the reward of the bad miner, basically stealing from the other miners' share. It can be prevented if the pool keeps a lookup table of the block hashes coming from each miner and check for repeated blocks, though this seems like overkill and too expensive. Another solution could be enforcing that the miner sends the block solutions in an increasing order of the nonces, that's would be easy to verify and no repeated blocks are possible.

From How is the network hash rate calculated? we can see that we can calculate the applied hashrate of an entity from the network difficulty and the number of blocks produced in a specific period (e.g. in a day). The entity in the linked question is the whole bitcoin network but the method can be applied to a single node. The entity cannot fake this hashrate because they have to present sufficient blocks with hashes less than the required target.
In any reasonable measurement period (e.g. a day), a typical pool member will not produce any hashes at the current Bitcoin network target. But if the pool asks the members to present blocks with hashes less than an easier target, every period the member will be able to produce many blocks meeting that easier target. The pool operator can therefore measure contributed hashrate. As you pointed out, the pool operator has to check that hashes are not repeated. To prevent collusion each pool member would need to include a unique marker in their template so that the pool operator can check.
Note that the method used by the pool member to mine blocks is completely independent of target, so they do exactly the same process for an easier target that they do for a harder target. So occasionally, one of the blocks with a hash lower than the pool's target will also be lower than the Bitcoin network target. This pays to the pool operator who can distribute the money according to contributed hashrate as measured at the pool target.

If the pool didn't keep a lookup table of every outstanding bit of work it offered to miners, it couldn't submit the complete block if the miner successfully found a block header. So mining pools must already keep track of all outstanding work units they've given to miners for as long as they are willing to accept shares for those work units.

I don't understand what exactly the pool is keeping on a lookup table.

@Lagrange.el.Ciencia The blocks that it asked the miners to mine. It needs a different one for each work unit it gives out or all miners would be repeating the same computations.

Not the entire block, at least the block header, or just the fields in the header that are used to change the block hash.

@Lagrange.el.Ciencia If it doesn't store the entire block, it cannot submit the block to the network if the block is successfully mined. So it must store the entire block. The blocks must be different or the miners will all be doing the same work.


text:
How to run Bitcoin Core and what folders to move to my second VM after having it successfully running on my first VM?
I've Bitcoin Core v22.0 running smoothly on my first VM.
Now I want to have Bitcoin Core up and running on my second VM but without syncing the blockchain from scratch as I did with the first VM to save bandwidth.
So what files/folders should I move to the second VM and after moving those files/folders, what shall I do after I install Bitcoin Core?
The two VMs are running Linux Mint 20.3
Thank you.


text:
Softening the 2106 hard fork
Following along the 2106 problem solution proposed in Will a hard fork be required to change timestamp fields? …
Is it possible to start including this logic into newer versions of core (is it already there?), or will this need to be a simultaneous upgrade by everyone?

Duplicate of https://bitcoin.stackexchange.com/questions/106783/will-a-hard-fork-be-required-to-change-timestamp-fields

That proposed solution is only one possible solution. There might be better ways to solve this problem, and Nate Eldredge comments below this answer that a solution might not be needed at all.
Realistically, it's completely fine to ignore this problem until say the year 2096. 10 years is more than enough for the community to agree on a solution and schedule a fork. There are more immediate issues requiring community attention for now.

Nate's comment ignores the need for timestamps in OP_CTLV. And 10 years sounds like plenty of time, but we should learn from rolling out IPv6 that you are probably drastically underestimating the time needed to upgrade a global network.


text:
Bitcoin Core Blockchain Sync Fatal Internal Error - Corrupt Block - Linux
I'm trying to perform the IBD on Bitcoin Core 0.18 and I continually receive "Fatal Internal Error" at seemingly random intervals, closing bitcoin-qt and preventing me from fully syncing.  Farthest I've gotten so far has been 5% after hours of trying and reindexing.  I might make it to 6 years back if I'm lucky, once to 5 years, but my luck has never held out any longer.  Attempts to reindex result in the sync rewinding to about 8 years back, representing <1% of the entire download.  I'm at my wits end.
The error I'm receiving in the debug.log is:
2019-07-22T00:14:07Z Error: Error: A fatal internal error occurred, see debug.log for details
2019-07-22T00:19:17Z ERROR: ConnectTip: ConnectBlock 0000000000000af5808c422d13a9bd6580e72a9db9a543336cb6834c9db75a40 failed, bad-txnmrklroot, hashMerkleRoot mismatch (code 16)
2019-07-22T00:19:17Z ERROR: ProcessNewBlock: ActivateBestChain failed (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))
2019-07-22T00:19:17Z *** Corrupt block found indicating potential hardware failure; shutting down
I don't know what's causing the corruption.  I've tested my hardware and everything checks out fine.  I ran badblocks on the SSD, memtester on the RAM, and monitored the CPU core temps during the sync--a constant, frosty 35 degrees C.  My OS is completely up-to-date.  There's nothing obviously wrong with this system and the hardware exceeds requirements.
What could be going on here?  And is there any hope that I can actually get this node setup or am I out-of-luck?
System Specs:
Bitcoin Core 0.18
OS:  Linux Mint
CPU: i5-8500 4.1GHz
1TB SSD
8GB RAM


text:
I started build my own blockchain based on mastering bitcoin book using git on win7 and i have a problem
I started learning how to build a blockchain from Antonopoulos book using Git Bash and i have a problem.
I used commands:
 git clone github.com/bitcoin/bitcoin.git
cd bitcoin
git tag
git checkout v0.11.2
and when i try to use command ./autogen.sh
on the screen appear information:
./autogen.sh: line 9: autoreconf: command not found.
Where is the problem? What i do wrong? i need some libraries?

I believe you have the same problem reported in the link bellow:
https://askubuntu.com/a/490839
Just try to install autoconf. The autoreconf come with it:
sudo apt-get install autoconf

But i have to install ubuntu? cannot do on windows?

Sorry Norbert, I didn't pay attention to the picture with Windows. Actually you are executing Linux tools, but these tools came with MinGW. In this case you are using the MinGW provided by Git that don't have autoconf. Try to download and install a new copy of MinGW and chose the packages that you need. Then you can open the new MinGW and try to compile again. If you still have problems, an alternative to MinGW is Cygwin.


text:
Parse the output field of getrawtransaction to generate a common address hash
Consider the following coinbase transaction:
https://www.blockchain.com/btc/tx/d70ae1131d433b655d0faeae1db4efa15bb4138f1e38e60a53073a58ea1dcc34
How we can retrieve the recipient address, i.e. 1JAL1WRvwbJqWWd1Ktks4Q89zCeUYSQM12 using the output field of the RPC command below:
bitcoin-cli getrawtransaction d70ae1131d433b655d0faeae1db4efa15bb4138f1e38e60a53073a58ea1dcc34 1

"vout": [
    {
      "value": 50.12000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0400d0ade32217e076945e0946ef7bed72d9aea035aa8891e4bf0749ae6e24f8a7d3ea56efafe472ac3943dbed3af7c093729720ac9ab04e8eba09286e3a00fe41 OP_CHECKSIG",
        "hex": "410400d0ade32217e076945e0946ef7bed72d9aea035aa8891e4bf0749ae6e24f8a7d3ea56efafe472ac3943dbed3af7c093729720ac9ab04e8eba09286e3a00fe41ac",
        "type": "pubkey"
      }
    }
  ],

For non-coinbase transactions, the output filed contains the value of addresses.
bitcoin-cli getrawtransaction bd20f46a4337ab787f6fbd036e9f4d65c7ae67d21cc6f9013162e783384d877c 1

"vout": [
    {
      "value": 1.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 53c32617316707bb8ba4e1546fa8c32bd212c86d OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91453c32617316707bb8ba4e1546fa8c32bd212c86d88ac",
        "address": "18dts6fXXA7jVKfYMBpsFqx7iZCELCfDpk",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 58.97000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 37fdd890381f9965d620fc3d0c9fa3e511cb1449 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91437fdd890381f9965d620fc3d0c9fa3e511cb144988ac",
        "address": "1674G5SSZAb7h4unJMjdxfgNwo71vxgGQg",
        "type": "pubkeyhash"
      }
    }
  ],

Observe that the type of the output is:

"type": "pubkey"

Pay-to-Public-Key (P2PK) outputs do not have addresses. They pay directly to a public key rather than the hash of the public key, as the name suggests. Bitcoin addresses encode public key hashes, for example, addresses starting with a 1 are known as Pay-to-Public-Key-Hash (P2PKH) addresses and encode the Ripemd-160(sha-256(public key)).
See my other answer here for the same sort of question.

Thank you for your answer. I'll follow the steps provided in the wiki to see how services like blockchain.com or blockchair.com pull out such addresses.


text:
Is there no Gmail required to receive Bitcoin payment from another company?
I don't fully understand how to receive payment, there is no Gmail address space, how can I get my address for business transaction, I mean which address will I use to receive payment?

I have no idea what you're trying to ask about. Which service are you talking about? What does gmail have to do with anything?

To receive Bitcoin, you don't need a Gmail address or any sort of email address.
What you need is a large random looking number called a Bitcoin-address. This number can be produced from another large number that is kept secret by you and is called a private-key. You can create these numbers using any of many different software programs called Bitcoin wallets.
See I am new to Bitcoin, how can I get started?


text:
Lightning protocol modification for app
I'm currently building a Lightning platform for online sellers. I have found that timing can be very problematic: For example, two people want to buy the last item in stock or a unique item like a particular watch. Both proceed to checkout and receive a Lightning invoice. If both pay, the seller would have the problem to reimburse one buyer. Would it be possible for the buyers to receive a refund "automatically" at the protocol level? Or better yet, would it be possible to condition the sale of an item on only one buyer winning (e.g. by using some tweaked hash(preimage), or something like that)?
Would it be possible in any way to implement (minor) Lightning protocol changes within a Lightning subnetwork if necessary? If my platform is an app with a Lightning node itself, then I could imagine that people using this app could live in this bubble with the modified protocol, or will it be a big hassle for me to implement something like this? (I want users to create payment channels and participate in the Lightning network - at least after the purchase of an item has been properly settled!)

I don't see why it needs to be at protocol level. Your node can simply not solve the second HTLC that arrives, you can keep track of items and possible conflicts when solving it. If you fail the HTLC, then no money is transferred and no refund is needed, this is relatively easy to do with any current implementation.

Also, this problem is not unique to Lightning, but rather an artifact of the checkout process.


text:
Pay invoice to offline lightning node
I wonder if there is a way to force a refund. Let's say A makes a payment to B. Later, B finds that he has to refund A, but A is offline. Can B reverse this payment while A is offline?
Could it be a solution for A to create an invoice when paying B, which B can pay later when A is offline?

It seems you are mixing two concepts in your question.
1.) the necessity of having an invoice
2.) the necessity of being online
Re1: invoices are not necessary with the not standardized keysend feature or the soon to be standardized BOLT 12 offers. Offers are specifically designed having refunds in mind as the also provide anonymous payer proofs which currently in lightning do not exist
Re2: both techniques in 1 still require both nodes to be online at the time a payment / refund is being conducted. That is just the nature of the protocol and there seems to be little we can do about it.


text:
Integrity of Bitcoin transaction outputs
I am a noob. Currently, I am reading Mastering Bitcoin book. If I understand correctly, output of a bitcoin transaction is just a locking script with this format:
scriptPubKey: "OP_DUP OP_HASH160 (PubKHash of reciever) OP_EQUALVERIFY OP_CHECKSIG"

My Question is: What prevents miners from modifying PubKHash section of the above script and changing it to their addresses and stealing bitcoins from sender?

The outputs of a transaction are signed by the inputs. Changing the outputs would cause it to become invalid, and it would not be able to be included in a valid block.


text:
A little help Mining software libraries
Are there any secure libraries in C/C++ or Python that can allow to get unconfirmed transactions, get block templates, create a block header, help check the structure of block, publish the block after its mined, see if it was mined successfully and receive the mining reward if the mining was successful in a preexisting online wallet or local wallet.
From whatever I am reading we need bitcoin core but it requires 400 GB download (bandwidth issue not storage). And I am failing to understand why we absolutely need it if we are just mining and publishing the whole block. Why can't we use libraries that use RPCs or have the data (like format etc) in them as we don't need a full client, block list or node for it. These tasks seem relatively simpler.
The mining of the header (the core of it as I understand is guessing the nonce) could be done separately by the user as solo (we don't need to worry about it). The rest of the process is what we are concerned about.
My environment is windows 32 bit.
I am new to bitcoins thus need some help as I am lost on this.
P.S. I am not trying to make profit and under no illusion that the problem is easy. So we don't need to worry about that. Just that failing to find the appropriate libraries/SW.

Are there any secure libraries in C/C++ or Python ...

https://developer.bitcoin.org/devguide/mining.html says

Resources: The GPLv3 BFGMiner mining software and AGPLv3 Eloipool mining pool software are widely-used among miners and pools. The libblkmaker C library and python-blkmaker library, both MIT licensed, can interpret GetBlockTemplate for your programs.