text:
How big can a wallet get?
Say for an exchange that manages thousands of users, and each transaction needs a new receiving address, how much space would thier wallet(s) take.
I am assuming 100000 users and each user would have about 10000 transactions, so there are about 10^9 keys to be stored. For safety, we would say there are 10^10 keys max that may be stored.
All I need to know is the size of one key stored in the wallet.

It will depend on which client (and version) you are referring to.
The Bitcoin.org client will at some point (likely soon) be changing from wallet.dat (BDB) to some other storage method, which will impact the size of storage.

With the current Bitcoin.org client, you'll run into performance issues with a wallet that has many thousands of addresses long before storage space begins to be a concern.  That will be getting addressed with changes to the wallet database.

The bitcoinj private keys are 32 bytes long. You would also want some sort of indexing around them so that you could access them efficiently.
If you used a deterministic wallet you would only need one seed and a chain code per customer and generate the addresses as required. I think they are typically 32 or 64 bytes long.


text:
Why do huge wallets often have repeated tiny (< $1) transactions?
Looking around at some so-called 'whales' on the BTC richlist (as well as other currencies) I see it is quite common a huge wallet is regularly making miniscule transactions as low as a few cents.
Just the one I had open:
https://bitinfocharts.com/bitcoin/address/3LYJfcfHPXYJreMsASk2jkn69LWEYKzexb

In this case the 0.00000547 value comes up many times. What does it signify when wallets have these sort of micro-transactions?

source: Stack Exchange

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

sort: votes


text:
How are newly created bitcoins are validated?
I'm trying to understand how Bitcoin works but there's a concept I can't get my head around.
I understand that transactions are validated by checking the signatures of each input is valid. However how do you validate new bitcoins or rewards that have entered the system through mining if these don't contain any any inputs?
For example if you're checking a transactions inputs are valid eventually you'll reach the point when the inputs were originally mined, so how would you know these were created legitimately?

