text:
I am confused about the difference between a fork and a client, can someone explain?

My understanding is that clients are different software environments which run on top of the decentralized computing infrastructure which is the blockchain architecture. The most popular of which by a large margin is Bitcoin Core. This made sense to me but I recently read that different clients process different types of transactions. For example, Bitcoin XT would process different transactions than the Bitcoin protocol. Would this not make it a fork of the original blockchain as opposed to a different type of software. How does Bitcoin Cash come into this also as they process different types of transactions but have their own blockchain? Should they not also be listed as a client?

Since everything is open source, anyone can take something, make some changes and it'll be different.
Some good examples:

Dash
Dogecoin
Litecoin
Bitcoin Cash

Just a few examples of someone taking Bitcoin's core code, tweaking it, and releasing it. Given some of them did it in different ways. Doge for example started over with Block 0. It's considered a "new coin". While Bitcoin Cash used the history of Bitcoin up to a specific block, before their changes took effect. This is a hard fork.
A node configured to run (or in some cases simply a flag in the config file) Dash, will not receive/process/store Litecoin blocks. The same way a Bitcoin node will not receive/process/store Bitcoin Cash blocks (once the block where the hard-fork occurred was hit). (I'm aware there are nuances to this but brevity is taking priority)
Finally to touch on your first point, there can be many clients for a specific coin. It's open source. There is no "official" client for Bitcoin as it's decentralized from the ground up. Some chains use a more centralized development process like the Ethereum Foundation. While they provide more input (as well as some communities have more sway over specific chains) it is ultimately up to the individuals running nodes on if they will upgrade and support the changes. This is best highlighted in the hard fork for Ethereum 25 October 2016. Those that did not fork were left with the original code and original coin now referred to as "Ethereum Classic".  Those that did upgrade, were then using the current day "Ethereum".
In the end no matter what client is used, it must follow the same basic protocols as the network it's trying to interact with. As long as it does, then it can be used.

Bitcoin and Bitcoin Cash have separate blockchains. A Bitcoin Cash transaction is invalid for a Bitcoin node, and the converse is also true. On the other hand, a Bitcoin node could connect to and communicate with a Bitcoin Cash node (and vice versa), which resulted all of the nodes to share the same pie chart. In late 2017, the Bitcoin Cash nodes changed network magic value. If node A tries to connect to node B, and they have different magic values, they drop the connection as they understand they are nodes of different networks. Since then, BTC and BCH networks are separate and have different pie charts.
Bitcoin XT's situtation was different. Although many nodes switched to it, a chain split (known as hardfork) did not happen, because of the Hong Kong agreement.


text:
Why does it make sense for mining pools to send empty blocks to miners in Stratum v1?
I am reading the recently released specs of Stratum v1 versus Stratum v2. One of the features is that "it is equally as efficient for pools to send full blocks for miners to begin working on as it is for them to send empty blocks ". I don't understand why it is efficient for mining pools to send empty blocks with Stratum v1 and at what stage of the mining process they send empty blocks. So this boils down to two questions:

Why is it efficient for mining pools to send empty blocks with the current Stratum protocol?
At what stage of the mining process do they send empty blocks? Is it when they are waiting for a miner to submit a block with valid proof-of-work?

Historically, block template generation has been very slow. It was faster to send an empty template with no transactions, then wait for the mining pool to create a block template with transactions, then send the result to the miners when it was ready (in the order of ten seconds occasionally). This is no longer the case in modern versions of bitcoin core.

source: Stack Exchange

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

sort: votes


text:
Miner's pool and Mempool relationship
I am wondering why we need Mempool (central and aggregated pool) while each miner has its own pool?
If we need the Mempool as an architectural design, how we can make sure that miners are sending their transactions to Mempool?
Is that possible for a miner to confirm a transaction on its own(Privately) but not send it to the Mempool(Shared-Public Pool?
Please correct me if my understanding from Miner pool as a private and the Mempool as a public area is not correct.
Thank you

The mempool is not a central or shared pool, every node has its own separate mempool (though a node does not have to keep a mempool, it will still function fine without one).

Addendum
Solo miners do not now share mempools and never have.  A solo miner can mine without any specific communication or coordination with other miners. Obviously nowadays a solo miner needs an enormous amount of hashpower to have any prospect of profit.
There is nothing in the original and current core network protocols for Bitcoin that explicitly coordinates, synchronises or shares mempools. It is likely, particularly when the network is less busy that all nodes have mostly the same set of transactions in their mempool. This is simply because the time for data to diffuse across the network is typically much less than the block interval.
Nowadays, because of the huge increase in mining and the consequent huge increase in mining target difficulty (to keep block interval roughly constant) - Mining has become very expensive and so most miners pool resources rather than mine separately.
Miners who are members of mining pools exchange information using one of several completely separate network protocols (e.g. Stratum) that are different and separate from the core network protocols of Bitcoin. I don't know these mining pool protocols or whether block templates are centrally chosen or selected in some egalitarian distributed method but, in principle, I don't see it is essential for them to share or synchronise mempools either.

Thanks for the response. I am still wondering how miners are sharing their mempools? If I am a miner and I do not share my mempool, what happens in the bitcoin protocols? Is that possible for me to just mining transactions in my pool? thanks

Thank you so much. I got the point. I have observations on transactions confirmed directly without waiting in mempool. But the miners are not solo. How we can interpret that? Is that discriminative behaviour among the agents requesting the service?

@motiv: Miners can mine their own transactions without first broadcasting the transactions - is that what you mean?

There can be other explanations too. Transaction propagation is not perfectly synchronizing for various reasons (different mempool sizes, network failures, attempted double spends), so there is no guarantee that just because you didn't see a transaction in your mempool that nobody did.

I got the point. thanks

There is only one mempool. This is where all of the transactions waiting for verification sit. Mining pool nodes take the transactions with the highest fees to fill newly discovered blocks. Mining pools may crop their version of the mempool to their desire to better allocate work to the miners.
Mining pools are 'pooled' hash rate.

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


text:
How to detect data insertion transactions in Bitcoin Blockchain?
I am wondering how I can detect data insertion transactions from the normal ones in blockchain.com UI?
https://www.blockchain.com/explorer
Thank you

Why do you assume there is a difference between the two?

I wanna separate data insertion transactions that are related to the Omni layer from the normal one which is related to the payment system feature of the blockchain.

I could find by processing output scripts and detecting op-return.


text:
did FIBRE technology improve the pace of Mempool data(pending transactions) propagation in Bitcoin?
The FIBRE technology seems to transmit the mined blocks. I am wondering if this technology transmits pending transactions in the Mempool as well.

Your question appears to be asking about the present time, but FIBRE was shut down in 2020 or 2021.

Thank you for your comment. I am study the effect of that on before 2021. I am wondering what was the mechanism for that.

Reading https://bitcoin.stackexchange.com/q/80927/5406 and https://bitcoin.stackexchange.com/a/56494/5406 it seems that it was only used for block relay, but I don’t remember in detail. I’m gonna suggest to some people that might remember to take a look at this question.


text:
NFT/data insertion transactions in bitcoin (Taproot)
I want to find transactions in Bitcoin which are of data insertion type. The new taproot and scripting feature in Bitcoin allows for NFT data insertion. I am wondering how I can detect these types of transactions.
Thank you

Does either https://bitcoin.stackexchange.com/q/118227/5406, or https://bitcoin.stackexchange.com/q/117018/5406 answer your question?

Please also note that NFTs and data insertion were NOT enabled by Taproot. See for example: https://bitcoin.stackexchange.com/a/118242/121614


text:
Classifying Miners based on their Location
Is there any way to classify the bitcoin miners based on their geographical locations?
Is there any possibility of doing so for the participants in cooperative mining as well?
Thank you


text:
How do merkle trees ensure credibility to blockchain, when full node wrongly denies a presence of a txn in a block?
How can Merkle Trees ensure that a full node doesn't lie to a thin node that a txn t is not present in a block B if infact B contains t? How can a thin node tell if the full node is lying if the full node denies the presence of a txn t in a block B and doesn't send any hash values(for the thin node to verify) and instead claims it can't generate hashes that are not there.
PS: Don't mind the informal style of my questioning. I'm just trying to get an intuitive understanding of Merkle Trees at first.

Your instinct is correct: a full node can lie-by-omission to a light client and deny them proof that a transaction was included in a block. This is a well-documented vulnerability of SPV wallets and the only mitigation really is to connect to more peers (you only need one "honest" peer).
This problem is also somewhat addressed by BIP157 aka "Neutrino". In this protocol, the light client scans entire blocks for its own transactions. It knows which blocks to check based on filters provided by full nodes. Of course, this brings us back to the first issue: what if a full node provides an invalid filter? Eventually we might see a soft fork that requires valid filters to be inserted in some part of the block, secured by proof-of-work.
Currently, BIP157 offers this:

Unless securely connected to a trusted peer that is serving filter
headers, the client SHOULD connect to multiple outbound peers that
support each filter type to mitigate the risk of downloading incorrect
headers. If the client receives conflicting filter headers from
different peers for any block and filter type, it SHOULD interrogate
them to determine which is faulty. The client SHOULD use getcfheaders
and/or getcfcheckpt to first identify the first filter headers that
the peers disagree on. The client then SHOULD download the full block
from any peer and derive the correct filter and filter header. The
client SHOULD ban any peers that sent a filter header that does not
match the computed one.


text:
ASICs not receiving all nonces
I have an Antminer S9 where one of the chains is not hashing. In the logs I see the following:
get nonces on chain[7]
require nonce number:912
require validnonce number:57456
asic[00]=00 asic[01]=00 asic[02]=00 asic[03]=00 asic[04]=00 asic[05]=00 asic[06]=00 asic[07]=00
asic[08]=00 asic[09]=00 asic[10]=00 asic[11]=00 asic[12]=00 asic[13]=00 asic[14]=00 asic[15]=00
asic[16]=00 asic[17]=00 asic[18]=00 asic[19]=00 asic[20]=00 asic[21]=00 asic[22]=00 asic[23]=00
asic[24]=00 asic[25]=00 asic[26]=00 asic[27]=00 asic[28]=00 asic[29]=00 asic[30]=00 asic[31]=00
asic[32]=00 asic[33]=00 asic[34]=00 asic[35]=00 asic[36]=00 asic[37]=00 asic[38]=00 asic[39]=00
asic[40]=00 asic[41]=00 asic[42]=00 asic[43]=00 asic[44]=00 asic[45]=00 asic[46]=00 asic[47]=00
asic[48]=00 asic[49]=00 asic[50]=00 asic[51]=00 asic[52]=00 asic[53]=00 asic[54]=00 asic[55]=00
asic[56]=00 asic[57]=00 asic[58]=00 asic[59]=00 asic[60]=00 asic[61]=00 asic[62]=00

followed by a whole stream of these (I don't think its necessary to paste all of them):
Below ASIC's core didn't receive all the nonce, they should receive 8 nonce each!

asic[00]=00
core[000]=0 core[001]=0 core[002]=0 core[003]=0 core[004]=0 core[005]=0
core[006]=0 core[007]=0

Later in the logs, I see the following:
last_nonce_num:0
chain[5]: All chip cores are opened OK!
Test Patten on chain[5]: OK!
chain[6]: some chip cores are not opened FAILED!
Test Patten on chain[6]: FAILED!
chain[7]: some chip cores are not opened FAILED!
Test Patten on chain[7]: FAILED!

Does anyone have any idea what the problem is, and a possible solution?

You yourself have stated that your boards are failing to hash.
It looks like some form of system test against the boards is failing.
I know I am being captain obvious here.
chain[6]: some chip cores are not opened FAILED!
Test Patten on chain[6]: FAILED!
Until you can find the point of failure with a volt meter, or replace the failing boards.
You can try tuning the voltage / frequency of the miner to see if this helps stabilize them.

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


text:
Mastering Bitcoin: Where is the checksum coming from when running bx base58check-decode?
For example, if I run bx base58check-decode with the base58 encoded private key of Kxj5ejwPg2s2ejZHW7N1zAydD4fkmFi9j19QRmgeVK9mXL3wFMmp from this example, I get the following:

{
    checksum 2274467570
    payload 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b982401
    version 128
}
The payload, as well as the version, make sense to me; however, if I convert the checksum to a hex, it doesn't match the checksum of F29E9187 that I'm expecting, i.e., I understand how to form it per this question. But I don't understand how 2274467570 and F29E9187 are related.

decimal to hex, and then reversed ordering:
$ echo "obase=16;2274467570" | bc
87919EF2

reversed:
87 91 9E F2 -> F2 9E 91 87

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


text:
Why are the seeds different when going from seed to mnemonic and back using bx?
From an example in the documentation:
$ bx seed | bx mnemonic-new | bx mnemonic-to-seed | bx hd-new

655a1ed2d4fef69bb314198c7327f23c
grab special regret prepare urge evidence slush lobster midnight odor wish ketchup
57bae342ae8e69eb63f17ef993a90a59159e0f78114b602bf0ebabfec0e5d086e883c31975bf03f8a47a32853452623094d1303fd0549745db457145e5756582
xprv9s21ZrQH143K43CUCgNp5SmXzg2axQx2P4WupA2zEnKpFM19QfqfdqfpJR3yfzAXZnsHeUaQhWQMwyuqL8DbdeLeCbdMoKNn6pCY4RUn2pK
In Mastering Bitcoin, the example given here shows it going back to the seed that was originally created; this was done using an older version of bx though. Can someone explain how the seeds from line 1 and line 3 in the example are encoded/related?

Warning: bx seed generates insecure seeds from a pseudorandom number generator and very low entropy.

They adopted bip39 where the seed mnemonic is run through a key derivation function to derive the seed. This is an irreversible step.

answering the wrong question, overloading the term "seed" is too common

Fundamental flaw here, multiple meanings of the word "seed"even within discussion of just BIP39.
The "entropy" is a better term for the BIP39 starting point. Then the endpoint of the process should be "BIP39 numeric seed".

"Convert the entropy to a BIP39 mnemonic. Use that mnemonic plus a (technically optional but no) passphrase as the inputs to produce the BIP39 numeric seed. End of BIP39. "

is how I would tell the story.
Now, looking at this from *Mastering Bitcoin *

The seed can be encoded using the mnemonic-encode command:

$ bx hd-mnemonic < seed > words
adore repeat vision worst especially veil inch woman cast recall dwell appreciate

The seed can then be decoded using the mnemonic-decode command:

$ bx mnemonic-decode < words
eb68ee9f3df6bd4441a9feadec179ff1

Andreas Antonopoulos is here clearly using "seed" to refer to the entropy. The process described does not involve hashing, or cryptographic "encoding", it's just a change in representation, like going from binary to hex.
Except for the N/32 checksum getting added.
Which means an input entropy of 256 bits is entirely reversible, but the last 8 bits to get to 264 (24 words x 11 bits) is the result of the checksum process.
What the other answers here are referring to is not the "entropy seed" but the output, the "BIP39 numeric seed" which is indeed a one way derivation process.
I believe the bx mnemonic-decode command may have gotten removed simply because it is useless, or at least I cannot think of a use case.
I do not think it stopped working in the transition to BIP39. EDIT The entropy to mnemonic "conversion" is reversed by many tools - see https://iancoleman.app

Yes the entropy and mnemonic "encoding" process is fully reversible http://www.petecorey.com/blog/2018/05/07/reversing-bip39-and-the-power-of-property-testing

Also with https://github.com/bitcoinjs/bip39

A note for those reading this in the future: "bx seed" is completely insecure and will result in your money being stolen.  See CVE-2023-39910, aka the "Milk Sad" issue:

The use of an mt19937 Mersenne Twister PRNG restricts the internal
entropy to 32 bits regardless of settings. This allows remote
attackers to recover any wallet private keys generated from "bx seed"
entropy output and steal funds. (Affected users need to move funds to
a secure new cryptocurrency wallet.)

I asked the same questions regarding the example in Mastering Bitcoin and here is the answer:

The old mnemonic-decode (electrum v1 mnemonics I believe) was dropped
  from libbitcoin before version3 and replaced with BIP-39 mnemonics.
  libbitcoin version4 also adds in electrum v2 mnemonics. Unlike
  electrum v1 mnemonics (which are symmetric), BIP-39 is asymmetric
  --https://github.com/libbitcoin/libbitcoin-explorer/issues/366

asking the wrong question, overloading the term "seed" is too common


text:
How can I recover a Core Lightning node as safely as possible if the backups might be out of date?
Suppose my Core Lightning node has suffered a catastrophic failure. I have a copy of the HSM secret. I also have copies of the emergency.recover file and the backup file maintained by the backup plugin.
However, I can't be certain the emergency.recover file or the backup file are absolutely up to date. My node does a small amount of routing. Even if the backups were copied off the failed node a minute before it died, I can't be completely certain there wasn't a change in the channel balances during that minute. The situation might be even worse and the backups might be several hours old.
What's the best way to deal with this to reduce the chances of losing funds? Can I test the backup in some way to see if it is up-to-date? Or do I have to start up the rebuilt node using the backup and wait to see if a penalty transaction gets triggered?
Is it safer to try using the emergency.recover file first? If the peer cooperates, is this completely safe? If the peer tries to cheat me, do I still have time to use the backup from the backup plugin?
This hasn't happened yet, but I want to learn how to handle it if it does.

This is a really good question.

Is it safer to try using the emergency.recover file first? If the peer cooperates, is this completely safe? If the peer tries to cheat me, do I still have time to use the backup from the backup plugin?

Yes this is safe, the peer can not cheat for two reasons:

The backup is encrypted so if something changes your node you will easily find out.
If your backup db is old I think you can start from this recovery before and if fails (maybe you have no peer that supports the peer backup feature) you can try to use the database.

Before trying this you should read in deep this page https://docs.corelightning.org/docs/backup-and-recovery

What's the best way to deal with this to reduce the chances of losing funds?

The best practice is not making the backup of the database by hand, as you said this will be always outdated. CLN has different ways to do the backup like [1].
As good news, all the implementations today use option_data_loss_protect. This means that you trigger this part of the spec [2]
  - otherwise, if it supports `option_data_loss_protect`:
    - if `next_revocation_number` is greater than expected above, AND
    `your_last_per_commitment_secret` is correct for that
    `next_revocation_number` minus 1:
      - MUST NOT broadcast its commitment transaction.
      - SHOULD send an `error` to request the peer to fail the channel.
      - SHOULD store `my_current_per_commitment_point` to retrieve funds
        should the sending node broadcast its commitment transaction on-chain.
    - otherwise (`your_last_per_commitment_secret` or `my_current_per_commitment_point`
    do not match the expected values):
      - SHOULD send an `error` and fail the channel.

So your old backup should trigger just force closes.
Good luck.
[1] https://docs.corelightning.org/docs/advanced-db-backup#sqlite3---walletmainbackup-and-remote-nfs-mount
[2] https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#message-retransmission

Thanks Vincenzo! This mostly makes sense, but having read your explanations, I'm now thinking it's better to use the possibly-outdated database backup before emergency.recover. If the peer is honest it makes no difference (right?), but if the peer isn't honest, my reconstructed node using a slightly outdated backup knows some of the outdated channel states and will detect these if a dishonest peer offers them, making it harder to cheat. Whereas if I reconstruct my node using emergency.recover, it will accept any outdated channel state the peer choses to offer it. Have I got this right?

Mh no it makes sense more using the emergency.recover because if you have an old state of the channel the other peer force close the channel with you. So it is better to use emergency.recover and then use your database. In this case you can have the old state, so you are not honest peer (just because you lost the data)

Thanks again. It's interesting to realise that my node is (potentially) "dishonest" in this state. I think I understand the situation now - emergency.recover is preferred not because it has a higher chance of not losing funds (it's the same as the outdated database backup in this respect), but because it allows the channels to remain open instead of being forced closed. Have I got that right now?

yeah, with emergency.recover you are asking the other peer, please provide me the last backup that we did for the channel. So if all goes well you get the last state of the channel from some peer and you can start your node again without any problems


text:
Why is it bad to split up a wallet seed redundantly?
I have been reading a lot about wallet security and this seems to be universally considered a bad idea (see for example this video or this answer), but I am struggling to see why it is not a good choice in some circumstances.
Let's say I have three moderately secure locations I can store information in - my own home and the homes of some close family, perhaps. I want to arrange things so access to the information at any two of those locations allows me to access my bitcoin, in case one location suffers natural disaster or theft, but I don't want anyone to be able to access my coins just by having access to one of those locations.
I create a wallet with a 24 word seed. I don't use Shamir's secret sharing algorithm, because I see this is widely advised against (see for example this article) and is a potential source of risk from cryptography I don't fully understand. Instead, I use a naive scheme I can perform entirely by hand where for each group of three words in the seed, I split them up like this:

Location A
Location B
Location C

word 1
word 1

word 2

word 2

word 3
word 3

So each of the three locations has 2/3 of the words, i.e. 16 words. It's easy to confirm (by experiment, if necessary) that I can reconstruct the full seed from any two of the three locations.
If an attacker gets access to the words in a single location, they only need to guess eight words in order to access the funds. That's superficially 8*11=88 bits of entropy, but since the seed contains some checksum bits I will handwave this down to 80 bits in practice.
My understanding is that 80 bits is not considered incredibly secure, but it is not trivial to break either. If I consider my storage locations reasonably secure and don't expect targetted theft ("we know he has a lot of bitcoins, we are going to break in to steal the words from one location, we have a cluster of machines on standby to brute-force the missing words") but am just trying to protect myself against opportunistic theft ("we broke in to steal the household electronics and any cash lying around, but we also found these bitcoin seed words!"), is it ridiculous to consider this acceptable?
The obvious alternative would seem to be a 2-of-3 multisig scheme. If each of those wallets uses a 12 word seed, an attacker getting access to a single location has to guess 12 words or 128 bits of entropy, which is obviously stronger. On the other hand, with 2-of-3 multsig:

An attacker getting access to a single location will get a copy of the master public keys I have to store at each location and can therefore see the wallet balance and transactions, which may incentivise a targetted attack or compromise my privacy in other ways.

The need to store the master public keys in each location adds a level of complexity and risk to the backup. I am probably more likely to lose my bitcoin through a mistake than the actions of an attacker whatever scheme I choose. If the paper in any one location suffers minor damage, I might still be able to make out a seed word - it's English, after all, and I know it comes from a certain list of words - whereas the gibberish string of characters which is the master public key doesn't have this extra redundancy.

It feels like this seed-splitting scheme has its own set of tradeoffs, but it's not obvious to me that it is outright bad. What am I missing?

Your analysis is correct. The weakness in this scheme is that if one location is compromised, only 80 bits of security are left. But 80 bits is sufficient for practical purposes and would likely take at least a decade to break assuming a highly-resourced attacker was willing to devote significant resources to breaking it.
This assumes the original seed was chosen in an unbiased manner. If there are any defects in the scheme used to generate the original seed, there might not be enough security left if 2/3 of the key is compromised.
Obviously, doing this with a 12 word seed would be a complete disaster.

I disagree with the "decade" assumption.
By my math it takes roughly 4.3 trillion years to brute-force 8 missing words on a single GPU. Which means that even a billion-fold increase in efficiency, through ASICS and more hardware, remains safe. A trillion-fold increase in efficiency would cost more than the funds being secured.
To arrive at the 4.3 trillion years number:
BIP-39 provides 128 bits of entropy per 12 words. Per word known, this reduces by 11 bits. For 8 words, then, that is 2^84 combinations, or roughly 19 trillion trillion.
A single GPU with OpenCL code optimized to stay in its fastest 64kb of memory and run parallel on all cores did 143,000 combinations per second as per https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752
A year has 31,536,000 seconds.
1.93e+25 / 143,000 / 31,536,000 = 4.3 trillion, give or take.
Granted that assuming that all possible combinations need to be checked is not a safe assumption. The likelihood of finding the correct one early goes up as the computation nears its end. But that does not reduce the magnitude of the task meaningfully.
Checking this math and poking holes in it will be very welcome. I'm relying on it to be correct, right now.


text:
SECP256K1 Minimum Value for Private Key
I've been looking into Elliptic Curve Cryptography, in particular the SECP256K1 spec which is used in Bitcoin and Ethereum. So I understand that the Generator point G is fixed based on the spec and that a 256-bit private key (privKey) is (ideally) truly randomly selected from 1 to 1.157920892373162e+77. The public key (pubKey) is derived from the private key such that the public key is privKey*G where this includes point addition and point doubling operations.
Now what I haven't seemed to figure out yet is that there is a fixed entrance point G which any adversary would need to start at to try and decipher a private key from a public key (assuming a partial rainbow table of values is not used).
So wouldn't that mean the largest value for the private key, which is the furthest amount of steps away from calculating (i.e. 1.157920892373162e+77), is the most secure?
Hence wouldn't private keys below a certain threshold be considered compromised e.g. private keys in the range of 0-1000 for example?
I feel like there is something I'm missing here, any help is appreciated!

If people in general would more often pick lower integers as private keys than larger integers, then it would be a good strategy for an attacker to start with lower integers.
However, the opposite also holds. If people would more often pick larger numbers, then atackers would ideally start at the end and work their way backwards.
In practice, no such bias exists. As long as people use decent proper random number generation, every integer is just as likely as any other, and it does not matter in what order an attacker tries things. He'll need to go through half of private key range on average regardless.
So no, there is no minimum number to start at. Yes, you have an extremely small chance of picking a number between 1 and 1000. But similarly you have an equal chance to pick a number between 76136428194729137 and 76136428194730136. An attacker has no reason to think you're more likely to pick something between 1 and 1000, so why would an attacker start at?
Also, whenever the attacker has the public key, there exist far faster (but still completely infeasible) algorithms to find the private key. These algorithms inherently operate in random order, so it does not matter.

thank you for the well explained answer, I stupidly thought that the Generator point had to be the starting point. In other words I didn't recognize how shortcuts could be made through the range of values using the double and add method and hence an adversary could quite easily start from almost anywhere in that range. This made sense as only being able to use the point addition operation would cause key generation to take a huge amount of time. Silly me, still learning I suppose!

Just a quick question, with the point doubling operation I can skip through the range of multiples as follows: 1G -> 2G -> 4G -> 8G -> 16*G .... and so on. Am I correct i saying this?

Yup, absolutely. In practice multiplying a point with a number is done through a variant of a double-and-add algorithm that computes subsequent powers of 2, and adds the ones that have a 1 in the bit representation of the scalar together.


text:
What does the term Mining means?
People say a "block is mined". What exactly do they mean?
I know mining is related to some group of people does a lot of work and get rewarded for the power and energy they utilized during the process. But what process are they performing and why?
I read from white paper of bitcoin that they perform work like guessing the nounce number which is randomly generated number attached to the block. So, is it really necessary to attach this random number to the block containing transactions in the first place and then wasting resources in guessing it.
I didn't wanted to flood this portal with small questions like this, so I think only in one go the explanation to this thing will work.


text:
What founders obliged to do if their ICO hadnt raised the required sum
If ICO hadnt raised the required sum is it considered failed and what founders of the company obliged to do with sold tokens and their investors?


text:
base58 cannot get 34 chars results (as Bitcoin address does) but 68 chars
I am trying to convert public key hex to Bitcoin address.
From this website http://gobittest.appspot.com/Address, I can do some test.
For example, I have this public key:
04b4d653fcbb4b96000c99343f23b08a44fa306031e0587f9e657ab4a2541129368d7d9bb05cd8afbdf7705a6540d98028236965553f91bf1c5b4f70073f55b55d

According to the website, the address should be:
1DU8Hi1sbHTpEP9vViBEkEw6noeUrgKkJH

which is the base58 encode of 0088C2D2FA846282C870A76CADECBE45C4ACD72BB655DA1216.
However, if I do Base58 encoding directly on 0088C2D2FA846282C870A76CADECBE45C4ACD72BB655DA1216 on this website https://www.browserling.com/tools/base58-encode, I will get:
bSLwwticQjhNvEtqTMZXbn3dLmFrPvNrDGE4hmHsfADpHWb3b2ruh3XqtNzv8ESS8V6V

which is totally different from the 34-char Bitcoin address.
Anyone knows why?

When you use that site, you are encoding the hex as a hex string, not of the actual bytes that they should be. The base58 encoding for addresses operates on the bytes themselves which are represented in the hex string. However that website is just encoding the hex string (which, as bytes, is double the length and is entirely other data).

Andrew Chow told you why. Now I'll tell you how.
First, convert hex to ASCII (I suggest this website)
(I can't copy the ASCII result below, since that would cause problems.)
Then copy the weird-looking ASCII text it created, and paste it to the Base58 Encoder.

Done!


text:
Very hard to sync Core Client from scratch
Recently I started running a Core 15.1 node with the blockchain on an external hard drive, and found it very hard to fully sync the blockchain.
The problem I keep running into is that (in about 90% of my attempts) the sync does not complete. A DB corruption occurs at some point (usually pretty late in the game, maybe 36 hours into it).
I did some digging in forums and saw that I am not the first user to notice this problem. Peter Wuille mentioned that he does a full sync on like a weekly basis and it always works, and he thus suspects that these type of issues are due to sub optimal hardware.
That seemed very reasonable at first because my initial attempt was done using a pretty old 400gig pocket hard drive. So I switched hard drives.
By now, about 2 months later, I have tried to sync the blockchain from scratch about 20 or 30 times and only twice managed to complete the process.
I did that on 4 different types of hard drives, including a brand new 1T Western Digital.
One may say that all 4 hard drives I used are "suboptimal", but I would object to that because

After the sync does complete, the node runs just fine.
I think it is
desirable to be able to run a full node on a raspberry pi with a
pocket size hard drive (note that I run the node on a raspberry pi
but use my linux desktop to do the initial sync)

Now the issue I have here is not so much the crash during sync, but the fact that when I restart the client after the crash the only option is to basically start from scratch (If I understand correctly, the client is not necessarily downloading everything from scratch but that is not my point) and sync again from Genesis.
Ideally I would like the client to keep synching from the point it successfully got to and not re sync from scratch on such errors.
I am wondering if this resync from scratch on error is necessary. I assume that corruption occurs in one (or more) of the files in the blocks or chainstate directories. If that is so then why sync from Genesis? Is it not possible to, say, delete all files post the corrupted file and sync from there?
If there is no fundamental reason for this behaviour, I would also appreciate a pointer to the relevant code in the client.
Thanks!!

Database corruption means the state of your node is corrupted, not just data it downloaded.  Resuming after state corruption would be like resuming your life after having a lobotomy.
During synchronization your node operates at hundreds of times its normal load: Consider, Bitcoin has existed for over 3000 days yet sync will complete in a day. This tends to expose marginal hardware. "suboptimal" would not be a very accurate way to describe it, "totally broken" would be better.
USB drive in general are notorious for causing corruption. Not only are the drives themselves often unreliable, but many people often suffer issues from their USB controllers and even cables.
At the expense of several more gigabytes of space usage Bitcoin nodes could periodically back up their state so that they could recover more gracefully from corruption... but the cost of doing that is great enough that the gains aren't completely clear. Especially since hardware that is messing up is also probably likely to corrupt the backups.

I have two and a half comments to make, from similar experience: a RasPi is a nice piece of hardware, but may not be the optimal device for the full node. Besides the many links in the forum here and bitcointalk.org, I think it boils down to these two issues:
The process of loading the blockchain into your computer is I/O heavy to the disk. And as the RasPi has only a USB port to the disk, it is times 10 slower than a standard interface to a disk drive. Whereas my std IDE interface is running at +20 megabytes per second, I had a hard time to achieve more than 2 megabytes per second via a USB device. And of course the SSD runs even faster...
But this is only the part of writing data to the disk. Then you also have to read previous sectors from the disk, which contain several blockchain data with previous transaction data. Here the amount of data is less relevant, but the disk I/O cycles come into the game. This is like randomly seeking through the disk drive, and might also slow down the process. Measuring CPU load showed +4.x, so there where more processes asking to do I/O, than the system could handle. I also played with the memory parameters, but to no avail. The I/O was the limiting factor.
And then there is the capacity of the RasPi CPU. I have learned, that my RasPi loaded the blockchain fairly well and in steady process up to July/August 2017, and then started to choke every now and then. This is exactly the time when blocks got more and more full. And I understand, that loading a full block means many, many data to be verified, adding load to the RasPi. For the operating system, I had more success loading the blockchain with Linux. Windows was simply not reliable enough. But still it took me more than 3 weeks on a RasPi2 to get the blockchain loaded.
What I then did: I have three different Macintosh’s, two equipped with SSD and Intel Core Duo and 4 Gig RAM (so fairly old, like +6 years). These SSD systems didn’t have any problem to download the blockchain, it still took them between 2 and three days.
Btw: I observed exactly the same issues with Ethereum and RasPi. So for me it looks like the RasPi has it’s limitations, when it comes to high loads. I haven’t debugged anything, but it looks like the RasPi is loosing some interrupts at high load, which leads to the errors in the writing of data to the disk. Also I hadn’t used a cooling device, so CPU got certainly to it’s max temp, when calculating all the sha256, base58 and sigs.
To circumvent this, I copied the downloaded blockchain from the Mac with the SSD to the RasPi, and then he would work again like a charm.
Hint: I did these tests with a RasPi2 up until Nov 2017, the type3 model should be slightly faster, but not magnitudes.
So when you say, you load the initial blockchain from your PC, is HDD still connected to the USB drive? Have you tried I’ver local disk, and then do an sync to the RasPi? Maybe worthwhile to check. I found, that the bandwidth of the internet link is not the limiting issue, while you are downloading the blockchain...

Thank you for the elaborate answer. As I said, I do not use the RasPi for  the sync for the reasons you mentioned, but rather sync directly to the USB drive on the PC. I guess what interest me the most is whether it is in fact necessary to sync all the way from Genesis when an error occurs during the sync, and whether somehow possible to continue sync from "the last point to which it did sync correctly".

Ah, yup, I see...  I was looking for the same, but couldn’t see a way on how to do so. And I haven’t looked into the code...

you have certainly seen the answers already on bitcointalk. For the other readers, here: https://bitcointalk.org/index.php?topic=3286587.0

Just stepped over the thread in bitcointalk: https://bitcointalk.org/index.php?topic=3307283.0 (by chow: Use the rescanblockchain RPC command which takes a height parameter)


text:
How many transactions per second can blake2s algorithm can handle?
i saw the hash functions speed (miBps) are 947 according to this website: https://blake2.net/
but how many transactions blake2s algorithm can handle? Verge uses the same algorithm right?
more about blake2s
https://eprint.iacr.org/2013/322.pdf

The number of transactions per second a blockchain can process is not correlated to the relative computational speed of the hashing algorithm.
A faster hashing algorithm just means the network's miners will be able to attempt more hashes per second, given the same (general purpose) hardware.
The number of transactions per second will depend on the block size, transaction size(s), and the average block time.

thanks for the answer, how can I calculate it in Verge? simple sample for that? thank you.

@chicolima (megabyte/block) / ((megabyte/avg transaction)*(seconds/block))


text:
it is any command line to check the ammout of coins willl be create after build the wallet?
it is any command line to check the ammout of coins willl be create after build the wallet?
i just cloned bitcoin and changed the ammount of coins to be 10 million
MAX_MONEY = 10000000

so i would like to know if it is any command to check this value I inserted.
i know i can check
the amount in circulation using the RPC call gettxoutsetinfo

First of all, changing MAX_MONEY won't change the total money supply.  See Why doesn't changing MAX_MONEY change the maximum number of coins?  You will instead have to specify a new initial block reward and halving interval.
There isn't a command line option to display the total number of coins to be created.  But there is a unit test in the source code, called subsidy_limit_test that computes this value and compares it with the correct number for Bitcoin.  You could adapt this code to do the computation and print out the result, and then change the test so that your code will pass.

many thanks to share your time and knowledge

No, there is no way to display the value of this constant. However, I am not sure that this constant is really doing what you want to do, so let me explain its meaning.
The constant MAX_MONEY is the maximum amount that can appear in an individual bitcoin transaction, for instance in tx_verify.cpp in CheckTransaction. Here, actually two checks are done:

The amount in each transaction output is checked against this value
The total across all transaction outputs is checked

So you could theoretically check that your new value is used after a recompile by submitting a transaction violating these constraints and wait for the error message.
However, what you actually want to do (if I read your question correctly) is to increase the total amount of bitcoin that can be mined. This number is not directly hardcoded, but the limit results out of the fact that every 210000 blocks, the subsidy, i.e. the amount of BTC that a miner earns in addition to the transaction fees for mining a block, is halved. This is done in GetBlockSubsidy in validation.cpp, using the parameter nSubsidyHalvingInterval in chainparams.cpp. Thus if you want to change that value (destroying consensus), you would have to make changes at these locations in the source code.


text:
Bitcoin-cli using getblock to retrieve historical data
I have recently set up a bitcoin node using bitcoind and want to perform some historical queries on the blockchain using getblock with verbosity set to 2.
I am using the default bitcoin.conf file but was wondering what's the best configuration to use to be able to query the blockchain historically?
Do I need to download the full blockchain using reindex or can I run a pruned node and still use getblock to get information on the genises block?
I know in order to use getRawTransaction you need to set txindex=1, but can I not get the same information from getblock (verbosity 2) in the tx array?


text:
BTCPay Server with lightening over testnet - Payment issue
I have recently deployed btcpayserver over testnet to demonstrate the user experience to my colleagues.
Lightening Implementation: LND
Following are setting

Every thing seems ok I can see the service status also comes as online moreover this node is now visible in https://1ml.com/testnet
I tried nc -v server:port as well that also working. So connection is not an issue apparently.
However while testing payments I tried two wallets and but failed to make a payment.
first I tried Lightning: Testnet Wallet but fails with "invalid invoice or address".
then I tried Eclair Mobile Testnet it reads the invoice and initiates the transaction but fails after a while. see the result below;
then I tried open channel directly to my node but it scanned it shown a form with pubkey and host details however upon proceeding with full funding it fails with error message "Failed to open channel:incompatible features"
Can someone please help me to understand where I am doing wrong. I am not able to find any further wallets supporting testnet+lightening Also most of the BTCPayServer tutorial videos are using mainnet.
Wallet 1 error

Wallet 2 error

I currently have exactly the same problem. Did you find a solution?

Luckily yes but only following wallet worked, please note that its direct APK file for android so be careful https://apkpure.com/simple-bitcoin-wallet-testnet/com.btcontract.wallettest


text:
Can a miner give themselves less than the maximum block subsidy if they wish to do so?
The current maximum block subsidy is 12.5 bitcoin. A mined block recently got rejected from full nodes after a miner tried to post the block subsidy as 13.26 bitcoin. But what about in the other direction? Would it have been accepted if the miner posted the coinbase transaction with 10 bitcoin?

Possible duplicate of Can someone explain this weird mining activity?

Yes, it would have. In fact, this has happened before in many different blocks.
The Bitcoin wiki has two instances of this documented:

In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence. Then, in an act of sheer stupidity, a more recent miner who failed to implement RSK properly destroyed an entire block reward of 12.5 XBT in block 501726.


text:
How has the Bitcoin average block size recently risen above 3 MB?
I was aware that the block size could rise above the 1 MB cap due to SegWit. However, my understanding was that the block size would still be limited under SegWit.
My understanding of SegWit is that it partitions the signature part of the block from the transaction part. I also believe I read that the signature part can account for 65% of the block size. If this is true, I would be under the impression that the maximum block size with SegWit would be 1 MB * (1/.35) making the theoretical maximum 2.85 MB.
Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

I also believe I read that the signature part can account for 65% of the block size.

This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the signature components and higher the ratio of signature size to block size. Also, higher the number of multi-sig inputs, more the signature components per input. Also, one has to note that both the signature and the redeemScript form the part of the witness, and not just the signature.

Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

Yes, the theoretical maximum limit of block size is 4,000,000 WU. To calculate size in bytes, it will be very very close to 4,000,000 bytes. Consider a block made up of only one transaction, with only one OP_TRUE anyonecanspend output in that transaction and only one input. Assume the redeemScript and signature are so big that they take up the maximum allowed space in the block (Bitcoin supports custom scripting, so I can theoretically create a script in that way). Now, the standard components of the a block are:
size = 4 bytes / 16 WU
block header = 80 bytes / 320 WU
transaction counter = 1-9 bytes (1 byte in our case as we use 1 tx) = 4 WU
Transactions = variable

So this leaves 4,000,000 - (16 + 320 + 4) = 3,999,660 WU for our transaction.

Standard components of the transaction are:
nVersion = 4 bytes / 16 WU
number of inputs = 1 byte / 4 WU
previous transaction txid = 32 bytes / 128 WU
previous transaction output index = 4 byte / 16 WU
script length = 1 byte / 4 WU
script = 0 byte
nSequence = 4 bytes / 16 WU
output count = 1 byte / 4 WU
amount size = 4 bytes / 16 WU
script length = 1 byte / 4 WU
script (OP_TRUE) = 1 byte / 4 WU
nLocktime = 4 bytes /16 WU

so witness size is: 3,999,660 WU - 228 WU = 3,999,432 WU

Now, to convert this to traditional bytes that would be relayed on the wire:
340/4 + 228/4 + 3,999,432 = 3,999,574 bytes

Note: Standard transaction weight is 400,000 WU, which means full nodes won't relay transactions higher than this cap. However, consensus rules allows transaction to be as high as the block size, which means nothing stops a miner from including this transaction in a block and then mine the block with it.


text:
Is there any benefits to a distributed computing architecture outside of cryptocurrencies?
I was recently talking to a German start-up that was in an accelerator programme. They are building a product which is a distributed database that they are proposing will have efficiency benefits over companies which keep their data on their own centralized database. They talked about leveraging the computational capacity of different computers in the company to increase efficiency. From what I know about distributed computing, it is more inefficient than having a centralized architecture. Are there scenarios where it provides some efficiency benefits and is this being applied?

The only systems which benefit from being distributed are ones that display the property of being "embarrassingly parallel", or some approximation of it. Tasks which do not require a significant amount of data to be transmitted between operating systems, or those which don't require a significant amount of coordination fit this description well. Typically anything like a database is poorly suited to being distributed due to the need for overall consistency, which is very difficult to achieve across a distance.
Bitcoin is the opposite of a distributed system at the node level, every participant in the system is expected to repeat the process of validation in perfect accuracy with the hundreds of thousands, or millions of previous attempts at synchronization that have happened before it. As the number of nodes increases, there is no change in the amount of computation done in either direction.
Generally speaking anything claiming to improve efficiency by using a decentralized, or distributed network should be met with skepticism, simply because this is typically an uphill battle that is taken on for other reasons despite its inefficiency, not in an attempt to gain efficiency. To exemplify this, Bitcoin would be most efficient, most usable, and most reliable if it ran on a single server, but that would largely defeat the design brief of being trust-less.

Unless it actually is an embarrassingly parallel problem, like SETI@Home or Mersenne prime searching, where a central server can hand out work units for home computers and otherwise-idle servers to crunch on for hours.  Distributed computing has had good success in those few niche problems, like getting people to donate idle CPU time to science, math, or some other problem (like crypto brute force challenged: https://www.distributed.net/RC5)

"Idle time" is an extremely poor way of putting it. While CPUs aren't under load, they don't use as much power. At the end of the day all of these projects cost significant amounts of money to run, rather than the implication that they are simply using otherwise wasted capacity.

Yes, I'm aware of that.  Some of these projects started before idle power saving was such a huge deal.  But good point, I should add a caveat to my answer.

Yes, there are several distributed-computing projects that let people donate otherwise-idle CPU time to the project.
(Note that with modern computers, that means also donating amount of electricity (30 to 80 Watts), because actually-idle CPUs / GPUs use (much) less power than when fully loaded.  If you already heat your home with electricity, having your computer make the heat doesn't cost you anything extra, otherwise it add to your power bill.  And extra air-conditioning if you're using more electricity to move the heat out of your house).

science: SETI@Home processing radio telescope data looking for signals for alien civilizations
Folding@Home:  a distributed computing project for disease research that simulates protein folding, computational drug design, and other types of molecular dynamics.
math: Mersenne prime searching: prime95
crypto brute force challenges like https://www.distributed.net/RC5.

I'm sure there are more, those are just the few that I can think of off the top of my head.
distributed.net was one of the early pioneers of this form of distributed computing, where a central server can hand out work units for home computers and otherwise-idle servers to crunch on for hours, eventually sending back a bundle of results and fetching new ones.  All of the projects I listed use that same model.
They motivate people to keep their computers contributing by running a leaderboard for contributions, and let users make teams.  A little bit of gamification can get people to put in the effort to set up the software on some extra computers that they wouldn't otherwise.  (Of course there's also the reward of contributing to something useful or interesting.)
To prevent cheating / corruption, the central servers will sometimes hand out the same block or chunk of data to multiple users, and compare the results.  For some problems, the client can compute a proof-of-work result as it goes, basically a hash of some internal result while crunching, which it couldn't compute much more efficiently without having gone through all the steps of the actual computation.  This allows the server to detect cheating clients that try to win the leaderboards (or just sabotage the project) by sending back work units as complete without actually having done the work.  For some projects, like prime searching, the actual result is just a "no primes in this range", which is obviously trivial to fake.

All of the problems this model is useful for are "embarrasingly parallel": you can work on a subproblem without communicating at all with threads / nodes working on other subproblems.

As @Anonymous says, databases are usually not like this.  The only thing I can think of is that maybe they're replicating the database onto every client, instead of having them send queries to a central server?  If it's small-ish, and read-mostly, that could make sense.  (Think like Git vs. SubVersion for revision  control: with a distributed VCS like GIT, everyone has their own copy of the repo and can run searches locally instead of putting load on a central server and needing the latency of a round-trip over the Internet.)

Or possibly the database you're talking about is only distributed over nodes in a tightly-coupled cluster
That's already a thing, I think.
There are also cluster filesystems where a whole cluster of machines have disks that make up one huge filesystem, like PVFS, Lustre.  That can be called a distributed filesystem, although distributed does often imply over a less tightly controlled cluster.  (There are some distributed filesystems that support having some nodes disconnected without stalling everything, though.)

See DWeb, an initiative from Mozilla foundation(?). They have a vision(search engine) for DWeb( for  distributed web)such as:
Problems that we commonly encounter in day to day usage: data sharing between devices(phone needs to connect to laptops when not connected to internet- as they mention on their website). Even to help in reading old versions of a web site.
To preempt internet giants usurping web sites contents, and thereby removing from the internet world any such sites (content) that may have succumbed to darwinism.
Actionable intent for this distributed project:

Stop hate speech
Support net neutrality
Stop censorship, governmental intrusion.

To this end, there is the beaker project, a distributed web browser, an experimental browser that enables peer to peer browsing, and distributivity. This project may just be the start of something, as it allows for better person-to-person (read peer to peer) information sharing, and thus enabling distributed computing, as sharing(media, content,etc) is done on on a peer to peer basis.
A file system or database is the underpinning of distribution, and such efforts, only
start in that direction. If for instance, peer to peer sharing in an environment that has
established rules - this could be enforced by a hypermedia sharing protocol such as Dat. An example of p2p sharing
-media from entity X goes to entity Y regularly, so there is ground for distributed sharing, and shared resource allocation, a distributed browser could enable such distribution.
Data could be stored locally on your computer- just shared by people on the p2p network.
For more Beaker’s decentralized browser, sans blockchain!


text:
If I were executing a 51% attack, would I be broadcasting my state of the network to nodes?
In the scenario where an entity has control of greater than 51% of the hash power and wishes to build a longer chain where they double-spend previously confirmed transactions, do they broadcast the chain to the network as they are working on it?
The alternative scenario I see is the entity working on the chain and only broadcasting it to full nodes at the point where it has overtaken what is believed to be the current longest chain. This second scenario would appear to me to be far more damaging to confidence in Bitcoin if it was pulled off. Technically, are both these scenarios possible?

Yes, both scenarios are possible.  The validity of a block is determined solely by its contents, not by when it is broadcast or received, so the attacker's longer chain is equally valid whether they broadcast it as they go, or all at once.
(There is an exception to this principle on testnet because of the 20-minute rule, but that's not relevant here.)


text:
Is it possible to limit bitcoin wallet balance?
I'm not sure if this is a right question, but is it possible to create  bitcoin wallet address with specific amount of limit?

No that's not possible.
Therefor a transaction must be declinable if the limit is reached, but:
You can not decline a transaction to your address (even if you are a miner and you decline it, someone else could mine it). If one of your friends creates a transaction, if it's a valid transaction and if a miner includes it into a valid block, it's done.


text:
Segwit transaction size not smaller
In this transaction;
https://blockchain.info/tx/573700fe19dbc926d037ee67dbe882ebcf3f765f1a3fcc9577665ba40554485f
All of addresses are segwit. According to my research this transaction size must be 166 bytes. But is seems 248 bytes.
Is there any idea?

You are mistaking virtual size that got introduced with SEGWIT with the legacy size.
166 bytes is the virtual size. 248 bytes is the legacy one. Unfortunately, Blockchain.info shows only the legacy size.
You can check your transaction with smartbit to get the VSize.
You can also check this awesome article about SEGWIT fees calculation


text:
Where do I obtain private keys?

Just received my profits from a "watch only" address, where do I obtain private keys?

Welcome to bitcoin.SE! Very big picture, without relevant explanation in it or link to the headline. Is there something missing we don't see?Maybe you can rephrase your question, and put some more (or much more) information? See how to raise good question: bitcoin.stackexchange.com/help/how-to-ask

Possible duplicate of I need to recover private key?,

They aren't your profits. They're funds a scammer is trying to convince you are yours but actually belong to the scammer.

If your profits were sent to a watch only address then you are in trouble.
Ordinarily, a private key is created first and then the address is created from that private key.
Your wallet makes new private keys for new addresses.
Please contact the person who gave you the watch only address.
If you do get the private keys then you should immediately move any bitcoin to a new address where only you own the private keys and nobody else knows them, so that the bitcoin cannot be taken.

https://bitcoin.org/en/glossary/watch-only-address
Watch-Only Address
An address or pubkey script stored in the wallet without the corresponding private key, allowing the wallet to watch for outputs but not spend them.

Other questions on this site suggest that this is a pretty common scam: someone says they are going to pay you money, gives you an address and sends some money there.  They trick you into believing  that seeing coins in that address means they are yours, and you send the scammer some money in exchange.  Scammer never gives you the private key so they keep their money and yours.


text:
How can coinbase transactions be created?
How can a coinbase transaction be created and what would happen if there was more than one coinbase transaction in a block?

The current bitcoin system does not allow to create a block with two coinbase transactions.
The rules are described here.
So a player against the system would need to craft such a block manually, which would get rejected, and eventually the node would get banned.
Hint: as his is a basic question of how bitcoin works, I recommend to read the technical articles on bitcoin.org, as well as the article on protocol specification in the link. And on top Andreas‘ book „Mastering Bitcoin“ gives a deep insight into the bitcoin world. It is also online available, in many languages. Highly recommended!

Coinbase Transactoin is created after new block is minned in blockchain.
Its the first transaction happen in any block and the transaction is minning reward(12.5 btc+fee) as per now.  When new block is minned particular amount of bitcoin is generated as minning reward and to make those btc come in existance it need to be assigned to some address. That address is generated within the block and minning reward is stored on that address which is known as coinbase transaction.

The address the coinbase coins are sent to does not "need to be generated in the block". It can be any valid bitcoin address, including a previously used one.

Any valid address doesnt men "any valid address will work", you should have access to the pvt key of the address, so for that obviusly the address has to be generated and ones address is generated and you have access to its pvt key you can use the same address multiple times as well

You can absolutely send the coins to an address for which no private key is known. You don't need access to the private key to send coins to it.

ohhh wow i didnt know this, how can we do that i am looking forward to try it,any reference?

It's known as "burning" coins. Essentially, you can send them to a Bitcoin address that you provably don't have the private key for. One such example is 1CounterpartyXXXXXXXXXXXXXXXUWLpVr, which was used for the initial counterparty burn. You can read up on https://en.bitcoin.it/wiki/Proof_of_burn for why burning is a thing


text:
Can op codes be used instead of signatures?
Are there any op codes or combination of opcodes that can be used instead of a digital signature when creating a transaction?

Existing signature schemes in Bitcoin are already implemented as opcodes (OP_CHECKSIG and OP_CHECKMULTISIG in particular), so this question's formulation seems a bit off.
If you don't mind a transaction whose outputs can be taken by anyone, this is trivial - you can just create an output with a script that does not use any signature checking opcodes.
Perhaps what you want to ask is Is there a way to create secure transactions without using any of the explicit digital signature opcodes?.
The answer to that is almost certainly no. You would effectively need to implement a digital signature scheme by hand, rather than relying on the provided ones. Digital signature schemes are remarkably complicated, and likely far beyond what is possible inside Bitcoin's current scripting language.

So is there no way to prove ownership of utxos without signing a transaction?

You can sign an arbitrary message with one or more private keys that can be verified against a bitcoin address or redeem script, thus proving you can access all UTXOs accessible by that address or redeem script

Can custom scripts be used to bypass the need for a sigbature?

@Errol Proving ownership of UTXOs is completely unrelated to your question above (ownership is a legal construction, and is not the same as access to the private key).

@Errol Based on several question I see you asking, maybe you're missing this: a script is Bitcoin is a description of the conditions under which the money can be moved. Every script will generally at least specify a digital signature with one or more keys are required. But there is no concept of ownership or control beyond what the script states. There is no way to bypass the script, as the script defines how the coins can be used.

Is it possible to alter the conditions of the script?

@Errol No, that would defeat the purpose. Read again what I said: the script is the definition of how the money can be spent. Being able to modify that (without spending) would be theft. Transactions are the only way to modify what amounts are under control of which conditions.


text:
What does a coinbase output script look like?
What does a coinbase output script look like and how would it be used to fund a transaction?

Coinbase transactions are almost identical to normal transactions.
The only difference is that they have exactly 1 input, which must have a special form (which would be invalid for non-coinbase transactions).
There is no difference between the outputs of coinbase transactions and others*. So just like any other transaction, they can have 1 or more outputs, and all those outputs have an amount and a script (address). Each of those outputs result in a new UTXO that is spendable by anyone who can sign for that script/address.
(*) Coinbase outputs have a special rule that they can only be spent after 100 blocks, instead of immediately. This is to prevent reorganizations from wiping out whole sequences of dependent transactions.


text:
Can you create a valid p2sh transaction with the redeem script in the scriptsig alone?
From my understanding, for a p2sh transaction to be valid the redeem script must hash to the same value as the output script being used to fund the transaction.
So can't you just put the redeem script of your address in the scriptsig and the transaction will be valid?

No, the BIP16 rules apply. They require that not only you provide a redeemscript whose hash matches that in the output (the address), but also that valid inputs for that script are provided (which will typically require at least valid signatures).


text:
How can OP_CHECKLOCKTIMEVERIFY be used to create outputs provably spendable by anyone?
While reading BIP 65 it says that op_checklocktimeverify can be used to create provably spendable outputs by anyone. How is this possible?

Start by reading the whole sentence:

CHECKLOCKTIMEVERIFY can be used to create outputs that are provably spendable by anyone (thus to mining fees assuming miners behave optimally and rationally) but only at a time sufficiently far into the future that large miners can't profitably sell the sacrifices at a discount.

In other words, CLTV is used to delay when an output can be spent, not to make it provably spendable by anyone. The latter is trivial: just don't have any signature checking operations in a script.


text:
Electrum transaction, 1 confirmation but i want to cancel it
I sent some bitcoin from my electrum wallet, however i left the mining fee very small so its stuck. But the transaction only has 1 confirmation, i dont want the transaction to go through so is there a way i can cancel it even though it has 1 confirmation. And I also read that after a few days if it isnt confirmed the right amount of times the transaction will jsut cancel so i was wondering how many days would it take to cancel if no miners confirm it.
Thanks.

How many confirmations does the tx have now?

If a transaction has 1 confirmation then it is in a block. Every ten minutes (on average) it will get another confirmation. It should have 6 confirmations after about an hour.
There is no way to cancel it.


text:
Can Miners spend the data-insertion amount?
I am wondering if a Miner can spend the amount mentioned in a data-insertion transaction for herself?
And what is the incentive for Miners to confirm data-insertion transactions?
Thank you

By data-insertion transactions you mean OP_RETURN outputs?
Typically those outputs have amount 0, so there is nothing to spend. But if the amount is not 0, those coins are burnt, and nothing - even miners - can change that.
However, such transactions can (and almost certainly, will) carry a transaction fee like every other type of transaction. That fee goes to the miner who includes the transaction in a block, and is the incentive to do so. This is the same for every type of transaction.

Thank you. Yes. I mean OP-Return outputs.

I have a follow-up question. Do you see any incentive for the Miners to pick data-insertion transactions to include in the block? I mean, if these transactions need less computational power for Miners? Thank you

Miners include transactions because transactions pay fees, period. There is no difference between "data insertion" transactions or others in this regard. The computation cost of including a transaction is absolutely negligible compared to pretty much everything else miners do. Further, even if you'd have a transaction with only OP_RETURN outputs, they still have inputs, with signatures that need validation.

Thank you so much. I got the point clearly.


text:
How to create output scripts?
How are output scripts created and how can you create your own scripts or is this only possible through creating a transaction?

https://bitcoin.stackexchange.com/q/14055/38618

related to https://bitcoin.stackexchange.com/q/72773/30668


text:
How can you send a transaction directly to the memory pool?
Is it possible to send a transaction to the bitcoin memory pool directly to have it mined without validating it?

There is no such thing as "the bitcoin memory pool". Every node has its own memory pool; it is not shared across all nodes in the network. A node can certainly add a transaction to its own mempool without validating it, but you cannot force other nodes to add a transaction to its mempool without validation. In fact, you can't force a node to add a transaction to its mempool, nor can you force a node to accept anything.


text:
Editing the utxo database?
Is it possible to manually add utxos to the utxo database?
Could this be done by editing the chainstate file?

Note that, like "the mempool", there is no "the UTXO database". You can change the UTXO database for one node and only that node. Such changes will not effect other nodes and does not change the state of the network. By modifying a node's UTXO database, that node has the possibility of forking off of the actual Bitcoin blockchain.

Is it possible to manually add utxos to the utxo database?
Could this be done by editing the chainstate file?

Yes it is possible to modify a node's UTXO database. It is just several files which you can modify directly. Bitcoin Core uses LevelDB so you will need to use something that can read and write to LevelDB databases.

So which are the files you would have to modify directly?

The *.ldb files in the chainstate folder of the Bitcoin Core datadir.


text:
Bitcoin unlimited nodes
What would happen if I try to broadcast a transaction being funded by segwit outputs with a bitcoin unlimited node?

Segwit transaction format is unknown for BU nodes. The peer either drop the connection or even ban your IP address for a while.

Wouldn't it just see it as anyone can spend and broadcast it?

Segwit transactions in "old" format are non-standard and are not relayed by default clients. Segwit transactions in "new" format are invalid for non-segwit clients

There is no ban for sending non-standard transactions, AFAIK.


text:
Why can't coins be sent from testnet to mainnet?
Why prevents bitcoins from being sent from the testnet to mainnet?

What prevents EUR from being sent to a USD bank account? They're different currencies; you need to exchange them as they have different market valuation.

But is it possible to exchange testnet coins for mainnet coins?

@Errol: Sure, if you could find somebody to exchange with.  Likewise, you could exchange Monopoly dollars for US dollars, if you could find someone willing to make the trade.  But nobody is going to want to do that, since testnet coins, like Monopoly dollars, aren't worth anything.

We actually do exchange dollars for Monopoly dollar ... plus plastic pieces and cardboard and other stuff at the toy stores.

Testnet and mainnet are two different blockchains, and their coins are incompatible.
A transaction takes outputs that already exist on the blockchain, and re-assign them as outputs to different addresses.  Think of a blockchain as a database.  Let's say testnet has outputs A, B, and C.  They are in the testnet database.  However, mainnet has never heard of these outputs.  They simply don't exist in the mainnet database.  Any transaction that is submitted to mainnet using A, B, or C will be immediately rejected.  Likewise, if you submit the same transaction to testnet, then the transaction goes through...but it goes through on testnet.  Mainnet is still none the wiser.


text:
How to model randomness in validators selection in PoS?
I searched a lot here and on the Internet to figure how how randomness selection of validators in PoS works? I understand it is a random selection based on fraction of stake a validator has, similar to PoW.
In PoW, we can model block arrival as a possion process. E.g., if block interval is 10 seconds,, we expect on average a block to be created each 10 seconds. You can get two blocks where the time between them less than a second (hence memoryless process). The chance each miner has for each block depends on its hash power fraction, but random in terms of assigning miners to blocks.
Now, how block arrival and assignment differs in PoS? from what i think is the same as in PoW. From other sources, i read time is divided into slots, where each slot is assigned to a validator (say deterministic). But not really understand how this differs from PoW. Any plain English explannation is appreciated (without too much technical details).

I understand it is a random selection based on fraction of stake a validator has, similar to PoW.

Not correct. In PoW, any miner can mine the next block. In PoS, a specific validator is chosen by the protocol that has the right to form/propose the next block.

The chance each miner has for each block depends on its hash power fraction, but random in terms of assigning miners to blocks.

The first part is correct that the chance a miner has depends on the hash power fraction. However, no miner is 'assigned.' Any miner can form the next block in the blockchain provided the block is valid and its header hash meets the target requirements.

How block arrival and assignment differs in PoS?

There is no one protocol set in stone that determines how the next block validator is chosen. (1) Peercoin (the first coin to implement PoS consensus along with PoW) used coin age (no. of coins x no of days the coins are in the wallet) to determine the next validator. (2) Then there is a hash selector (Ouroboros Praos protocol) wherein you take the current date and time, sign it with your private key and then check if it is less than the difficulty target. If yes, you are selected as the next validator. (3) There was one method where the randomness of the next block will depend on the signature of the current block (this method is now defunct due to potential vulnerabilities.)

Thanks for the comment! just to clear second point i mean in PoW there is a way to select a miner for each block, the lucky one who found the nonce. In PoS, let assume we have three validators V1,V2 and V3, each controls 1/3 of total stake. Now, when blocks will be generated? and who generated each of them? if difficulty is to target a block each 10 seconds. Should be similar to PoW, where you might see two blocks happened just after each other (but for long run average between blocks is 10 seconds). Also, for long run will V1 will have created 1/3 of total blocs? Thanks

There is no miner selection. One who finds the solution to a valid block mines it. In PoS, a validator is chosen, and he is the only one that is allowed to propose/form the next block (unless Ouroboros Praos protocol). In BFT-style PoS, validators are randomly assigned the right to propose blocks, but agreeing on which block is canonical is done through a multi-round process where every validator sends a "vote" for some specific block during each round, and at the end of the process all (honest and online) validators permanently agree on whether or not any given block is part of the chain.

Thanks it is getting better. Yet, still not clear for me when blocks are generated, either at fixed point of time each 10 s or random point of time (but on long run average of 10s is achieved, like PoW). It seems to me PoS also affected by stale rate e.g., if V1 was selected to create B1 (where refers to genesis block) at time=10; and send B1 to other nodes, and then V2 was selected to create a block at time=20, but V2 has not yet heard of B1 that was sent by V1. In this case, V2 will create a block referring to the genesis block. At the end, one of these blocks will be discarded. Is it true?

If you want to keep the block time at 10 sec, the protocol selects the next validator at ~10 sec. In case of conflicts, it is resolved via voting. Different validators bet on the accepted block. The winning block is the one that receives the most votes; votes are weighted by holdings,


text:
TX nLocktime and mempool
Where is a broadcasted TX located at before it's nLocktime reached? in mempool or not? I have tried a lot can't figure out. Help please.

Such transactions are located only with the transaction creator. Nodes generally do not keep in their mempool transactions that cannot be immediately mined.

further to Achow's answer, here an extract from Andreas' bitcoin bible ("Mastering Bitcoin, 2nd edition"):

If nLocktime is nonzero and below 500 million, it is interpreted as a
  block height, meaning the transaction is not valid and is not relayed
  or included in the blockchain prior to the specified block height. If
  it is above 500 million, it is interpreted as a Unix Epoch timestamp
  (seconds since Jan-1-1970) and the transaction is not valid prior to
  the specified time. Transactions with nLocktime specifying a future
  block or time must be held by the originating system and transmitted
  to the bitcoin network only after they become valid. If a transaction
  is transmitted to the network before the specified nLocktime, the
  transaction will be rejected by the first node as invalid and will not
  be relayed to other nodes.


text:
How many times of validation needed for a whole payment transication?
I try to figure out it. So far, I believe there are 3 times, in wallet before broadcast, before accept to mempool by node, before accept a new block created by other node. I don't believe it's all. Maybe before mining to construct a new block need a validation. Anybody clear about it? What's the different for those validations?

In theory, a transaction is validated before it is sent, when a transaction is accepted into a node's mempool, when it is selected for inclusion in a block, when the block is verified before being broadcast, and when it is in a block that is received by a node. However, there really is no need for doing this validation multiple times because the same validation is done every single time.
So instead many node software will validate the transaction only when it is received in the mempool and only keep valid transactions in the mempool. When a new block is received, the transactions that were in the mempool need to be removed from the mempool, and because it knows that those transactions were valid because they are in the mempool, it does not need to re-validate the transactions from the block. The only transactions that need to be validated in the block then are the new transactions which the node did not have in its mempool.
For miners, the transactions they select will be from the mempool which only contains valid transactions. Thus this removes the need to validate transactions before selection and after block creation.
Additionally, the node can cache validation results for invalid transactions so that if it sees such transactions in a block it can look up the result in the cache instead of re-validating the invalid transaction. They can do this for valid transactions too to skip some validation steps.


text:
Does BTC.com support ASICBOOST
Does the www.btc.com pool support Asic Boost? Does it have to support it for me to use Asic Boost on it? If it doesn't support Asic Boost which pools do?

I believe mining Bitcoin with overt (version-rolling) ASICBoost is currently (may 2018) supported by Slushpool, Ckpool, F2pool and my own pool Bitminter.
I would expect this list to keep growing, although adoption has been very slow for some reason.


text:
How net earners got their incomming channels?
Lighting looks good for net spenders:

download node/wallet
lock your funds by openning channel to some hub
spend until has something in channel
close it

All costs like channel fees and locked funds goes to funder/spender.
But what in case of net earners (shops like bitrefill) another party should lock their funds and pay fees to deliver funds. I don't found answer in Lighting RFC, it seems like it should be whole OTC market with Banks/Hubs and unsafe protocols. Net earners should pay someone to lock their moneys by opening channel in their direction.
Inspired by:
https://medium.com/failsafe/why-lightning-and-raiden-networks-will-not-work-d1880e4bc294

Merchants get channels from customers who want to transact with them. This isn't something that needs to be specified; if someone wants to transact with you over LN, they can open a channel with you. This is how many transactions currently happen over LN - the customer opens a LN channel with the receiver. Furthermore, autopilot modes like the one used by LND will automatically open and close channels to various nodes so nodes that accept incoming channels will likely have connections from others where autopilot connected to it.


text:
Has a consensus algorithm where temporary authorities are fairly “elected” via PoW been discussed?
In the usual proof-of-work consensus system, miners constantly compute hashes (“wasting” resources). What if hashing were restricted to a certain time window, e.g., 1 hour per day?
This could act as a leader election for the remainder of the day. These leaders are “representative” of the entire network since they’re sampled using PoW.
The leaders could then use some Byzantine fault tolerant consensus algorithm to decide what blocks to append — without mining — until their “term” is up.
Has such a system — or something (even vaguely) similar — already been discussed?

The obvious question is how vulnerable this system is to colluding attackers. (Clearly it is weaker than the usual “51%” majority rule, but exactly how bad is it?)
If we assume that the BFT consensus algorithm can tolerate a fraction of 1/3 bad leaders, we can calculate the probability of a successful attack as a function of the bad PoW capacity share using some binomial distribution maths. Some back-of-the-envelope Python calculations suggest that perhaps 20% bad PoW share is tolerable, which isn’t absolutely terrible.
Maybe there is no known BFT consensus algorithm that would scale to anything close to the Bitcoin network (e.g., in PBFT the number of “replicas”, i.e., leaders, is << 100).

I’m sure there are plenty of other potential problems, I’m just wondering if it is feasible at all. Perhaps it has been discussed in some other context.

We need a way to ensure that hashes were actually calculated during the claimed window, because otherwise miners will cheat by performing hashes during off hours and lying about when they were done.  How will that work?  Time stamps in blocks can't be trusted because they're inserted by the miners themselves.  You could have a central "timekeeper" authority that releases a magic key when mining is to start, and requires that all blocks for that day contain that key, but then you have to trust that the timekeeper can't be bribed to secretly share the key early...

... thus giving his friends an advantage in mining.  Likewise, the timekeeper might be able to lie and claim that hashes from his enemies arrived too late.  One of the major design features of Bitcoin is that there is no single person or organization whom everyone must trust.

I had imagined some block would act as the start block (making pre-mining impossible as usual in the blockchain), and after the election window is over, consensus rules reject further mined blocks. If using actual clock time is a problem, how about setting a fixed number of blocks rather than using time windows?

You should look up Bitcoin-NG, it proposed a similar construct, where the miner that finds the last block publishes a chain of sub-blocks until the next miner finds a block (and reconfirms the transactions from the sub-blocks).

Thanks for the pointer, @Murch! That’s pretty much what I had in mind as an answer (i.e., anything even slightly similar, and that definitely is) and was very interesting.

I’ve since found several related concepts in research papers or coin protocol proposals:

Bitcoin-NG separates leader election (key block) and the following “election term” (epoch), in which microblocks are freely added by the leader.
Tendermint (and, before it, Hyperledger) uses BFT consensus (but with PoS as the basis for elections).
Building upon the previous, ByzCoin elects leaders via PoW and uses PBFT to agree on the microblocks.

The article The Road to Scalable Blockchain Designs gives a good intro to and context for ByzCoin. Exploring the citation graph of the ByzCoin paper leads to further similar work at ETHZ and Cornell as “hybrid consensus” or a “strongly consistent” blockchain.
None of these use the energy-savings aspect that motivated me; instead they all aim at improving throughput and/or transaction verification time. But the “PoW leader election + BFT consensus” concept seems to be pretty actively researched.

What you're trying to describe is exactly the same as having reusable proof-of-work: to make work doing hashes and then being able to use those hashes for any block you create.
That doesn't solve the problem mining is supposed to solve, that is the double-spending problem. A miner could use the same hash that gaves him/her the 'right' to mine a block to mine two or more parallel blocks that spend the same bitcoins but send them to different addresses.
Proof-of-work hashes need to be linked to one and only one block.

Maybe we misunderstood each other. During the leaders’ “term”, double-spending would be prevented by consensus rules, e.g., built on (an even more practical variant of?) Practical BFT. I believe Tendermint uses some variant of this. In other words: the leader election is done as in Bitcoin, the term is done as in Tendermint; both should be safe (within their usual constraints on the number of badly behaving nodes).


text:
Could you use ASICBOOST on Bitcoin Cash?
Can you use ASICBOOST on the Bitcoin Cash blockchain or would it not work.

Yes, ASICBoost works on the Bitcoin Cash blockchain because the block header format of Bitcoin Cash blocks are the same as the block header format of Bitcoin blocks. ASICBoost operates on the block headers. Furthermore, both overt and covert ASICBoost work on Bitcoin Cash.


text:
What other proof methods are there?
I am familiar with the proof of work method and a little with the proof of stake method. Is there any more methods that are out there and how do they work?

A few others on top of my head, in addition to variations of PoS (DPoS, LPoS, etc)

Proof of Importance (PoI): kinda like PoS, but stake here is the total transaction amount (greater than some vested amount of coin)
Proof of Authority (PoA): transactions are validated by selected validators
Proof of Burn (PoB): please refer to this SE question: How does Proof of Burn work?


text:
Where can I download the Antminer S9i Software
I would like to try putting some s9i software on my s9's but where can you download the s9i software or is that just the newest version of software that they have for the s9's. Where can I get the s9i software?

Firmwarescan be downloaded from https://shop.bitmain.com/support.htm but Bitmain is smart enough not to upload S9i's firmware. You'll need to dump a friend's S9i's firmware by yourself.

As MCCCS commented:

Firmwares can be downloaded from Bitmain but Bitmain is smart enough not to upload S9i's firmware. You'll need to dump a friend's S9i's firmware by yourself.

Comment converted to Community Wiki answer in attempt to remove this Q from list of unanswered questions

So are you sure there is no alternatives i have no friend with an s9i.

@Learn2Mine: Contact your hardware supplier Bitmain for the latest firmware.

https://shop.bitmain.com/support.htm?pid=00720180525135351672WCe9WPkv06BF Is this the firmware i need to flash onto that sd card


text:
Is it more profitable to mine non-SegWit blocks
The fees for a SegWit address are lower than non-Segwit ones. Is there less fees per block with Segwit blocks? Is it less profitable to mine Segwit blocks?

A "segwit" block does not exclusively contain segwit transactions; it can contain both segwit and non-segwit. "Non-segwit" blocks contain exclusively non-segwit transactions because it does not have the requisite segwit commitments. Since segwit blocks can contain both types of transactions, it is actually less profitable to mine non-segwit blocks as you will be missing transactions that segwit blocks can contain.

Plus more SegWit transactions for into a block and that block can become larger than non-SegWit blocks, so total fees are actually higher.


text:
How do you enable ASICBOOST on an s9
How do you enable ASICBOOST on an Antminer s9?

It's a secret that nobody is willing to share.

Both Bitmain and Braiins have now released S9 firmware that enables overt AsicBoost.


text:
What are the Differences Between an Antminer S9 and an Antminer S9i
On the Bitmain Website they now list the Antminer S9i how is this different than the S9?

The main hardware difference is, the hash board heat sinks are different heights! You cannot use all 3 S9i hash boards in a regular S9. The S9i heat sinks are 3mm smaller on the bigger heat sink side(silver) and the smaller brown heat sinks on the other side are 3mm taller. You can only fit 2 S9i hash boards in a S9 housing.

Wow that's insane. Do you think that's what Bitmain was using all along?

Same difference minus the 20 Watts of savings as mentioned above. It also seems they are dropping the price and moving bountiful amounts compared to before. Sites like Blokforge https://blokforge.com/product/bitmain-antminer-s9i-14-th-s/ are carrying hundreds of these units unlike any time in the past where units were limited to 1 or 2 per person.

S9i is an upgraded version of s9, shares almost the same hashrate 13TH/s+-10% and power consumption at 1300w+-10%, S9i is cheaper than S9.

Only difference is price -- It is exact the same machine!      They have changed software a drop to save about 20 watts per unit that means about $1 per month savings just about no difference.
Just a marketing game they will be releasing the newest hardware soon, JUNE I imagine .. for September shipping!

That is exactly my thought @Kris they will probably be dumping their old s9s so they can put in s11's.

Is it possible to put s9i software on an s9?


text:
How to view a bitcoin cash transaction in hex or json?
Is there a block explorer that allows you to view a bitcoin cash transaction in hex or json like blockchain.info does for bitcoin?

DoubleSpend.Cash can be used!
https://doublespend.cash/txdata/9dbfbc12caa531afcfe00d90d786bd42cee2ef43.json
UPDATE: Doublespend.cash works a little different. Here's a better alternative:
https://bch.blockdozer.com/api/tx/e6ed64fc714f4ffdd11b439ab1a22e1414bace2c05f38fa0221a58e45b678f74

Replace /tx/ with /rawtx/ to see the TX in the hex format.


text:
Original default bitcoin script
Where can I read the original Bitcoin script for verifying the transactions?
Also, who controls the GitHub profile of bitcoin?
Thanks.

Where can I read the original Bitcoin script for verifying the transactions?

You should be able to find the source code on GitHub
e.g. https://github.com/trottier/original-bitcoin but I'd verify that before relying on it for anything important.

who controls the GitHub profile of bitcoin?

Some subset of
https://bitcoin.org/en/development#bitcoin-core-contributors
See https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-commits/trusted-keys

See also:

Is there a list of core Bitcoin committers? (hat tip to Pieter Wuille for pointing this out)

For the list of maintainers, see this question: https://bitcoin.stackexchange.com/q/176/208

@Pieter Thanks for pointing that out, link appended to answer.


text:
Mnemonics but for Public addresses
Are there any implemented ways for turning addresses into human-readable word(s)? If not, why? I.e., are there any known technological issues in implementing this?
Thanks

Are there any implemented ways for turning addresses into human-readable word(s)?

No

If not, why?

Because, copy-pasting works and no one has proposed a method for something that no one I'm aware of has needed.

I.e., are there any known technological issues in implementing this?

No

It might be worth mentioning checksums and QR-codes both of which which also help avoid transcription errors and make addresses easier to use.