text:
How did Satoshi Nakamoto mine 50 bitcoins by creating genesis block? And where can I see blockchain?
According to bitcoin.org, mining is referred to as 'the process of spending computing power to process transactions, secure the network, and keep everyone in the system synchronized together'.
First, I browsed the wiki to figure out how SN created the genesis block to earn bitcoin. It said he published the Bitcoin Core software, used it to create genesis block and was rewarded with 50 bitcoins.
According to bitcoin.org, how did he literally mine bitcoin, while at that moment there was no
transaction between peers by bitcoins? Did SN verify any transaction when he created genesis block? I think it's a contradiction.
Besides… I want to know the reality of blockchain. People say it's a public ledger—so where can I see that public ledger, and check whether every transaction is recorded on every computer? Is there any website for that?

The blockchain is the shared journal of all transactions on the network. Mining is the process which authors new blocks to extend the blockchain. Miners do not need unconfirmed transactions to create a block, but they earn transaction fees from including them. The only transaction in a block that is required by the protocol is the coinbase transaction. (We refer to blocks that only have a coinbase transaction as empty blocks.) As the difficulty regulates the interval, mining acts as a distributed lottery to elect a block author about every ten minutes. As a reward for the expended work, the lucky miner collects the transaction fees of the included transactions and creates some new bitcoins for themselves. The long interval between blocks gives other network participants time to catch up to the new chaintip and converge on a shared truth.

First, I browsed the wiki to figure out how SN created the genesis
block to earn bitcoin. It said he published the Bitcoin Core software,
used it to create genesis block and was rewarded with 50 bitcoins.

The order of these events is mixed up. The Genesis Block was created before the Bitcoin software was published. Each block points at the previous block. Block 3 points at Block 2. Block 2 points at Block 1. Block 1 points at the Genesis Block. This forms the blockchain.
GB ⇐ 1 ⇐ 2 ⇐ … ⇐ 719935

The Genesis Block is special because there was no previous block. The Genesis Block was created to define the starting point of the network. The first release of Bitcoin included the Genesis Block to make all nodes agree on the starting point!
However, the Genesis Block includes the headline of a newspaper from that day. This proves that the Genesis Block couldn't have been created before the newspaper got published, which was only a few days before the software was released. Satoshi Nakamoto did not create any money for himself with the Genesis Block, because the output of the Genesis Block cannot be spent. Since the Genesis Block is hard-coded as the starting point (for the first block to have a previous block), every new node already knows about the Genesis Block, and they do not read the Genesis Block like other blocks. Because nodes do not read the Genesis Block normally, they don't notice the money the Genesis Block created. The first block that is new to Bitcoin nodes is Block 1. The first spendable money was created with Block 1, because the first transaction that nodes process is the transaction in Block 1.
Even empty blocks provide proof-of-work and secure the network.

Where can I see that public ledger?

You can acquire your own copy of the blockchain by running the Bitcoin software, or browse one of many blockchain explorer websites such as e.g. mempool.space, blockstream.info, or blockchair.com.

One block may contain one or more transactions, the only required is called "coinbase" and is the very first one. Coinbase's transaction pays the miner's reward (fee + subsidy), and is required.
If a block contains only a coinbase transaction, it's called an empty block, and it's totally fine.
There are plenty of sites where you can see all bitcoin's transactions in this “public ledger”, it's called block explorer. Here, you can see Bitcoin's genesis block, which only contains the newly minted coins.


text:
Who first started to name 'blockchain technology' as 'blockchain'
I read through the whitepaper of Satoshi Nakamoto.
I could find the expression 'blocks are chained...' but he did not specifically use the word 'blockchain' itself.
I want to know the origin of the term blockchain....
Thank you.

The first use of the phrase "block chain" was by Hal Finney in his response to Satoshi's email with the whitepaper. Over time, the two words have been combined into the single word "blockchain".

thank you veryyy much professor

source: Stack Exchange

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

sort: votes


text:
I have all 12 phrase words, but can't figure out the order of the last six words. What do I do?
I'm trying to recover my Trust Wallet account. I have all 12 words of my phrase. For 6 of them I strongly believe that I know the right order but the remaining 6 words are completely random. Is there a way I can figure out the order of the remaining 6 words?

Was there a particular reason why you added the tag [trust-wallet]?

yes cause its the passphrase for a trust wallet account

I see, that wasn't apparent from the question's previous phrasing. I've added a mention of this and the tag to the question.

There are only 720 (6!) possible ways to order six words, so you could write a script that generates them all and then checks whether there are any transactions associated with any.
As @meshcollider pointed out in a comment, you could then use the 4-bit checksum that mnemonic seeds include to reduce this set of possible combinations even further to about 45 seeds for which you'd need to check the addresses.

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


text:
Upgrading Bitcoin Core from very old version
Running a full Bitcoin node since 2013 but current version is 0.13.1.
Can I install version 0.20 directly without going through all the intermediate upgrades?

Yes, Bitcoin Core is designed so that version 0.20 could be installed directly after 0.13.1. There isn't "going through all the intermediate upgrades" necessary.
Besides, it is even not necessary to uninstall or overwrite 0.13.1. There could be 2 versions installed next to each other. It would probably be safer to configure a separate data directory (blockchain, wallet, config data storage locations or "datadir") to be used by new version.
The best practice is to backup data first before modyfing anything (by default the data are stored in "%UserProfile%\AppData\Roaming\Bitcoin" in Windows).

Yeah, definitely do not run two installations from one directory. Especially make a backup of the wallet.dat before attempting to install the newer version.


text:
Why is my raw transaction not valid?
For educational purposes and better understanding of bitcoin script, I try to broadcast this transaction:
01000000 -> version

01 -> 1 input

0410a792656db6b10c28f2ded1a21f0cdf7cf31200b5a0179b5a254e325438b2 -> input hash

00000000 -> input index

8a -> sigscript lenght

4730440220460e5bf8a20995a4323c573c2428272d4c5738a35ac99def37813f1d752591cd022000c09914c6ec5cf9cbcba8228ea46583ec856d43da5fcc85b8fea8a1227763ec014104292959febef0a3c9ac140cb5a013f174f85a7978838890b196de3028fab725ed1a95cc9f26365f8665d6bbc9619b3f9f06695b4ce45f691b93f57a9f07e28849 -> sigscript

ffffffff - sequence

02 -> 2 output

0100000000000000 - > 1 sat

04 -> 4 bytes long

87021111 -> OP_EQUAL 0X1111

1819000000000000 -> 6424 sat

19 -> 25 bytes long

76a9145294db2204c27889dd9b7b88ff30cff6c40a62d788ac
-> OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG

00000000 -> timelock
01000000

I know the script of the 1st output is not standard (it's my purpose : OP_EQUAL 0X1111) but why is not valid?

note that your custom script is unspendable, as OP_EQUAL will push a 0 or a 1 and 0x1111 pushes 0x1111, you end up with 2 stack elements. (ending with 2 stack elements is not valid spend, segwit would be anyone can spend if this was the case)
transactions with outputs under the dust limit (1 sat definitely is) or nonstandard output scripts are nonstandard and will not be relayed

first i just figure out i might to invert OP_EQUAL and 0x1111 in my purpose (i want to can spend by "providing" only 0x1111 as a signature script so) 0x1111 + 0x1111 OP_EQUAL might work, right?

yes that will work

second, i was not knowing about dust limit, now its more clear!

maybe the testnet is a better place to try and learn bitcoin scripts, coins are free and nonstandard TXs are relayed there

by free i mean there are websites that give small amounts of free testcoins, just search 'bitcoin testnet faucet' on the internet

yes i know about testnet and faucets but i prefer to do it on mainnet, because on this case, maybe it will work on testnet, but not on the mainnet


text:
Why does a script length of 254 need three bytes?
I'm looking at some raw txs (P2SH in that case) for learning, and I have one question about a particular tx:
tx hash 0aeae24fa55544da49ba06ec338c9beee592ab4bea71eb8085908f377dd46084, i use this tool for analysis:
https://hashxp.org/0aeae24fa55544da49ba06ec338c9beee592ab4bea71eb8085908f377dd46084
I don't understand its script length (fd fe 00). The value is analysed as 254 by the tool. So, why is the script length stored as 3 bytes, but only uses the value of the second byte?
Does anyone know a paper about how to build a standard P2SH tx?

If we look at the network format of the input section of a transaction message we see

Field
Description
Size

Previous Transaction hash
doubled SHA256-hashed of a (previous) to-be-used > transaction
32 bytes

Previous Txout-index
non negative integer indexing an output of the to-> be-used transaction
4 bytes

Txin-script length
non negative integer VI = VarInt
1 - 9 bytes

Txin-script / scriptSig
Script
<in-script length>-many bytes

sequence_no
normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
4 bytes

So the Txin-script length is of type Varint.

Variable length integer
Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length. Longer numbers are encoded in little endian.

Value
Storage length
Format

< 0xFD
1
uint8_t

<= 0xFFFF
3
0xFD followed by the length as uint16_t

<= 0xFFFF FFFF
5
0xFE followed by the length as uint32_t

-
9
0xFF followed by the length as uint64_t

(my emphasis)
So for script-lengths longer than 0xfc and less than 0xffff the script-length is represented as a Varint with three bytes, the first byte of which must be 0xfd so that the format can be unambiguously differentiated from other lengths of Varint.

If the first byte we read is lower than 253 (0xFD) we know the Varint is one byte long and the value we just read is the length of the script.

If the first byte we read is 253 (0xFD) we know the Varint is three bytes long and we need to discard this byte and read the next two bytes as the length of the script.

Ditto 254 (0xFE), five bytes, next four.

Ditto 255 (0xFF), nine bytes, next eight.

So we can't represent a script length of 254 in a one-byte Varint because 254 (0xFE) is a special marker byte-value for a five-byte Varint. Instead of using a one-byte Varint, we have to go to the next size up of Varint - a three-byte Varint, and use it's special marker byte value to prefix a two-byte (Uint16_t) length value.
The endianness of the Uint16_t is why the first byte of the last two is the lowest part of the Uint16_t value. 254 is 0x00FE but in little-endian byte-order that is 0xFE00.

What this teaches us is that the developers of this network protocol prioritised compactness of message size over clarity and simplicity.
Given the prevalence of other protocols that take the opposite approach to message size (consider SMTP with XML payloads like DOCX etc or HTTP with HTML payloads) it must be debateable whether this was a necessary or good choice. Maybe a simpler, less confusing choice could have been used, optionally wrapped in a compression envelope. But the choice was made and I guess it is one that Bitcoin developers  must live with.

@cc1cc1: If RedGrittyBrick answered your question fully, you can accept his answer as the most helpful by clicking the checkmark.


text:
CLI tool like Bitcoin Explorer (bx) for BIP85? multisig?
Looking for a CLI tool like Bitcoin Explorer (bx) that will generate multiple seeds/mnemonics from a single entropy string, as per BIP85
Also one that allows for a decent  multisig scheme? Or if not an automated tool, maybe a recommendation for HowTo docs that are pretty well accepted?
Not worried at this point about transaction signing, but establishing good receiving address and cold storage opsec.
Let me know if these should actually be separate questions, they may just be intertwined in my brain only.

I extended my bitcoin bash tools library today to support bip-85.  You can check it out.
I don't have any support for multisig at the moment, though.

BTC HD Wallet is BIP85 compatible
Bitcoin wallet generator, supporting bip39 / bip32, bip44, bip49, bip84, slip132 (Multi-signature P2WSH in P2SH, Multi-signature P2WSH)
not established? verify everything
Looks very flexible

from-entropy-hex
from-mnemonic
from-master-xprv
from-bip39-seed

Wasabi import file format (inspired by ColdCard)
also create a watch only wallet from extended pub key
https://github.com/scgbckbone/btc-hd-wallet


text:
How can 6.10 ₿ be the average value of a Bitcoin transaction (lately)?
Number of Bitcoins sent in the last 24 hours: 1.84 million ₿.
Number of Bitcoin transactions in the last 24 hours: ~301,900.
This becomes on average 6.10 ₿ per transaction. That's shocking to me. Since I just started with this little "formula", I don't know how normal/unusual this is.
It sounds extremely strange. I would've guessed that 0.01 ₿ or something would be the most common amount. Not multiple Bitcoins at once. Certainly not 6.10 ₿ on average.
Is this an extreme 24 hours in that sense? Or is this normal?! Or has there been some really MASSIVE single one which skews the average for today grossly?

It might be interesting to look at the median as well as the arithmetic mean.

In other assets you can manipulate price by doing big realestate trades in a region to move up the price.

This is normal. Here you can see a chart of average transacted value every day: https://blockchair.com/bitcoin/charts/average-transaction-amount-btc
There are 2 things that contribute to this:

The very large transactions skewing the numbers. This becomes more apparent if you take a look at the median transaction values, which are around the 0.02-0.03 BTC range, closer to your expected value: https://blockchair.com/bitcoin/charts/median-transaction-amount-btc

The fact that many transactions aren't just sending money from one person to another person, but in most cases, includes change (sending money back to the sender's own wallet), and batched transactions (a single transaction that sends money to multiple people, often used by exchanges to process withdrawals while saving money on fees).