The first transaction of each block is special according to the Bitcoin Protocol, and people give it a special name: generation transaction (because it can generate new bitcoins) or coinbase transaction (because it's the only transaction to contain a field called the "coinbase" [the company Coinbase is named after this field, but is otherwise unrelated]).
Generation transations have the following rules (among others not relevant to your question):

One, and exactly one, generation transaction must be present in every block.  (If you've ever heard of "empty blocks", that just means a block with nothing besides the generation transaction.)
They can only have one input.
That input "spends" an output (outpoint) of all zeroes.  This doesn't correspond to any actual transaction output.
That all-zero outpoint is considered to contain the newly-generated bitcoins (subsidy) for this block as well as the transaction fees paid in this block (fees), which are collectively known as the block reward.
The special input has a field called the coinbase field where the signature script (scriptSig) would go in a regular transaction.  Anything put in this field is validated like in a normal transaction, but in the original Bitcoin protocol, miners were not required to put anything in this field at all---they didn't need to provide a signature since the only person who could've created this transaction as the first in the block was the miner themselves.  Since them, BIP34 and BIP141 have changed the rules somewhat, but not in a way relevant to your question.  Also not particularly relevant, the coinbase field is limited to 100 bytes in length.

Actual validation works like this:

When a node receives a new block, it starts by looking at all of the transactions besides the generation transaction.  It calculates how much transaction fee they all pay.
Then the node calculates the amount of new bitcoins (subsidy) the miner is eligible to claim, for example 50 BTC for the first 210,000 blocks or 12.5 BTC as of this writing (blocks 420,000-629,999).
The node adds these two numbers together.  This is the maximum amount of block reward the miner can claim.
Now the node looks at the generation transaction, makes sure it follows all of the other rules, and validates that its outputs spend a total of less than or equal to the block reward computed above.

Of interesting historical note, the generation transactions in over 1,000 blocks did not claim all the block reward they were eligible to claim.  This seems to have mostly occurred early on.  What happened to those bitcoins?  They can't be claimed by the miners of those blocks after the fact and nobody else can claim them, so they're permanently lost.

from the wiki:

The coinbase is the content of the 'input' of a generation transaction. While regular transactions use the 'inputs' section to refer to their parent transaction outputs, a generation transaction has no parent, and creates new coins from nothing.

So the miner who mines the block is free to send the newly created coins to any address he wants. There is nothing to validate (other than it is the correct amount).

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


text:
Why would someone use 1-of-1 multisig?
Today I noticed a transaction that spends a bunch of 1-of-1 multisig P2WSH inputs:
675b106c71f110ebca9e6435f49508a07b45d40d38e237d02b89e5506f3b136b
For example, the first input has this script in the witness:
OP_PUSHNUM_1
OP_PUSHBYTES_33 031f1c516fc9362202883b24fd92e6548776a8f1701baca38b63bbe635da8a82f7
OP_PUSHNUM_1
OP_CHECKMULTISIG

I then wrote a script to find more of these transactions, and it turns out in the last 1000 blocks there were 3883 transactions spending 1-of-1 multisig inputs. This one spends over 30 BTC: 4d8a475e7a0433ef84baec9ec941342cb31d4194b42dedccdc4503e4acad02f8
Why would anyone use this instead of P2WPKH which is both cheaper and has a larger anonymity set?

You may be looking at transactions of an unknown entity dubbed "Crazy1o1". To my knowledge, it is still unknown who they are or why they are using 1-of-1 transactions, but they've been active for years. Notable mentions:

LaurentMT first describing and naming Crazy1o1
LaurentMT analyzing some traffic of Crazy1o1
Stepan Snigirev asking about 1-of-1 transactions
Crazy1o1 consolidating 720k+ UTXOs at over 100 s/vB while the mempool was essentially empty
On-going traffic of 1-of-1 multisig transactions
Crazy1o1 on OXT.me

Update: LaurentMT suggests that Crazy1o1 is a “Crypto and Forex broker named KOT4X”


text:
the switching timing between high-bandwidth mode and low-bandwidth mode in CompactBlockReray
If the Compact Block transmission node is bandwidth-limited, there is a statement in bip152 implemention Note that an 'inv/headers' is sent. Are there specific thresholds or settings for this in the Bitcoin Core implementation, and could you please indicate where in the implementation this is located?"


text:
What is the probability of randomly getting a 12 word seed phrase with the same word repeated 12 times?
It appears that the 12 word seed phrase CAN be the same word repeated 12 times.
Is it true that the probability of randomly generating that "stuttering seed phrase" would be:
= 2048 * (1/2048) 12
= (1/2048) 11
The logic is that there are 2048 choices at the first round and then it must pick the one chosen in the first round from then on out which has a probability of  1/2048 for the 11 remaining rounds.

Hello Ralph, please don’t answer your own question in the question post of your topic. In the question post, please focus just on asking an open question. If you want to provide your own answer, please post an answer.

That's not correct.
Remember that the last word has a checksum for the other 11, which means that not every word of the 2048 will work.
Actually, only 130 words do the trick, which means there are only 130 phrases possible in a universe of 2048^12 possible phrases, so the the probability is 130/2048^12

Wow @bordalix Thanks!  I did not even know about that.  I will update the question/answer

The correct number is 130 (not 190) and I found a better link where you can verify that.


text:
Signmessage with Raspiblitz
For an absolute beginner, how do I sign the new adress formats (taproot e.g.)? In Ride the Lightning (RTL) there is the possiblity to sign messages for lightning.
But I need to sign from a specific onchain adress. I also tried bitcoin-cli signmessage <adr> <msg> but this did neither work for a taproot adress nor for a Bech32 address (both generated from RTL).
The error message returned is
error code: -32601
error message:
Method not found

which somehow seems like the signmessage command is unkown?
I also found this thread. However I am currently unaware where to get the private key from for the suggested solution signmessagewithprivkey
I tried bitcoin-cli dumpprivkey <adr> which resulted in the same error as above (Method not found).

Solved it with the help of the support of Pocket Bitcoin. T
Get the Adress you want to sign with, I used the RTL interface to generate a new onchain adress but you can also use
lncli wallet addresses list

Be wary though this might entail already used adress so first confirm that you are not reusing an address you already used in the past (you can e.g. verify via mempool.space)
Signing itself is then very easy via.
lncli wallet addresses signmessage --address <enteradreee> --msg <msg>


text:
What is the purpose of addr_recv? What does it mean that addr_recv influences the heuristic for determining which of the receiving nodes IP is public?
I found here the purposes of addr_recv and addr_from.

Bitcoin Core actually ignores addr_from in received version messages.
addr_recv is used to influence the heuristic that determines which of
the receiving node's IP addresses is publicly reachable.

However, I can't figure out this what is written for addr_recv.
Can someone explain the purpose of addr_recv in more detail? How does addr_recv influences the heuristic for determining which of the receiving nodes IP is public?

A reachable Bitcoin Core node self-advertises its own address regularly so other nodes can know about it and connect to it. In order to do that, it must know the address(es) under which it is reachable.
There exists discovery logic that attempts to detect the address under which a node is reachable, but it doesn't work perfectly under all local network conditions, and sometimes it can yield multiple results, leading to the question which one is the "best" that should be used.
This is where addr_recv comes in - it is used in the logic to decide which address should be advertised.

Occasionally (rng-based), a node advertises the address they see us under back to the peer, instead of using one of our self-detected addresses (see GetLocalAddrForPeer)

addr_recv is used in a scoring mechanism to "vote" for one of the previously self-detected addressess (see SeenLocal). This increases the probability of this address being picked for self-advertisements in the future - for all peers.

However, addr_recv cannot be trusted and could be easily manipulated by a malicious peer.
Therefore, addr_recv received from one peer is never used in an advertisement to a different peer. If an attacker would send an incorrect address in that field, all they would achieve is to get that incorrect address relayed back to themselves occasionally (see point 1 above). They wouldn't impact the voting mechanism of point 2 because the incorrect address wouldn't be among the self-detected addresses.


text:
Can ACINQ (Phoenix wallet peer) steal my funds during a recovery?
Phoenix wallet is a unique Lightning wallet in that, among other things, it allows the user to restore channels by simply entering their seed. According to ACINQ's blogpost, this is how they achieve it:

TL; DR: Each time channels are updated, Phoenix sends an encrypted version of their data to its peer. This allows for easy backup/restore of channels while maintaining privacy.

In the case of Phoenix wallet, the peer is always ACINQ, but my question applies to any similar peer backup solutions: what's to stop the peer from making me recover an old channel state, and claim all my funds when I try to close it?

Nothing.
If you have lost the last state and are recovering it from your peer then you are trusting it, no matter if it's encrypted or not.
They could lie and continue operating (or close) from a state of the channel in which they had a higher balance, or could serve you an encrypted backup for a revoked state and trick you into force-closing to steal your funds through the penalty transaction.

The fact that the data is encrypted with a key derived from your seed. So the peer cannot use that data it can only back it up for you. After you recover you will need to request that data and decrypt it yourself

That's right, the peer cannot use the backup data to close the channel in my name. But the question was, can the peer send me an old backup and therefore trick me into closing the channel using an old state, allowing them to claim all the funds?

Oh sorry misread that. I think that is actually a pretty valid concern your question raises. I guess a (not optimal) solution would be to have backups with several peers and compare them


text:
What is a payment basepoint?
The BOLT #3 Commitment Transaction documentation talks about a payment basepoint, but I can't find it defined in the glossary or anywhere else. It also mentions various other basepoints like a revocation basepoint, delayed payment basepoint, local and remote basepoints and an HTLC basepoint.
What are these basepoints?

Basepoints are simply public keys from which all other public keys for a certain category (payments, revocation, htlcs, ..) are derived. They are used in order to deterministically generate fresh keys for each new pair of commitment transactions.
See the "Key Derivation" section of BOLT 3 for details as well as for a rationale:

Each commitment transaction uses a unique localpubkey, and a remotepubkey.
The HTLC-success and HTLC-timeout transactions use local_delayedpubkey and revocationpubkey. [...]
The reason for key change is so that trustless watching for revoked
transactions can be outsourced. Such a watcher should not be able to
determine the contents of a commitment transaction — even if the watcher knows
which transaction ID to watch for and can make a reasonable guess
as to which HTLCs and balances may be included. [...]
For efficiency, keys are generated from a series of per-commitment secrets
that are generated from a single seed, which allows the receiver to compactly
store them.


text:
Bitcoin Core configured for testnet, syncs mainnet
I'm trying to get Bitcoin Core to sync the testnet, but it keeps syncing the mainnet instead.
Here is my bitcoin.conf file:
[test]
addnode=104.237.131.138
addnode=151.80.205.132
addnode=192.155.82.123
addnode=74.220.255.190
addnode=80.100.203.151
rpcbind=127.0.0.1
rpcport=18332
chain=test
testnet=1

debug=net

txindex=1
listen=1
listenonion=1
daemon=1

proxy=127.0.0.1:9050

server=1
rpcallowip=127.0.0.1
rpcuser=user
rpcpassword=pw

zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

I'm calling it like this:
$ bitcoind -conf=./bitcoin.conf -datadir=./bitcoin-testnet/

But the command line tool tells me it is connected to the mainnet:
$ bitcoin-cli -conf=./bitcoin.conf -datadir=./bitcoin-testnet/ -getinfo
Chain: main
Blocks: 0
Headers: 0
Verification progress: ▒░░░░░░░░░░░░░░░░░░░░ 0.0000%
Difficulty: 1

Network: in 0, out 3, total 3
Version: 250000
Time offset (s): 0
Proxies: n/a
Min tx relay fee rate (BTC/kvB): 0.00001000

Warnings: (none)

What do I need to do to sync the testnet?

You need to pass -testnet to both the bitcoind and bitcoin-cli calls, so they know to even look into the [testnet] section of the config file.

In my wallet that I use for testing, have testnet=1 before the [test] heading in the bitcoin.conf file.
This forces both bitcoind and bitcoin-cli to look into the [test] section.


text:
How can I run the skipped Bitcoin Functional Tests?
I am trying to run the functional tests. Everything is a pass but I have some tests skipped. Here are some:
260/288 - feature_unsupported_utxo_db.py skipped (previous releases not available or disabled) - "For this one I don't know what to do, and have about 5 of the same tests skipped"
241/288 - feature_bind_port_discover.py skipped (To run this test make sure that 1.1.1.1 and 2.2.2.2 (routable addresses) are assigned to the interfaces on this machine and rerun with --ihave1111and2222)
223/288 - feature_bind_port_externalip.py skipped (To run this test make sure that 1.1.1.1 (a routable address) is assigned to one of the interfaces on this machine and rerun with --ihave1111) - "For this one and the one above, I tried assigning the machine ip address to 1.1.1.1, tried running the test with --ihave1111 flag, nothing helped
I would like to know why these test are being skipped and how to run them.
Update
I tried the network issue, now the test fails. Here is the output:
sudo test/functional/feature_bind_port_externalip.py --ihave1111
--ihave1111and2222 doesn't work
2023-12-21T15:59:42.460000Z TestFramework (INFO): PRNG seed is: 9034826233842177560
2023-12-21T15:59:42.461000Z TestFramework (INFO): Initializing test directory /tmp/bitcoin_func_test_ryvl93pg
2023-12-21T16:00:43.190000Z TestFramework.utils (ERROR): wait_until() failed. Predicate: ''''
self.wait_until(lambda: sum(peer['version'] != 0 for peer in from_connection.getpeerinfo()) == from_num_peers)
'''
2023-12-21T16:00:43.190000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/home/jack/bitcoin/test/functional/test_framework/test_framework.py", line 130, in main
self.setup()
File "/home/jack/bitcoin/test/functional/test_framework/test_framework.py", line 297, in setup
self.setup_network()
File "/home/jack/bitcoin/test/functional/test_framework/test_framework.py", line 407, in setup_network
self.connect_nodes(i + 1, i)
File "/home/jack/bitcoin/test/functional/test_framework/test_framework.py", line 620, in connect_nodes
self.wait_until(lambda: sum(peer['version'] != 0 for peer in from_connection.getpeerinfo()) == from_num_peers)
File "/home/jack/bitcoin/test/functional/test_framework/test_framework.py", line 765, in wait_until
return wait_until_helper_internal(test_function, timeout=timeout, timeout_factor=self.options.timeout_factor)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jack/bitcoin/test/functional/test_framework/util.py", line 276, in wait_until_helper_internal
raise AssertionError("Predicate {} not true after {} seconds".format(predicate_source, timeout))
AssertionError: Predicate ''''
self.wait_until(lambda: sum(peer['version'] != 0 for peer in from_connection.getpeerinfo()) == from_num_peers)
''' not true after 60 seconds
2023-12-21T16:00:43.247000Z TestFramework (INFO): Stopping nodes
2023-12-21T16:00:43.505000Z TestFramework (WARNING): Not cleaning up dir /tmp/bitcoin_func_test_ryvl93pg
2023-12-21T16:00:43.505000Z TestFramework (ERROR): Test failed. Test logging available at /tmp/bitcoin_func_test_ryvl93pg/test_framework.log
2023-12-21T16:00:43.506000Z TestFramework (ERROR):
2023-12-21T16:00:43.506000Z TestFramework (ERROR): Hint: Call /home/jack/bitcoin/test/functional/combine_logs.py '/tmp/bitcoin_func_test_ryvl93pg' to consolidate all logs
2023-12-21T16:00:43.506000Z TestFramework (ERROR):
2023-12-21T16:00:43.506000Z TestFramework (ERROR): If this failure happened unexpectedly or intermittently, please file a bug and provide a link or upload of the combined log.
2023-12-21T16:00:43.506000Z TestFramework (ERROR): https://github.com/bitcoin/bitcoin/issues
2023-12-21T16:00:43.506000Z TestFramework (ERROR):
Maybe it is connected to this line "not true after 60 seconds" is it a timeout error?
Also, the command sudo test/functional/test_runner.py which runs all tests cannot be run with the --ihave1111 flag, spits an error.
note: I am running linux on virtual machine, maybe that is why the test fails

For the tests skipped with "previous releases not available", you need to have older versions of Bitcoin Core in a local directory. This directory has a folder for each version (named v25.0, v24.1, etc.). Within each version's folder is another folder named bin, and within that are the binaries for that version. The layout of that will look like:
|_ v25.0
   |_ bin
      |_ bitcoind
      |_ bitcoin-cli
      |_ bitcoin-tx
      |_ bitcoin-wallet
|_ v24.1
   |_ bin
      |_ bitcoind
      |_ bitcoin-cli
      |_ bitcoin-tx
      |_ bitcoin-wallet
|_ v23.0
   |_ bin
      |_ bitcoind
      |_ bitcoin-cli
      |_ bitcoin-tx
      |_ bitcoin-wallet
...

This directoy must either be named releases in your current working directory, or you can provide the full path to it as the environment variable PREVIOUS_RELEASES_DIR
For the tests that require 1.1.1.1 and/or 2.2.2.2, you need to create another network interface on your machine and set their IP's to 1.1.1.1 and 2.2.2.2. There are instructions for doing this in the tests themselves.
From feature_bind_port_discover.py:
# We need to bind to a routable address for this test to exercise the relevant code
# and also must have another routable address on another interface which must not
# be named "lo" or "lo0".
# To set these routable addresses on the machine, use:
# Linux:
# ifconfig lo:0 1.1.1.1/32 up && ifconfig lo:1 2.2.2.2/32 up  # to set up
# ifconfig lo:0 down && ifconfig lo:1 down  # to remove it, after the test
# FreeBSD:
# ifconfig em0 1.1.1.1/32 alias && ifconfig wlan0 2.2.2.2/32 alias  # to set up
# ifconfig em0 1.1.1.1 -alias && ifconfig wlan0 2.2.2.2 -alias  # to remove it, after the test

Then you can pass the --ihave1111and2222 and --ihave1111 options to the tests.


text:
FAIL: qt/test/test_bitcoin-qt.exe when running 'make' after building Bitcoin Core 26.99.0
I'm building Bitcoin Core 26.99 following this:
https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md
I'm using this option for building Bitcoin Core on Windows:
Windows Subsystem for Linux (WSL) and Mingw-w64.
When I ran "make check", I got the full error below:
Making check in src
make[1]: Entering directory '/home/amaluenda/bitcoin/src'
make[2]: Entering directory '/home/amaluenda/bitcoin/src'
make[3]: Entering directory '/home/amaluenda/bitcoin'
make[3]: Leaving directory '/home/amaluenda/bitcoin'
  GEN      obj/build.h
make  minisketch/test.exe
make[3]: Entering directory '/home/amaluenda/bitcoin/src'
make[3]: 'minisketch/test.exe' is up to date.
make[3]: Leaving directory '/home/amaluenda/bitcoin/src'
make  check-TESTS check-local
make[3]: Entering directory '/home/amaluenda/bitcoin/src'
make[4]: Entering directory '/home/amaluenda/bitcoin/src'
PASS: minisketch/test.exe
PASS: univalue/test/object.exe
PASS: univalue/test/unitester.exe
make[5]: Entering directory '/home/amaluenda/bitcoin'
make[5]: Leaving directory '/home/amaluenda/bitcoin'
  GEN      obj/build.h
FAIL: qt/test/test_bitcoin-qt.exe
============================================================================
Testsuite summary for Bitcoin Core 26.99.0
============================================================================
# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See src/test-suite.log
Please report to https://github.com/bitcoin/bitcoin/issues
============================================================================
make[4]: Leaving directory '/home/amaluenda/bitcoin/src'
make[3]: Leaving directory '/home/amaluenda/bitcoin/src'
make[2]: Leaving directory '/home/amaluenda/bitcoin/src'
make[1]: Leaving directory '/home/amaluenda/bitcoin/src'

And here's the src/test-suite.log:
==============================================
   Bitcoin Core 26.99.0: src/test-suite.log
==============================================

# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: qt/test/test_bitcoin-qt
=============================

FAIL qt/test/test_bitcoin-qt.exe (exit status: 2)

Will someone be so kind as to please help me resolve this?
Thank you very much.

This question may be better suited for a GitHub issue, given that it is failing a unit test, which usually indicates an issue with the code, rather than how the person asking the question is using it.


text:
Do mined coins show up on blockchain explorers and can the balance of the addresses that mined the coins be seen?
Somebody wants to do a deal for a bitcoin transaction but when proof of the coins is required they say that the coins will not show up on blockchain.info as they were "mined coins".
Is this really true? Will mined coins really not show up on blockchain.info for the address' balance?
If that is the case how can proof of funds of bitcoins be seen before the deal goes through?

They DO show up in the blockchain. The block reward(new mined coins) is sent to the miners address who has found a block via the coinbase transaction.
The coinbase transaction can be viewed and is found as the first transaction in every block.

Thank you.
So to clarify, if the bitcoin seller claims to have bitcoins but their address provided shows as having zero bitcoins on blockchain.info, then it is likely that the address does not actually hold the amount of bitcoins they claim it does, as even if they had mined the coins that would show up on their balance on blockchain.info?

Thats right. Although I am not too sure if blockchain.info shows unconfirmed balances.

correction Nov 15: There is in each block a coinbase transaction and it"s always the first transaction.
The mined coins show up and the balance can be seen in the explorers (miners reward plus fees). Not necessarily it's in the first transaction of a block and not necessarily a block needs to contain a miners reward, but in most cases it is there and it's the first transaction. You can recognize the miners reward coinbase transaction because the explorer shows only for this one no input transactions where the coins derive from.

Could you please elaborate what you mean with " Not necessarily it's in the first transaction of a block"? Are you talking about payouts from a mining pool to the pool contributors or something? Because the coinbase transaction is required and it has to be the first transaction in the block.

There are blocks where the coinbase transaction is not the first transaction in the block. I realised because programs stopped because of this and I needed to modify. As well for a valid block it's not mandatory to have a coinbase reward at  all or the miner can reduce the reward, only above the limit would make the block invalid. Here an example block with a coinbase reward of 0: Block 501726 (transaction 9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182 )

Need to partially correct myself. A coinbase transaction is mandatory in a valid block. The accepted value is maximal 50 BTC for the first 210,000 blocks and then halving every 210,000 blocks (less is not making the block invalid, even not 0 BTC). It can be sent to one or more addresses as long as the total value isn"t higher than the coinbase + the fees. It can be spend after 100 confirmations except the genesis 50 BTC which are unspendable. At least in the early protocol versions it was possible to put the coinbase transacition not on the top of the outputs.

huh, never heard about that before. I posted a new question about that here: https://bitcoin.stackexchange.com/q/91683/5406

Do you mean that Coinbase transactions can have multiple outputs or are you talking about a different coin? Otherwise, it seems that Coinbase transactions have always been required to be the first transaction in a block (see question I posted above)'

The coinbase transaction can have of course multiple outputs. I talk about Bitcoin BTC. I'm trying to find the script which stopped at a block where the coinbase wasn't the first transaction. Will report back as soon as I find it or alternatively if my memory is wrong and I mixed up with something else... .

Found my mistake. I once loaded all transactions into a separate database and had an error which mixed up the order of some transactions in their blocks .That led me to the wrong assumption that a coinbase reward transaction isn"t necessarily the first transcation. As double check I scanned tonight all 600k first transactions of the blocks and indeed they are all flagged as 'coinbase'. Apologies for confusing you!

Okay, thanks for your effort and checking!

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


text:
How can I pull the "Candles" argument from the Huobi websocket data?
I've a problem with Huobi Websocket, I know my ways in REST API but new to asyncio and websockets, and Huobi only gives resonable amount of history through websocket request so I'm stuck with it. I'm using their [sdk](https://github.com/HuobiRDCenter/huobi_Python. I managed to figure this out:
from huobi.client.market import MarketClient
from huobi.client.market import CandlestickInterval
import pandas as pd
from pandas import DataFrame as df

def callback(candlestick_req: "CandlestickReq"):
    Candles = candlestick_req.data

Market_client = MarketClient()
Market_client.req_candlestick("btcusdt", CandlestickInterval.MIN60, callback, from_ts_second = 1611788400, end_ts_second = 1614812400)

History_dataframe_new["Date"] = [Candles[f].id for f in range(len(Candles))]
History_dataframe_new["Open"] = [Candles[f].open for f in range(len(Candles))]
History_dataframe_new["High"] = [Candles[f].high for f in range(len(Candles))]
History_dataframe_new["Low"] = [Candles[f].low for f in range(len(Candles))]
History_dataframe_new["Close"] = [Candles[f].close for f in range(len(Candles))]
History_dataframe_new["Volume"] = [Candles[f].vol for f in range(len(Candles))]

The problem is, how can I get this Candles argument out of the callback to use below? I'm not calling callback directly, only in the req_candlestick so return won't work. And it's a callback so I propably have to wait for the response somehow. And tips how to do that? Or if what I'm trying here is the correct way?

Not familiar with this particular exchange but websocket requires you to subscribe to a data feed/channel after opening the websocket connection. I'm not seeing in your code where you are subscribing to anything. Once subscribed the message should start flowing in. After that it should just be simple JSON parsing the incoming messages.

This exchange is the only exchange I know that has history data pull from websockets, I guess there is no need to subscribe, if I go candlestick_req.print_object() there in the callback I receive the required data. I shall check how to parse with JSON, thanks!

I will just throw it out here, there is a better way to do it, here above I was using Huobi SDK but I find using websocket without any external libraries better. A great template for websocket connection below:
import gzip
import json
import pprint
import threading

import time
import websocket

def send_message(ws, message_dict):
    data = json.dumps(message_dict).encode()
    print("Sending Message:")
    pprint.pprint(message_dict)
    ws.send(data)

def on_message(ws, message):
    unzipped_data = gzip.decompress(message).decode()
    msg_dict = json.loads(unzipped_data)
    print("Recieved Message: ")
    pprint.pprint(msg_dict)
    if 'ping' in msg_dict:
        data = {
            "pong": msg_dict['ping']
        }
        send_message(ws, data)

def on_error(ws, error):
    print("Error: " + str(error))
    error = gzip.decompress(error).decode()
    print(error)

def on_close(ws):
    print("### closed ###")

def on_open(ws):
    def run(*args):
        data = {
            "req": "market.btcusdt.kline.1min",
            "id": "id1"
            "from": int("fromtimestamp")
            "to": int("to timestamp")
        }

        for i in range(5):
            time.sleep(2)
            send_message(ws, data)
        ws.close()
        print("thread terminating...")

    t = threading.Thread(target=run, args=())
    t.start()

if __name__ == "__main__":
    # websocket.enableTrace(True)
    ws = websocket.WebSocketApp(
        "wss://api.huobi.pro/ws",
        on_open=on_open,
        on_message=on_message,
        on_error=on_error,
        on_close=on_close
    )
    ws.run_forever()


text:
Bitcoin transaction malleability is it only for unconfirmed transaction?
I do understand what is transaction malleability and how to do it in practice eg. DER-encoded ASN.1, ECDSA and know that these 2 have been fixed.
Also there are some other types (do not know examples), and SegWit fixed all possible transaction malleability.
Question:
My understanding is that transaction malleability is only possible if transaction is non SegWit eg. P2PKH and only while it is unconfirmed, once it is confimed (is in some mined block) it is not possible any more to change txid.
Is this understanding correct?
If not what am I missing?

TL;DR: Yes, once a transaction is confirmed, unless a chain reorganization makes it unconfirmed again, no forms of malleability are possible. SegWit specifically fixed TXID malleability of unconfirmed transactions, but other forms of malleability are possible.

Transaction malleability in general refers to the possibility of a third party changing some parts of a transaction without making it invalid. For example, with ECDSA it's possible to change a valid signature into a different signature that is still valid for the same message. This isn't a problem in most cryptosystems, but because in pre-SegWit transactions the TXID depends on the transaction signatures and transaction inputs reference the TXID of a transaction whose outputs they're spending, this makes it unsafe to rely on chains of unconfirmed transactions (required by off-chain protocols such as Lightning).
While there were proposals to limit the ECDSA scheme to remove this vulnerability (see BIP62 which also covers other malleability vectors), SegWit took a more general approach by introducing the "witness", a new transaction component where signatures and other data needed to satisfy scripts go, that isn't depended on by the TXID. This was a superior solution in that it's now possible to create chains of unsigned or partially signed transactions and know that no matter what signatures and other data will be included in the witness, the TXIDs will stay the same and the chain remains valid.
However, TXID malleability isn't the only type of malleability to look out for. Some scripts can be satisfied in multiple ways, and if a third party can come up with a solution that takes more space in the witness, they can reduce the fee rate of your transaction. As another example, it was recently discussed that if a Taproot script tree includes the same script multiple times on different levels, a third party that knows the tree structure can change the witness to spend the script at a deeper level, which again increases the witness size and lowers your fee rate. These sources of malleability can generally be avoided.


text:
How can I store a file hash in a Schnorr signature? Or something other than an OP_RETURN?
I have this python script that puts file hashes on the bitcoin blockchain:
from bitcoinutils.utils import to_satoshis
from bitcoinutils.setup import setup
from bitcoinutils.transactions import Transaction, TxInput, TxOutput
from bitcoinutils.script import Script
from bitcoinutils.keys import PrivateKey as utilPrivKey
from bitcoinutils.constants import SIGHASH_ALL

setup('testnet')

# private key for tb1qpeervdxrt2np74xhm4q4jjp76ey5f9fh9tf58f
sender_priv_key = utilPrivKey.from_wif('PRIVATE KEY FOR THE SENDING ADDRESS')
sender_pub_key = sender_priv_key.get_public_key().to_hex()
addrs_for_script = sender_priv_key.get_public_key().get_address()

# private key for tb1qj57tu40e9da959w4lj9s3njwteq2z89uy7kenh
receiver_priv_key = utilPrivKey.from_wif('PRIVATE KEY FOR THE RECEIVING ADDRESS')
receiver_addr = receiver_priv_key.get_public_key().get_segwit_address()

txin1 = TxInput("a86f0187be2eca4590a456e2423a2f5286b269c3b777846092ceb2fc44270aad", 1)
txin2 = TxInput("9019818039f181ed00046d682411719050a4b2dc1d1eb6aaa2d781df863522fc", 0)

script_code = Script(['OP_DUP', 'OP_HASH160', addrs_for_script.to_hash160(), 'OP_EQUALVERIFY', 'OP_CHECKSIG'])
msg1 = "69eb032167c25784108b9783c9d59ce23608d00238eb9e3c03c73cdd79f74528"
op_return_script = Script(["OP_RETURN", msg1])

txoutOpR = TxOutput(0, op_return_script)

# 0.00005 left for transaction fee
txout = TxOutput(to_satoshis(0.00036275), receiver_addr.to_script_pub_key())

tx = Transaction([txin1, txin2], [txoutOpR, txout], has_segwit=True)
txsign1 = sender_priv_key.sign_segwit_input(tx, 0, script_code, to_satoshis(0.00034416), SIGHASH_ALL)
tx.witnesses = [Script([txsign1, sender_pub_key])]
txsign2 = sender_priv_key.sign_segwit_input(tx, 1, script_code, to_satoshis(0.00006859), SIGHASH_ALL)
tx.witnesses.append(Script([txsign2, sender_pub_key]))

signed_tx = tx.serialize()
print("raw tx below this line")
print(signed_tx)
print("raw tx above this line")

The above python script works, but I am trying to move away from OP_RETURN. Some Bitcoin devs have voiced their opinion against OP_RETURN so I'm afraid it will get deprecated.
Is there any way to modify my python script to store the hash in a Schnorr signature instead of an OP_RETURN? Or some other future proof way to store a file hash in a Bitcoin transaction?

It is usualy discouraged to embed data directly on the blockchain because it is not supposed to be used like that and by doing so you can congest the network and make the blockchain grow in size for no real reason, but if you still want to do it you should be using a P2WSH ( Pay-to-Witness-Script-Hash ) you could do it with taproot too but we will be using P2WSH here.
with this transaction you would create a transaction output that can only be spent by providing a valid witness script that satisfies the spending conditions and since the condition can be arbitrary, such as requiring a specific signature it can do what you want and the witness script will also contain the file hash you want to store.
For your script we will modify it by removing the OP_RETURN and using a P2WSH instead:
edit: there was a misunderstanding in your code you try to call get_address() on a Script object, lets use to_p2wsh_script_pub_key directly on witness_script then we convert it to hash160
from bitcoinutils.utils import to_satoshis
from bitcoinutils.setup import setup
from bitcoinutils.transactions import Transaction, TxInput, TxOutput
from bitcoinutils.script import Script
from bitcoinutils.keys import PrivateKey as utilPrivKey
from bitcoinutils.constants import SIGHASH_ALL

setup('testnet')

# private key for the sender address
sender_priv_key = utilPrivKey.from_wif('PRIVATE KEY FOR THE SENDING ADDRESS')
sender_pub_key = sender_priv_key.get_public_key().to_hex()
addrs_for_script = sender_priv_key.get_public_key().get_address()

# private key for the receiver address
receiver_priv_key = utilPrivKey.from_wif('PRIVATE KEY FOR THE RECEIVING ADDRESS')
receiver_addr = receiver_priv_key.get_public_key().get_segwit_address()

txin1 = TxInput("a86f0187be2eca4590a456e2423a2f5286b269c3b777846092ceb2fc44270aad", 1)
txin2 = TxInput("9019818039f181ed00046d682411719050a4b2dc1d1eb6aaa2d781df863522fc", 0)

script_code = Script(['OP_DUP', 'OP_HASH160', addrs_for_script.to_hash160(), 'OP_EQUALVERIFY', 'OP_CHECKSIG'])

msg1 = "69eb032167c25784108b9783c9d59ce23608d00238eb9e3c03c73cdd79f74528"
witness_script = Script(['OP_IF', 'OP_SHA256', msg1, 'OP_EQUAL', 'OP_ELSE', 'OP_DUP', 'OP_HASH160', addrs_for_script.to_hash160(), 'OP_EQUALVERIFY', 'OP_CHECKSIG', 'OP_ENDIF'])
p2wsh_script_pub_key = witness_script.to_p2wsh_script_pub_key()
witness_script_hash = p2wsh_script_pub_key.to_hash160()

txoutP2WSH = TxOutput(0, Script(['OP_0', witness_script_hash]))

# 0.00005 left for transaction fee
txout = TxOutput(to_satoshis(0.00036275), receiver_addr.to_script_pub_key())

tx = Transaction([txin1, txin2], [txoutP2WSH, txout], has_segwit=True)
txsign1 = sender_priv_key.sign_segwit_input(tx, 0, script_code, to_satoshis(0.00034416), SIGHASH_ALL)
tx.witnesses = [Script([txsign1, sender_pub_key])]
txsign2 = sender_priv_key.sign_segwit_input(tx, 1, script_code, to_satoshis(0.00006859), SIGHASH_ALL)
tx.witnesses.append(Script([txsign2, sender_pub_key]))

signed_tx = tx.serialize()
print("Signed raw transaction:", signed_tx)

I get AttributeError: 'Script' object has no attribute 'get_address' on this line: witness_script_hash = witness_script.to_p2wsh_script_pub_key().get_address().to_hash160()

I modified my answer

Getting closer... I got AttributeError: 'Script' object has no attribute 'to_hash160' on the line: witness_script_hash = p2wsh_script_pub_key.to_hash160()

I am kinda lost here, not used to this library


text:
I get a not a P2TR scriptPubKey error when trying to generate a bech32m taproot compliant P2TR address with python
I have the following script that is supposed to derive a taproot P2TR address:
from bitcointx import set_custom_secp256k1_path
set_custom_secp256k1_path('./bitcointx_secp256k1_here/libsecp256k1.2.dylib')

from bitcointx.wallet import P2TRBitcoinTestnetAddress, P2TRCoinAddress, CBitcoinTestnetKey, CBitcoinTestnetExtKey
from bitcointx.core.script import (CScript, OP_CHECKSIG, OP_NUMEQUAL, CScriptWitness)

sender_priv_key = CBitcoinTestnetExtKey('PRIVATE KEY TESTNET EXTENDED WIF')
sender_pub_key = sender_priv_key.pub
csript_from_pub = CScript([sender_pub_key, OP_CHECKSIG])
print(csript_from_pub)
addrs_for_script = P2TRBitcoinTestnetAddress.from_scriptPubKey(csript_from_pub)
print(addrs_for_script)

But all that this prints in my terminal is:
b'!\x02\x8fy\x12\xc2\xc1kO\x0er\xfc\x98\xeaM\x87X\xee\xbbf\x16\xd9\x02\x9e\xca-\xdc\xea\x03\xb2\x02k\x07{\xac'
Traceback (most recent call last):
  File "/Users/MYUSERNAME/Desktop/Dev/bit_useful_scripts/simple_send_from_segv1.py", line 12, in <module>
    addrs_for_script = P2TRBitcoinTestnetAddress.from_scriptPubKey(csript_from_pub)
  File "/Users/MYUSERNAME/.virtualenvs/py_scratch_310_071722/lib/python3.10/site-packages/bitcointx/util.py", line 331, in wrapper
    return fn(*args, **kwargs)
  File "/Users/MYUSERNAME/.virtualenvs/py_scratch_310_071722/lib/python3.10/site-packages/bitcointx/wallet.py", line 504, in from_scriptPubKey
    raise P2TRCoinAddressError('not a P2TR scriptPubKey')
bitcointx.wallet.P2TRCoinAddressError: not a P2TR scriptPubKey

It fails with a "not a P2TR scriptPubKey" error.
I know that 'PRIVATE KEY TESTNET EXTENDED WIF' is capable of producing a P2TR address. What am I doing wrong?


text:
Bitcoin Cross-compilation failed with errors in notification.cpp
sudo apt update
sudo apt upgrade
sudo apt install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl git
installed all the dependencies in dependencies.md
sudo apt install nsis
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
sudo apt install g++-mingw-w64-x86-64-posix
PATH=$(echo "$PATH" | sed -e 's/:/mnt.*//g')
cd depends
make HOST=x86_64-w64-mingw32 -j9
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make -j9

For Linux, the build was successful and the QT wallet is working correctly, but when I tried to build for Windows, the problem started with several errors in notificator.cpp, which is located in the qt folder.
Machine specifications
Debian bookworm LXQT Release: 12
AMD Ryzen 7 3800X
RAM 32GB
HDD 2TB
version of Bitcoin Core is latest

Hi Nobody, this is a question and answer platform. What’s your question? If you want to file a bug, it might be better directed at the Bitcoin Core repository

I already did this, but after a few minutes they closed the issue without giving any solution.

Assuming that you are talking about https://github.com/bitcoin/bitcoin/issues/29682, it looks like the people responding to your issue indicate that you are not following the instructions for cross-compiling for the version of Bitcoin Core you were trying to compile. What happens when you try to follow the documentation?

I actually built with posix and with win32 and got the same errors, but the build was successful for Linux, by the way, I build & cross compiled successfully other POW Kawpow, Progpowz, Heavyhash but for BTC I got these errors

If that was what you were trying to indicate with the last two comments in the thread, I think it would be easier to understand that if you edited your comments to elaborate a bit more. At least I didn’t understand from those comments what you seem to be telling me here now. I’m sure if you made clear that your issue persists even after following the advice of the documentation, that the issue would be reopened.

Your last answer gave me a little hope, I will of course do what you said, but then I should open a new issue or just to add comments to the closed issue?. I'm asking because almost all the time I solved these problems myself but now I'm looking for real help, anyway really appreciate your last answer

I think you should add another comment that clearly states the issue that you are running into and what you have tried. There are multiple contributors already engaging with the issue, if you add another comment they will see it and evaluate accordingly. As you can see from the repository having just shy of 30k issues and PRs, we get a lot of issues, and it is a common problem that people didn’t find the documentation or didn’t follow it. Since you have found an actual issue that persists given the documentation, you will stand apart by clearly stating that.

You really clarified things to me and what I should do. I'll do all what you said. Thank you so much


text:
Very old Bitcoin Wallet
What I am going to share with you will make you very surprised. I will quickly jump in to the topic as I need some help here.
I have one of the oldest wallet key from 2009 Dec.
I used to play an MMO game on my HTC G1 Android mobile. S.Nakamoto and his developer team mates were also there and we used to play together. I dont remember the name of the game anymore but it was just a shooting game with only 3 or maybe 4 characters and you could have a team of 4 people divided into two teams and play a death match. there was a also small chat window through which i got to know about the BTC as they told me about it. First I read the whitepaper and when I got back on the game the next day I was very excited and I told them this is great i would like to mine. Long story short, they onboarded me and also helped me to setup my wallet. There was also a mobile app by which i could watch in real time the blocks and transactions. I dont remember what that app was maybe it was G-Miner or something like that.
All I have now is some old keys (Private Keys) but when I try to log in to my wallet it shows "0" balance and no transactions at all. I remember that there was a big amount of bitcoins in it so I think there is something wrong, maybe I am not importing the wallet correctly.
By the way the BIP32 and BIP39 was mainstream from 2013 onwards but They taught me how to convert the private key to a 12 word seed phrase back in 2009. But somehow I do not have those seed words, I cant find them. I remember converting the private keys to some SHA256 hash. As even back in 2009 there was some tool that could do that.
please guide me and help me out and whoever successfully helped me I promise to share 2% of my BTCs.
Maybe what i need to know now what was the oldest BIP standard? was it BIP 001? and then if I could convert my "Entropy Hexa Hash" to the correct BIP reference then I could have the correct private key and the seed words to access my wallet. do you get it what I am saying?
Thank you
Oldman

if you look at the bitcoin development github you will find that the bip001 started from 11 years ago: https://github.com/bitcoin/bips/blob/master/bip-0001/process.png

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.

There was also a mobile app by which i could watch in real time the blocks and transactions.

The first Bitcoin app was probably Electrum in 2011

I dont remember what that app was maybe it was G-Miner or something like that.

Unlikely. "The first version of GMiner was released on September 21, 2018"

if I could convert my "Entropy Hexa Hash" to the correct BIP reference then I could have the correct private key and the seed words to access my wallet.

The first Bitcoin Improvement Proposal (BIP) was created in 2011 - so any feature present in 2009 will not have been first defined by a BIP.
An "Entropy Hexa Hash" could conceivably be used to generate a private key but, so far as I know, no one in 2009 would have written that hash down in preference to writing down the private key or, arguably more usefully, backing up the wallet.dat file. I don't know where in the application Bitcoin core (then "Bitcoin") would have made that entropy information available.
Bitcoin core does not and has never supported the use of seed-phrases (recovery phrases) like those defined in BIP-39.

All I have now is some old keys (Private Keys)

Importing those into a wallet application and getting the wallet to rescan the blockchain should tell you accurately whether those keys ever had control over any money. You would see a list of transactions involving the public key derived from each of the private keys in 2009.

i converted the orginial keys to something else for keeping them secure ... You could simply take the private key and convert it via a cryptographic tool into SHA256 hash

The process that produces a hash is not reversible. Therefore you will not be able to recover a private-key from a hash of a private-key.

whether or not bitcoin supports BIP-30 recovery phrase that is not the question. The idea behind convering private keys to understandbale words was there right from the beginning. And there was also an option to convert the private key to BaseXX or different cryptographic standards. And I did that.Since now there are 12 word and 24 word seed phrases I am wondering if I could convert the key that I have to the seed words and import in Electrum wallet. But when I do that I see 0 balance so that means I am not using the right conversaion method.

There was an app on Android HTC mobile phone .APK format that could show  how many blocks are mined and how many transactions are being done in real time. Maybe none of you would know this because  you didnt even know in 2009 that bitcoin was existed at that time. only some one who was involveds in bitcoin from 2009 is maybe able to help me.

that app was not launched on google Market (Play store) it was available on Android (Blackmarket App)

what I am trying to do now is to generate xpub keys from the entropy hash that I have (because i converted the orginial keys to something else for keeping them secure). And then i use those xpub keys on blockchain.com to check if thats the correct wallet but i see zero balance. please let me know where can i see bitcoin block explorer? is blockchain.com is the right place?

the entropy information was not available in the bitcoin core. You could simply take the private key and convert it via a cryptographic tool into SHA256 hash or other cyrptographic standards like binary etc.....

See extended answer


text:
How do I generate a testnet segwit v1 taproot compliant bitcoin address?
I have a script that generates a segwit v1 taproot compliant address and private key. The script currently generates a regtest address but with minor tweaks it spits out a mainnet address. I think the only difference between a regtest and mainnet address is that for regtest you remove the "bc" from the beginning of the string and replace it with "bcrt." Private keys for regtest and mainnet appear to be the same. This is my script:
def gen_segwit_v1():
    privkey, pubkey = generate_bip340_key_pair()
    program = pubkey.get_bytes()
    version = 0x01
    address = program_to_witness(version, program)
    return privkey, pubkey, address

It creates a bitcoin segwit v1 wallet for usage in taproot transactions. The problem is that my script relies on generate_bip340_key_pair() and program_to_witness() which I copied from https://github.com/bitcoinops/taproot-workshop/blob/master/test_framework/address.py.
This is what program_to_witness() looks like:
def program_to_witness(version, program, main=False):
    if (type(program) is str):
        program = hex_str_to_bytes(program)
    assert 0 <= version <= 16
    assert 2 <= len(program) <= 40
    assert version > 0 or len(program) in [20, 32]
    return segwit_addr.encode_segwit_address("bc" if main else "bcrt", version, program)

I want to generate a testnet Private Key and a testnet segwit v1 address. I think the private keys for testnet and mainnet are different. I don't know the technical derivation formula for bitcoin private keys, but for some reason, all of the testnet private keys I've generated start with a "c" and all of the mainnet keys I've generated start with a "K" or "L" . I'm guessing the formula is different for testnet and mainnet private keys.
So in conclusion, is there a simple way to generate a testnet private key and get the testnet taproot compliant segwit v1 address?

https://bitcoinlib.readthedocs.io/en/latest/#segregated-witness-wallet
This may help?

Oh nice! This is close but I don't think these docs show how to create a segwit v1 address. The address created in this example is a v0 segwit address. I think taproot requires v1.

Private keys are just big numbers. Although there's a nit on x-only keys (you must use keys whose pubkeys have an even y coordinate), it doesn't appear to be a problem here, since you can generate regtest and mainnet addresses. In theory, there's no differentiation between those networks when it comes to private key.
I noticed that program_to_witness only creates addresses that start with bcrt or bc. Testnet's prefix is tb, perhaps this is your issue?

I see what you're saying. Yes, I can just remove bcrt or bc from the beginning of the address and replace it with a tb, but is that really a valid testnet address? I mentioned that all of the testnet private keys I've generated start with a "c" and all of the mainnet keys I've generated start with a "K" or "L," so I think the actual private key has to be different.

You can generate testnet, regtest, or mainnet segwit addresses from the same private key. They’ll be all different from each other. It’s not just prefixes.

Private keys follow the same rules for all networks.
Three issues come to mind that you might need to consider:

The human-readable part of the bech32 address is also covered by the checksum. Therefore, it’s not possible to simply replace the human-readable part of an address. To use the same key for a different network, one would need to pick the network before deducing the address. I think the data part would be the same, but the address would have a different checksum.—It’s generally not recommended to use the same keys on multiple networks for privacy and security reasons.
The human-readable part for testnet addresses is tb, not bcrt as @DavidsonSouza mentioned.
While native segwit v0 outputs (P2WPKH, P2WSH) use the “bech32” (BIP173) encoding for their addresses, native segwit v1 outputs (P2TR) use “bech32m” (BIP350). This only changes how the checksum is calculated (and probably is covered if your function is specific to BIP340).


text:
(litecoin) High hashrate but low amount of submitted shares in solo
I'm playing around with litecoin mining and have been mining at a pool but decided to mine solo using cgminer.
When I mine at pools the amount of shares submitted to the pool sinks dramatically when I crank up the intensity (180 khash/s at intensity 11 compared to 20 khash/s at intensity 15). This is the same no matter which pool I'm on.
According to cgminer the khash/s go up as would be expected when intensity is upped.
For solo I really want to know if just the submitted amount of shares goes down for some reason or if a higher intensity really somehow ups the khash/s but lowers the submitted shares. cgminer's output is not easily checked for this.

The system of shares on a pool is set by the pool owner. It is not exactly the same as mining litecoin solo, and in fact some pools will have much smaller shares (pool-x.eu) set up to encourage you to continue mining, even though you are not actually mining more litecoin. Other pools have larger shares which take longer to mine (ltc.kattare.com), but are actually less work for the server so (theoretically) you should get a bit more from the longer ones.  While solo mining you are A) getting all the shares yourself with no "pool power" and B)getting the normal share size for litecoin. Hope this helps, 5mil

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


