text:
Why multisig transaction has OP_CHECKSIGVERIFY as first opcode?
48490a078c7909194ddb995885b661b7513e9af05af66d2369190a2d983da3ee
I'm trying to understand why here is the OP_PUSHBYTES_32  OP_CHECKSIGVERIFY as first operation, does it work like 1-of-1 and 6-of-9 multisig? What is the reason for this?
OP_PUSHBYTES_32 3247347a997cac1b91c796b896ae85c2185fed60431ff98b4ad789f215929a1c
OP_CHECKSIGVERIFY
OP_PUSHBYTES_32 23b29f89b45f4af41588dcaf0ca572ada32872a88224f311373917f1b37d08d1
OP_CHECKSIG
OP_PUSHBYTES_32 4b15848e495a3a62283daaadb3f458a00859fe48e321f0121ebabbdd6698f9fa
OP_CHECKSIGADD
OP_PUSHBYTES_32 8242640732773249312c47ca7bdb50ca79f15f2ecc32b9c83ceebba44fb74df7
OP_CHECKSIGADD
OP_PUSHBYTES_32 cbdd028cfe32c1c1f2d84bfec71e19f92df509bba7b8ad31ca6c1a134fe09204
OP_CHECKSIGADD
OP_PUSHBYTES_32 d3c79b99ac4d265c2f97ac11e3232c07a598b020cf56c6f055472c893c0967ae
OP_CHECKSIGADD
OP_PUSHBYTES_32 d45c70d28f169e1f0c7f4a78e2bc73497afe585b70aa897955989068f3350aaa
OP_CHECKSIGADD
OP_PUSHBYTES_32 de13fc96ea6899acbdc5db3afaa683f62fe35b60ff6eb723dad28a11d2b12f8c
OP_CHECKSIGADD
OP_PUSHBYTES_32 e36200aaa8dce9453567bba108bdc51f7f1174b97a65e4dc4402fc5de779d41c
OP_CHECKSIGADD
OP_PUSHBYTES_32 f178fcce82f95c524b53b077e6180bd2d779a9057fdff4255a0af95af918cee0
OP_CHECKSIGADD
OP_PUSHNUM_6
OP_NUMEQUAL

does it work like 1-of-1 and 6-of-9 multisig?

Yes, it appears so.

What is the reason for this?

There is nothing we can infer from the transaction except for the fact that it is implementing an A and 6-out-of(B,C,D,E,F,G,H,I,J) policy (where the letters refer to the 10 keys in the script).
If you want to know the intent, you will have to find and ask the author of the transaction.


text:
Has the PoW algorithm changed?
I am in a graduate program in Software Engineering and have recreated the mining programs in Python and Ruby, as well as computing the Merkle Root, etc..
I have been randomly chosing blocks from Bitcoin to test my algo(s).  I notice that my nonce and current block hash finder works upto a certain point.  It seems that it works upto about block 400,000, circa 2015... but fails beyond this point.  Did they tweak the mining algorithms around that time?  Should there be another data point?
I have these data points:

previous hash
merkle root
difficulty
version
time in unix
nonce: (this is what the program searches for and puts out the nonce and current block hash, if found)

As I mentioned it confirms and "mines" the blocks up to about block 400,000... but fails afterwards.
Some enlightenment is appreciated.

You validate the correctness of generated block hashes, or claim that you were able found hashes of some of 400,000 blocks using code written in python?

I guess that I wasn't clear.  I can validate the hash of block 'n' for all blocks from #0 the genesis, but have discovered that my program doesn't validate the correct hash of the blocks starting around #400000, around 2015.

Block #410000 is where it fails, I guess that it's related to the "VERSION" field... all previous blocks had a single integer entry of 1to 4... changed the way data is displayed in this field... that is my only guess.

This might be good call. Here is the chart with block versions changing in time: https://data.bitcoinity.org/bitcoin/block_version

Yes, that is it.  I plugged in the new version number and it confirmed it.  It's confusing as a noob, I noticed that Blockchain.info and Blockexplorer.com display the info differently.  I am learning my way through this.  Thanks for the link.

I wrote a python program to hash a block header a while back: https://bitcoin.stackexchange.com/a/46024/2306

You can post your own answer to this question, explaining what you learned.  Otherwise it will remain marked as "unanswered" forever.

I will take the suggestion above and post the answer for others.
As mentioned I am a noob at looking into the bitcoin and blockchain.  My interest is the programming code behind the cryptocurrencies and the various blockchain implementations.
When I was backtesting the correctness of my code, which I did in Python and Ruby, I discovered that it wasn't working at a certain point.  I wasn't sure at which block #, where it was failing until I tightened up the test and discovered it was at that block #410000.  A simple look at the data, I realized that either the mining algorithm changed slightly for difficulty or something in the inputs wasn't correct, so I isolated all the inputs and realized that it was the VERSION field that changed.
Of course, I know nothing about the different versions of the blocks, nor the forking behaviors yet... it wasn't clear until the poster provided the link that confirmed to me that the versions had changed, thus throwing off my program.  But I can easily tweek it to adapt to the version field, now that I realize it is not as hardcoded as the other fields.
One thing that I noticed, and I am not a probabilities expert, but the nonce values seem to land in the 9 or 10-digit range... so when a miner is searching for the nonce, I would assume that the miner does not need to start the search at 0.... but rather 100000000 and increment, it seems the time to calculate is reduced substantially.
My next step is I'd like to analyze the range of nonce values and see if they fall within a certain spectrum of values and where they cluster, whether 9 or 10-digit lengths. It's all just curious analysis.
My goal to all of this is the create a fully running program that pulls all of the blockchain, and dynamically confirm the blocks(merkle roots and header hashes), store the info in a csv file.  The point is for me to learn to scrape, process and analyze the results just to find any irregularities, or randomness if that's the case... just from curiousity sakes.
As a pet project, I am going to create a blockchain-distributed ledger for a friend who has a PhD in food safety and security, and see where it goes from there.

The algorithm itself did not change, and changing the inputs fields is not a change of the algorithm. The version field is used to signal soft forks.

source: Stack Exchange

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

sort: votes


text:
GH/s is bigger than TH/s
How does BAIKAL X10 make more money than AntminerS9 although BAIKAL X10 Only 10 GH/s and Antminer S9 14 TH/s ?
So, which one is bigger GH/s or TH/s?
I am confused.

TH/s is bigger than GH/s, maybe this BAIKAL X10 mines another currency where 10GH/s makes more money than 14TH/s in bitcoin.

A quick google query tells me it mines dash.

I'm voting to close this question as off-topic because the question is too localized and is unlikely to help future visitors

TH/s is bigger than GH/s. But there are many different kinds of hashes that you can do and some pay more than others. The Antiminer S9 does SHA256d hashes which tend to pay the least per hash of any hashing algoirthm because they are the simplest.

GH/s stands for gigahash per second
TH/s stands for terahash per second
Giga- and tera- are SI prefixes just like kilo- and mega- and they are used everywhere (kilometer, megahertz, gigahertz, gigabyte, terabyte, ...). You can find the full list of SI prefixes here:

https://en.wikipedia.org/wiki/Metric_prefix#List_of_SI_prefixes

So, to sum up:
1 kH/s = 1000^1 = 1 000 hashes per second
1 MH/s = 1000^2 = 1 000 000 hashes per second
1 GH/s = 1000^3 = 1 000 000 000 hashes per second
1 TH/s = 1000^4 = 1 000 000 000 000 hashes per second
1 PH/s = 1000^5 = 1 000 000 000 000 000 hashes per second
1 EH/s = 1000^6 = 1 000 000 000 000 000 000 hashes per second

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


text:
Why all blocks at Blockchain are relayed by Unknown now?
only last week I could study which mining pool signed latest blocks.
Today this option turned status to Unknown
https://blockchain.info/
Any idea?
(formatted table)
Height  Age     Transactions    Total Sent  Relayed By  Size (kB)   Weight (kWU)
491728  31 minutes  352     196.23 BTC  Unknown     1,002.67    3,992.19
491727  31 minutes  266     920.01 BTC  Unknown     134.31  515.14
491726  33 minutes  1447    2,900.32 BTC    Unknown     1,017.02    3,996.92
491725  39 minutes  290     822.51 BTC  Unknown     132.29  494.91

Issue seems to be fixed.
Blockchain back in order, blocks relayed by real names of mining pools.
Thank you Blockchain
Height  Age     Transactions    Total Sent  Relayed By  Size (kB)   Weight (kWU)

492019  1 hour 4 minutes    2628    18,615.76 BTC   ViaBTC  1,035.85    3,992.75
492018  1 hour 7 minutes    2662    19,214.10 BTC   BitFury     1,036.1     3,992.5
492017  1 hour 11 minutes   2856    4,369.50 BTC    ViaBTC  1,038.23    3,992.72
492016  1 hour 13 minutes   2815    6,719.06 BTC    AntPool     999.17  3,728.27

There was an update to the site that changed its behavior to no longer properly identify who relayed blocks.
Until they fix the issue, you can use other blockexplorers to find the information.
Given your stated usecase, I suggest you look at http://coin.dance/blocks

thank you, since my conference paper abstract has been accepted I need to attach 50+ pages of stats + charts. Since coin.dance publishes blocks by mining pool chart, tell me how to access raw data as provided by the Blockchain in the past and how to download block headers ?  api.blockcypher.com/v1/btc/main/blocks/491658 is great but made alike modification, setting every nonce to "0", making block data useless for any R&D study.  any idea ?

from https://blockchain.info/pools      " A large portion of Unknown blocks does not mean an attack on the network, it simply means we have been unable to determine the origin."

I dont know if coin.dance/blocks can give you raw data. there is many block explorers available (google for bitcoin block explorer), and you can always download and setup a bitcoin node then use the jsonrpc functions to query the data directly from you own node.

Thank you Jonathan,  knowing the right search term "bitcoin block explorer" is a key to success. Still work hard to get access to download all block headers in json or another format.


text:
Which alternative currencies might experience a sharp rise in popularity like bitcoin recently did?
Simple question for newbies. Which other alternative currencies (crypto and others) are possible candidates for a surge in popularity?
Is there any reason that bitcoin will always dominate the alt currencies or is it just one of many contenders waiting to be discovered by the masses any day now?

Voted to close because this seems far too speculative to produce any useful answers.

there is no real way to predict where the market goes. Therefore it is a question without an answer.
The part about bitcoin surge is just a question of supply and demand. bitcoin doesn't really have a value. the value lies in the demand from people hoarding or spending them and the supply from miners and/or brokers. It is now in high demand so it's high in price.If by popularity you mean a hyper deflation. Well then yes. bitcoin will probably always dominate the others.