text:
A question about CPFP relaying policy
Let's say I broadcast a transaction tx0 signaling RBF replaceability. Later on, send another transaction tx1 that spends the same inputs of tx0, but this time with higher fees.
In this case, tx0 is removed from mempool right? so what if then I try to send a child transaction tx0child that forms a more profitable CPFP than tx1 alone? But without the context of removed parent (tx0) this CPFP cannot work then, although it's more profitable?

Correct. tx0 is removed, and tx0child is "invalid" because it spends a UTXO that does not exist in the current chain or mempool. This could change in the future with package RBF and package relay if tx0 + tx0child are submitted as a package.
In this scenario, if the goal for tx0child was to fee-bump the original payment and RBF is possible, it probably makes more sense to just create another RBF to replace tx1.


text:
How are public & private keys in an address created?
I understand the high level concept I am more interested specific details.   How is a private key generated.  How exactly is public key generated, how is address generated from public key.

The public and private keys in a Bitcoin address are a normal ECDSA key pair. I haven't poked through this particular bit of Bitcoin's own code but the offshoot products I've had a chance to work with typically use the Bouncy Castle crypto library. Bouncy Castle also has an excellent introduction/tutorial on how to use their library. Their examples are in Java but it's fairly simple and should be easily ported to other languages.
There is also an excellent pre-written library for JavaScript key generation available from Tom Wu under the BSD license.

As is normal when doing Elliptic Curve encryption, a private key is simply a random number. In the case of secp256k1, the elliptic curve used by Bitcoin, it has to be a number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336 (or in hexadecimal, between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140).
This private key is converted to a public key by performing an EC point multiplication with the curve's base point. The result is an (x,y) coordinate pair, which constitutes the public key.
Finally, RIPEMD160(SHA256(pubkey)), where pubkey is a serialization of those coordinates, is computed, and encoded in base58, together with a checksum. This becomes the address.

How did you determine this was the maximum value?  I'd like to learn both the right / wrong way so I can learn from your [edits] ;)

I copied it from https://en.bitcoin.it/wiki/Secp256k1, which itself copied it from the SEC2 specification document: http://www.secg.org/collateral/sec2_final.pdf

Updated link to SEC2 document http://www.secg.org/SEC2-Ver-1.0.pdf

Are either of those two steps reversible?

No, they're not (as long as ECDLP is hard).

Bitcoin private keys are most commonly displayed in wallet import format (WIF), also known as base58check (a number expressed in base 58 with a checksum at the end and a version byte at the beginning).
To create a WIF private key, you need to:

Generate an ECDSA secret exponent (the private key) using the SECP256k1 curve.
Convert the secret exponent/private key into base58check format.

Here are two simple ways to generate a secret exponent:

Select a random number in the range [1, curve_order).
Generate a random 64-character hexidecimal string (the hex string representation of a 256-bit number) and check to make sure that the number is in the range [1, curve_order). Repeat if necessary.

For SECP256k1, the curve order is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 (or 115792089237316195423570985008687907852837564279074904382605163141518161494336L).
This number is extremely close to the largest 256-bit number (0xFFF...FFF in hex), so you can expect that you'll never exceed the curve order if you generate a random 256-bit number.
As Pieter Wuille mentioned, public keys are derived by performing point multiplication with the curve's base point and the secret exponent/private key. The resulting (x,y) coordinate is the public key.
The Bitcoin address, just like the private key, is also displayed in base58check format. To get the address, we do the following:

Calculate the hash160: ripemd160(sha256(public_key)).
Convert the hash160 to base58check format.

To convert a number to base58check format, just perform the following steps:

convert the value to a byte array and append the version byte to the beginning
calculate the first 4 bytes of SHA256(SHA256(result of step 1)) and call it the checksum
append the checksum to the end of the result of step 1
move the result of step 3 to the keyspace "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
check how many leading zeros the original binary value had and append those to the beginning of the result of step 4

Here are the more detailed instructions.
Now if you don't want to worry about any of this stuff, I would check out the python library Coinkit (https://github.com/halfmoonlabs/coinkit or "pip install coinkit").
You can perform simple operations like these:
>>> from coinkit.keypair import BitcoinKeypair
>>> hex_private_key = '91149ee24f1ee9a6f42c3dd64c2287781c8c57a6e8e929c80976e586d5322a3d'
>>> k = BitcoinKeypair(hex_private_key)
>>> k.private_key()
'91149ee24f1ee9a6f42c3dd64c2287781c8c57a6e8e929c80976e586d5322a3d'
>>> k.public_key()
'042c6b7e6da7633c8f226891cc7fa8e5ec84f8eacc792a46786efc869a408d29539a5e6f8de3f71c0014e8ea71691c7b41f45c083a074fef7ab5c321753ba2b3fe'
>>> k.wif_pk()
'5JvBUBPzU42Y7BHD7thTnySXQXMk8XEJGGQGcyBw7CCkw8RAH7m'
>>> k.address()
'13mtgVARiB1HiRyCHnKTi6rEwyje5TYKBW'

You can also create random keypairs:
>>> k = BitcoinKeypair()

And brain wallet keypairs:
>>> passphrase = 'shepherd mais pack rate enamel horace diva filesize maximum really roar mall'
>>> k = BitcoinKeypair().from_passphrase(passphrase)
>>> k.passphrase()
'shepherd mais pack rate enamel horace diva filesize maximum really roar mall'

Disclosure: I'm one of the creators of Coinkit.

The Javascript code from: http://www.bitaddress.org might give you a good example of this as well.

How they are created is fully documented on wiki: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
In Java

Include the jar of bitcoinj Java library in your classpath
The code:
import com.google.bitcoin.core.*;

NetworkParameters params = new MainNetParams();

String publicAddress = new DumpedPrivateKey(params,
        "KzzuoFPzrPhD55icpAi7idW7z7tH8xSYo3xqTcZm3fHk3AzVxpoP").getKey()
        .toAddress(params).toString();

The result is 17vFi4XjRibQPCktoMcGhZ3DmnG85r1VHE.

In JavaScript
Using bitaddress.org javascript library:
var key = new Bitcoin.ECKey('KzzuoFPzrPhD55icpAi7idW7z7tH8xSYo3xqTcZm3fHk3AzVxpoP');
console.log(key.getBitcoinAddress());

The result is 17vFi4XjRibQPCktoMcGhZ3DmnG85r1VHE.

Note 1: Before, I did bitcoin-cli getnewaddress and bitcoin-cli dumpprivkey <pubkey> to get the key pair.
Note 2: To make things even more easy, under your directory https://github.com/pointbiz/bitaddress.org/tree/master/src just run:
cat array.map.js cryptojs.js cryptojs.sha256.js cryptojs.pbkdf2.js cryptojs.hmac.js cryptojs.aes.js cryptojs.blockmodes.js cryptojs.ripemd160.js securerandom.js ellipticcurve.js secrets.js biginteger.js qrcode.js bitcoinjs-lib.js bitcoinjs-lib.base58.js bitcoinjs-lib.address.js bitcoinjs-lib.ecdsa.js bitcoinjs-lib.eckey.js bitcoinjs-lib.util.js crypto-scrypt.js > all.js

and you get a 174kb file that is all you need to run.
Note 3: If you want to get this file (from commit f6c6bbe53df28c1bf51a6216f02ad1467b36c9f7) look here: http://pastebin.com/raw.php?i=rH8V2j9H

The full functional example
<!DOCTYPE HTML>
<html>

<head>
    <meta charset="UTF-8">
    <script type="text/javascript" src="http://pastebin.com/raw.php?i=rH8V2j9H"></script>
</head>

<body>
    <form onsubmit="alert(new Bitcoin.ECKey(document.getElementById('pkey').value).getBitcoinAddress());">
        <label>
            Private key:
            <input id="pkey" type="text">
        </label>
    </form>
</body>
</html>

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


text:
Is Bitcoin-lightning still not scalable?
Bitcoin verifies about 220 million transactions a year. Even when using Lightning, wouldn't I want to verify my Bitcoins at least once a year on the Blockchain? With 8 billion humans verifying once a year, wouldn't it take on average 40 years to get verified in the blockchain? What if you're forced to close a Lightning channel?
Wouldn't this make the Bitcoin use not secure anymore?

Yes.
But with the coming  taproot upgrade and schnorr signatures we can create a single Bitcoin tx that is n - of - n multisig which enables us to do multiparty channels with n participants in 1 transaction. So if you take n=40 we can onboard 8bn people in 1 year. If you choose n=480 we can do it in 1 month. So let's keep fingers crossed for that Bitcoin upgrade.