text:
How can Bitcoin be adopted as tradeable currency pairs on Forex?
There are Forex clearing-houses all over the world. How can we have a Forex clearing-house offering Bitcoin as tradeable currency pairs?

Well, the Bitcoin exchanges are a form of a forex clearing house. At the moment, however, Bitcoin is not really ready to be traded alongside all world's currencies at some more major exchanges - the big players could sway its value up and down at a whim with a fraction of what money they have. Before that happens Bitcoin still needs to grow and become more noticeable. However, there isn't much stopping someone from incorporating Bitcoin into a new forex.

Essentially, it is a tradeable currency pair today, just that there is no leverage (or very little leverage) compared to what you see with forex.
Bitcoin is different enough from foreign currencies that it may take a very long time for Bitcoin to be considered "investment grade".
In the meantime, a plethora of alternatives can flourish where stability can exist from the vast number of ways it is being used.  For instance, ICBit.se's futures contracts based on the BTC/USD, and now their Gold/BTC and Crude(WTI)/BTC futures contracts as well, are innovations that put bitcoin to use in new ways which allow to some degree a method of shorting bitcoin with leverage (in the case of the Gold/BTC futures contract) or going long with leverage on the BTC/USD (in the case of the BTC/USD futures contract).
MPEX offers CALL and PUT options on the BTC/USD with front-month and next-month expirations.  They also offer bond tranches where the proceeds are used for settlement of the options business.  These are just some of the first innovations (excluding some false starts, like Bitcoinica and the investment funds on the now-defunct GLBSE).
Existing forex outfits will probably see the opportunity when some bitcoin-specific exchange market begins to grow rapidly, but there's nothing much of the sort just yet.