Litecoin, Lxcoin, Terracoin, PPcoin & maybe Liquidcoin which ever come first. But for now seeing as Litecoins are cheaper and easier to mine that maybe next boom in alternative cryptocurrencies.

Can you provide some justification for why you chose those ones? (You did provide some for Litecoin; I'm talking about the others)

If anybody could answer that question, they would be too busy buying up every last coin of said currency.


text:
Why did bitcoin rise so sharply in the last week?
Answers a plenty!
Because it broke $1b market cap?
Because it was on many financial paper front pages?
Because all the usual suspects (forex watchers) saw a bubble coming?

This question is likely to invite speculation and discussion. For that reason, I'm voting to close it.

A large number of people in certain countries in Europe have begun using BTC as a place to shelter some of their financial holdings from government seizure.

Not that I necessarily disagree, but can you cite this claim?

Aren't those people playing with fire anyway given the wild fluctuation we might reasonably expect in the future?  I realize govt seizure is worse, but aren't there less risky places to shelter their funds?


text:
Is there a way to push the output value of a UTXO to the stack in Bitcoin script?
When defining the spending conditions for a UTXO can one use the output value in a script by pushing it to the stack?

No. You can't push the value of the output being spent in Bitcoin Script as of December 2023.
It's been explored in some of the covenants proposal however. For instance with the Taproot upgrade on the Liquid sidechain, a new OP_INSPECTINPUTVALUE was introduced which allows to push the value of (any of) the input(s) onto the stack.

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


text:
Mismatch between utxo increase and total utxos
I'm running bitcoin core and using the commands getblockstats and gettxoutsetinfo.
I ran gettxoutsetinfo at block 770992 and it showed a total of 83,420,287 unspent transaction outputs. I then waited for block 770993 to appear and ran getblockstats for that block.
In getblockstats it shows a utxo_increase field, which is the difference between the outs and ins fields (outputs created - outputs consumed). For block 770993 it showed -603.
I ran gettxoutsetinfo at block 770993 and it shows a total of 83,419,633 utxos. Why doesn't it match up?
I tested it for a couple previous blocks as well and the same thing happened. Any ideas?

The utxo_increase and utxo_size_inc fields of getblockstats does not exclude provably unspendable outputs. However provably unspendable outputs will not be added to the UTXO set, so gettxoutsetinfo will not count them.

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


text:
Why do nodes have a maximum peer count?
Why do nodes have a maximum peer count, in other words what could go wrong if each node is connected to all the nodes of the network?

Holding the state of a peer and handling its requests consumes resources. Mainly RAM, bandwidth and CPU. Each additional peer has a fixed cost for a node but a decreasing utility.

You could additionally mention that due to the limit on listening nodes there is also a limited amount of slots for other nodes to make inbound connections in the first place.

I initially started writing something along these lines but figured it didn't answer the question which was rather about why is there a limit at all for those listening nodes, if i'm understanding correctly. But i don't mind adding it.


text:
bitcoinjs-lib is installed but cannot use its functions
I've installed the latest version of bitcoinjs-lib but I cannot use the functions of the library.
const bitcoin = require('bitcoinjs-lib');
const keyPair = bitcoin.ECPair.makeRandom();
const { address } = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey });

I get errors like:
TypeError: Cannot read properties of undefined (reading 'p2pkh')

Can you help?

I’m voting to close this question because it's a general programming question not specific to Bitcoin.

You seem to be using an old version of bitcoinjs-lib. The payments interface was added in version 4.0.0 which was released in 2018.
Note that the ECPair interface was removed in 6.0.0 so this code won't work on the latest version either. bip32 should be used instead.


text:
Question about bitcoin generating block time in book "mastering bitcoin " 3rd edtion
In book "mastering bitcoin" 3rd, chapter 2, page 27, there is a statement: Approximately 19 minutes after the block containing Alice’s transaction is broadcast, a new block is mined by another miner.
My question is why it is 19 minutes? i think it is about 10 minutes.
you can find this book by link below.
https://github.com/bitcoinbook/bitcoinbook/blob/develop/BOOK.md
thanks.

It is talking about an actual block, mined on February 4th 2023, which took 19 minutes.
The average time between two blocks is, when the hashrate is stable, approximately 10 minutes. However, this is just an average. Even in theory, the time between blocks follows an Exponential Distribution, which has a range from 0 to infinity. In practice, more uncertainty is added to this due to the hashrate not being constant. Real inter-block times vary from seconds to over an hour.


text:
collision attack on bitcoin p2sh
Book "mastering bitcoin" 3rd edition, on page 73, there is a statement as following:
"but there are organizations that expect to receive billions of dollars in bitcoins to
addresses generated by processes involving multiple parties, which could make the
attack profitable."
anybody can take an example to explain it? thanks.

Does this answer your question? Birthday attack on P2SH