Isn't that severely difficult under the ln-penalty paradigm? Wouldn't we need SIGHASH_ANYPREVOUT?

As far as I know Eltoo channels would most certainly make communication and handling of multiparty channel state easier. So yes this additional upgrade would come in handy but I believe ln-penalty would work for multiparty channels if it had to.

Sorry to sound pessimistic, but even setting up channel factories and then having smaller subgroups of users be able to update their substates bilaterally seems like a major challenge for 40 new users, let alone 480—even with Eltoo, but with LN-penalty it sounds nigh impossible.

Aren't such huge n-of-n channels more likely to fail to update assuming O(1) failure rate of each user? If each user fails (loses key, gets hacked) with probability p, 0<p<1, then the success probability for a channel update is (1-p)^n which is exponentially decaying with growing n. Thus, the probability of forced closures (on-chain) for fund recovery is 1-(1-p)^n, very likely. Thus, IMHO, such large channels will cause many on-chain transactions. There might be an optimal trade-off in terms of n between 2-party channels with high dependability and n-party channels with low dependability.

A lot depends on how you define "scalable".
If your question is: do we have ready-to-go technology, which without further on-chain Bitcoin protocol changes, is sufficient for making everyone on the planet to have personal Lightning channels on Bitcoin, the answer is almost certainly no (I'm not an expert on Lightning).
But scalability is generally understood to be more a question of "how do resource requirements scale in function of usage", and for that, Lightning is a significant improvement compared to purely on-chain payment transactions (while coming at the cost of additional assumptions like liveness: the ability for participants to get their settlements timely included on chain). That doesn't mean further technological improvements won't be necessary for further growth.

Using eltoo along with a SIGHASH_ANYPREVOUT Bitcoin upgrade and channel factories this is certainly doable. At this point you are not dealing with lightning penalties anymore nor are you concerned with the overhead of previous state transactions that lightning nodes currently have to manage and store. In addition, channel factories with 20 users is likely a max you would want to deal with due to issues of people going offline. However, channel factories allow channel re-balancing and allow people to open multiple channels at once, increasing their connectivity. A 20 person channel factory opening via a single taproot address allows 100 channels to be opened. Yes, people going offline is problematic when you consider the fact that people in channel factories have channels opened with multiple people, then waiting a day or two for the other person to come back online is feasible. In addition, with channel factories you can splice out the non-responsive person and continue with a new hook transaction.
As for onboarding, you can onboard 6 billion people in 90 days with just 20 person channel factories. If the running narrative is "Get the world onboard as quickly as possible" then protocols can work with exchanges to achieve this with the least transactions possible. Consider 20 people using an wallet app to connect and form a channel factory. They could very easily work with an exchange like Coinbase to get their fiat converted into BTC. The 20 people would combine their 20 public keys into the 20 of 20 multisig hook transaction address and give it to coinbase so they can send the sum of all their funds to the new address. This would effectively onboard 20 brand new people onto the Bitcoin/Lightning network at once via factories.
Given that hundreds of thousands of people would be doing this with the exchanges since "everyone wants to get on bitcoin", the exchanges would be incentivized to minimize their fees by constructing large transactions. They could construct a 1 to 23,250 P2TR transaction that was the size of an entire block. With the sum of fees from all the participants, the exchanges massive transaction fee would be more than enough incentive for the miners to mine it.
Given than each of the 23,250 outputs represents 20 people via a 20of20 multisig channel factory hook transaction, then that would mean a single Bitcoin block could onboard 465,000 brand new people onto the network. At this rate you would be able to onboard 6 billion people in 90 days. (Note: I calculated the max transaction output of 23,250 using the bitcoin core max weight size of a block at 3996000WU)


text:
What is signature grinding?
What is signature grinding and why does the answer to What is the size and weight of a wrapped segwit single-sig input? "highly recommend it"?

The serialization format used for ECDSA signatures requires 33 bytes to encode an r-value that falls into the higher half of the range, but only 32 bytes to encode one falling into the lower half of the range. This means that by repeating the signing until you get an r-value in the lower range ("grinding the signature"), you can decrease the size of your signature by 1 byte. This takes an expected two attempts per signature and makes it easier to estimate the necessary fees for transactions before signing and reduces the blockspace footprint and fees for transactions.

Is this a real technique used in practice? Only 1 byte in reduction seems impractical. Still very interesting. – m1xolyd1an

Yes, and it's not just 1 B, it's 1 B per signature.
On P2PKH, when you build a transaction, you have to conservatively estimate inputs as 148 B, lest you perhaps undershoot a target feerate, although about half of the inputs will be 147 B and the other half will be 148 B. Using signature grinding, you can always estimate with 147 B.
For 2-of-3 P2SH, you always have to estimate with 297 B, because both signatures could be high-r. However, only about 1/4 of the inputs ends up being 297 B, 1/2 will be 296 B, and 1/4 will be 293 B. Why 293? Well, if both signatures are low-r, you slide into the smaller varInt range to specify the length of the scriptSig which saves another two bytes. You can therefore estimate with 4 B less using signature grinding, and save an average 2.5 B on each input from hitting the blockchain.
So for P2PKH, it reduces the overall cost (input+output size) you need to conservatively estimate for by about 0.5% (181 B vs 182 B) and produces an about 0.25% reduction of actual blockspace used (181 B vs 181.5 B). For 2-of-3 P2SH, it's about a 1.2% reduction of the fees (325 B vs 329 B), and a 0.75% reduction of blockspace used (325 B vs 327.5 B). Implementation is easy, and the only on-going cost is approximately doubling the signing effort. See e.g. Bitcoin Core's implementation here: Always create signatures with Low R values #13666


text:
Is there a way to allow use of unconfirmed RBF outputs in transaction building?
Bitcoin Core seems to not consider unconfirmed outputs that are marked replaceable in input selection. Is there a way to override this protection and allow use anyway? The transaction is created using bitcoin-cli.
Edit:
Turns out the unconfirmed output was not change but came from an external wallet. Bitcoin Core doesn't use unconfirmed external outputs.

Bitcoin Core will happily spend RBF marked inputs it doesn't avoid them much less prohibit them.
Perhaps you're being confused by the fact that it will not spend an unconfirmed input created by a third party? Or maybe you have spendzeroconfchange set off or only have long-chain unspents?

Following up with the prompter of the question. Foreign output seems like a good explanation.


text:
What contributions have Blockstream developers made to the Bitcoin project?
I’m spending a lot of time debating people about Bitcoin online these days. One issue that I encounter regularly is that my opposite colloquists are unaware of the contributions the Blockstream developers have added to the Bitcoin project since the company was founded.
My aim is twofold: I’d like to be able to simply link this question next time I read "Blockstream produces only vapour, and contributes nothing", and I think that the answer to this question deserves more visibility.
Please list what measurable contributions Blockstream developers have made to the Bitcoin project?

Good question. I'll add to the answer later. Note that you are limiting this list to Blockstream (that's ok) but most of the members of what is now Blockstream were already big contributors to Bitcoin before Blockstream was founded. Just wanted to leave that as a side note.

@Jannes: This is intentional as for some reason there is a prevalent prejudice against the work of developers since their joining of Blockstream. It doesn't have to be answered that strictly though.

@Murch note, that I replied to the question in bold, ie. contributions to the Bitcoin project in a general sense rather than contributions to bitcoin-core only. I just realized that maybe you meant only bitcoin-core..? I will try to update including more specific information on that.

@karask: No, not necessarily. I mostly would like to have an overview of tangible contributions to refer to. :)

@Murch ah, great then those are by far their biggest contributions that I know of and I might add more if something new comes to my attention.

Disclosure: I'm a Blockstream co-founder
Major feature contributions to Bitcoin Core:

Greg Maxwell, Andrew Poelstra and myself (as well as several other contributors) worked on libsecp256k1, a well-tested library for efficient elliptic curve cryptography using the curve secp256k1. Bitcoin Core switched signing to it in 0.10 and verification in 0.12 (with a 5x speedup for signature validation as a result). This work also led to the discovery of CVE-2014-3570 (OpenSSL bignum squaring bug). Work on the library started as a hobby project of mine in 2013, but many optimizations, tests, correctness proofs, and automated verification were added after we could work on it full time.
I worked on headers-first synchronization (Bitcoin Core 0.10), a new mechanism for block chain downloading which downloads from multiple peers at once, and solved many of the problems with the earlier mechanism. The idea was first described by Greg Maxwell in 2012, but the implementation only got finished after starting at Blockstream.
Jorge Timon and Matt Corallo (as well as Cory Fields) worked on the creation of libbitcoinconsensus, a shared library built from the Bitcoin Core codebase that exposes part of the validation logic, and shipped with 0.10.

Besides that, we provided a large number of changes implementing numerous features, cleanups, optimizations, refactors, improvements, and general maintenance. When looking at the history of Bitcoin Core v0.12.0rc1 after august 1st 2014, 500 out of 2185 commits (23%; over 30% when including libsecp256k1) came from Blockstream employees and contractors. Most of these people were active in the project long before the creation of the company, as these same people were responsible for 866 out of the 4195 commits before august 1st 2014 (20%). These numbers exclude merges, to avoid favouring people with commit access to the repository.
We were also involved in several improvements not directly related to Bitcoin Core code changes:

BIP66 fixed a potential forking risk from the network that was caused by an inconsistency across platforms between OpenSSL versions and opened the door to non-OpenSSL based validation.
BIP68, BIP112, and BIP113 were proposed and first implemented by Mark Friedenbach to introduce relative locktimes and enforcement thereof, which are necessary for more efficient payment channel systems like Lightning.
Several generic blockchain technology improvements were discovered by us and implemented in our first technology demo sidechain Elements Alpha, including segregated witness, confidential transactions, Schnorr signatures and key tree signatures. Segregated witness is currently being worked on as a soft-fork for Bitcoin (BIP141 through BIP144), and includes script versioning which makes introducing things like Schnorr signatures in future softforks much easier.
Other proposed BIPs: BIP99 (consensus change best practices) by Jorge Timon, BIP103 (block size increases following technological growth) by me, BIP111 (NODE_BLOOM flag) by Matt Corallo, BIP9 (Version bits with timeout and delay) by me, Greg Maxwell and Rusty Russell (as well as Peter Todd).
Matt Corallo implemented and operates the Bitcoin relay network, providing low latency block propagation to various parties.

This list is by no means exhaustive, and I'm probably focusing mostly on contributions I participated in myself.

I know of their work on:

Sidechains and the soon to be released Liquid Sidechain and,
the Lightning Network

They lead these efforts and are close to implement a production sidechain. These contributions are quite impressive.
For the above projects some changes are required to bitcoin-core as well (e.g. OP_CHECKLOCKTIMEVERIFY, OP_CHECKSEQUENCEVERIFY, ...) and they contribute towards that end as well.

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