text:
How do I import private keys from Bitcoin-qt to Multibit client?
Question says it. I spent 20 mins Googling. Saw several links on bitcointalk.com but amazingly found no solution to this. Am I the first one trying to do this?
Note the following are not the solutions I am looking for:

Transfer the BTC from Bitcoin-qt to Multibit by making a transaction
Some commandline geeky stuff

Some commandline geeky stuff

Well, that's the way it is done.  You could pay someone to do that process for you -- but then you would need to trust them as they have your private keys.

That "commandline geeky stuff" can be done through the debug window / console that is available with the Bitcoin.org client v0.7.

Unfortunately there are some commandline geeky stuff commands that you will need to execute.  Please see my answer below.

Manual Steps

Copy your public receiving addresses from Bitcoin-Qt.
Go to the Bitcoin-Qt console: click Help/Debug Window and then select the Console tab.
Run walletpassphrase [your password] [timeout in seconds] to unlock your password protected wallet.
Run dumpprivkey [Receiving Bitcoin Address] for each receiving address to be migrated to MultiBit. There may be hidden private change addresses in Bitcoin-Qt which don't show up in the receive tab. Run listaddressgroupings.
Copy the results of dumprivkey for each address (which are the corresponding private keys).
Start the Multibit client and create a new wallet.
Click Tools/Export Private Key after selecting the Do not password protect export file option.
Open the exported file in a text editor.
Below the private key generated by MultiBit, paste the private keys you have copied above. Remember to paste them before the End of private keys line.
After each private key, add a date that is prior to when you created the corresponding wallet. (You can check this date in the Bitcoin-Qt Transactions tab and scrolling to the very bottom.)
Repeat for all addresses you want to move to Multibit Client.
Save the key file and import it to the Multibit client using Tools > Import Private Keys.
In MultiBit, you may not see your total until you click Tools > Reset Blockchain and Transactions
In order to protect yourself from theft, delete the private key files.
Done!