First note that, since Mastering Bitcoin was first published, Bitcoin has activated SegWit (BIP-141) and multi-party users now have the possibility of using P2WSH to lock up their funds, which is secure against collision search because it uses a 256-bit hash (sha256) which has 128-bits of security against birthday attack.
Even the forked version (Bitcoin Cash) eventually ('23) solved the problem by extending the P2SH feature (BIP-16) with P2SH32 (using sha256d, source).
Newer blockchains mostly had 256-bit addresses from the get-go, and now this collision problem only persists in some old forks of Bitcoin's codebase (e.g. Dogecoin).
Why was it a problem that needed solving? Here's a brief explanation / example (source):

The problem arises when users are asked to pay into an address where
someone else had control over address generation, such as P2SH
multi-party multisig addresses and public-facing covenants.
Feasibility of a collision attack makes it usable as part of a con
executed in 3 stages:

Collision attack: generate a colliding contract (redeem script) pair;
Social hacking set-up: release the address and only one of the two colliding contracts to some other party or parties and convince them
to pay funds into the contract address;
Rug-pull: when the address has accumulated enough funds to pay for step 1 and have some profit, steal the funds from the address by using
the other, secret, contract.

For the con to work, the contract revealed to other parties must look
innocent while also having a variable part suitable for manipulation
by the attacker, one that can encode a whole 160-bit hash in order to
make use of the constant-memory method by finding cycles. This does
not just mean a continuous 160-bit block, it is much more broad - it
means any degree of freedom which would let the attacker feed 160 bits
of entropy of his choice into the final address. The other message can
be anything that will allow only the attacker to spend from it.

Note that, while it is feasible to birthday attack a 160-bit hash collision, it is still not cheap to do it. Ripemd160 ASICs don't exist yet (P2SH hash160 is ripemd160(sha256(x))), however the Ripemd hash function has similar construction (Merkle-Damgard) as sha256 so R&D may not need to have large capex cost. If we assume efficiency to match sha256d we could estimate cost of individual collision search based on Bitcoin's hashrate and value of block reward.
Collision search would need 2^80 attempts (about 1M exahashes). Bitcoin network as a whole now (November 2024) does 790 exahashes/s meaning it now does 2^80 hashes every 21 minutes!
Assuming hash160 ASICs of equal efficiency, the cost of a single collision search would be about 2 block rewards, or about 470,000 USD per collision search.
The attacker would need a target of high enough value for the attack to be worth it. How could he set it up? Here's a hypothetical long con (source):

Example Attack
To better illustrate the attack, consider an adversary that creates a
custody service which sets up 2-of-3 P2SH multisig addresses for their
users. Any user of such service would control two keys, and the
custodian (attacker) would control one. Note that there exist
legitimate services that work just as described, enabling users to
hold one of their two keys in cold storage and rely on the service to
produce 2-of-3 signatures.
For the attack to be possible, user interface of the rogue service
would have to first ask the user for their 2 public keys, and the
adversary would add its key last to generate the multisig address, and
then reveal their 3rd key to the user so the user could verify
correctness of the contract. The user would likely think it is safe,
because it would be the familiar multisig contract (redeem script)
template which, if evaluated on its own, indeed works as advertised:

Redeem script: OP_2 <attacker's 33-byte pubkey> <user's 33-byte pubkey 1> <user's 33-byte pubkey 0> OP_3 OP_CHECKMULTISIG;
Locking script: OP_HASH160 <hash160(redeem_script)> OP_EQUAL.

Such an output could then be spent from using an input of the
following form:

Unlocking script: OP_0 <user's signature> <user's other signature or attacker's signature> <redeem_script>

In our con scenario, when setting up the multisig address the attacker
would have generated a redeem_script_steal, one that would hash to
the exact same address and allow him to spend from the address by
executing an entirely different script like:

Redeem script: <20-bytes> OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG.

The script would be kept secret until stage 3. of the attack, the
rug-pull. In the innocent-looking multisig script, his key would not
really be a key, he would be using it as a variable part in his
collision search. If the attacker expects users to call on the service
to actually use the key from the innocent-looking script, then it
would make stage 1. somewhat more expensive but still feasible.
The service could be operating legitimately for a long time, waiting
for the right target or a set of targets. The attacker would not need
to perform step 1. for all users, that would have an uncertain
return-on-investment. He would first need to attract enough users and
identify high-value targets, ones where they have enough funds to make
a collision search worthwhile. The attacker could then ask his targets
to move their funds into a new contract that would have the same 2
user keys, and the attacker could plausibly say he has to update his
key for some internal security upgrade.
He would wait for his targets to move the funds, and then steal them
all in one go and disappear.
There is a simple way users could protect themselves in this scenario:
insist on having the last say in address generation. The service would
have to provide their public key first, and the user would then
generate two brand new keys for himself and use those to finalize the
P2SH multisig address. The user would then be the one with the freedom
to generate a collision, but in this scenario he is already the owner
of the address so neither himself nor the service would be exposed.


text:
Question about bitcoin transaction minted time
Book "mastering bitcoin" 3rd edition, on page 26, there is one statement as following:
"Approximately five minutes after the transaction was first transmitted by Alice’s
wallet, a miner finds a solution for the block and announces it to the network."
My question is why it is "five minutes"?

That's just a model example. The average time between blocks is 10 minutes, while the median is approximately 7 minutes, so 5 minutes is a pretty common time to wait for the next block.


text:
Is it possible for the commit and reveal transaction to be on the same block?
I'm new to the inscribing process and I noticed there were two transactions required for inscribing. Is it possible to have these on the same block? or is there a way to control the tx fee on the reveal tx to help increase the possibility of it to be on the same block?

If you give the second transaction a higher fee rate, the two transactions will be treated as one "package" by any reasonable transaction selection algorithm and will almost certainly be mined in the same block. However, there's no way to actually prevent a miner to only mine the first transaction but not the second.


text:
Probability of Finding a Block
I've been using cryptocurrency revenue calculators and have appeared to figure out that for all of the major algorithms, the probability of a hash being valid is 1/(D*2^u) where u is either 0, 13 (weird), or 32 and D is the network difficulty. I used the formula (my_hashrateblock_rewardtime) * 1/D * 1/2^u to find revenue. I believe the following is true:
u = 32 for SHA-256, Scrypt, X11, Groestl, X11Ghost, Lyra2Rev2, NeoScrypt, Blake (14r)
u = 13 for Equihash
u = 0 for CryptoNight, Ethash
Can someone explain this phenomenon? Will the constant part of the probability change over time or will the difficulty adjust?

To look at it a different way, the probability for solving a block in Bitcoin is approximately:
1 / ({total network hash per second} x {average block time in seconds})

Note that block time is the average.
As of writing, this is:
Probability = 1 / (24,667,167,000,000,000 x 600)
= 1 / 1.48003002×10¹⁹
= 6.75661970694351186200939356621969059789746697164966964... × 10^-20 (WolframAlpha)

Data source: blockchain.info

That '0' doesn't look very accurate or useful.

@PieterWuille You are right, I didn't try very hard for that. I will improve it.


text:
Blockchain.info Paper Wallet
I created a Blockchain.info paper wallet back in 2014. At the time I used a passphrase which only contained 8 words as the recovery seed as per the instructions. When I try to scan the public key QR code in order to check the balance I get the following "http://qr-to/banAvd".  The public key is "13gmfrUCaRB1dZB2RftmoDVYd7jjSyhq32".

and what is the question itself? your 13gmf... is neither public key nor valid bitcoin address. we are happy that you did something wrong three years ago but this information is absolutely useless

Could be one of several formats and compressions for public key. The sure way is to figure it out from the private key.

@ amaclin is it not a 33 char address base 58?

@mc my english is poor, aren't you understand my comment above? there is no question, no info, no clues, but some garbage and broken link.

I think it is a 33 byte compressed public key

@amaclin - you don't need to be rude or condescending. The question is quite clear - the guy is asking what to do. If you feel like there is not enough info you can ask for it, or ignore the question altogether, but please don't behave like a jerk

the correct address is 13gmfrUCaRB1dZB2RftmoDVYd7jjSyhq32

@amaclin - do you think that I could also find the missing character in the private key that I have?

From amaclin's comment about one digit missing in your public address above, you can checs your balance here (BTC 0.01840202): https://bitref.com/13gmfrUCaRB1dZB2RftmoDVYd7jjSyhq32
After that you can do the following:

Download and install any bitcoin desktop wallet. e.g. Electrum (https://electrum.org/#home)
Import your PRIVATE KEY that you find in your paper wallet into that Electrum wallet. It will show you the balance and allow to move the money to another paper wallet or an exchange (if you want to sell it)

IMPORTANT: as your bitcoin is pre-split (which happened earlier in August) that private address that you have also contains an equal amount of Bitcoin Cash.
These are the steps I went thru to get mine:
Where to split BTC

this is not a "compressed public key", but an address without one symbol at the end

When I attempt to import the private key from my blockchain.info paper wallet into my bitcoin core wallet an error occurs "invalid key". Any Ideas?

The length of my blockchaininfo paper wallet private key starts with a "5". The total length including characters and numbers is 50.  Shouldn't it be 51? Confused.

That's correct, it should start with 5 and it has a length of 51 characters total. Did you print it out or wrote down by hand? Could you have missed the last character? You can try brute force add a 51st character trying 0-9 and a-z

I used a printer. Brute forcing the last character did not work. Also, I have tried the mnemonic (8 words) that can be used to recover the password on "https://blockchain.info/wallet/recover-wallet" however it also fails.

Not sure what else you can try. At least the good thing is you don't have much left on that wallet.

I have a printed copy of the mnemonic to recover the password when i created the BlockchainInfo legacy wallet but that doesn't work as well.

I think it is a public key in a common 33 byte compressed form. I generated an address from it
12r9cntQ5T8o6mELxxcj1RwBZiKGVV
to check the balance and bitref says it has 0.0 bitcoins sent or received.
Also zero transactions for that wallet.

What service did you use to generate an uncompressed public key? I haven't found one

I think the guys is confused. That's why the easiest way for him is to import the paper wallet into a desktop wallet using the private key. That is, if he has ever actually transferred the bitcoin there :)

I find blockchain does not work with the public key, but the address. I used a site first to hash 160 the compressed public key, then use hash to generate an address for the purpose of checking balance. http://bitcoinvalued.com/tools.php

Blockchain does indeed work with uncompressed public keys, but it dies not work with compressed ones.


text:
Zero-knowledge/Arthur-Merlin Proof-of-Work for NP-like problems with coin flips hashes of recent transactions
On a previous answer to a question about making proof-of-work more useful, two challenges were provided:
"1. The work must be much, much easier to verify than to do,  and
2. The work must in fact secure the transactions and not be severable from them. If I see that you sent me 10 Bitcoins and then billions of computations are piled on top of that, it must not be possible to remove that transaction and then pile those same computations on top of a conflicting transaction."
To address these, has anyone considered a zero-knowledge / Arthur-Merlin proof of work (of some NP problem or co-NP problem, e.g.), with the public coin flips being the hash of the most recent blocks?
After each new block is mined, a number of other random instances of the problem may be publicly announced.  The instances could be created based on the hash of the block.  Whoever solves (the most number of) outstanding problems is the winner for that block.  She then uses the hash of that block as the coin flips for the validation of the proof-of-work.
E.G. for graph non-isomorphism, every block that is solved spawns, say, 128 new graphs added to a pool.  The first miner to find proofs of non-isomorphism for, say, the most number of the graphs in the pool wins.
It's also a truism that most instances in NP may, in fact, be "easy."  Depending on how instances are added to a pool, the instances that have been "in the pool" the longest are probably harder to solve, and may be worth more when finally mined.  (An easy 3-SAT with 20 literals may be easier to solve than a hard 3-SAT with 5 literals right at the percolation point.  The profit from mining may reflect that.)
Engaging in more rounds of commitment, with more rounds of random coin flips based off of more blocks in the chain, may lead to more complicated problems being mined (e.g. IP=PSPACE.)
A fraudster might try to buy Merlin/Peggy the miner's PoW form her, but as instances are spawned randomly, it might not do the fraudster much good. Also it’s a little harder to buy solutions to PSPACE or co-NP problems I think, without having to engage in actually finding the solution.

Just a couple of thoughts about your proposal: 1) How is G chosen (so that the difficulty can be adjusted and the Hamiltonian path can not be precomputed beforehand)? 2) When someone finds a Hamiltonian path, then she is able to create as many valid blocks as she wants (generating different permutations of G), isn't she?

Since you have referenced another question, you should probably just link to it.  Otherwise it's hard to follow the context.  It will also save you some typing ;)

This approach would have the problem that once someone solves a block, they could re-solve the block and put in different transactions. Granted, it's not impossible to make that work. (Proof of Stake systems have the same issue.) Very interesting question.


text:
Purpose of a BlockChain in local wallet application
I have installed the BitCoin wallet application on my PC, so that I can cold store my BitCoin. It's "Synchronizing with the network" and has 272 weeks of BC left to download (painfully slow!!)
What I want to know is, why do I need to download the BC in order to send/receive funds from my wallet. Is this absolutely necessary?

The blockchain is the full record of all Bitcoin transactions. Without it, we wouldn't know how much each address is able to spend.
There are some clients (called lightweight clients) that rely on their peers' blockchains while others like Bitcoin Core (sometimes called a full client/node) store the blockchain themselves. If you choose a full client, you should expect to download and store the blockchain (~21 GB currently). You can speed up the initial sync by download bootstrap.dat from a torrent, as instructed here.
What you're describing, though, is not cold storage! Cold storage means that the keys are only accessible via offline means, like a piece of paper, or a computer that is never connected to the Internet.

Thanks for your answer. I'll certainly take a look at the bootstrap.dat torrent. In terms of cold storage I intend to encrypt the wallet.dat files and burn them to a cd and remove them from my pc.


text:
Erroneous blockchain transactions...more coins than I specified!
This isn't directly related to Bitcoin; rather this is related to Infinitecoin, however the technologies are virtually the same.
The other day I sent 2,000 IFC from my wallet (Infinitecoin-QT for Windows, version 1.8.8.0) to another address.
I looked at this transaction on the blockchain, and it is reporting that I sent 60,000 IFC.
The transaction shows the 2,000 IFC as being sent to the correct address, and then another 58,000 IFC to an unknown address.
Here is a link to the transaction for more info:
https://coinplorer.com/IFC/Transactions/106a8812b178c74b65303c42c8a754941db4a296b861eab116d71bd8f4c0492c
I'd really like to know where my 58,000 IFC went!
P.S. My wallet does not show 58,000 missing coins

Don't worry, altcoins are on-topic here. See the tour page for more details:  http://bitcoin.stackexchange.com/tour

The 58000 coins have gone to a change address in your wallet. When you sent 2000 from the 60000 UTXO you've had 60000 go out to two inputs: your change address and the spending address.
Keep this in mind: when spending from a single input you're  sending the whole lot!

What is a change address, and how do I verify this against my wallet?

Open your debug console from the QT client, and do 'validateaddress x' on the address. Ismine should be true.


text:
emergence of quantum computing and its potential threat
Considering the emergence of quantum computing and its potential threat to cryptographic security, how might the Bitcoin network adapt and evolve to maintain its integrity and resilience in the face of this technological advancement, while preserving its core principles of decentralization and trustlessness?

Does this answer your question? Are there any plans to make Bitcoin quantum-resistant?


text:
Bitcoin wallet generation with P2TR
I am a newbie in bitcoin development and I just started it with bitcoinj library for Java.
I can get the code snippet to generate bitcoin wallet and legacy address.
Timestamp createdAt = Timestamp.valueOf(LocalDateTime.now());
DeterministicSeed seed = new DeterministicSeed(entropy, "", createdAt.getTime());
Wallet btcWallet = Wallet.fromSeed(netParams, seed, Script.ScriptType.P2PKH);
Address receiveAddress = btcWallet.currentReceiveAddress();
String bitcoinAddress = receiveAddress.toString();

This works well for P2PKH but I want latest type - P2TR. I just changed that parameter but it throw exception. I could not get any help from googling.
Any help would be great for me.
Thanks in advance.

As far as I know, BitcoinJ does not support (receiving to) taproot addresses yet.

@PieterWuille Ah, I got it. Then what is the latest version that bitcoinj support?