text:
What is a hash pre-image as it is used for the breach remedy?
Until this afternoon I thought the anti-cheat transactions or breach remedies built on the exit-transaction of the counterparty.
Apparently, they build on something called a "hash pre-image". What is it the pre-image from? How and why can it be used to create a transaction once the counterparty tries to breach the payment channel?

In the image below from Rusty Russell's Deployable Lightning paper, you can see a visualization of the commitment transactions and their outputs:

For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob.  Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although only one of them could be included in the blockchain since both transactions spend the same inputs).
Both transactions pay two outputs.  The transaction Alice has (on the left in the diagram, Commit TxA) pays the following two scripts:

A regular P2PKH (or its segwit equivalent) output that Bob can spend at his leisure.
An output that Alice can spend after waiting a specified number of blocks (let's say 100), as enforced with OP_CSV, or which Bob can spend if he has a piece of data that hashes to a value in this output.  I call this the pre-image; in other descriptions of Lightning this is a private key used to generate a signature.

In the transaction that Bob has (on the right, TxB) these are reversed, there's:

An output that pays Alice using P2PKH.
An output that Bob can spend after waiting 100 blocks or which Alice can spend at any time using a pre-image.

In these outputs, Alice selects the pre-image that prevents Bob from spending her output (Revocation-A) and Bob selects the pre-image that prevents Alice from spending his output (Revocation-B).  They could use a random number of large size, although they'll probably both use hashes from a hashchain generated using Rusty Russell's 64-dimensional shachain to allow compact storage of any revealed hashes, seeding the chain with some initial random value.
Each time Alice and Bob agree to update the state of the channel, they both reveal to the other person the pre-image for the hashlock they placed on the output for the previous state of the channel, allowing the other person to create a breach remedy transaction.

If Alice revealed to Bob the pre-image for the hashlock, allowing Bob to create a breach-remedy transaction, why wouldn't Bob immediately broadcast the breach-remedy transaction with the pre-image, and take all the funds?

I think I solved it: Alice revealed to Bob the pre-image for the hashlock of TxA, but Bob only sent to Alice TxA with Bob's signature. Bob cannot broadcast TxA without Alice's signature. Only if Alice's broadcasts TxA with both Bob's and Alice's signatures, Bob can then immediately broadcast the same transaction with the same signatures but also with the pre-image, and get all the funds. Right?


text:
What is the composition of transaction types in current blocks?
What types of transactions do we see in blocks today and how much of the blockspace do they occupy?
I.e. does someone have data how much of the blocks are Pay to PubKey Hash, Pay to PubKey, Pay to Script Hash,…?
I've found A survey of Bitcoin Transaction Types, but it's from April 2014 and outdated.

I recently had the same question and made a small script to compute it (using this python library). Here you have a cumulative plot showing the number of transaction outputs of each kind over time:

Thanks, very cool. Would that script be available somewhere or the image perhaps even dynamically updated in the web somewhere? 0:-)


text:
How much does the weight of 2-of-3 multisignature inputs differ between P2SH and P2SH-P2WSH?
I'm trying to calculate the weight of a 2-of-3 multisignature P2SH-P2WSH input. I found the related question Predict multi signature transaction size, which I've calculated with m=2, n=3 here:
pubkeySize=33
sigSize=72

SizeOfRedeemScript = 1+n*(1+pubkeySize)+1+1
// 2-of-3: SizeOfRedeemScript = 1+3*(1+33)+1+1 = 105

SizeOfScriptSig = 1+m*(1+sigSize)+SizeOfPushDataFor(RedeemScript)+SizeOfRedeemScript
// 2-of-3: SizeOfScriptSig = 1+2*(1+72)+2+105 = 1 + 146 + 2 + 105 = 254

sizeOf(input) = 32+4+SizeOfCsuintFor(SizeOfScriptSig) + SizeOfScriptSig + 4
// 2-of-3: sizeOf(input) = 32+4+3+254+4 = 297

The size of 2-of-3 input in P2SH has 293 to 297 bytes1. Thus, this  would correspond to up to 297*4 bytes = 1188 wu.
How would I calculate the corresponding weight for a 2-of-3 multisignature P2SH-P2WSH input?

1Note that if both signatures are 71 bytes, the scriptSig is 252 bytes which as a length can be encoded in 1 byte, but in the worst case both signatures are 72 bytes and the length of the scriptSig needs 3 bytes.

To calculate the block weight, you need to know the size in bytes of the non-witness data and the size in bytes of the witness data.
With a P2SH-P2WSH input, your scriptSig will always be 36 bytes. This makes the size in bytes of the inputs to be 36 + 36 + 4 = 76. The witnesses contain your signatures and scripts, so the witness for that input will be 1+m*(1 + sigSize) + SizeOfVarIntFor(RedeemScript) + SizeOfRedeemScript. For a 2-of-3 multsig input, you will thus have 1 + 2*(1 + 72) + 2 + 105 = 254 as the size in bytes of your witness.
The formula for calculating block weight is base size * 3 + total size. The base size is the size of all non-witness data, so your base size is 76 bytes. The total size is the size of all data, including witnesses, so your total size will be 76 + 254 = 330. Plugging this into the formula gets 76 * 3 + 330 = 558. Thus the weight of the P2SH-P2WSH 2-of-3 multisig is 558.
*Note that SizeOfVarIntFor(RedeemScript) is actually two bytes because you need to use OP_PUSHDATA1 since the length of the redeemscript is longer than 75 bytes.

If SizeOfVarIntFor(RedeemScript) would be be two bytes because redeemscript is longer than 75 bytes, wouldn't the same apply to SizeOfVarIntFor(SizeOfScriptSig) since SizeOfScriptSig is 251?

@Murch No. There are two ways of representing the size of things in transactions. Within a script itself, we actually use pushdata opcodes. We need two bytes for scripts longer than 75 bytes because we then need to use the OP_PUSHDATA1 opcode before the size byte. However for sizes of things outside of scripts like SizeOfScriptSig, we use Compact Size Unsigned Integers. The csuint only needs an additional byte on top of the number itself when the number itself needs more than 1 byte. You can see how csuint works here: https://bitcoin.org/en/developer-reference#compactsize-unsigned-integers

The differences between P2SH, P2SH-P2WSH and P2WSH are the following:

P2SH: the scriptPubKey has a P2SH program. The scriptSig provides the corresponding script arguments and redeemscript to satisfy the P2SH program.
P2SH-P2WSH: the scriptPubKey has a P2SH program. The scriptSig has the witness program and forwards to the witness stack for evaluation. The witness stack provides the script arguments and witness script.
P2WSH: the scriptPubKey has a witness program, the scriptSig is empty and the witness stack provides the script arguments and witness script.
The witness stack is identical for equivalent P2SH-P2WSH and P2WSH inputs.

So to calculate the size of a P2SH-P2WSH multisig, the script arguments and redeemscript get moved to the witness stack as script arguments and witness script, and you need to add the cost of the forwarding script.
The scriptSig in P2SH-P2WSH is composed of scriptLength witnessProgramLength witnessVersion hashLength hash or varInt PUSHBYTES OP_0 PUSHBYTES <hash>. The length of the scriptSig can be expressed in a 1-byte varInt, so the scriptSig in total takes 1 + 1 + 1 + 1 + 32 = 36 B. This means that the non-witness bytes of the input are the outpoint (32+4 B), the scriptSig (36 B), and the nSequence (4 B) which sum to 76 B in total.
The witness stack has the count of the witness items (1 WU), the three script arguments, an empty dummy element because OP_CHECKMULTISIG pops an additional element of the stack and the two signatures (1+2×(1+72) = 147 WU), and the witness script, witnessScriptLength OP_m n×(PUSHBYTES+pubkey) OP_n OP_CHECKMULTISIG (1+1+3×(1+33)+1+1 = 106 WU).
Altogether, the vsize of a 2-of-3 P2SH-P2WSH input is therefore:
txid:vout:scriptSig:nSeq::witLength:scriptArgs:witScript
 32 +  4 +    36   +  4  +    1    +    147   +    106  = 76 + 254/4 = 139.5 vB

Full details of all three types follow below for your convenience.
P2SH
The size of a P2SH-based 2-of-3 multisig input works out to be 293, 296 or 297 bytes as described in the question.
PREVOUT:
  hash (32 bytes)
  index (4 bytes)
SCRIPTSIG:
  length (varInt 1 or 3 bytes)
  signatures¹ (1+2×(1+72²) bytes = 147 bytes)
    dummy-OP_0
    m×(PUSHBYTES+sig)
  OP_PUSHDATA1 len(redeemscript) (2 bytes)
  redeemscript (1+3×(1+33)+1+1 = 105 bytes)
    OP_m n×(PUSHBYTES+pubkey) OP_n OP_CHECKMULTISIG
nSequence (4 bytes)

32 + 4 + 3 + 1 + 2×(1+72) + 2 + 1 + 3×(1+33) + 1 + 1 + 4 =
36 + 3 + 147 + 2 + 105 + 4 = 297 B

Since signatures can be 71 or 72 bytes, it works out that the input needs a 1-byte varInt to express the scriptSig's length for two low-r signatures. If either or both signatures are high-r it needs a 3-byte varInt to express the scriptSig's length.
P2SH-P2WSH
The weight of a P2SH-P2WSH 2-of-3 works out to be 556–558 WU, which translate to 139.0–139.5 vB.
PREVOUT:
  hash (32 bytes)
  index (4 bytes)
SCRIPTSIG:
  length (varInt 1 byte)
  witness program: (1 + 1 + 1 + 32 = 35 bytes)
    length
    version (OP_0)
    PUSHBYTES <32-byte hash>
nSequence (4 bytes)
WITNESS STACK:
  item count (1 WU)
  script arguments (1 + 2×(1+72²) WU)
    dummy-empty-element¹
    m×(varInt+sig)
  witnessScript (1+1+3×(1+33)+1+1 = 106 WU)
    length (varInt 1 WU)
    OP_m n×(PUSHBYTES+pubkey) OP_n OP_CHECKMULTISIG

32 + 4 + 1 + 1 + 1 + 1 + 32 + 4
+ [1 + 1 + 2×(1+72) + 1+1+3×(1+33)+1+1]/4
= 36 + 1 + 35 + 4 + [1 + 147 + 106]/4
= 76 + [254]/4
= 76 + 63.5
= 139.5 vB

P2WSH
The P2WSH has the same witness stack as the P2SH-P2WSH, so it saves exactly the 35 B from circumventing the redeemscript. The weight of a P2WSH 2-of-3 works out to be 416-418 WU which translate to 104.0–104.5 vB.
PREVOUT:
  hash (32 bytes)
  index (4 bytes)
SCRIPTSIG:
  length (varInt 1 byte)