Scott's answer above is excellent, but I think there are some final steps missing, which are: After step 8: 9. Save the file that you added the keys to
10. Click Tools/Import Private Key. Find the file you saved and import it.

By the way, this is a great answer, but besides the comment of @Velonius above, you have to make sure to put a date prior to the creation of your wallet when pasting the private key into multibit.key file. This ensures the proper replaying of the blockchain which will then pick up all the transactions.

Also missing, if you have a password on your wallet, is before step 3 writing:  walletpassphrase [your password] [timeout in seconds]

My transactions were picked up, but my total did not appear in MultiBit until I did "tools > reset blockchain and transactions" at the end (after step 11).
Also, be aware that the QT-client uses hidden private change addresses that don't show up in the receive tab. listadressgroupings in the Qt-debug-console showed my missing addresses which I then followed steps 3-10 for to make ALL of my transactions and money appear in multibit. Get all addresses from bitcoind

Thanks Marcelo Delgado and Crashthatch, I updated the answer.  I hope it helps others and is easy to read.

Simpler now: bitcoind -daemon; bitcoin-cli dumpwallet wallet-dump.deleteme; grep label= wallet-dump.deleteme | cut -d' ' -f1,2,3 > import-into-multibit.key -- but don't do it on insecure storage! Those contain raw private keys. I'd like to improve this by importing labels as well, but couldn't figure it out.