There isn't really a "versioning" of things regarding that, just features that may or may not be supported. I don't follow BitcoinJ development, but according to https://en.bitcoin.it/wiki/Bech32_adoption, receiving to P2WPKH and P2WSH addresses is supported.

@PieterWuille Thanks a lot.


text:
Code: -26, Error: non-mandatory-script-verify-flag (Data push larger than necessary)" when trying to spend from P2WSH
I have sent to a P2WSH but I can't spend from this address because I get this error;
Code: -26, Error: non-mandatory-script-verify-flag (Data push larger than necessary)"
This is the script that was hashed to make the P2WSH address:
Raw hex:
930108870063036f7264010109696d6167652f706e67004d080289504e470d0a1a0a0000000d494844520000004b000000640103000000f47a5f4a000000017352474200aece1ce90000000467414d410000b18f0bfc610500000006504c5445000000ffffffa5d99fdd000000097048597300000ec400000ec401952b0e1b000001bb4944415438cb7d933d2f436114c7cfedad6aeaad8410f1528bd818c5a211a38184cdd0dd6a61d03bfa06d686854af808bd9385cd2cadb704154d8918aedee39cd3e79ea7a4f1a4b7fde577fff77f4e9316009c35e453218c9d283e6e28de6d19747e651b8a8ecd9e56d5de5a7bffacb643ad17bbfc60f46487a13c62830387bbc9cea8611d1c832f4f823e675701f28c097067043dde6c13600731cbd3ce0002ac156407803abe8a5df0dd23bc95692b696aab67f85b9cc5c0c5371e01d4e0e020079229207bc2127ab264a7057b0b845719b1d4524f732f24093fa6781ac429fb709163eca2ab9ae47dc1a56983fdd2d047d9e325c131d093901230657306077cc819a469bec114389ec16170416d22c24918017ef1be7e26b2e35e540013fcd4bc603c4e6fe9a69dd37586ec66a3169bb13f275a9b5694fe2e4f6f2d5b8c59ecf8f550fb2a88b7b52d986adbd0627b2c76b7f46615f7adddb618da45dfadfdb693d17c3a39909f259dd90ae0b7d03029c4b0582c9650d09cb6f8e92bd68c6d68a064b35f74058cc13f652dd8883028a9cd6b20aca93db08f056f8a9f58ce301bac856563cb78838b82215de7a54233b0f755be164b7f36c46ae50752e785b8f36ef2c30000000049454e44ae42608268
Script with comments;
93 - op_add
01 - OP_PUSHBYTES_1
08
87 - op_equal
00 - OP_0
63 - OP_IF ?
03 - OP_PUSHBYTES_3
6f7264 - "ord"
01 - OP_PUSHBYTES_1
01
09 - OP_PUSHBYTES_9 ?
696d6167652f706e67 - "image/png"
00 - OP_0
4d0802 - OP_PUSHDATA2, 520 bytes
89504e470d0a1a0a0000000d494844520000004b000000640103000000f47a5f4a000000017352474200aece1ce90000000467414d410000b18f0bfc610500000006504c5445000000ffffffa5d99fdd000000097048597300000ec400000ec401952b0e1b000001bb4944415438cb7d933d2f436114c7cfedad6aeaad8410f1528bd818c5a211a38184cdd0dd6a61d03bfa06d686854af808bd9385cd2cadb704154d8918aedee39cd3e79ea7a4f1a4b7fde577fff77f4e9316009c35e453218c9d283e6e28de6d19747e651b8a8ecd9e56d5de5a7bffacb643ad17bbfc60f46487a13c62830387bbc9cea8611d1c832f4f823e675701f28c097067043dde6c13600731cbd3ce0002ac156407803abe8a5df0dd23bc95692b696aab67f85b9cc5c0c5371e01d4e0e020079229207bc2127ab264a7057b0b845719b1d4524f732f24093fa6781ac429fb709163eca2ab9ae47dc1a56983fdd2d047d9e325c131d093901230657306077cc819a469bec114389ec16170416d22c24918017ef1be7e26b2e35e540013fcd4bc603c4e6fe9a69dd37586ec66a3169bb13f275a9b5694fe2e4f6f2d5b8c59ecf8f550fb2a88b7b52d986adbd0627b2c76b7f46615f7adddb618da45dfadfdb693d17c3a39909f259dd90ae0b7d03029c4b0582c9650d09cb6f8e92bd68c6d68a064b35f74058cc13f652dd8883028a9cd6b20aca93db08f056f8a9f58ce
30 - OP_PUSHBYTES48
1bac856563cb78838b82215de7a54233b0f755be164b7f36c46ae50752e785b8f36ef2c30000000049454e44ae426082
68 - OP_ENDIF ?
As you can tell it should be spendable by just pushing two 4s onto the stack in the wittness.
Any help much apprecisted

Please fix the formatting, this is very hard to read

Bitcoin Core standardness rules require data pushes to be minimal, i.e. where multiple ways exist to push the same byte vector, the shortest one must be used. (See explanation at Opcode Explained.)
In two cases you're pushing a single byte with OP_PUSHBYTES_1 that you should push with a dedicated opcode, namely 08 and 01. Use OP_8 (0x58) and OP_1 (0x51) respectively instead.


text:
Blockchain transaction message length limit
When I perform a transaction on the blockchain, I can add a message to the transaction, which will then exist forever in the blockchain.
Say for example I wanted to use the blockchain to store digital assets...
Could this type of information be encrypted and stored as a transaction message, and if so, is there any limit to the message length of a transaction?

This message exists only on blockchain.info site. It is not a part of bitcoin protocol. You should not think, that it will exists forever, because blockchain.info is  third-party-service
Point your view to a OP_RETURN output scripts. http://bitzuma.com/posts/op-return-and-the-future-of-bitcoin/

I can add transactions messages using BitCoin-QT...


text:
Can bitcoin be forked in such way that the monetary base increase?
Can it be forked into a new coin, such that if i had X bitcoins i will still have X coins in the new crypto-coin, but the monetary base will be 50M coins for example?