nSequence (4 bytes)
WITNESS STACK:
  item count (1 WU)
  script arguments (1 + 2×(1+72²) WU)
    dummy-empty-element¹
    m×(varInt+sig)
  witnessScript (1+1+3×(1+33)+1+1 = 106 WU)
    length (varInt 1 WU)
    OP_m n×(PUSHBYTES+pubkey) OP_n OP_CHECKMULTISIG

32 + 4 + 1 + 4
+ [1 + 1 + 2×(1+72) + 1 + 1 + 3×(1+33) + 1 + 1]/4
= 36 + 1 + 4 + [1 + 147 + 106]/4
= 41 + [254]/4
= 41 + 63.5
= 104.5 vB

¹ OP_CHECKMULTISIG pops one extra element off the stack
² Signatures can be 71 or 72 bytes (or seldom even smaller)


text:
How much blockspace would it take to spend the complete UTXO set?
I was curious how much blockspace has already been spoken for in the future. Paraphrased:
Assuming all block space were used to consolidate the UTXO set in the most efficient manner (and all key holders were collaborating for this purpose). How many blocks would it take to consolidate the UTXO set to a single UTXO?

via https://txstats.com/dashboard/db/utxo-set-repartition-by-output-type
Let's assume the following numbers of UTXOs:

P2PKH: 51.9M
P2SH: 15.4M
P2WPKH: 13.6M
P2WSH: 881K
Bare multisig: 435K
P2TR: 89K
P2PK: 49K
Unknown: 9K

Please feel free to use a reasonable estimate for the size of *SH types.

Does this question has any practical purpose or is just a personal curiosity? I liked it but I'm not sure whether it is important to know how much does it take to combine all UTXO set into a single one because obviously that would never happen. Although it would give a better sense of bitcoin network scale.

I was curious how much "blockspace debt" the current UTXO set constitutes.

Would you explain what is "blockspace debt"?

Each UTXO that is created will have to be spent eventually to allow reassigning its value. I refer to these already existing future claims on blockspace.

TL;DR: Spending the whole UTXO set would take the blockspace of about 11 500 blocks.
What follows is some very rough napkin math that is almost certainly off by a few percent points. I've roughly estimated a few values, that could probably be collected more exactly, feel free to suggest concrete improvements where you would expect to see a significant change by estimating more exactly with reasonable effort.
Single-sig
These are the easiest to estimate. We known basically exactly how much it'll weigh to spend them.

A P2PKH input weighs 148 B.
51.9M × 148 B = 7 681 200 000 B
A P2WPKH input weighs 68 vB.
13.6M × 68 vB = 924 800 000 vB
Let's assume all P2TR UTXO are spent via keypath. An input weighs 57.5 vB.
89K × 57.5 vB = 5 117 500 vB
A P2PK input only has a signature in the scriptsig and therefore should weigh 113 B.
49K × 113 B = 5 537 000 B

P2SH
For P2SH UTXOs it gets more complicated. We know the redeemscripts only for about a third of the UTXOs per this P2SH breakdown:

via https://txstats.com/dashboard/db/p2sh-repartition-by-type

unknown: 9.24M
P2WPKH:  3.18M (91 vB)
2-of-3:  1.48M (297 vB)
wrapped 2-of-3: 778K (139.5 vB)
various non-segwit multisigs¹: 607K
other non-multisig: 24K

¹ 3-of-4, 2-of-2 and 3-of-5 are the most common known output type after the explicitly listed. I'm assuming that "other multisigs" and "other non-multisigs" are smaller than 3-of-4, but it seems reasonable to estimate all the remaining non-segwit multisigs and non-multisigs as approximately the average of 2-of-2, 3-of-4, and 3-of-5: 360 B
Known outputs:
3.18M × 91 vB + 1.48M × 297 B + 778K × 139.5 vB + 631K × 360 B =
1 064 631 000 vB
Assuming the average input virtualsize of 175.5 vB applies also to the unknown P2SH UTXOs: 9.24M × 175.4 vB = 1 620 696 000 vB
P2WSH
I haven't found a breakdown of P2WSH outputs. Since more than 3/4 of the multisig in P2SH was 2-of-3, we're just going to estimate with the size of a 2-of-3: 881K × 104.5 vB =
92 064 500 vB
Bare multisigs
Bare multisig only needs the signatures in the input as the scriptPubKey already contains the condition script itself. Let's assume a 2-of-3 multisig. From the top of my head, an input should be roughly 168 B. (32+4+1+1+1+64+1+64)
435K × 274 B = 73 080 000 B
Unknown
Probably the 9K unknown are mostly unspendable trash, but they're such a small portion of the total UTXOs, that we won't bother being too exact and just assume they were the most common type, P2PKH. 9K × 148 B = 1 332 000 B
All inputs in sum

P2PKH: 7 681 200 000 B
P2WPKH: 924 800 000 vB
P2TR: 5 117 500 vB
P2PK: 5 537 000 B
P2SH: Known: 1 064 631 000 vB, Unknown: 1 620 696 000 vB
P2WSH: 92 064 500 vB
Bare Multi:  73 080 000 B
Unknown: 1 332 000 B

Sum: 11 468 458 000 vB
Glossing over the size of coinbase transactions and block headers, the inputs would therefore require about 11 470 blocks.
Assuming we only use standard transactions, we'd need to create 11 outputs per block. Adding the creation and spending of these transaction outputs assuming P2WPKH adds 11 × 11470 × 99 vB = 12 490 830 vB.
Adding the block headers, coinbase transactions, and the new outputs of the consolidation transactions, it should be possible to spend the whole UTXO set in fewer than 11 500 blocks which is less than three months worth of blockspace.


text:
At what height exactly can a relative time-locked output be spent?
Assume a UTXO created in block n with the output using a relative timelock of s blocks (s OP_CHECKSEQUENCEVERIFY).
What is the lowest blockheight which may contain a transaction spending that UTXO?
Bonus: At what height will such a transaction be eligible for relay on the network?

What is the lowest blockheight which may contain a transaction spending that UTXO?

A UTXO created in block number n, can be spent in block number m (and not before), if the transaction input spending them has nSequence value m-n or lower.
If the UTXO (unconditionally) has <s> OP_CHECKSEQUENCEVERIFY in (all) its script(s), then that means the nSequence of the transaction inputs spending it has to be s or higher, and thus indirectly, spending it can happen in block number n+s or later.

Bonus: At what height will such a transaction be eligible for relay on the network?

According to today's relay policy in Bitcoin Core, transactions can be relayed whenever they can legally be included in the next block (among many other rules, of course).

A transaction may spend an OP_CSV-locked TXO s blocks after it was created. I.e. if it was locked for s blocks, and created in block n, the transaction spending it may be included in block n+s.
If Alice’s transaction confirms in block 100 and contains an output with a 30-block relative time-lock for Bob, Bob may spend this output in a transaction that gets confirmed in block 130.
Bitcoin Core will consider a transaction spending a relative time-locked TXO policy-valid at a height one lower than it can be included in the blockchain: the transaction will be accepted into the mempool and relayed by nodes whose best chain is at least at height n+s-1 (block 129 in above example).


text:
Known cases of block-withholding attacks
At the moment I am doing a course about Bitcoin. The topic of the last session was the block-withholding attack and the course (being from 2014) claimed that there are no known attacks so far.
Is block-withholding a strategy used by mining pools in 2021? If so, where can I find evidence to back that up?

I found a lot of papers about block with holding attacks
This seems a survey
https://www.researchgate.net/publication/309628092_Bitcoin_Block_Withholding_Attack_Analysis_and_Mitigation
These r newer
https://www.researchgate.net/publication/343236094_Countering_Block_Withholding_Attack_Efficiently
https://www.aimspress.com/article/id/4266
https://www.sciencedirect.com/science/article/abs/pii/S0951832018310494
https://ieeexplore.ieee.org/document/9284756
Reading the abstracts  this includes some of the Selfish Mining ways (I'm sure I read the idea in the IEEE paper in a Selfish Mining paper:
Detective Mining: Selfish Mining Becomes
Unrealistic under Mining Pool Environment,
Suhyeon Lee and Seungjoo Kim,
CIST(Center for Information Security Technologies), Korea University, Korea; ADD(Agency for Defense Development), Korea.)
I don't think Selfish Mining or Block With Holding is something u'll read in the news about, it is a miner or a pool used a block mining efforts; only maybe if it helped in a 51% attack which the papers point as a risk.
Wait, I did find more in my library under Selfish Mining
https://academy.binance.com/en/articles/selfish-mining-explained
https://outlast.me/selfish-mining-in-five-tweets/
In this one there's a curve unfortunately I don't know its source about ratio of Selfish Mining in known pools

[I added this part for the sake of promoting knowledge, understanding, scientific research,... nothing more]
I also wondered would it be a malicious way to do front running?ie convince a high bidder ( would be paid more to get his TX as fast as possible) that his/her TX is guaranteed say 1st place in ur block, while u plan to drop the whole block & front run with another TX (maybe I did read that in a paper before, MEV ?)
& yes I did read about it under MEV, they're called Privately Mined Transactions or Private Transactions , they didn't allow more links so I'll just add the screenshots I made about it ( u can search for urself under these terms)

The question asked for evidence that block-withholding (probably selfish mining) attacks have happened in practice. This answer lists a number of theoretical papers without addressing the question.


text:
Is there an easy way to estimate the number of mining nodes?
I was curious about the number of mining nodes on the network, yet I haven't seen it discussed.
I tried two different approaches to approximate the count of mining nodes. I looked up the hashrate of the fastest hashing machine (which appears to be the Antminer S19 Pro at 110Th/seconds) and compared its projected mining profit with the total mining reward.
A profitability calculator estimates that I'd earn 0.2911 Bitcoin per year with the device running 24/7/365. This means that at 6.25 bitcoin per block, I contributed to solving 0.0465 block in 1 year. If the network used only these machines, then I estimate 55,000 blocks / 0.0465 blocks per mining node = 1,182,795 mining nodes. This is the lower bound, the minimum number of mining nodes on the system.
Now, my other assumption is that the network difficulty is equivalent to the average weighted hashrate of the sum of all mining nodes on the network (time frame is probably smoothed here). If the current, March 18 2021, network difficulty is 21.6 Th/seconds, then the same calculator calculates that my device would earn 0.0572 Bitcoin in 1 year. Using the same calculation, I get 55,000/(1/(6.25/.0572)) = 6,009,615 mining nodes.
These two numbers are quite a bit apart. Is there a better way to estimate the mining node count?

there is nothing "official" in Bitcoin

Does this answer your question: Total # of miners?

Hi Denys, I saw that you posted the gist of your post as an answer on the question RedGrittyBrick linked. Generally, if you're in the situation where you want to know whether you got a good answer for something, it would be preferable if you post a question to start the topic and then post your answer as the answer to the question. That facilitates other people giving a competing answer to the actual question. Anecdotally, such topics get more interaction than a "Am I right about ?" post.