Oh, here's the script and a helper, I'll add more if I need it: https://github.com/timmc/app-1113

Your link is dead.

Thanks, I removed the link.  I'm glad I wrote out the steps here!

It does not answer your question of getting your private keys out of bitcoin-qt, but this link explains how you import a single private key into MultiBit:
http://multibit.org/help_importASingleKey.html
If you have more than one private key it is simply more rows in the import file.
The date alongside each key is a bit non-obvious. It has to be before the date of the first transaction using that key so that the blocks with the transactions in can be found. I recommend just finding the first transaction in your wallet and putting the date one day before it in on every row. (Using a day earlier avoids any time zone problems).
Note that the import only knows about the sipa format private keys (the ones beginning with a 5). It does not understand compressed keys. ( What is a compressed Bitcoin key? )

Still strange to see people name the base58 private key format after me. I'd prefer them adding support for compressed public keys (which I also came up with, including the base58 format...).

Hi Pieter, yes I will no doubt get round to adding parsing of compressed keys - it is in my issues list. As the export files are mainly to backup the MultiBit keys it is not top of the list though. I think you will probably have to get used to being famous. :-)

I wrote this a while ago and used it to convert all my wallet.dat s to multibit.key to be able to import them to multibit.
https://github.com/shayanb/Open-Wallet-Format

authors: Миша Труханов


text:
How is this transaction valid?
Transaction in question: 16ac7736552c5791cff5643e6104c76c24018236b2193e014b308efea4f32f81
The P2SH input has a strange redeem script:
OP_DUP
OP_HASH160
OP_PUSHBYTES_20 caaa64d70e561ca95bbb4f1220636f625494bf70
OP_EQUALVERIFY
OP_SWAP
OP_CHECKSIG

This is almost the same as a P2PKH script, except that the hash is checked against the signature, not the public key. It shouldn't be possible to satisfy this script, because the signature message commits to the script, and therefore the signature itself. Without this circular problem, we could have covenants in Bitcoin today by putting the signature (or its hash) into the script.
Indeed, while the hash checks out, I'm not able to verify the signature against the input's signature message. Additionally, the signature itself is strange, it's only 65 bytes and most of its bytes are 20. So how is this transaction valid?

I'm new to Bitcoin, so I'm not sure how much I can help you, but as far as I know, the hash preimage for the P2SH goes with the redeem script on the place of ScriptSig, which in this case includes the public key hash, not the signature itself. So there will be no circular problem.

The signature is actually valid. The sighash is 8cc2772af5af61583c5a7ae89f777d3173afa470ce8b1bfa5f8d4b9a54635ccb and you'll find that the signature does indeed validate.
So the question is how is this signature valid? The trick is actually public key recovery. Given a signature and a message, it's possible to calculate a public key that makes the triplet valid.
You'll notice that the hash of the signature is in the redeemScript, not the public key. The public key is not committed to at all as it is not included in the sighash message. Thus the person who created this transaction was able to compute their sighash, combine it with the signature, and compute the public key that would make it valid.

It turns out I was calculating the sighash incorrectly, using the output script instead of the redeem script, it checks out now. Public key recovery didn't occur to me, as I didn't quite realize the public key wasn't committed at all and could be freely adjusted to match the signature. Thanks!


text:
how to get every inputs signature from a raw hex bitcoin transaction using python?
I have this raw transaction :
01000000000105330279cf447f9bb7fda6126fa9dccec60aa5d88fc337f5277937a876453915ff0000000017160014fa19560857496be932b9bd97743dd9f6903bb766ffffffffbcd372e8706a2d82a43cf76da29c93cd41c0034b4dc80ee588c07048e693d3f80100000017160014fa19560857496be932b9bd97743dd9f6903bb766ffffffff5564b82766e450bb9da37ebc024f1a65929202f0dec762ff232578e761af21170400000017160014fa19560857496be932b9bd97743dd9f6903bb766ffffffff98f7a465ab6e524a9974da0f98539480b5e0ff460754fbbec9cc312eba3ded740100000017160014fa19560857496be932b9bd97743dd9f6903bb766ffffffff14c0ed8059c6e0045144ba42d802ec8da0bf3bcb23b09993bfdba91c5dc417700100000017160014fa19560857496be932b9bd97743dd9f6903bb766ffffffff02ad141900000000001976a9142956ec12b882a6fbb96a49be0bf18a54385c975488ac7b6f00000000000017a9144fad3f234dc8acced507798cd64d1d8ed7357e99870247304402205bfc32d6b5c8e7f2059f60047d76ae8d600bf9e19fd964110430729b9b60d1e202204c7ce43c174e2fd7e2fba937b422f7dad7c1e62e62f1dc3a212cd3cafc744e0a0121022347931ca8ce8a645ccdc340684375fa94918d7c3643619e24bb461fd0f985730248304502210099dddb3e17f183630210e39aae43967ce3ab824117878bb372a2ef4c232c5e620220453cbb9484aeea881dca96898a511191412149f4f153c0f59197f69b9c4ea7a10121022347931ca8ce8a645ccdc340684375fa94918d7c3643619e24bb461fd0f985730247304402203cdabf0747658f43028e2c8c78c256498a759bcebefd0de81e30540a5c8f3bf502203910ec0623d9730b02359888533d49436a54131e0095b51e9ae854b67be0ec890121022347931ca8ce8a645ccdc340684375fa94918d7c3643619e24bb461fd0f985730247304402206c989bd6fdbc6502f8c05f973b601e01428b2c81eba068ac9a925984963452ff022029db750831ffa70cf50ec5b9170a80b3f8eca177aebb0d50d0633fd098cbb7760121022347931ca8ce8a645ccdc340684375fa94918d7c3643619e24bb461fd0f98573024730440220369527cfbdc32612dccc71787b1aada23de5915739ae246b27b6b017a12a52b30220063367dc3ae31af55aee79c51b9648aae781586b3d595ad8e6a9b7e645e5cd060121022347931ca8ce8a645ccdc340684375fa94918d7c3643619e24bb461fd0f9857300000000
It has 5 inputs, and I would like to get the signatures of all of them.
I can use bitcoinlib to get the info about this transaction, but the info doesnt give me the signatures.
I used 'transaction_deserialize()' from the transaction module to get the info.
I already have, server=1 and txindex=1, into the bitcoin.conf file
How can I decript any raw transaction to get the signature of all the inputs?

Does this answer your question? https://bitcoin.stackexchange.com/questions/93711/how-do-i-to-get-the-r-s-and-z-values-from-a-raw-transaction-version-2

it seems to be great indeed, but I dont know how to use this with python, do i have to install bitcoin-cli?

Yes you'd need to install Bitcoin Core which includes bitcoin-cli. If you want to use Python specifically can you make that clear in the question please? I'll look over some Python libraries and get back to you.

ok, I will make the change to my question, it was not clear that i wanted to use python. Thank you for your help bro

There's this too https://bitcoin.stackexchange.com/questions/78452/does-exist-some-library-for-decode-encode-raw-transaction. I haven't used this library though so can't comment if it works, is sufficiently maintained etc https://github.com/mcdallas/cryptotools

thanks for your help man, I will try this out to see how it is working, It seems to be what i was looking for, I will come back here if this worked well. Thx.

I tried two different packages, the one that you suggested and https://github.com/primal100/pybitcointools
I think that the one that you suggested is easier to use and the information I need are extracted in a better fashion.
Thank you for your help, have a great day.

No problem. Marking this is a duplicate as the above answered your question.


text:
What are the privacy implications of revealing one xpub in a multisig setup?
What information can a third party derive about a multisig wallet if one of the xpubs in the setup is known?
This could be relevant for a few reasons:

For a collaborative custody setup such as Unchained, would using an xpub that is already used in a private wallet setup reveal information about that wallet?
In general, if the same key is used in multiple multisig wallets, can those wallets be linked by a third party?
An advantage of multisig is that if one private key is compromised, that is not enough to steal funds (assuming quorum>1) but would an attacker be able to see a wallet balance?

In a multisig setup, all of the xpubs are needed to generate wallet addresses, which may make it seem like revealing one xpub does not reveal any information about the wallet. However (based on poking around on the block explorer) I think the situation is more like the following:

Each xpub is used to derive a sequence of public keys which are used in the spending script. These public keys are revealed at spending time, so while the full set of wallet addresses/UTXOs cannot be generated from one xpub, someone who knows one xpub could find transactions on the blockchain that spent from the multisig wallet.
Similarly, using the same xpub in multiple multisig wallets setups means that transactions from the different wallets could potentially be linked together - in particular transactions spending from the same address index in each. e.g. if one setup uses xpub1, xpub2, xpub3 and the other xpub1, xpub4, xpub5, then the spending script for address index k in the two wallets will contain something like (pubkey1k, pubkey2k, pubkey3k) and (pubkey1k, pubkey4k, pubkey5k) - so they are linked by having the same pubkey1k in each.
The solution to avoiding the above issues would be to use different derivation paths, which would generate different xpubs from the same private key, e.g. using different account numbers in the derivation path for a private vs. collaborative custody setup. (For this reason, revealing a multisig xpub would not reveal info about single-sig wallet and vice versa).


text:
Binance or cold wallet?
I’ve been using Binance to trade and store my cryptocurrencies, but I’m unsure if it's the safest option in the long term. I’ve heard that exchanges can be vulnerable to hacks or other risks. Should I keep my assets on the exchange, or would it be more secure to transfer them to a hardware wallet or other type of cold storage?

would it be more secure to transfer them to a hardware wallet

Yes.
Many times, major exchanges go bust are hacked or founders disappear with the money. Cryptocurrency exchanges are not well regulated despite what many claim. There are no government safety nets for investors and creditors of cryptocurrency exchanges.
The risk with a cold wallet is that you fail to make backups, fail to store a recovery phrase in physical form in a separate location and fail to make provision for family to recover money should you become unable to, through illness, injury or death.

I am also concerned about government safety nets for investors and creditors of cryptocurrency exchanges. Thank you for your reply.


text:
elderly mom transfrred bitcoin out of coinbase but doesn't know where it went ... have identifiers and hash stuff
My mom is and she transferred bitcoin out of her coinbase account which we finally regained access.
She does not know where she transferred it to, i.e., a wallet, or other account?
We have the transaction data from Coinbase showing the identifiers and hash ids but can't figure out how to trace where it went. We looked a a few of those hashes / identifiers by copying and pasting them into the search at bitcoin.com and they returned information reporting those transactions as occurring, stating the value, the charge for the transaction, and that that section of the "block" now has no value.
Any way to find where the lost bitcoin went?
Thanks
Marc

A transaction ID or bitcoin address alone will give you no clues as to what sort of wallet created the address that the bitcoin was sent to.
You will need to work with you mom to remember where the coins were sent. Try searching her digital devices for wallet applications, her email for wallet backups or exchange/wallet service registration emails, her physical belongings for wallet backups (mnemonic seed phrases, or perhaps a paper wallet of some sort), or anywhere else you might be able to find a clue.
Without any other information, I'm not sure anyone here can be of much further help.


text:
I formated my hard drive with bitcoin core on it
First timer here
...I downloaded bitcoin core a few weeks ago until last week where it still had not synced so i started all over...I was originally waiting for BTC CORE to synchronize(I missed the part in the installation that stated I needed 220+ gb of free space)...I had to format BOOT ssd(256gb..also where I originally tried to save BTC CORE)...thats why it was taking so long and I purchased 1tb samsung evo. I'm  wondering if my BTC address will be the same(since I never actually synced with the servers and since I am not using the same SSD where BTC CORE is being saved. However, it is the same SSD that windows is booting from but I had to reinstall windows.
I have now downloaded BTC CORE on my new SSD and it is synced. Unfortunately, I cant find my BTC and when I use a block explorer the funds are not there(I checked with a BE last week and the BTC was there... but pending or waiting to sync...now its not)
...did my BTC address change? will it ever sync with the older one so I can get my funds?
hope someone can help

Addresses are not magically tied to the hardware you use. If you delete the file that contains the private keys for your addresses, you will lose them and thus lose access to your Bitcoin.
Since it seems that you formatted your hard drive without making a backup of your wallet file, your private keys and thus your Bitcoin are lost. You may be able to recover the file using file recovery software such as Recuva.

whats the name of the file i should be looking for?          I saw someone say wallet.dat but id like to confirm

The file is named wallet.dat.

Thanks...I found what I believe may be the lost file but when I copy/paste...then boot BTC CORE it says corrupt file and then fails