Yes. It's possible to do that in a not backward compatible fork (hardfork).
Assumed that the new currency would be bitcoin50 (B50):
You could copy the whole Bitcoin-blockchain (as in every hardfork) but only modify (increase) the future block rewards so that there are around 50,000,000 B50`s available when the reward is 0 in ~100 years.

Thanks for your answer. Isn't it kind of a threat to the value of bitcoin? What prevent some powerful personals in the bitcoin community to do something like this in the future, just because there is some economic need to increase the monetary base? in the same why we abandoned the gold standard.

Well, you can be sure that someone tried something like this in the past. But remember: There is only 1 original bitcoin. And if the new currency with 50,000,000 coins is published: Why should you trust it? The developers behind it could also say 1 year later: What about 100,000,000 coins? Furthermore you need to convince a large part of the bitcoin-people. Otherwise, the b50-coins is irrelevant/worthless.


text:
Anomalous 2.7 BTC transaction fee observed
I noticed a 2417 byte transaction with a 2.7 BTC transaction fee. Is there any rational explanation for this, or was it perhaps a mistake?

What's also possible is that someone mistakenly swapped the sending amount and the transaction fee amount. I almost did that with the bockchain.info wallet but luckily noticed it in the confirmation screen.
In this case, he could have intended a fee of 0.02314796 BTC and tried to send 2.7 BTC to the address. The other 65+ BTC could be just change.

There certainly is a rationale explanation- if you are manually constructing your own transactions i.e. you are writing your own code to create bitcoin transactions its pretty easy to do this by accident.
The reason this is so easy is because there is no explicit 'transaction fee' output, rather  transaction fee = total inputs - total outputs. Hence it is pretty easy to accidentally forget to e.g. send. the remainder back to yourself or to miscalculate the remainder.
I did this once when I was testing sending miner fees in some transaction code I was writing. I mistyped the conversion factor converting from BTC to satoshis (raw bitcoin transactions record amounts as satoshis - 64-bit unsigned integers), published the transaction, and ended up sending something like 10 BTC instead of 0.1 BTC to the miners.

One possibility is that the transaction was injected by the same person who mined the block. Thus the same person who paid the fee collected the fee.

FWIW the block this transaction was included in was mined by the EclipseMC mining pool.

I already heard about rumors saying that such of "mistakes" are in fact attempts to laundry stolen Bitcoins.

Hard to tell if it was intended or accidental, but there are many other transactions out there that have very high fees.


text:
How do block rewards work with a mining pool?
I understand there are a number of different schemes for sharing rewards.
My question is about the block reward itself, and how it's shared.  If only one miner (typically a pool) can find a reward, that means that a pool doesn't get a reward for every block processed.  Yet somehow, the miner is still paid, even if no block is found.
Are all the shares submitted between blocks found counted?  ie.  If a pool finds a block every 10 blocks, do the shares from the other 9 get added together and the entire block reward split across all work done on the found and previously unsuccessful blocks based on the share scheme?

As others have said schemes differ. But to try to answer the question you asked:

Are all the shares submitted between blocks found counted? ie. If a pool finds a block every 10 blocks, do the shares from the other 9 get added together and the entire block reward split across all work done on the found and previously unsuccessful blocks based on the share scheme?

Probably not. That would be a terrible scheme. Assume a pool has a constant hash rate. Right after it has found a block, it's just as likely to find another block in the next minute as it is when it hasn't found a block for a long time. But the reward per share will be much higher if the pool finds a block shortly after finding another block and much lower if the pool hasn't found a block in a long time.
So a pool that counted every share since it last found a block would likely see a huge influx of users right after it found a block, since the expected reward per share will be abnormally high.
And if the pool is unlucky and hasn't found a block in a long time, the number of counted shares will be abnormally high, making the reward abnormally low. This will cause miners to abandon the pool.
So counting all shares since the last found block is perhaps the worst reward scheme possible.

Then how is that shares submitted during blocks that do not result in a valid has still get paid?  Where is that coin coming from?  I've used pools with a number of different schemes, and all of them pay at least something for every valid share submitted.

Look up PPS, PPLNS, Prop reward schedules.

@ErikFunkenbusch As has been said a few times, it depends on the reward scheme which varies widely between pools.

@DavidSchwartz Actually, that is pretty much what proportional payout pools used to do, and the problem you're describing was heavily exploited in practice (pool hopping). No pool still uses proportional payouts, but early on they were pretty much the only popular scheme.

There are different pools and different mechanisms, to distribute the funds. I suggest to read it here: http://chimera.labs.oreilly.com/books/1234000001802/ch08.html#mining_pools

I know there are different schemes.  I have a very specific question that should apply to all schemes.  your link does not answer that question.

@ErikFunkenbusch I don't see anything in your question that applies to all schemes. Which shares count varies by scheme.


text:
Locating Bitcoin with only seed phrase
I purchased Bitcoin back in 2018. I have no record or recollection of how it was stored, but I do know it was never transferred to a physical wallet. At one point I was trading via an online exchange on my phone, but I can no longer log onto to any of the crypto apps I have on my phone from back then (and many of them no longer exist in the app store). I do however have the 12-word seed phrase. Is there any way I can access the BTC with this alone?
Any assistance much appreciated.
Thanks!
Miles

This question is similar to: Why is this 12-word mnemonic deemed invalid by multiple wallets?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

Also see I forgot which software I created my wallet with. How can I recover from a 12 word seed phrase?


text:
copy an existing transaction
in case I copy an existing transaction (I mean copy everything of an transaction fromAdress, toAddres, amount, signature, ...) and try to broadcast it, I know that It will fail because the transaction is exist before. My question is: Is bitcoin have to traverse to all transaction on all block before to see that my transaction is exist before, I think that is just very inefficient

This question is similar to: How does the transaction signature prevent transaction duplication?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

Is bitcoin have to traverse to all transaction on all block before to see that my transaction is exist before

No.
Nodes such as Bitcoin Core maintain a list of unspent transaction outputs (UTXOs). When verifying a transaction they check that its inputs are all in their UTXO set. Transaction outputs referenced as inputs to earlier transactions will no longer be in the UTXO set.


text:
How was this transaction's relative locktime satisfied?
I was looking at this transaction: 3c1c9fb9d6b215efdeedb5caf6a951a9e6c6c1e3de6e5674f646c63e94667497
TapScript with nSequence also set to 0x4001fa
OP_PUSHBYTES_3 fa0140
OP_CSV
OP_DROP
OP_PUSHBYTES_32 a4c184aae8b4ccba9682b5ea95faf15ff2f82820fa1eb34aa5a13220fb366285
OP_CHECKSIGVERIFY
OP_PUSHBYTES_32 2a9a53362dd63cb58cfe9a7ee7a05d84b9872054ac366e615fc2dc12eddf20fa
OP_CHECKSIG

fa0140 converts to 4194810, I believe it means seconds, which translates to roughly 48 days. But its output was created around 4 days ago, so how it was confirmed?

The sequence 004001fa (big-endian, padded to 4 bytes) actually represents a relative locktime of 259,072 seconds, almost exactly 3 days.
The way you interpret a sequence number as a relative locktime (as specified in BIP68) is as follows:

Check if the highest bit is set, if so then no locktime applies.
Interpret the lowest 16 bits as an unsigned integer, and:

If bit 22 is not set, this value is the locktime in blocks.
If bit 22 is set, multiply this value by 512 and you get the locktime in seconds.

Now, let's look at the sequence 004001fa in binary, with the relevant bits highlighted:
0000 0000 0100 0000 0000 0001 1111 1010
^          ^        ^^^^^^^^^^^^^^^^^^^

Since the highest bit is not set, bit 22 is set, and the lowest 16 bits give the number 506 (111111010 in binary, 1fa in hexadecimal), the locktime is 506 × 512 = 259,072 seconds.


text:
How to find IP addresses for large mining sites？
How can I find the Bitcoin core IP addresses of large mining sites such as Foundryusa and Antpool, query transactions entering Mempool, and push my transactions in? Mempool.space hides some conflicting orders, which is no longer reliable!!!

Have you considered asking their support teams?


text:
Open-source blockchain explorer for regtest mode
I'm trying to find an open-source Bitcoin blockchain explorer that will work in regtest mode, so I can more easily inspect the blockchain, see what transactions are getting processed and included, etc.
I found the following ones, but all of them seem to have issues:

blockcypher is "not easily compatible with running your own version locally, and this is no longer recommended (except for expert users)."
bitcoinchain is not open-source AFAICT.
Bitcore's insight-ui [1], [2], [3] does not work with bitcoind AFAICT.
toshi does not work with bitcoind AFAICT. Not sure how to set it up in regtest mode to connect to another bitcoind full node.
bitcoin-abe does not seem to support regtest mode, though it could be as easy as adding a new Abe/Chain/Regtest.py file.
blockchain.info: can't really tell if the My-Wallet-V3-* repos [1], [2] are for the block explorer website or for the wallet-management side of the website.

So, any suggestions for an easy-to-setup blockchain explorer that works with a local bitcoind node ?

Great list however, Toshi doesn't really have much to do with Bitcoin and is not an explorer AFAIK.

I managed to point Abe to regtest just by using datadir=/home/$USER/.bitcoin/regtest in the config file and following the official instructions.

worked fine. there is a bug with segwit MerkleRootMismatch: Block header Merkle root does not match its transactions. block hash=0000000000. i solved it by cloning https://github.com/marioschlipf/bitcoin-abe repo

I tried Abe but couldn't easily make it work on MacOS. I had a look at some other options and managed to make this one https://github.com/janoside/btc-rpc-explorer work easily and nicely. It has quite a lot of things you want from an explorer.

Bitcoin Abe is awsome.
create virtual environment for python2.7(since abe only work with python2.x)::
sudo apt-get install virtualenv, python-dev
virtualenv --python=/usr/bin/python2.7 myenv

Install requirements:
source ./myenv/bin/activate
pip install pycrypto

clone marioschlipf's repo (since it solves segwit) and install it::
git clone https://github.com/marioschlipf/bitcoin-abe
cd bitcoin-abe
python setup.py install

Create abe.conf with contents:
datadir=/home/USER/.bitcoin/regtest
dbtype sqlite3
connect-args abe.sqlite
upgrade
port 2750

Perform the initial data load:
python -m Abe.abe --config abe.conf --commit-bytes 100000 --no-serve

Look for output such as:
block_tx 1 1

Then run the web server as:
python -m Abe.abe --config abe.conf

Now vist on browser http://localhost:2750


text:
Bitcoin client which doesn't use wallet.dat?
Is it possible to use Bitcoin client without wallet.dat file, by entering your addresses and being able to see the balance, but without the ability to spend bitcoins? I know that it's possible to backup wallet.dat and use another wallet.dat, but in that way you don't see your transactions and balance and can't label your addresses etc.
If it's not possible in official client (I believe it isn't), are there alternate clients that allow this? The point is to be able to backup wallet.dat and plug it in only when spending bitcoins, but not lose the ability to see your transactions in the meantime.

Does that really work? I used to do that, but once you start spending, the change goes into newly created addresses that the Bitcoin client does not display, so you cannot track that. http://bitcoin.stackexchange.com/questions/736/how-does-change-work-in-a-bitcoin-transaction Works for monitoring incoming transactions, though.

This is not exactly what you're asking for, but might be helpful. Bitcoin v0.4 supports encrypting wallet.dat, so you cannot spend without entering the password. Basically you would do something like:

make a copy of wallet.dat
encrypt your copy with Bitcoin client v0.4 and set a long random password (one you will easily forget)

Voila, you have just created your read-only wallet. Because of 100 keypool you will even see some new transactions made with original unencrypted wallet.dat
You can download Bitcoin v0.4rc2 here.

This is the best available option currently.  It would be great if someone developed a client that kept the public keys seperate from the private keys so that you could not only encrypt the private keys but keep them offline.  But until then, the best option is to just keep the private keys always encrypted.

On the other hand, isn't it a weird choice to allow reading the public keys in the wallet without the password? That way, if someone finds your wallet, your anonymity is greatly compromised (it becomes obvious what your keys are and how many coins you have). Shouldn't there be an option to encrypt it "all the way"?

@Thilo: How would that be any different from just not having the wallet at all? Simply encrypt the wallet with any tool you want for that effect.

@David: I was just surprised that the new encryption feature (if it does work as hinted at above) does not already do this, so that you still have to "encrypt the wallet with any tool you want" (in addition to the built-in feature, which I thought would have made the extra step unnecessary).

@Thilo: If you're going to be decrypting the wallet every time you need to see your balance, the risk is too high that you'll either leave your wallet unlocked (so malware can capture it from memory) or type in the password (so malware can capture it from the keyboard). The cost/benefit on that approach just doesn't make any sense for most people. As for an "extra step", it's fairly trivial to automate, whereas the more sensible (for most people) hybrid approach is harder to automate.

I don't think that it's possible to do anything like that using the official client.
btcbalance.net is a service that lets you store a number of public addresses and view their balance and latest received payments online. I can't vouch for it though since I haven't used it myself.
If you don't want to give your addresses to anyone else you could always just store some links to blockexplorer. http://blockexplorer.com/address/<your_address> will show you the balance and transactions of that address. That's not as convenient as a client/service doing it for you of course.

btcbalance.net looks promising, I wonder if it allows to set labels for addresses.

The problem with btcbalance.net and any solution like it is that they don't deal with the fact that most people have bitcoin addresses that are invisible to them.  When you send BTC to someone, there is almost always a new bitcoin address generated for you that receives the "change".  So if you receive 10 BTC at an address and then send 4 BTC to someone, the difference (6 BTC) is now assigned to a hidden address that your wallet.dat knows about, but you can't see.  btcbalance.net would show your balance as 0 BTC which isn't correct.

@Erv: That is hopefully changing in a future version of the client as well though. Should handle addresses in a much more intuitive way.

The BitcoinJS project implements a client that has no wallet.dat.
It does, however, keep the keys necessary for spending on the mobile client in the html5 local datastorage.
 - http://bitcoinjs.org
WebCoin's implementation: http://www.webcoin.ch

As mentioned above, btcbalance.net does what you're looking for.
Also, I have not tested it, but according to this forum post, a Chrome extension called Collate allows you to view your balance without making your bitcoins available for spending:
https://bitcointalk.org/index.php?topic=17158.msg334959#msg334959

In 0.2 you can use the Block Explorer to examine your wallet without
  actually having to run the BitCoin client.  This means you can keep
  wallet.dat on an encrypted partition via TrueCrypt or w/e and you can
  still monitor your account balance (although to send coins you will
  still need to start the BitCoin client for obvious reasons).  In 0.2
  the Block Explorer method of viewing a wallet supersedes the old way
  of connecting to the BitCoin client since the latter requires that
  your private key be stored in memory all the time (which is a bad
  idea).

Collate can be downloaded here:
https://chrome.google.com/webstore/detail/anlcpclkmbeeoglfgbfboogijdkbohkn


text:
What's the most popular Namecoin exchange?
There are several Namecoin exchanges listed at official wiki and Bitparking seems to be the oldest, but which one is the most used?

Namecoins have such a low value you shouldn't really care, just pick one.

@Lohoris, value doesn't really matter to me. Exchange popularity does.

I'm sorry, but Namecoin is so popular you got 0 answers so far, so...

I couldn't find actual numbers (so I'm not going to formally answer), but Bitparking, in what open buy/sell prices and volumes are listed on the site, is by far the largest.

@Lohoris obviously. :)

@BinaryMage thanks, that's something to begin with!

This answer has been attracting a lot of low-quality answers and is off-topic by community guidelines. Voting to close as off-topic.

Almost everyone seems to use the Bitparking Namecoin Exchange.

I don't disagree, but can you back that up with numbers? "Almost everyone" is far from absolute.

Use the Bitdango market search to find Namecoin markets:
http://bitdango.com/markets?baseCurrencies=NMC
Then look at each market's order book, more orders means more liquidity (probably) so that's one way to base your decision.

bitparking is not recommended as they don't know what the word BACKUP is and is holding people coin now because their HD crashed and have not fixed the issue.  I highly recommend you stay away from them.
There are so many other alt coin exchanges out there.
I am currently using:
http://cryptsy.com/

It seems that since I asked this question BTC-E has taken the lead in terms of Namecoin traffic - but this is just my educated guess, haven't got the numbers to back it up.

I love how someone down voted my bash on bitparking.. go to their website and see for yourself:
2013-11-26: Work on the recovery site got delayed but it's back in progress
and I hope to have something up soon. I have been processing
recoveries during this time so some funds have been restored.
Yet I still have not received my lost coin there despite multiple attempt to get it back.. and we are only talking about 3 NMC.  LoLz.. what a looooooooser website

currently 94+ BTC and 69k+ NMC not returned to customers.
https://bitcointalk.org/index.php?topic=165153.msg5689939#msg5689939

www.cryptsy.com, www.mintpal.com, www.coinmkt.com

While listing exchanges that list namecoin may be useful, you are not necessarily answering the question which is the most popular, maybe check the relative volumes of these exchanges and add it to your answer.


text:
Bitcoin usage charts
There is a lot of data out there about BTC prices, but are there any simple charts which show how much is Bitcoin really used? Something like number of Bitcoin transactions per day/week, or daily amount of bitcoins transferred, from the beginning to present?
The data should be available in blockchain, but did anyone make pretty charts?

Blockchain.info is an alternative to blockexplorer that has additional statistics regarding market prices, mining costs and bitcoins in general. There is some information there about transactions that might interest you.
Here is a chart with data from last year:

A chart with Bitcoin Days Destroyed is also available at the website. This might be a better way to represent Bitcoin's usage. See this question and the wiki for more information about Bitcoin Days Destroyed.

Though the problem is those transaction counts can be manipulated -- such as a single user sending back and forth between two wallets, or they could be simply transactions to and from exchanges and not reflect whatsoever any increase or decrease indicating whether Bitcoin is gaining or losing traction.
But at least that data point is better than having no data.

Stephen Gornick, that's a good point. @Domchi might be also interested in Bitcoins Days Destroyed. It tries to provide a more accurate measure of bitcoin's volume.

The macroeconomic concept of 'velocity' is relevant in this context. However, Because it is not possible to be certain which portion of a Bitcoin transaction is 'spend', and which part is 'change' back to the spender, the traditional definition of velocity is difficult to apply.
An alternate means of measuring 'velocity' or use in the Bitcoin economy is something called 'Bitcoin Days Destroyed'. It is explained at the wiki here. A more recent chart is available here. It is also summarized in the last column of the alternate block explorer.

Im unable to find a clear description on what days destroys actually shows. I understand how it is derived, but I dont understand the use value of what is being measured.

osmosis: it is simply a way to "weight" the importance of a transaction - making the assumption that a transaction involving coins that have not been used for awhile is more likely a "real" transaction than coins that were moved just yesterday. It is a very imperfect measurement, but adds different perspective to pure usage statistics, which are very noisy. See also: http://bitcoin.stackexchange.com/questions/845/what-are-bitcoin-days-destroyed

http://bitcoinwatch.com/ Gives charts and stats:
( FYI I am not affiliated with bitcoinwatch )


text:
Paper backup from Armory that requires a password?
I'd like to make a paper backup of my Armory wallet that will still require a password to recover. Right now it seems that the paper backup is not encrypted.

This is what the core armory dev had to say about encrypted wallet backup.

As the paper backup consists of two simple string you can use any encryption scheme you'd like to implement this.
This can be as simple as manually applying rot13-like encryption, to one-time-pads. Just make sure you keep the ciphertext short in order to still be able to print and, more importantly, type it in eventually.

As Nick mentioned, I'm not a fan of encrypted paper backups.  Instead, I added "Fragmented Backups" to the new version (0.90-beta, posted a few days ago on the website), to give the user flexibility in balancing physical security & redundancy without the high risk of permanent coin loss.  After all, 95% of the emails we get are users who forgot their password.  Many of them didn't even realize that their paper backup protected them against that.  As far as I'm concerned, that's the number one reason to make it.
Of course, doing it this way does reduce physical security, but that's far from the biggest threat to most users. If you are concerned about physical security, I recommend you explore the fragmented backup system in the new releases, which addresses these concerns in a robust and "responsible" way.


text:
What was the longest held UTXO ever spent?
What output had the longest period between when it was created and eventually spent?

As of June 19 2019, using the following query:
bitcoin-indexer=> select reverse_bytes(output_tx.hash_id || output_tx.hash_rest),
 output.tx_idx,
 output_tx.current_height,
 input_tx.current_height,
 input_tx.current_height - output_tx.current_height from output
 inner join input on input.output_tx_hash_id = output.tx_hash_id AND input.output_tx_idx = output.tx_idx
 join tx as output_tx on output.tx_hash_id = output_tx.hash_id
 join tx as input_tx on input.tx_hash_id = input_tx.hash_id
order by (input_tx.current_height - output_tx.current_height) desc limit 40;

against fully indexed blockchain (using rust-bitcoin-indexer), I was able to identify the coinbase of d5a045c9d8a5bf7619c52968945c494d49333b80d51f1d0e2747b9e8bb2c6709 as the longest held UTXO ever spent (so far).
It was created in block 45697 and spent in block 559367, which lasted 8 years 10 months and 3 days.
The full set of results:
                           reverse_bytes                            | tx_idx | current_height | current_height | ?column?
--------------------------------------------------------------------+--------+----------------+----------------+----------
 \xd5a045c9d8a5bf7619c52968945c494d49333b80d51f1d0e2747b9e8bb2c6709 |      0 |          45697 |         559367 |   513670
 \x67e8d773078b75fb5680089b8d2d380be93943a1dcf9c37e309d517a98e5d40c |      0 |          66188 |         570705 |   504517
 \x9c90d07be3d18c7a3612cd971934ed89c0d07fa302d4922481d1114dfaedc93d |      0 |          73303 |         577470 |   504167
 \x7a8a36f68d265ff49e4df5215a2a6dd922dbfbb6cc695399d2b10efd4a75c47d |      0 |          52632 |         553012 |   500380
 \x08ca56db26ad6d171e7fbcb24e592590bf369d70fc5931eb3790278681f35768 |      0 |          52644 |         551281 |   498637
 \x5fba526502ee887bc1e6beb0255cfcdfaaf41e0d25e233e447e585458ed37ac5 |      0 |          52652 |         551281 |   498629
 \x9596d84e671daea6ee965244ca75e204dfa72a471db3cb51dc406fbfeacc2e92 |      0 |          69951 |         567828 |   497877
 \x82b6f02c86fd3afb5ca23b7bf88d509e92516129dc36ceb4864114ed5ec710f5 |      0 |          66446 |         563621 |   497175
 \x31a67bf1f3cf01351b76cb16931ceb45c670b50af850181ab586d97040d90a1b |      0 |          82729 |         579816 |   497087
 \x463b0f7c96214418af0f50836047ce0e9cbc5940b739d7d67eed1842e2edf768 |      0 |          82944 |         579816 |   496872
 \x508d7a4ff36cda617aecd02da86fd5449176b0c75d3e398242253dbce6d54eeb |      1 |          83477 |         579817 |   496340
 \x4e0584a90c9dce50ecd9ed1b2d79a3a8af0f690041dccc035fd81f06ac200571 |      0 |          56710 |         551275 |   494565
 \xc6c9e4be37ea843fe50df740b5acba5d23c894a4b68191b1c157b281a8a985c5 |      0 |          74897 |         568169 |   493272
 \x9296baa58de452d15763079e71861f5580863c462ce855a41e485e92f28f6e98 |      1 |          68586 |         560782 |   492196
 \x404116e265c3717b403697ea226f6d839a24f88009b1802b978b692edca95cf4 |      0 |          59137 |         551279 |   492142
 \xf6a0cc22d749a299c83c86df3406b9d6d9e6a70215978363ef5e884812112461 |      0 |          60717 |         551279 |   490562
 \xa28a27378b3499997d1c990813adddbd25e470e0b44510896435b9a918968a0b |      0 |          61047 |         551272 |   490225
 \x36a230b30815e40d238f27f2654ff3681f6c1931076e90c4c05065002b9d91e6 |      0 |          73788 |         562598 |   488810
 \xdcc71895e1baf0abb83ff27348211662b517105b18789f4410a55a51dc50a156 |      0 |          66637 |         555282 |   488645
 \x899ee05d5c4e91b3ee49958a9d0333ff9b1987c352d946ecdb1fd91588f667ac |      0 |          66336 |         554738 |   488402
 \x6284dc97c5c923308675e9b0db88210ad61a42815caaf024b07cc0eb9e262c67 |      0 |          33538 |         521167 |   487629
 \x56102337f6f10161a2286fe1ffb91e353b13a17db6a41c6149574d6dae476528 |      0 |          33590 |         521167 |   487577
 \xf398b7e93220747aa2f45f36284606b2ae802741160f28f2fd3f2afa40bfd346 |      0 |          66627 |         553372 |   486745
 \x708d840ea0041386b4376896b14e510d0cad3cdaeb707fe93ab2d33372723503 |      0 |          68283 |         554738 |   486455
 \x452e2d312a18d907f2ef1ec976b1ed18ef2f5a079ee47037a346f260bad339e2 |      0 |          33784 |         519776 |   485992
 \x0c1739923133af9f52a5764227f2da487f5f4520b5d0127c0867062a311cfeca |      0 |          65671 |         551393 |   485722
 \x6f69ff89b936ac2120cbdc824138022de749977202153680b199bfb1d8afba75 |      1 |          89869 |         575308 |   485439
 \xfcc26559921b51b07cf81d858689a4007fc9cf8fad96d4394da89e3e2d1a1299 |      0 |          91948 |         576386 |   484438
 \xd1ff751609b5a74f99573d7d7baa1c1dc493c9bebd586f6bf381ee0877282ed2 |      0 |          97810 |         579234 |   481424
 \x583b6351a67d96fc42c5294ee4282616c5bd1481e464720cb959fa4c3a5ce192 |      0 |          70534 |         551654 |   481120
 \x836f332753244b3eaa6ea80ddcd59d6727de8874abef09f5f5bfa44d05025d05 |      0 |          70541 |         551654 |   481113
 \xee2feeca4e02840b7036e28045a5dfd06ab65af5b1068cd9598ec3b87d4f4b32 |      1 |          70542 |         551654 |   481112
 \xb0d701da413083e89f00f824a8300387ded7671ca3ca967811c758019cfaf3ba |      0 |          93709 |         574785 |   481076
 \x23b140fb832912031596256b184010e52e24cf66da94dabc80770970087d2f82 |      1 |          92499 |         573193 |   480694
 \x7712a8c8752090e8fa9527603ed08f72b00ace2b9a495d91e78523ff50844182 |      0 |          77095 |         555959 |   478864
 \xed151ae3b0d1cd50df1f97cc4b8747d185b56f54f5aef3754079faa089e3e783 |      0 |          83936 |         561411 |   477475
 \x8d432c241971e25172268765b219d6ed82c3868981a85c9189812b57ddd28912 |      0 |          97972 |         574951 |   476979
 \xcfc9154235db58abd3f09bfd277b084a95ccbd03ed2161d0ab4ef4ed36166821 |      0 |          84411 |         561076 |   476665
 \x5ad52480756416f6288be488f14392799c0ea2d050f96d4306b846d516b02f80 |      1 |          82966 |         558812 |   475846
 \x269bbd2cd3dd7f88da4ca7086e75d36f0d2d4a54b1b5f0ed7509f7375cc71715 |      0 |           3607 |         479423 |   475816
(40 rows)

As of 20 May 2020, there is a new record:
The UTXO had a value of 50 BTC, and was created in this coinbase transaction, in block 3,654:
f38d6f043c070ce9805ee81f46db4d32d0c9f148d62bbfbc0378bc5847c7dc70
The UTXO was then spent in this transaction, sending 40 BTC to one address, and ~10 BTC (less fees) to another address, in block 631,058:
cb1440c787d8a46977886405a34da89939e1b04907f567bf182ef27ce53a8d71
The UTXO was thus held for 627,404 blocks, or about 11 years, 3 months and 11 days.
At the time it was spent, the output was worth just under $500,000 USD. When it was spent, there were 205,887.48 bitcoin days destroyed.

Another one? https://www.reddit.com/r/Bitcoin/comments/lrgrip/ultimate_hodl/


text:
Reusing bitcoin hw wallet infrastructure as a PGP replacement?
A lot of people who own Bitcoin are already know how to securely generate, store and use their BIP32 + BIP39 wallets, and own hardware wallets.
Are there any existing projects/standards trying to bolt on PGP-like capabilities on top of this existing secure-key infrastructure?
I imagine, that in a perfect world people would just generate their 24 words once in their whole lifetime, and then export some applicatin/device specific derived keys to other (potentially less secure) devices and use these for things like git commit signing, encrypted communication, 2FA, etc. . When the keys get compromised, or it's time to simply cycle them, they could use the determinism to switch to new keys (by just bumping the sequence number in the derivation path) which were known well in advance, but which were never exposed to anything other than the devices handling the master key. Seems like it would simplify and unify a lot of secret-key management, by piggy-backing on what's already being done in Bitcoin.

While I'm not sure how far the development of hardware wallet support for Lightning is, there is an E2EE messaging protocol called "Sphinx chat" based on the Lightning Network. Some HWW also function as smart cards for PGP and general password manager. I'm not aware of a project that aims to provide an email encryption system.


text:
blockchain.com websocket not working
I started to listen to the "wss://ws.blockchain.info/inv" websocket address in the link below, but none of the transactions I made were sent to the messages. Later, when I tried the blockcyper's websocket, all the transactions came. Currently, I am looking for a free websocket service, not a paid one.
https://www.blockchain.com/explorer/api/api_websocket

I had to solve the problem by listening to all transactions and checking the address as follows.
ws.addEventListener('open', () => {
    ws.send(JSON.stringify({
        "op": "unconfirmed_sub"
    }));
});

ws.addEventListener('message', (res) => {
    let data = JSON.parse(res.data);
    let outs = data.x.out;
    let out = outs.find(o => {
        return String(o.addr).toLowerCase() == receiver.toLowerCase();
    });
    if (out) {
        setTimeout(() => {
           startCallback(data);
        }, 6000);
    }
});


text:
How does Bitcoin Core Wallet calculate the weight of each input before it's spent?
The Bitcoin core wallet selection algorithms, particularly coin-grinder use a weight metric for each output.  My understanding is that an output's weight is composed of the base_weight which is a constant amount plus a satisfaction_weight which is variable depending on the type of output and script/arguments needed to unlock it.  My question is, how does bitcoin core know the weight during coin-selection before it's actually spent?  Is this weight an estimate based on the type or is it accurately computed?

The coin selection algorithms all use an estimated weight. It is not a metric but rather the estimated weight that the resulting input will have.
The estimate is based on the type of the output script. For some script types, it will be accurate, for others, it is an upper bound. Bitcoin Core can only make these weight estimates for script types that it knows, it cannot do this for arbitrary scripts.


text:
Pending lightning network transaction for over 30hours
I sent a Btc transaction from cash app Btc wallet to my exodus lightning network wallet using the lightning network.  The payment was made around 1:00pm central time on Monday, July 24.  Have spoken with cash app and they tell me “there is nothing we can do”. Before, and after, this attempted payment, I sent multiple payments on the lightning network to my exodus wallet without any real issue.  The transaction sent after the stuck pending one im writing about took longer than usual, but still completed within 15 mins.  Is there anything I can do, or need to do, in order to allow the pending transaction to either drop off and fall back into my cash app wallet or proceed to its destination in my exodus wallet.
Please help.
Thanks

1st you can wait for timelocks and 2nd you could provide details about the payment so that we can help debug. Cashapp team is most likely right though

I had ~0.0001 BTC lost the abyss recently as well, vanished from sending via CashApp to a lightning invoice.  Got stuck in Pending in CashApp.  I ignored it for a few days, checked just now and it properly canceled itself on CashApp side.  When it was stuck in Pending, the amount being sent was subtracted from the bitcoin balance before the send attempt.  Now that it canceled itself, the original BTC balance is back in my bitcoin wallet.  Lightning Network = not yet perfect, but better than having to deal with banks.


text:
A few questions on BRC20
I'm testing BRC 20 tokens on bitcoin testnet and there are some points I don't understand.
1 => It seems tokens cannot share a common name. For example, there cannot be two different BRC 20 token deployments whose tickers are "ordi". How does the system know this?
2 => Also, I inscribed the minting script {"p":"brc-20","op":"mint","tick":"ordi","amt":"1000"} and successfully recorded on the blockchain network (that is, reveal transaction). "ordi" token has already been fully minted on testnet and even though the transaction was successful, no amount of ordi tokens was dropped into my wallet. How does the system know this?
Are there some kind of verification algorithms/checking processes for BRC 20 tokens on bitcoin source code? If so, where can I see them?

I believe BRC-20 software keeps track of precedence and gives priority to those who first deploy a token name. But the inner workings of BRC-20 are off topic here, Only their effect on Bitcoin is relevant to this specific  Bitcoin question and answer website.

Are there some kind of verification algorithms/checking processes for BRC 20 tokens on bitcoin source code?

The  source code of Bitcoin core has no knowledge whatsoever of BRC-20
This is true of many other Bitcoin node software implementations.
You need BRC-20 software if you want to assign meaning to data hidden inside Bitcoin transactions.

Thanks. So BRC 20 is a consensus reached among the public (irrelevant to bitcoin core) on how to interpret the witness data written in a specific format?

I believe that is correct.


text:
Can anyone give me some help editing the Abe html?
I've got Abe running, but would really like to get the page looking nicer. I've managed to change the logo, but would like to change the title and change some colours and fonts, maybe add some more text.
I know this HTML is generated on the fly, from abe.py? I've tried editing that, but it doesn't seem to effect my page at all.

Are you re-running abe.py each time you edit it?

I do CTRL + C to break and then start Abe.

Hmmm... you're editing DEFAULT_TEMPLATE to change the HTML, right?

I think so, yeh. The bit directly underneath,
# Abe-generated content should all be valid HTML and XHTML fragments.
# Configurable templates may contain either.  HTML seems better supported
# under Internet Explorer.

I use CSS only.
Try this: Use default Abe html layout and use the following modified abe.css. The only changes needed are logo margins and color/font palette. Name your logo the same as abe's (logo32.png - makes things easier)
Click here for the modified abe.css
I modified the previous abe.py but found with the current version I'm using (0.8pre) that css is much easier. Most objects on the page can be manipulated.


text:
What is the maximum number of inputs/outputs a transaction can have?
Is there a maximum recommended number of inputs/outputs for each transaction? I was scripting a faucet and wasn't sure whether to payout in one transaction to all addresses or split them into groups of say 100 or 1000.

I don't think there is a limit, except that every transaction must be capable of fitting into a block.

The total size of the transaction must be less than 100,000 bytes or it will not be relayed across the network or included in blocks.
There COULD be a miner that is mining >100K transactions, but I don't think there is; if there is such a miner or you mine the transaction yourself then the limit would be the 1,000,000 byte blocksize limit.

This was true previously however, BIP141 has changed things when it was activated. See this question: What is the current maximum Bitcoin block size in MB?

These numbers are slightly different today after the segwit and taproot softforks got activated.
A standard transaction is limited to 400 000 weight units (WU). The smallest standard (single-sig payment¹) input is a P2TR keypath input with 230 WU. The smallest standard (payment²) output is P2WPKH with 124 WU.
The header of a segwit transaction takes at least 42 WU. For transactions with large input or output counts, the counter will increase from 1 byte to 3 bytes when we have more than 252 inputs or outputs. This means that for the below transactions the header bytes will weigh 50 WU, leaving 399 950 WU for inputs and outputs.
Therefore, a standard transaction with one P2TR input (230 WU) could have 3223 P2WPKH outputs (3223 × 124 WU = 399 652 WU) (and could optionally add one OP_RETURN output (40 WU+) for a total of 3224 outputs).
A standard transaction with one P2WPKH output (124 WU) can have 1738 P2TR keypath inputs (1738 × 230 WU = 399 740 WU).

¹ A P2WSH input with an OP_TRUE witness script would be smaller and considered standard (H/T @instagibbs), but I’m sticking to commonly used script types based on a single signature for this answer.
² OP_RETURN outputs can be smaller (H/T Pieter Wuille), but you are only permitted a single OP_RETURN output in a standard transaction.

The economical way in your case would be to pay off (create as much outputs) as you can to decrease the fee cost.
Some standard transaction with one proven input and one output is about 161 - 250 bytes. see reference some est. basic values:

10 bytes for transaction header
50 bytes for previous transaction reference

9 bytes for header

50 for output (depending on script size)

The standard requirement (for miners to include your tx) is to pay 0.0001 BTC per 1000 bytes.
If your transaction is larger than 100 kB theoretical limit could be that your transaction is non-standard which means it fails the test IsStandard() for including the tx into the block because it is too large.
Nevertheless, it is possible to include even non-standard transaction into the block. This is being done by several mining pools but usually requires slightly higher fee.
So I estimate you can create transaction with up to 1900 outputs paying just 0.02 BTC fee and having transaction most probably verified in the upcoming block.
Please note that I have not tried this myself it is just my assumption.

I appreciate your input here. 0.02 is actually quite a high fee considering the small nature of the transactions I make. Furthermore I do not require that the transaction is processed promptly. Due it being a faucet I'm not bothered how long the transaction takes to confirm. In this instance what do you think would be a suitable number of addresses to include for a fee closer to 1 mBTC or similar?

@cainy393 Yes, you can have the fee as low as a 0.00001 BTC but it will take ages to get confirmed. I advice you to make some research on this - try to relay some low fee txs.

Since I was using the blockchain.info API I just set the transaction fee to normal and let it select a reasonable one, which almost always seems to end up being 0.1 mBTC as per usual.
I found that much more than 100 transactions at a time became a problem due to the fact that I was making a GET request to the API and I think the url was too long.

The maximum theoretically possible number of outputs in a transaction is 111105
To achieve the theoretical maximum, the transaction must be a coinbase transaction with non-output fields minimised (so that the ~whole block can be dedicated to outputs).
A formula for the possible number of outputs, N, in that case:
Block_size_limit_bytes = Transaction_fields_bytes + N*output_size_bytes
N = ⌊ (Block_size_limit_bytes - Transaction_fields_bytes) / output_size_bytes ⌋

(⌊x⌋ means round x down to nearest integer)
For P2PKH:
Transaction_fields_bytes: 47 bytes (ignoring BIP34)
output_size_bytes:  25 + 9 = 34 bytes

N = ⌊ (1000000 - 47) / 34 ⌋
N = 29410

Maximum number of P2PKH outputs is 29410
For P2WPKH:
Transaction_fields_bytes: 47 bytes (note no witness field required as no Segwit inputs)
output_size_bytes:  22 + 9 = 31 bytes

N = ⌊ (1000000 - 47) / 31 ⌋
N = 32256

Maximum number of P2WPKH outputs is 32256
For AnyoneCanSpend:
Transaction_fields_bytes: 49 bytes (additional 2 bytes as no outputs>2**16)
output_size_bytes:  0 + 9 = 9 bytes

N = ⌊ (1000000 - 49) / 9 ⌋
N = 111105

Maximum number of AnyoneCanSpend outputs is 111105


text:
Why does Litecoin have lower transaction fee than Bitcoin?
Is it only because LTC doesn't have as many users as BTC? Or do the faster confirmation times also help with lowering fees?
Thanks

Litecoin's blockspace supply is greater:

Litecoin's block interval is a fourth of Bitcoin's at 2.5 minutes
SegWit is activated, limiting blocks to 4MB weight instead of 1MB size. With leisurely adoption of the new segwit transaction format this would eventually allow a capacity equivalent of blocks with ~1.7-2.3 MB size.

Litecoin's blockspace demand is much lower:

Bitcoin does about 250k transactions per day with the mempool never completely flushing out, Litecoin has just slightly over 19k, while it could do about 2,000k.

Bitcoin is operating with demand exhausting the supply continuously, thus finding actually a price for blockspace. In the past months we've seen feerates move between 1 and 540 satoshi/byte. Now that the latest hype has cooled down slightly, we can observe a daily and weekly cycle, under the week going from ~8 to ~400 satoshi/byte, dropping down to as low as 2 satoshi/byte on weekends.
On the other hand, Litecoin is operating with demand at approximately 1% of the supply. Miners appear to be observing a hard coded minimum fee of
100 litoshi/B.

So basically it's because they have less users on the platform? If LTC also had a similar amount of users as BTC, then it would have similarly high transaction fees?

@student77 The price of transactions is subject to supply and demand just like a service on any other market

Yes, blockspace supply on LTC is factor ~4-8 higher, and demand is factor 10 lower. If these were getting closer, LTC would also transition to a fee market instead of their flat fees.

Ok so to clarify: if LTC had the same number of users as BTC, then LTC would still have lower fees because blockspace supply is greater? That is the main long term differentiator in transaction fees?

If LTC had a similar amount of users as BTC, they'd have a fee market. Likely the market would find an equilibrium at a lower cost if we're only going by supply and demand, but they also have a higher degree of miner centralization, and lack some of the block relay infrastructure that Bitcoin already has. It's a complex market, it finds it's own price.

What is the block relay infrastructure that you're referring to?

FIBRE


text:
What are the steps to overcome a state in which miners couldn't mine blocks?
The difficulty is set according to the total hash rate of the network.
Is there a possibility in which miners just can't validate blocks (will not find hash that will satisfy the POW)?
I understand the probability.
there's a very small percent where they couldn't do it, is that assumption wrong?
If a situation like that is possible, what will be the solution?
As far as I understand, there will be an adjustment of the POW, decrease the difficulty, until somebody will find block?
I'm trying to understand if a potential risk to the blockchain exists at that point.

Unclear what you’re asking. What would happen for them to not be “able” to “validate” blocks?

Just will not find hash that will satisfy the POW.

Then they need to hash a bit longer.

Clarification for the original question: Are you talking about a situation where miners are unable to mine a block within a reasonable time (but if they keep at it they'll eventually get one) or a situation where it was actually impossible to ever find a valid hash for any block a miner could create?

A hash that can satisfy the PoW can always be found, the only determinant is time. This is identical to coin flipping - you can always flip a head, you just have to keep flipping until you do.
On average it takes ten minutes to find a hash, but let's consider something very dramatic has happened: let's say the Chinese have cut all links to the outside world, the Americans have successfully banned all Bitcoin activity, and the Europeans have a topsekrit piece of code that successfully intercepts and scrambles anything uploaded from one of their miners. Let's say that all of that happened inside the time it takes to mine one block, and let's say that for whatever reason there is now one single, solitary, functional miner anywhere on the planet, it's a Raspberry Pi, and it'll take Eleventy years to mine the next block. And a hundredteen times longer to reach the next difficulty adjustment. I think you'll agree that this is a state in which miners couldn't mine blocks. What then?
The most obvious step is a hard fork that resets the difficulty for that one miner. The miner will obviously agree; those using the blockchain would rather have that fork than wait in hope too.

I wouldn’t say always. It’s possible that there’s no hash which satisfies a specific target. We just assume that’s not realistic.

Do you mean there's possibly no preimage which can hash to a specific target? If so I'd be intrigued to know what research has been done on this. I ask this because as your statement stands ("no hash..."), target - 1 as a hash will satisfy a target for all targets equal to or greater than 1.

@Anonymous That doesn't sound possible to me. The target is just a number with the same number of bits as the hash itself, so there's always a hash <= target.

@Jannes: The question is whether any valid block header (including the hash of a given previous block) has a hash that is less than the target.  It is conceivable that all of them have hash values that are too large.  We believe it is so unlikely that it will never happen, but the unpredictable nature of the hash algorithm means that AFAIK we do not know any way to prove that it cannot happen.  On the other hand, we also do not know any way to prove that it can happen.

@NateEldredge I don't see where Alistair restricted "can always be found" to one specific blockheader. Obviously miners run through all possible nonces all the time without finding a suitable hash. Then they change some other bits and try again. His point seems to me: miners can always keep trying and will eventually always find one. Also confirmed by his comment "Do you mean there's possibly no preimage which can hash to a specific target?" The original question is also alluding to ending up in a situation where it's impossible to ever find any new blocks.


text:
Antminer S7 Dual Power Supply
I am planning on powering up Antminer S7 with dual power supply per usermanual (https://shop.bitmain.com/files/download/Antminer%20S7%20user%20guide.pdf) page 4.  It does not say minimum power requirement for PSU1 and PSU2.
Two boards with 950Watt and 1 Board with 850 Watt.

I plan on using regular power mode without over clocking.  So can it be safe to assume I only need 450 Watt per board and 950 Watt for two board will be just enough?  Will it work?

Since we only need 450 Watts per board and 950 Watts PSU1 and 850 Watt PSU2 worked. Make sure you turn on PSU2 After PSU1 as the S7 manual says.


text:
Connection issue between Sparrow and Bitcoin Core
I currently have my Bitcoin Core node set up to utilize an external hard drive for the data directory in order to conserve space on my laptop. Initially, when I connected Sparrow to the node for the first time, everything went smoothly. However, subsequent attempts to use Sparrow have resulted in an error message stating, "Connection failed: Wallet file verification failed. Failed to create database path '/Volumes/External Hard Drive/cormorant'. Database already exists." To resolve this, I've been closing Sparrow, removing the cormorant folder from the data directory on the external hard drive, and then reopening Sparrow. Doing so creates a new cormorant folder, and everything functions correctly. I'm hoping to find a solution that eliminates the need to delete the cormorant folder each time I want to use Sparrow. Thank you for any assistance you can provide!


text:
Bitcoin Core stores public keys and balance unencrypted, a few questions
I came across this statement in the Sparrow Wallet documentation;

Unfortunately, Bitcoin Core stores your public keys and balance unencrypted on the computer it is running on. If this computer is regularly connected to the internet, it is at risk to hackers - which will make you a target once your balance is discovered.

If this is a concern to you, consider running an Electrum server, which does not keep any record of your balance, but indexes all Bitcoin transactions equally.

And I have a few questions;

Is there a specific reasoning behind keeping the public keys and balances unencrypted?
Is it possible for a user to encrypt this data without breaking functionality of core?
Is the only reasonable mitigation to this issue to "not use Bitcoin Core" but instead Electrum server?

Thanks!

Speculation: 1) So can generate receiving addresses and check balance without having to enter password of private keys. 2) By using an encrypting file system (EFS) 3) If you prefer that tradeoff between security and convenience.


text:
What version of the bitcoin wallet was in 2010 and is there an official resource with software for this?
please describe detail how safely open and Bitcoin wallet files for desktop from 2010?