Thank you Murch. Yes, I think I have to learn how to use this post. But since I was asking for opinions, it's because I was unsure of my approximation, hoping someone wold jump in with a link to a formula or some data or something. But I understand what you are saying. This morning I found this blog where a person posts a "market share", but it doesn't make sense...I am not sure what he means by "Implied Market Share" of ones mining device, but it's not the answer I was looking for. https://medium.com/chainalysis/bitcoin-mining-calculations-ff90dc958dba The remainder calculations look OK

Hi Denys, I compacted your question to make it more accessible. I hope I managed to capture the gist of what you wanted to know. Please feel free to further edit the question if I did not. Please check out our [tour] to get an overview how our site works.

While it's possible to estimate the current hashrate from the difficulty, they are two different measures. You can find an estimate for the global hashrate on the same site where you found the difficulty. The current estimate is 162 EH/s (162,000,000 TH/s).
Using a similar approach as proposed by you, we can estimate an upper bound of  162,000,000 TH/s / 110 TH/s = 1.47M mining nodes by comparing the global hashrate to that of the fastest mining equipment.

TY, a year later, I am sorry I may have stolen the punch line answering my own...it was as an intro, yet no one has still produced a decent "official" calculation. Yet, I misspoke at the time.  The confusion iarises from the terminology mining node, when most people involved or interested in the subject will interpretet this as a network present node. I was trying to estimate the number of mining machines. On network maps, only first belt nodes figure, the network is now all corps or groups. Not all nodes are on first bel;t (Bitnodes quotes 15000 fisrt belt nodes).


text:
How does the blockchain resolve arbitration issues?
I understand that a bitcoin wallet is nothing but a transaction record performed on the block chain.
How are transaction details updated in the decentralised block chain?
In a centralised system a transaction is based on the transaction record maintained in their centralised servers. For example A and B are connected to centralised C. When   A initiates a transaction with B, C refers to its centralised database and verifies whether it is a valid transaction and permits the transaction based on the validation results. In other words, there is a central log for cross verification and debugging to settle issues when there is arbitration needed by any one of the two transacting parties.
But in decentralised transaction there is no centralised arbitrator. How is arbitration provided in case of a misplaced transaction?
In other words is there any confiscate mechanism to strip the owner of his bitcoins who is involve in illegal practices?

How are arbitration resolved in case misplaced transaction. - same way any other dispute between humans is resolved

I understand that bitcoin wallet is nothing but transaction record performed on block chain.

A bitcoin wallet stores keypairs, and allows the use to interact with the network by sending/receiving bitcoin transactions.

How are transaction details updated in decentralised block chain?

A 'full node' can be run by a user that wants to independently verify the state of the network for themselves. Each full node keeps their own local copy of the network state (blockchain history), and the nodes communicate new blocks and transactions to each other. By doing so, all of the nodes will come to agree upon the current network state, without the need for a central server.

How are arbitration resolved in case misplaced transaction.

Network nodes follow a set of rules (often called 'consensus rules'), that allow them all to arrive at the same conclusion about what the network state should be. In the event of conflicting blocks, the chain with the 'most work' is eventually ruled the valid chain.

In other words is there any confiscate mechanism to strip the owner of his bit coins who involve in illegal practices?

No.

A node verifying that a transaction is performed looks at the block chain... but perhaps more explicitly, it looks at "block chains."  There's no actual requirement that a node only look at just a single block chain when deciding whether a transaction is valid or not.
They can then assign some level of trust as to whether the transaction occurred, and act appropriately.
The algorithm is designed around eventual consistency.  If most nodes are honest (meaning the follow the recommendations in the algorithm), the algorithm will naturally move towards all honest nodes agreeing upon which block chain is "true."  This is managed with a feedback loop: miners trust the longest chain that they are aware of, and miners lengthen that chain by mining.  A malicious player would need to have a majority on the mining power for the entire bitcoin network in order to convince the honest miners to believe their fraudulent claims.  Practically speaking this would require hundreds of TW of energy (for comparison, the largest nuclear powerplant is currently 0.008TW).  Without such power, they could only provide fraudulent chains which are shorter than the main chain.  This would be detected by an honest node, and they would choose not to honor the transactions on that chain.
This is why it is typically recommended to wait for 6 blocks before considering a transaction to be "official."  Due to networking, its plausible that you could see a fraudulent block appear with your transaction.  However, it is exceedingly unlikely that you would see 6 blocks appear on the fraudulent chain without seeing the "honest" chain, with more work put into it.  By 6 blocks (give or take), it is unlikely that someone could, say, buy up all of the AWS servers and quickly race ahead of the honest miners to make their fraudulent chain into the "best" chain.
As for mechanisms to confiscate illegal gains, there's none written into the algorithm.  The algorithm only looks at the length of the chain when deciding which chain is valid.  There are known tricks involving double-spending which take advantage of this.  However, at the highest level, there is a way.  If all "honest" actors decide that the longest block chain is "fraudulent," and they agree on another block chain that is not fraudulent, they are free to all shift to this new block chain.  This would go against the algorithm, technically, but would be something that could be done socially.

Technically speaking, Bitcoin (or proof-of-work based systems) do not achieve eventual consistency. A former state is never guaranteed to be final, as any block can be reorganized. Under economic assumptions (no majority of hashrate will work against consistency for an extended period of time) the probability for that happening drop exponentially as time progresses, but even then, it never reaches 0.


text:
Why was the MIT license chosen for Bitcoin?
Given that an open, transparent, distributed p2p network is a central element of Bitcoin project it seems unusual that it is licensed under the MIT license which allows proprietary closed source derivatives.
http://en.wikipedia.org/wiki/MIT_License
Does anyone know if there was a stated or expressed reason for not choosing a free software license?
Has there been any discussion to license future versions of the Bitcoin client under licenses which have "copy left" and "patent retaliation" provisions such as GPL?

Just to clarify, Bitcoin clients adhere to an open protocol.  Some of the other Bitcoin clients are FOSS - free, open source software:
https://en.bitcoin.it/wiki/Category:Free_Software

MIT licence is less restrictive than for example copyleft, giving you freedom to do more with it. It allows people to make the choice of whether they want to give their source code away or not, which can draw more people in to work on the project than if they wouldn't have that option.

Satoshi:

If the only library is closed source, then there's a project to make
  an open source one.
If the only library is GPL, then there's a project to make a non-GPL
  one.
If the best library is MIT, Boost, new-BSD or public domain, then we
  can stop re-writing it.
I don't question that GPL is a good license for operating systems,
  especially since non-GPL code is allowed to interface with the OS.
  For smaller projects, I think the fear of a closed-source takeover is
  overdone.

+1.  Awesome cite.  I disagree with the assessment but interesting to see the logic.

Noble idea... but now everyone and their uncle is claiming their fork is the 'real' bitcoin...

@RosdiKasim That's the entire point of a decentralized system. Nobody gets to make an authoritative claim of ownership or authenticity.