text:
Where does the term "derivation path" originate
BIP-32 never mentions the term "derivation path" but a quick search (https://bitcoinsearch.xyz/?search=derivation+path) returns a bunch of results so one must assume "derivation path" is part of the Bitcoin vernacular.
Two questions please:

Is "derivation path" the correct term?
If so, where did it come from (is it specified or just use colloquially)?

Thanks

Is "derivation path" the correct term
and where did it come from

It is very widely used and you can see part of the origins in BIP-44 from 2014-04-24

Path levels
We define the following 5 levels in BIP32 path:
m / purpose' / coin_type' / account' / change / address_index
Apostrophe in the path indicates that BIP32 hardened derivation is used.

(My emphasis added)

Thanks man, that's close enough for me.


text:
How to solo mine bitcoin if the blockchain is on an external hard drive?
I am trying to solo mine bitcoin but the blockchain has been downloaded to an external hard drive.

You don't need to store the full blockchain in order to solo mine. A pruned node works just fine and requires only a few gigabytes of storage.
If you join what's called a "solo mining pool", you don't need to run a node at all, provided that you're okay with a small level of trust towards the mining pool and with a small percentage fee taken from your reward in the highly unlikely event that you actually manage to find a block.

Is there a solo mining pool with Getwork protocol? My ASICs can't connect with stratum..

According to this answer, no mining pools have supported getwork since 2011.


text:
How to manually verify an ECDSA signature in Python?
Maybe I got the formula wrong but I heard that x = (z*s^-1)*G+(r*s^-1)*K is the equation for verifying an ECDSA signature but my code says signature is invalid but the values are from a valid bitcoin transaction.
def gensig(d,k,h):
    x = bitcoin.fast_multiply(bitcoin.G, k)
    r = x[0] % n
    k_inv = mod_inverse(k, n)
    s = (k_inv * (h+(r*d))) % n
    return r,s

def verfy(r,s,pk,h):
    # Verify the signature
    w = mod_inverse(s, n) # Calculate the modular multiplicative inverse of s
    u = (h * w) % n
    v = (r * w) % n
    y = bitcoin.fast_multiply(bitcoin.G, u)
    b= bitcoin.fast_multiply(pk, v)
    a = y+b
    x =a[0] % n
    # Check if the calculated point matches the R component of the signature
    if x == r:
        print("Signature is valid")
    else:
        print("Signature is invalid")

def solve_k(h, r, x, s, n):
    # Calculate the modular multiplicative inverse of s modulo n
    s_inverse = mod_inverse(s, n)

    if s_inverse is None:
        return None  # No modular inverse exists

    # Calculate k using the formula
    k = (h + r *x ) * s_inverse % n
    return k

def solve_d(s, k, h, r, n):
    rinv = mod_inverse(r, n)
    d = (((s * k) - h) * rinv) % n
    return d

Given these:
R=0x0089848a1c90ee587b1d8b71c9bafccbc072613e41b3fd38cc2b1cf3041e3792bc
S=0x45305be296870b32cca5dac0f0972cac820090214158652581f406fc70ef30f3
Z= 0x3d4a58fa8e5f94e9b8ed1d79a2d584ce45803153b75d43d7bcdbf49171d90992
priv1 = 1

When I do this:
pk = bitcoin.fast_multiply(bitcoin.G, priv1)
verfy(R,S,pk,Z)

I get signature is invalid but why?
What am I doing wrong?

What is the module bitcoin you are using? That would be helpful for anyone who wants to reproduce the problem.

@PieterWuille standard bitcoin module, just imported via import bitcoin and pip install

i think the culprit is y = a+b which should be ECC point addition

As I suspected the error was the + sign on two points instead point addition is required, so I modified the code like this:
def addp(P,Q):
    point1 = Point(curve, P[0], P[1])
    point2 = Point(curve, Q[0], Q[1])
    # Perform point addition
    result_point = point1 + point2
    return result_point.x()

def dub(Q):
    point1 = Point(curve, Q[0], Q[1])
    # Perform point doubling
    result_point = point1.double()
    return result_point

def verfy(r,s,pk,z):
    # Verify the signature
    w = mod_inverse(s, n) # Calculate the modular multiplicative inverse of s
    u = (z * w) % n
    v = (r * w) % n
    y = bitcoin.fast_multiply(bitcoin.G, u)
    b= bitcoin.fast_multiply(pk, v)
    a = addp(y,b)
    x = a % n
    # Check if the calculated point matches the R component of the signature
    if x == r:
        print("Signature is valid")
    else:
        print("Signature is invalid")

And it works.


text:
New to BitCoin - Purchased Coins but they haven't shown up in my wallet yet - Wallet still syncing
I purchased some BitCoins last night.  I downloaded the BitCoin client around a year ago but and only had it open once or twice for just a short time.
Because of that, my wallet is still synchronizing and looks like it will continue doing so for quite some time.  lol
Needless to say, my wallet is still at zero...  Did I screw myself over by transferring coins before my wallet ever initially synced?
It was a small, small amount thankfully, just to try it out (as I said, I'm a newbie).  :)
Any help is appreciated it.
Thanks!

possible duplicate of Help! I sent coins to my bitcoin wallet before it was properly synced!

Check blockexplorer / blockchain.info with address, or public key..

Just wait for your wallet to synchronize.  It won't show up in your wallet until you have the block that contains the transaction, which would be a very recent block.


text:
When will price of BTC go below 100$?
Currently the price of 1 btc is more than 300$ at the time i wrote this. But , I had sold 5 BTC when the price was at 130 $ . I planned to buy them back when the price declined. But it never did.
Can I expect the bitcoin price to go back to 100$? If yes when? (Just make a guess...)

Currently, the total number of bitcoins in circulation are approximately 12.000.000.So, maybe you mean 1.000.000, not 10.000.000 bitcoins stolen. Moreover I highly doubt that the value of bitcoin will fall as soon as the heist history of bitcoin will be media notished.

Questions calling for guesses are not a good fit for this site.

Silkroad 2 has just launched so it wont fall back down.

Speculation is an entire category of its own, in spirit of giving you some useful information I shall direct you to the following:
Speculation board: https://bitcointalk.org/index.php?board=57.0
Reddit Bitcoin Markets; http://www.reddit.com/r/BitcoinMarkets
BitcoinMarkets on freenode also for live discussion also.


text:
Bitcoin Armory Difference in GPG Output
The section "Verifying Downloaded Files' at http://bitcoinarmory.com/download/ says that I should see the following output after running GPG:
$ gpg --recv-keys --keyserver keyserver.ubuntu.com 98832223
gpg: requesting key 98832223 from hkp server keyserver.ubuntu.com
gpg: key 98832223: public key "Alan C. Reiner (Armory Signing Key) <alan.reiner@gmail.com>"

However when I ran it, I got:
gpg: key 98832223: public key "Alan C. Reiner (Offline Signing Key) <alan@bitcoinarmory.com>" imported

instead. A link I found on btcarmory.org (http://pgp.mit.edu:11371/pks/lookup?search=Armory+Signing) has a result that implies that these two outputs are acceptable, but can someone please confirm that this is true?
Is the difference in the GPG output a concern? I only ask because of how intensely it is suggested to do this stuff! Thanks.

The output is fine. The key fingerprint is the same. Alan merely has several uid records in this key.
See for yourself:
$ gpg --list-key 98832223
pub   4096R/98832223 2012-02-28
uid                  Alan C. Reiner (Offline Signing Key) <alan@bitcoinarmory.com>
uid                  Alan C. Reiner (Armory Signing Key) <etotheipi@gmail.com>
uid                  Alan C. Reiner (Armory Signing Key) <alan.reiner@gmail.com>
sub   4096R/DE6B2D74 2012-02-28

GnuPG simply chose to show you one of the other, completely valid uids for this key.

You could email him and advise him to update what it says on the site to eliminate the confusion that spawned this question.


text:
How do I see if I've invested in bitcoin
I can't remember if I ever invested in bitcoin how can I check can someone please help

Related: https://bitcoin.stackexchange.com/questions/103688/i-have-lost-my-wallet-what-can-i-do

Does this answer your question? I have lost my wallet, what can I do?

Typically you would know because you would have the keys to the wallet in your possession. It's also possible you invested on an exchange and in that case you wouldn't have the keys, and you would need to check with the exchange. Perhaps a simple search in your email for "bitcoin" or "crypto" will reveal if you have any accounts that you could look into further.


text:
What are the OP codes associated with bc1?
As the title says I'm trying to extract bc1 addresses by using opcodes I've found from reading about bitcoin online. However, I cannot actually find the opcodes associated with bc1. The segwit outputs here are described as, from what I gather, not having OP codes. How can this be? Surely I'm misunderstanding something. Can anyone elaborate?

Native segwit scriptPubKeys are of the form OP_n + <data>, so first a single number opcode followed by a push of some data (called the witness program). Specifically:

For P2WPKH (pay to witness pubkey hash, BIP141), OP_0 followed by a push of 20 bytes. Those 20 bytes are the Hash160 of a public key. Their corresponding address format is defined by BIP173.
For P2WSH (pay to witness script hash, BIP141), OP_0 followed by a push of 32 bytes. Those 32 bytes are the SHA256 of a script. Their corresponding address format is defined by BIP173 as well.
For P2TR (pay to taproot, BIP341), OP_1 followed by a push of 32 bytes. Those 32 bytes are a tweaked x-only public key. Their corresponding address format is defined by BIP350.
For future witness versions, any OP_1 through OP_16 followed by a push of something between 2 and 40 bytes (except OP_1 followed by 32 bytes, which is P2TR). These too have addresses associated with them in BIP350, but no semantics (yet).

In general, native segwit outputs do not contain any "active" opcodes like OP_CHECKSIG or OP_HASH160 or anything like that, they're just stubs that push some data. The segwit (and taproot) consensus rules know how to interpret them.

It's listed under "N/A" there, because direct pushes aren't considered opcodes. Pushing 32 bytes is just 0x20 (hex value of 32) followed by the 32 bytes being pushed in the script encoding.

One last question. I realize that you have shown me the op codes that are in front of the public key. What about the op codes following the public keys? I deleted my reference to the op codes form that site since it's not actually for bitcoin.

Are they followed by op_return? as per https://bitcoin.stackexchange.com/questions/87832/how-i-can-extract-all-bitcoin-output-addresses-from-tx-message?noredirect=1&lq=1

No, OP_RETURN makes any output unspendable. It's only included in so called "data carrier" outputs which are deliberately not intended to be spensable. As I stated in my answer, native segwit outputs are of the form OP_n + some data push. There are never any other opcodes involved in the scriptPubKey.

I'm sorry to keep bringing up more questions but this is fascinating. So, how exactly do you signify the end of what needs to be decoded as the public key then? If it's OP_n, then it signifies exactly how many bytes to pull out?

@bitcoinluvr6969 Look, I get that you're trying to reverse engineer the entire transaction format based on just a hex dump. This is foolish, it'll make you miss all sorts of edge cases even if it works. Implement a proper transaction decoder, and if need be, a Script parser. You don't need to guess these things; the script field has a well-defined length in a transaction, so with a proper decoder you'll never need to guess. Just trying to pattern match for known byte sequences will only work some of the time. You'll find the basics on https://en.bitcoin.it/wiki/Protocol_documentation e.g.

I understand that you're somehow constrained to not use existing libraries to do this parsing for you. But that means there is only one option: learn how the actual protocol works. And that means starting with the beginning: learn how messages are encoded on the wire. Then learn how transactions (and maybe block) messages are encoded. And when you have all that, you'll see where the scripts appear and what to send a script decoder.

I think you may be misunderstanding how an address is constructed and where scripting opcodes fit into that. The bc1 indicates the use of the bech32 address format for SegWit versions as defined in BIP 173 and also broken down here. The hash of the witness script (SegWit version 0) or the tweaked internal key (SegWit version 1) is included within that address. The opcodes used in the witness script or the tweak of the internal key are only revealed on spending from the address. So to view and analyze the opcodes you need to look at the transactions spending from a particular address rather than the transactions sending to a particular address.

I think you’re mixing up “witness script” and “witness program”. Native segwit output scripts are defined as consisting of <version> <witness_program>. In P2WSH the witness program is the hash of the witness script, so your third sentence should therefore read “The hash of the witness script…”.

Thanks @Murch. Updated.


text:
What if someone locks some bitcoin with a script which only requires a user to know a preimage, but it matches the p2sh template?
The basic script for a lightning network HTLC output has a conditional branch which requires a user to know a preimage of a hash. It also requires the user to give a valid signature, but it got me thinking, what if before P2SH was a thing (back in the day) a user created a locking script which just so happens to match the P2SH template? For whatever reason, the user only intended to lock the bitcoin with a "spender must know the preimage of this hash" requirement. But this preimage is not a bitcoin script itself, so can't be executed even though it matches the P2SH template. Do P2SH-knowing nodes lock this bitcoin forever?

Yes, that could happen. However it is also possible to inspect the blockchain for such outputs, and none exist that weren't known to be for testing.

Looks like there might have been a handful, but were these all known at the time? https://bitcoin.stackexchange.com/questions/115803/did-the-p2sh-bip-0016-make-some-bitcoin-unspendable

I think this question is effectively asking what happens if you try to pre-empt future soft fork rules and broadcast a transaction which can only be spent after a future soft fork lays out the rules for spending that output(s). Today such an output would be anyone-can-spend on broadcasting so it would be the complete opposite of being locked up forever. But at the time of the P2SH soft fork (2012) it would have been locked up forever unless the transaction constructor was able to perfectly pre-empt the future rules for spending the output. Any slight mistake when attempting to pre-empt those future rules could have resulted in them being locked up forever so it wouldn't have been advisable to try this.

I was thinking the opposite, where a user creates a script which is unintentionally restricted by a future softfork.


text:
Why is the challenge scalar multiplied with the private key scalar In the Schnorr identification protocol?
If Alice wants to prove to Bob she is the holder of private key x, without exposing x, they can use the Schnorr identification protocol which has the public function sG = kG + exG and the private scalar function s = k +ex. In these functions, G is the static generator point, k is a hidden nonce chosen by Alice to protect x from being revealed to Bob, and e is a nonce chose by Bob so that he can trust kG (can't be calculated by someone pretending to hold x).
This all makes sense to me, but I am curious if there is a reason that e is multiplied with x instead of just following the same addition operator as k. So the equations would become sG = kG + eG + xG and s = k + e + x. k has a very valid reason to use addition, that is how x remains hidden. I can't think of a meaningful difference for the goal of the protocol if e is multiplied or added, maybe I missing a core concept?

I don't see how this is related to Bitcoin. Perhaps this question would be more suitable for Cryptography Stack Exchange (they even have a tag named schnorr-identification).

This is trivial to forge.
Just to make sure we're on the same page, this is your protocol:
Alice has private key x, Bob has public key Q:

Alice generates k, computes R = kG, and sends R to Bob.
Bob generates e, and sends it to Alice.
Alice computes s = k + e + x, and sends it to Bob.
Bob verifies that sG = R + eG + Q.

Mallory is running your modified protocol with Bob, trying to pretend to be Alice.

Mallory generates a random k and sends R = kG - Q to Bob.
Bob generates e and sends it to Mallory.
Mallory computes s = k + e and sends it to Bob.
Bob verifies that sG = R + eG + Q. This will always hold.

Thus, Mallory successfully impersonated Alice, without having access to x.

Ah I see, thanks!


text:
I created my own crypto coin. Do I have to keep my node running all the time?
I created my own crypto coin.  I have two questions:

Do I have to keep my node running all the time?
Is it better to have more than one node running?

You really should not be using your own altcoin if you don't know the answers to these questions.  If you just want to experiment, you're welcome to use Bitcoin's testnet or regtest mode.  However, here are the answers anyway:

Somebody has to keep a node running all the time or new users of your altcoin won't be able to download its block chain.
The more nodes you have running (on different computers), the more capacity your altcoin will have to grow its userbase.  By default, each Bitcoin Core node can handle 125 connections (normally 8 of which will be outbound).  I assume you didn't change that part of the code, so unless you expect more than about 100 users to suddenly start using your altcoin, running one node should be sufficient.

Again, running an altcoin is not something a newbie should be doing.


text:
Insufficient money, need xxxxxx Satoshis
Trying to process a transaction out of my Multibit wallet, entering the key & the error message 'insufficient money' appears on the screen. I know that I need to add a transaction fee, which I am doing, however the number of Satoshis required increases at every attempt! For instance, the transaction will require 100250 Satoshis, so I will amend the amount being transferred to 100300 to compensate & allow for any fluctuation.
The warning then reappears stating it now requires 100500 Satoshis.
This cycle is continuing, I can't find a figure beg enough to get
ahead of the curve, without literally throwing my money away! Any help
would be appreciated, this has been frustrating me for some time now!

Seems others have had similar problems with that wallet

they say the fee is like 0.0001 BTC but I had to make it 0.0005 or more BTC for it to send.

Support
Issue