Using a more restrictive license would have slowed adoption. The biggest obstacle to Bitcoin is lack of adoption. Anything that would restrict the set of things people can do with Bitcoins or make it more expensive or more difficult to use them in particular ways increases the chances that Bitcoins never get significant penetration.
Some Bitcoin uses involve proprietary, closed source derivatives. How would it help Bitcoins to discourage those uses?
But the actual historical reason is even more important. If the Bitcoin client had been licensed under the GPL, anyone who wanted a proprietary client would have to recreate it. That would create a whole host of real problems that would harm the usefulness of the Bitcoin system.
For example, say the developers want to add a new type of script. Right now, they can add support for that script in the official client and everyone will have it in a few months. But if there were proprietary versions, they may never be able to cost justify adding the new scripts, and this could cause adoption of the new scripts to fail. If a new currency supported those scripts and forks meant Bitcoin didn't, that could make Bitcoins fail.
Or say there was a bug in the client that caused it to accept blocks that are subtly invalid. If the network had a significant number of clients separate developed, they might reject those blocks while the official client accepts them. If fewer than 50% of the network runs the official clients or miners tend to run the proprietary clients, this could result in a serious network fork that would be very painful to resolve.
Another problem would be if different clients wind up using different attack resistance methods. If one client passes a message another client considers abusive, attackers could exploit this to isolate nodes from the rest of the network. Having all clients use the same logic for validating messages avoids this attack method. (If X punishes nodes for it, X also won't pass it to other nodes. So if other nodes follow the same logic as X, X will never get punished. But if X passes a message Y punishes for, sending that message to X will result in X not punishing you, but X getting punished by Y.)

Revisiting this two years later there are as of yet no proprietary clients being distributed.  There is a lot of proprietary work done in the Bitcoin "ecosystem" but these are specific internal implementations which would have been compliant with a GPL style license anyways.
Sadly what has restricted alternative development isn't licensing but the fact that there is no independent library.  The QT (reference) client is a library, full node implementation, and a specific wallet all rolled into one codebase with the major functions horribly interdependent.  Maybe someday this can be refactored.

If Bitcoin was under the GPL the Bitcoin developers could sue companies developing proprietary "Bitcoins" for all profits. All they need is a black hat / grey hat hacker to decompile the code, and dump it publicly. They can then grep for matching portions of code, and sue like Ghostscript did.

@ZeroPhase Which would have meant those developers would not have existed, weakening bitcoin in comparison to how much stronger it would be with those developers and applications.

@DavidSchwartz I'm definitely more practical in terms of licensing. I do think there is a business model, using the GPL, with a decentralized bank backed by a basket of crypto assets and stablecoins printing money to buy financial assets, while inflating and deflating the currency based on current demand. You then start businesses this bank funds. I believe they'd be capable of economically dumping on competitors while paying more to talent. They should not need to turn a profit for decades if the debt to equity ratio is correct. Something like SBF Holdings, but purely on blockchain.

The GPL is just there to prevent corruption on either side. If the decentral bank implements bad policy. The code gets forked and you have a competitor with all of these vertically integrated businesses capable of shifting loyalty. I think it's one of many solutions f monopolies

What sense would it make to turn away all the adopters who need to distribute proprietary versions of the code and drive them to other projects that don't use the GPL though?

Satoshi did not use a FOSS license because it was not intended to be a community project. The protocol was intended to be set in stone for its entirety. Satoshi was also not around in 2011-2012 when others were given access and moved the code to github.

This is 100% the opposite of the truth. In fact, the idea was that bitcoin could not be technologically surpassed or obsoleted because any innovations would have to be open source and patent free and so could just be incorporated by bitcoin.

Having read a lot of Satoshi's communications and followed Bitcoin development for about a decade, this answer is plainly false.


text:
weak transaction in secp256k1
My question is related to weak signature vulnerability testing where a hypothetical attacker does not know the values of the nonce or private key itself, but can determine that the nonce 'k1' is designed  by private key 'd' to message hash z , such that: k = 128 MSB bit of z + 128 bit MSB of d (privatekey)
example:
d= private key in hex
z= message hash
k= nonce; where nonce is equal first 128 bit of z + 128 bit of d
d= 0x036ed4f5f383049827edc4fe337f46f83a240b124242620b02b97552b2fc11a4
z= f55ab477c48f9afaf1a72ab448bf96b4a05f336f7a1e27e08993308dfaa783b5
k = f55ab477c48f9afaf1a72ab448bf96b4 + 036ed4f5f383049827edc4fe337f46f8
k= 0xf55ab477c48f9afaf1a72ab448bf96b4036ed4f5f383049827edc4fe337f46f8
signature:
r= 62326678398279634483781267842729177896577268934832461436294590773005653623297
s= 78373122694400608572761948114834235891083358005495335895684705221713649603747
z= 110976909682006680432155795488402189554785886863009729379902726621537291961269
I have searched the stack exchanges and various articles and research papers and have not found a workable solution to this problem. My own linear algebra is not as strong as I would like it (it's been a number of years), and my attempts have not been successful.
Is there any way to calculate k or privatekey?
N: Finite field of the secp256k1

I believe this would be trivial to break.
Let's say that:

z = z0 + 2128z1, with 128-bit z0, z1.
d = d0 + 2128d1, with 128-bit d0, d1.

In that case, according to your construction, k = d1 + 2128z1.
For ECDSA signatures (r,s):

We know s = k-1(z + rd) (mod n) (the signing equation)
Put otherwise: sk = z + rd (mod n)
Substituting the above: s(d1 + 2128z1) = z0 + 2128z1 + r(d0 + 2128d1) (mod n).
Grouping: rd0 + (2128r - s)d1 = 2128z1(s - 1) - z0 (mod n).

All variables in the last equation above except for d0 and d1 are known. Finding solutions for those restricted to range [0,2128) is a simple lattice reduction, which likely has at most a few solutions. Those can be tested exhaustively.


text:
What is this unusual transaction in the Bitcoin blockchain?
I found a transaction in the Bitcoin blockchain. The first output is unspent and has an abnormal Pkscript. What is this output and why does this output address have no transaction and balance on it?
Link to transaction: b53e3bc5edbb41b34a963ecf67eb045266cf841cab73a780940ce6845377f141

The first output of transaction b53e3bc5…5377f141 has the following scriptPubKey:
OP_PUSHNUM_1 OP_PUSHBYTES_32 01010101…0101010101

The segwit softfork in 2017 defined versioning rules for all native segwit outputs, but only defined spending rules for version 0.¹

This output worth 5431 satoshis matches the native segwit schema, but the leading OP_PUSHNUM_1 indicates that it is a version 1 output. It shows up as "Type: UNKNOWN", because there are currently no spending rules for version 1 outputs active on the network. Therefore, this output could be spent by anyone, as long as they get a miner to include a non-standard transaction in their block that claims the funds.
We are anticipating the activation of the Taproot softfork in November, which will give exactly this output pattern meaning (see BIP341): Pay to Taproot (P2TR) outputs will be version 1 native segwit outputs with a 32-byte witness program that consists only of a public key.
Finally, the public key 01010101…01010101 here is obviously not randomly derived from a private key, so the private key can be assumed to be unknown. The corresponding address will essentially become a "burn address" once Taproot activates and spending of funds received there must follow Taproot's rules.
I surmise that whoever created this output in 2019 simply wanted to be the first person to create a Taproot output on the blockchain and was willing to burn a few satoshis on that.

¹There are two output types defined in version 0: Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH).

To add to Murch's answer:
The output was created by Matthew Zipkin to test support for sending to SegWit v1 support on purse.io. This was done in the context of the Bitcoin Optech Compatibility Matix.
Here is a screenshot of the purse.io withdrawal that was added in PR 303 to the Bitcoin Optech website.


text:
What is the relationship between a Bitcoin Private Key / Public Key / Address?
What is the relationship between a Bitcoin Private Key / Public Key / Address?  I see that a private key / public key pair is generated, but is there a possibility of generating a private key already in use?  And, also I'm assuming that a wallet address is a bitcoin address?  Does each wallet address have a one-one relationship with a private key?
Thanks

Related: https://bitcoin.stackexchange.com/q/48322/5406, https://bitcoin.stackexchange.com/q/8804/5406, https://bitcoin.stackexchange.com/q/25024/5406, https://bitcoin.stackexchange.com/a/25071/5406

Private keys
Old wallets used one private key generated randomly by the wallet when first run.
In modern "Hierarchical Deterministic" (HD) wallets. One private key is generated either randomly or derived from a phrase called a seed-phrase or recovery-phrase which itself is generated from a random number. Then many other private keys are generated from this using a "derivation path" which can differ between different brands of wallet. The derivation path is chosen by the developers and some different developers chose different derivation paths. This affects wallet recovery.
Public keys
One public key is generated from (along with?) each private key.
Addresses
Addresses are constructed from public keys for certain common types of transaction. Not all transactions involve addresses.
The most common types of transaction create addresses as a prefix followed by a hash of a public key followed by a checksum (so that typing errors may be detected).
Because HD wallets generate a new address for each transaction, behind the scenes they are using the fixed derivation path to generate new private keys and public keys from which to create the address.
So HD wallets have many addresses, it isn't sensible to think of a "wallet address".

Relationships and Probabilities

What is the relationship between a Bitcoin Private Key / Public Key / Address?

Something not entirely unlike this:
entropy --> random number  --> phrase --> private key --> public key --> address
                   |                        ^   |
                   '------------------------'   +--> private key --> pubkey --> addr
                                                +--> private key --> pubkey --> addr
                                                :
                                                '--> private key --> pubkey --> addr

is there a possibility of generating a private key already in use?

Its about as likely as your home spontaneously changing into a pot of petunias. Which physicists might tell you is theoretically possible but not ever going to occur due to its improbability. The point is we are talking about statistical probabilities involving numbers that are far more vast than most of us have any hope of comprehending because they are far greater than any numbers we routinely encounter or can imagine.

And, also I'm assuming that a wallet address is a bitcoin address?

Yes.

Does each wallet address have a one-one relationship with a private key?

So far yes.
New types of transactions can be invented and I imagine new types of address could be invented.

Thanks @redgrittybrick!.  Explains it well.  So, the first private key in your diagram is essentially the crucial part of this scenario?  If I have this (since it's my own bitcoin account), then I can simply use it on another wallet provider, and just add my private key there, and the bitcoins will be there for me to send from?

@Chris: Yes. But the new wallet must use the same derivation path. Many wallets allow you to choose the derivation path. Some don't.

Using Elliptical Curve Digital Signature Algorithm (ECDSA), the private key is used to generate the public key, a secure hash function is then applied to the public key and a checksum appended to produce a Base58 formatted bitcoin address.
A private key collision is theoretically possible, but practically impossible due to the sheer number of them available on the network (quadrillions+).

Just to add a little color: the number of private keys is way way way bigger than a quadrillion. It is more than 115 quadrillion quadrillion quadrillion quadrillion quadrillion. The limit on the number of private keys is the order "n" of the Generator, which is "fairly close" to 2 raised to the 256 power. The actual value of "n" is: 115792089237316195423570985008687907852837564279074904382605163141518161494337

What is the relationship between a Bitcoin Private Key / Public Key / Address?

The Public Key (a curve point) is equal to the Generator (a fixed curve point) multiplied by the Private Key (an integer).
There are multiple different kinds of addresses. But, one common type of address is an encoded hash of the public key. (In practice what is hashed is the byte representation of the x-coordinate of the public key with either 0x02 or 0x03 appended to the front to account for the sign of the y-coordinate, and additionally there is some checksum data--just another type of hash--appended prior to encoding).

is there a possibility of generating a private key already in use?

Yes there is. For example, if you choose your private key to be the number 1 then you will have chosen a bad private key (the private key 1 is already in use--see if you can find it!).
However, if you choose your private key at random  from integers greater than zero and less than  115792089237316195423570985008687907852837564279074904382605163141518161494337, then you will have a valid key and the chance of a key collision is very very low (because 115792089237316195423570985008687907852837564279074904382605163141518161494337 is very very large).

Two nits: (1) there are multiple types of addresses (some encode a hash of a public key, some of a script, and new P2TR ones encode a public key directly), however none of them are a hash of just the x coordinate (P2PKH addresses also hash the parity of the Y coordinate).  (2) The number 0 is not a valid private key (and neither is the curve order, as mod n they are the same).

Re (2): Yes, I agree, that was inaccurate, I updated the answer to state greater than 0 and less than n. Re (1): Since I didn't specify the hash function, the part in nit (1) about the hash doesn't technically apply. (A hash function that is the action of ripemd160 on the sha256 of '\x02'+x-coordinate is still a hash function. Similarly appending on the checksum is still a hash function.) Since the function can be applied to arbitrary input and produces a fixed size output, it's still a hash function.

The part in Nit (1) about multiple address is a valid nit, but maybe too much info for OP to handle? Anyways, I updated the answer to reflect nit 1 as well.

Sure! Perhaps I wasn't clear, my nit is not that you should mention other types, but the fact that what you currently state is wrong: P2PKH addresses are a hash of public keys, but not just of their X coordinate.

OK, I think maybe I see what you are getting at... But I would contend that, in some sense, it is "mostly" the x-coordinate that gets hashed, and only "a little" the y-coordinate (just effectively the sign of y--the y value is implicit). In other words, in practice, the public key (a curve point) must be converted to a byte string in order to be processed by the hash function. This conversion to bytes is performed by converting the x-coordinate to a byte string and then appending either 0x02 or 0x03 to the front of the byte string to account for the sign of the y-coordinate.

I updated the answer. I'm guessing this is probably answered elsewhere on this forum as well...

Just so you see where I'm coming from: the pair (y parity, x coordinate) uniquely identifies a point, and thus a hash of that is effectively the same as hashing (x coord, y coord). While just hashing the x coordinate would have a distinguishable outcome: it would imply that negating a private key would not change the hash (because only the y coordinate would change).

yep yep, gotcha!

A private key is an integer k from the range (0, n), 0 and n excluded, where n is the order of the generator G, which is 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141, a number slightly smaller than 2256. The public key K is the corresponding elliptic curve point on secp256k1: K = k×G, where G is the base point or generator of secp256k1.
A Pay to Public Key Hash (P2PKH) address is derived from the public key by first applying a SHA256 hash and then a RIPEMD-160 hash. The address is then encoded using Base58Check. This means that there are only 2160 addresses for about 2256 private keys. Therefore, about 296 private keys map to each address. Since there is no central registration of addresses after they are generated, there is no mechanism to prevent key collisions, but as Travis already explained, the sheer size of the number space makes collisions astronomically unlikely to occur. The question Is each Bitcoin address unique? goes into more detail.
By now, there are a number of different address types that can be derived from the same private keys. So strictly speaking, there can be multiple addresses associated with the same private key, but for most practical purposes you can assume that each address is unique and has a one-to-one relationship with a private key.
Without further context, I would take "wallet address" and "bitcoin address" indeed to refer to the same concept.

I think the range of the private key is actually limited to the order "n" of the generator, which is close to 2**256, but not equal to it. The order is 115792089237316195423570985008687907852837564279074904382605163141518161494337

See section 2.4.1 here: https://www.secg.org/sec2-v2.pdf

Thank you for the note, @hft, I hope this is better.

you are welcome. One other nitpick: it is just SHA256, not SHA256d that is applied prior to the RIPEMD-160 hash when forming the unchecksummed address hash.

Indeed, thank you for pointing that out. I've corrected my post.


text:
Buy Bitcoins in partition
Can you buy some percent of bitcoin at different rates and merge them to form one bitcoin? Is it like you buy at different rates so you will get different exchange rates for particular percent

Buying bitcoin is no different to buying carrots.
If you buy 10kg of carrots for $3 in one place and the next day buy another 10kg of carrots for $4 you have 20kg of carrots.

Can you buy some percent of bitcoin at different rates and merge them to form one bitcoin?

Yes you can totally take your carrots out of your two 10kg bags of carrots and put all your carrots into one bag that then weighs 20kg.

Is it like you buy at different rates so you will get different exchange rates for particular percent

If you buy from a supermarket that only sells carrots in 10Kg bags, you likely wont be able to negotiate a bulk discount for buying one ton of carrots.
In the world of currency this is probably more true, the exchange rate probably varies less by transaction amount because your purchase is generally going to be tiny compared to market volume. But this is still a question about markets - not some weird voodoo that only applies to currencies.
The next day If someone is willing to pay you $0.40 a kg for your carrots you have $8 worth of carrots, not $7 worth of carrots.
The price of fresh carrots does not depend on what you paid for them, only on what people are willing to pay you for yours.
The point is that carrots are carrots, they are not some strange form of promises of future dollar amounts. They are not derivatives of dollars. They are carrots.


text:
Why I can't transfer from BTC trading wallet to my BTC wallet? using Blockchain
I am trying to transfer bitcoins on Blockchain from BTC trading wallet to my BTC wallet, all I get is "insufficient funds" eventhough I have enough funds in the BTC trading wallet. Any solution?

Have you accounted for transaction fees? The sender pays the fees in Bitcoin.

First, make sure there isn't a "hold period" on your recently deposited funds. Many exchanges that do business in the USA put a 7-day "hold" on all your deposits, meaning you can trade cryptos on that exchange all you want, but until those 7 days are over, you can't withdraw anything, or transfer crypto to an outside wallet.
Also, as mentioned in the comments, make sure that you have enough funds in your trading account to cover your transfer PLUS the transaction fee, and 5hat you are not trying to transfer less BTC than whatever their "minimum transfer amount" is currently set to.


text:
How do I choose new lightning channels in order to minimize hops when rebalancing?
Currently my fees are quite high when I try to rebalance and I noticed that I can't rebalance some channels from any of my other channels. I have only six or seven channels and would like to expand to at least 10 for now.
Up until now my strategy for choosing nodes to open channels with was to use https://moneni.com/mcb/nodematch to maximise for the total number of nodes my node can reach with the least hops.


text:
How many bytes does a Bitcoin address weight?
One of the biggest issues of Bitcoin blockchain is the ever increasing size. Each address has a weight in bytes or bits. What’s holding someone from creating trillions of different addresses and breaking the block chain this way? Overflowing Bitcoin blockchain by creating addresses? Bitcoin blockchain is unbreakable so I heard. Can it be broken by forcing the size increase and making it unprofitable to run a full node?

Addresses don't get registered anywhere. You can create as many as you want without having impact on any other network participant.
Addresses only get tracked by others once funds get sent to them. Needing to tie up funds for each address suffices to curb the proposed attack.


text:
Why do people claim that governments cannot confiscate Bitcoins?
Let's say that I practice impeccable data security processes using dedicated devices, encryption, and no clear-text backups. Even if they cannot find all of my backups, this doesn't protect me from criminals or government agents threatening violence to steal or confiscate my assets.
Please explain how having Bitcoin is any different in practice from having a bunch of gold bars that they can just steal?

Hi Marcoa R, I've compacted your question to focus it on the main point. If you feel that I  dropped a relevant aspect, please feel free to rollback the edit or further edit the post to readd it. In the future, perhaps try to focus on the main gist of your question.

While it is true that Bitcoin can still be physically taken away from you, it is still much harder to do that than it is for a government to confiscate your fiat stored in a bank account (as most fiat is). With fiat in a bank account, the government can simply go to your bank and order them to freeze your account and lock you out of it. There is no need for them to track you down, no need to go to your physical location, and no need to beat you up. It is very simple for the government to just freeze your bank account and thus confiscate your money.
But with Bitcoin, as you say, they need to go to your house, find your Bitcoin, and forcibly take it from you. It is much more work to do that as it involves people physically going to your home in order to physically seize the devices holding the keys to your Bitcoin.
And yes, this is not any different from having a bunch of gold or a bunch of cash. As with anything which is physically in your possession, the government can confiscate it by physical force. But those physical currencies and valuables are much less convenient to transact with, particularly online.
Furthermore, many countries have regulations regarding the amount of cash that you can be carrying across the border. They often will require you to declare it, and in some instances, the money can be seized by customs. Even when you are not crossing borders, simply having a large amount of cash or other valuables in your possession may raise the suspicion of police who may confiscate them. Bitcoin does not have similar problems (with the exception of novelty physical Bitcoin coins).
With Bitcoin, you can have all of the keys for your Bitcoin stored on a flash drive, a laptop, paper, or something else. It won't be extremely obvious that you are transporting large amounts of money. Even hardware wallets just look like random electronics and flash drives so they don't raise much suspicion. So if you are carrying some Bitcoin on your laptop, it is unlikely to be seized by customs agents or police where carrying similar amounts of cash or gold bars might be.
Lastly, there is also a philosophical form of confiscation that governments partake in - inflation. Central banks nowadays routinely issue more and more fiat currency leading to some amount of inflation. Over time, any cash that you have will have less purchasing power. If you simply save money, then over time, the government is effectively confiscating some of your money through inflation. On the other hand, Bitcoin has a known supply that eventually becomes fixed. While there is some inflation, because of the eventual fixed supply, Bitcoin largely becomes deflationary thus allowing your saved Bitcoin to actually have a greater purchasing power in the future. While precious metals currently have a fairly fixed supply, theoretically it would be possible to find large quantities of them somewhere else in the universe which would then cause the value of those precious metals to go down. With Bitcoin, that is not possible.

Perhaps also note that they will need your active cooperation (possibly under strong coercion) to actually transfer the assets to a different owner. Merely confiscating the medium which contains the wallet makes it inaccessible to you, but that is not the same as actually confiscating what's in the wallet.


text:
How does bitcoin impact the real economy?
I have a question in my head since a while.
What if Elon Musk sells all his companies (spacex, Tesla, ...) and puts all the money in bitcoin and then loses the keys. What is going to happen to the real economy?

Hi dmx, we already have a few questions that are very similar to this one. Is your question answered by one of these? https://bitcoin.stackexchange.com/q/50497/5406, https://bitcoin.stackexchange.com/q/41744/5406, https://bitcoin.stackexchange.com/q/1638/5406, https://bitcoin.stackexchange.com/q/62112/5406

If Musk sells his companies, the companies (and their assets) still exist.  If he loses his private keys, the blockchain still exists.  Aside from the possibility that the new owners of the companies cannot replicate some unique skills belonging to Musk, why would you expect anything to change?

I think bitcoin is like a knife, it can be used for both cooking and killing. If you say I use it for cooking, it does not mean that others do not use it to kill.
Terrorist groups, spy agencies and even criminal groups are all abusing Bitcoin.


text:
bitcoin-qt 0.21.0 in win10 keep hight disk I/O, and GUI not respond
My OS is win10, and I used to use bitcoin-qt 0.13.0, it was fine but I found it syncs very slow now, so I upgraded bitcoin-qt to 0.21.0.
I feel 0.21.0 syncs much faster, but it always keep high disk reading (about 2M bytes /sec average) even while income network traffic is low (and disk writing is 0).
This is somehow strange, and causes GUI almost not respond. The process is not frozen  or dead locked, the block chain sync is progressing, and my mouse click can get handled in about 2 minutes.
Is there any command line option could prevent bitcoin-qt 0.21.0 from high disk reading?


text:
Do I need to pay for a Transfer Code to withdraw funds from account?
Do I have to pay a transfer fee to complete my withdrawal to receive a transfer code?

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


text:
How fast is the Bitcoin (mining) network?
How fast is the Bitcoin mining network compared to other distributed computing networks? ;)

I'm unsure what you are asking here... how fast it is... doing what? What exactly would you like to compare?

This is probably to gather evidence regarding a Guinness Book of Records entry.

According to Bitcoin Charts, it is equivalent to 127.25 PetaFLOPS currently. This would make it faster than 500 fastest supercomputers in the world (58.9 PetaFLOPS), or Folding@home (4.1 petaFLOPS) [reference]. However, this is only equivalent computation speed, if you would measure actual amount of FLOPS of Bitcoin mining it would be... 0, as Bitcoin does not use floating point operations. Moreover, I'm not exactly sure how Bitcoin Charts computed that figure.
However, objective measure of how fast Bitcoin is in computational sense, would be it's current hashrate - 9.738 Thash/s. At peak rate it was estimated to be over 15Thash/s.
As a side note, one might also be interested in the speed of propagation of blocks in Bitcoin network, which is estimated to be close to 2 seconds.

The Bitcoin network is made up of lots of different types of hardware.  The only thing we know for sure is how quickly it can solve blocks by running the sha256 hashing algorithm.
The difficulty is calculated every 2016 blocks (2016 blocks is 6 blocks per hour * 24 hours per day * 14 days, so approximately every 2 weeks) in an attempt to keep the average block generation time being 10 minutes.
Given that, we can calculate the hash rate in Thash/s over the last set of 2016 blocks.  At difficulty 1, an average of 2^32 hashes need to be calculated to solve a block.  This increases linearly with difficulty.  So we can use the following command to look up the current difficulty and use it to calculate the approximate hash rate:
$ python -c "print $(bitcoind getmininginfo | grep difficulty | sed 's/.*: \(.*\),/\1/') * pow(2,32) / 600 / 1e12"
9.87590105239

bitcoind getmininginfo is a new RPC call which is available in the current git HEAD, and will be in the next release of the official Bitcoin client.