text:
BTC transfer duration
When BTC is mined, it is sent to the BTC wallet. The duration of the transaction can be up to 24h for online wallets.
 Is the duration faster, when transferring BTC to a “cold wallet”?

Note: newly minted coins cannot be spent for 100 blocks (but that doesn't seem to be the basis of your question).

Coins are spendable by a wallet as soon as the transaction is included in a mined block. Some online wallets use their own software to sync, or in other words, to make their application aware that the account has received coins. Applications that use this method could have varying durations for recognizing received coins. Furthermore, different wallet providers may also have additional criteria, such as requiring that at least 4 blocks have been mined after the transaction was included in a block. This is known as Minimum Confirmations. For example, Coinbase will credit your account once there have been 3 network confirmations. In this case, the duration to "receive" coins on a local wallet such as Bitcoin Core, would be much faster than on Coinbase, because you would not have to wait for 3 blocks in order to spend the coins. It's also worth noting that this is not an issue of "online" versus "cold" wallets, it's more of an issue of third-party service based wallets versus personal wallet clients which you control the keys for.
As @JBaczuk pointed out below in the comments, technically coins are spendable even without a confirmation. This is especially useful for child-pays-for-parent (CPFP) transactions, where the first transaction may have a fee that is too low, but it is used as an input in a second transaction with an extra high fee, so miners will include the second transaction, which would also require including the first transaction.

If you run a node, and you have the transaction in your mempool, technically, you can spend it before it gets mined, and those transactions (which spend each other) could be in the same block.

@JBaczuk good point. I have updated my answer :)

It's helpful to keep in mind that a wallet, is just an application that interfaces with Bitcoin by managing your keys associated with your bitcoin. So if you broadcast a transaction, the transfer time you're talking about, is actually the time it takes for the miners to include your transaction in a block included on the blockchain. The time it takes doesn't rely on the wallet type you're using, but the actual Bitcoin network.
If you are waiting 24hrs, it could have to do with a low transaction fee. If the mempool is full, the miners will generally choose transactions with higher fees (to maximize their profit). If the fee that was paid on your transaction is relatively low you'll have to wait for the mempool to empty out before the miners include it in a block.
If you're relying on a third-party, they may be doing something else that isn't transparent from the outside, and is causing a longer wait time.


text:
Is there any method to extract transactions for an bitcoin address which is not in my wallet using bitcoin core?
I have setup Bitcoin core and trying build an API to fetch all transactions under an address ( not in my wallet ).
Bitcoin core RPC documention says that an address which is not in my wallet needs to be imported. So I did the same using importaddress while setting rescan true e.g. importaddress '35z3Re9SgLHBfeg7y1HdR35t9HrTqTsKFV' 'test' true. It took more than a week to rescan the whole blockchain database.
After importing the address, when I issued the getaddressinfo RPC command I got empty set of transactions in response.
Am I missing something ? Can you please help me here with the steps ?

getaddressinfo doesn't return transaction information.

You can use the scantxoutset command to scan for unspent outputs for a given address (or script).
Importing an address adds it to your wallet, and you will see transactions for imported addresses under the listreceivedbyaddress and listtransactions commands.

source: Stack Exchange

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

sort: votes


text:
Making the block reward dependent on the difficulty?
I am looking for papers which discuss, if making the block rewards dependent on the difficulty could be used to curb excessive PoW growth.
Idea is that BTC price roughly drives difficulty and energy consumption proportionaly. If the block rewards would decrease with difficulty (like in reward=(a+b/difficulty) with suitable constant values for aand b) then it would become much faster unprofitable to add more hash power, thus curbing the growth of total hash power and energy consumption.
This must have been discussed somewhere before, but I can not find anything related.

Your approach is interesting however to have a significant energy-consumption decrease you need to have a signficiant reward decrease which will involve a significant hash power decrease since then the security would have a significant decrease (because any old high hash power organization like current mining pool could "easily" reach 51 % of hash power of the total network hash power cf https://en.wikipedia.org/wiki/Double-spending#51%_attack)

Difficulty is proportional to hash power. If buying more hash power doesn’t increase difficulty but reduces you  profit it wouldn’t make sense to invest but in a larger scale it would kind of correlate the halving with the hash power. But not every 4 years or so. And the total amount of coins would be unknown but still capped when a certain hash limit is reached.

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


text:
Problem spending funds from P2WSH address: non-mandatory-script-verify-flag
I've tried to find an answer here and on BTT but without luck so far.
I'm having issues creating a transaction to spend from a P2WSH address which I created and sent funds to.
I based my code off of this example: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2wsh-txout.py
My code can be found here: https://gist.github.com/i0x0ff/b29b2307b4e9ce316a4d6533464cf7a1
P2WSH address with funds: tb1qhxy36055wje22qkxn4mtjl4k9vykcnq7avgtu3smnw6xpdxmw0qqjvywtn
I want to send funds to: tb1qffmyyg5v9atg3zzvlafzzu22ht6cexj7xt8sx4yl0f6c3zktzqrq8hempj
When broadcasting the transaction I get the following error:
{
  "code": -26,
  "message": "non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)",
}

One thing to note is that, I'm making this transaction on SIGNET and I've modified the code in the python-bitcoinlib to support SIGNET. I intend to make a PR for after I figure out this problem.
If there's any more information that I can provide in order to make it easier for anyone to help out, let me know what else would be useful. I'm just starting out with development on Bitcoin and will also document my process, finding and learnings.

Could you share the raw transaction bytes (in hex) that you broadcasted?

Of course, this is what I'm broadcasting:
0100000000010179ebc0d716496a2803828657074196c073bf9be23a43604530deec6a7f6ef6660100000000ffffffff011c250000000000002200204a7642228c2f5688884cff5221714abaf58c9a5e32cf03549f7a75888acb10060247304402203fb1c7b9d5c93716968ef7e010923f123b816a6ff255ff401b3dbf090c69f430022044509913f254e107d32696cd930c6ff6a4968fc84ed7417cb80f100c9562bcc5012321029bed8c78bc0f557742303db2fb3c48e8b5025cf11cdf1cdea764805f234a443cac00000000
I'm broadcasting using: https://explorer.bc-2.jp/tx/push

Your signature is invalid. When OP_CheckSig is executed it pushes false to the stack that is probably why you get that error message.

Thank you. I'm trying to read through the code and am comparing with my notes but can't figure out which steps I'm doing wrong that produce an invalid signature. Will keep on digging.

Answering for anyone who might come across this. My linked script is invalid, I tried to spend funds from txout for which I don't have access for.
The linked script works as expected and if you follow its steps it will work as expected. Please note that python-bitcoinlib does not have support for signet and I have made modifications to it locally.


text:
How to calculate the Average velocity and the Average acceleration of Bitcoin transactions
I am working on a Bitcoin project and I would like to extract the following features
1- Average velocity: represents the speed with which bitcoins flow to a user
2- Average acceleration: represents the acceleration of bitcoin flow to a user
I have the following attributes:

user ID ( represents the user)
the total number of transaction (e.g 100 transactions)
the total value of Bitcoin transferred (e.g 10000 BTC)
the date of each transaction (represents the date of each
transaction)

Can you please help me how to calculate the velocity and acceleration?
Thank you for any help you can provide
Regards,
Khaled

This question makes no real sense - acceleration and velocity have no meaning when talking about Bitcoin. What are you trying to achieve?

I'm trying to extract features from bitcoin dataset, I have linked between the addresses, transactions, and users with their relative values and times. I.ve aggregated the total of transaction value belong to a single user and extracted total amount, average in_amount, average out_amount, max and min, and in_degree and out_degree. So, now I want to calculate the acceleration and velocity of bitcoins flow to a user. I found this solution but I am not sure: Transaction velocity can be calculated by dividing the number of bitcoin transaction volume by the number of bitcoin in circulating. Tq

You can calculate an average velocity/flow of bitcoin to an address/user by summing all bitcoin received that address/user in a given time period and dividing it by the time period. I think your issue is that you don't have the time each transaction was made. The easiest way to get a rough time (+/- 2 hours) a transaction was made is to look at the timestamp field in the header of the block that transaction was included. So, for example, with if you have the transaction 58513acbb340fd24d2b27d8680961196f0363b79f90ee34a974d6593bf64559b, you can get the time of this transaction in bitcoin core by running this command:
>bitcoin-cli getrawtransaction 58513acbb340fd24d2b27d8680961196f0363b79f90ee34a974d6593bf64559b true | jq ".blocktime"
1576581288

This timestamp is the UNIX epoch timestamp that the miner chose for the block. Bear in mind that miners can choose a timestamp that is off by about up to 2 hours and the block would still be valid, so don't take this the last two/three digits of this timestamp very seriously - this value is mainly used to calculate difficulty adjustments in bitcoin which occurs only about every two weeks. Another way to assign a time to a transaction would be to know when that transaction entered the mempool but that information can be extremely hard or impossible to get a posteriori and can have less practical meaning than the block timestamp.
With an approximate instant when each transaction was made, you can group all transactions done in a day or week, for example, and divide the total bitcoin amount by the time period. To calculate the acceleration takes two consecutive velocities and divide them by the time period again.
Be careful not to confuse the velocity of money, which is an economic concept, with the velocity that you are trying to calculate which is specific to your data set.

I appreciate your help.
Actually I have the timestamp of each transaction, and I already grouped all transactions by week. May I know what do you mean by takes two consecutive velocities and is it possible to divide all weely grouped transactions by week means by 7
Thank you so much

It depends on what units you want to use. If you have your velocities in [BTC/week] you can have your acceleration in [BTC/week^2] and for that you just need to subtract one velocity by the preceding velocity to get the acceleration, buf if you want your acceleration in [BTC/day^2] you should divide the velocity difference in [BTC/day] per 7 days. It's more like a physics question than a bitcoin one.


text:
Is it possible to mine bitcoins faster on CPUs with this strategy?
This guy on bitcointalk.org suggested a potentially faster method for mining bitcoins using CPUs: https://bitcointalk.org/index.php?topic=265759.0
To quote from the author:
"Rather than computationally solving for SHA256(SHA256(block_header)), the approach is to solve it symbolically.   What I mean by this is, rather than treating the block header input bits as 0 or 1, treat each input bit as an individual symbolic variable (640 in total).   Next, perform the double SHA256, and produce a set of equations that represents each bit in the final hash.  These will obviously be huge, but you can PolynomialReduce after each step of the hashing to reduce the equation size.
The SHA256 output is 32 bytes, so what you end up with is a system of 256 equations, consisting of 640 variables each (which include all the logical operators applied from the double hash.)  For the purposes of mining at difficulty 1, you can discard all but the first 32 equations.
Now to mine using this method:  You have to collapse the equations and simplify.   Take the current, real block_header in question, and fill in actual values in your 32 equations for every bit except for the 32-bit nonce (608 in total.)  Reduce.
Now you have a system of 32 equations, and 32 unknowns.   Set all 32 equations equal to one another, and solve the system of equations.
What you end up with are 3 possible solutions: A nonce that produces 32 "0" bits (what we want), a nonce that produces all "1" bits (discard) or no solution (increment extraNonce.)
Note to make reduction and solving the system of equations simpler, convert the logical operators (xor, or, and) into arithmetic operations and do the reduction and solving in the modulo 2 number ring, for example:
a^b == (a+b)%2
(a | b) == ( (a*b)%2 + a%2 + b%2 );
(a & b) == (a * b) % 2 "
Now, I'm not a math guy, but from what I can gather, this strategy takes up a lot of computing memory. Therefore, my question is - is this strategy theoretically feasible? Can it be as efficient as ASIC mining?

The key question is whether there is any way to solve this system of equations that's significantly faster than "guess and check", which would take about 2^32 guesses, which is about the same amount of time as via the usual hashing.  In general one wouldn't expect that, because it's the NP-complete Boolean satisfiability problem.

It's not clear what the strategy is. It just says "and solve the system of equations".
The entire structure of cryptographic hashes like SHA256 is carefully designed to make doing this as difficult as possible, and there's not even a hint of how to solve that system of equations.
This is precisely what ordinary miners do, except they try to solve the system of equations by guessing possible solutions and seeing if they solve the equations. If there is a simpler way to solve them, what is it?

I think he is referring to Boolean functions or something.

@Biologynerd Which is exactly what bitcoin miners do.

Now, I'm not a math guy, but from what I can gather, this strategy takes up a lot of computing memory. Therefore, my question is - is this strategy theoretically feasible?

If it is feasible, SHA256 is broken and we should switch to something else.
The whole point of proof-of-work is to find a function for which partial preimages can practically only be found by iterating candidate solutions (or at least using work proportional to the number of candidate solutions tried).
If an algebraic way to solve these equations exists, it means SHA256 is not sufficiently distinguishable from a random function, as the relation between input and output obeys some tractable algebraic formulas. It wouldn't just be a break for its use in Bitcoin, but to SHA256 in general.

Can it be as efficient as ASIC mining?

If it works and is feasible, it'd likely be faster as it would permit solvers that scale better with increasing difficulty.
Thankfully, this approach is infeasible.


text:
What are the difference between a segwit and legacy wallet
I am installing a mobile wallet and it ask me what type of address I want to use, I want to try and use a segwit address but is there a risk that my coins will be lost if I try to transfer fund from an exchange if they dont support it, or if I want to transfer coins from my segwit address to a legacy one.

There are, broadly, three types of addresses in use at the moment:

P2PKH - Pay to public key hash addresses start with a 1, and should be accepted by essentially any service in the Bitcoin ecosystem
P2SH - Pay to script hash addresses are commonly used for multisig, but as of the segwit activation, they are also used for wrapped segwit addresses. These start with a 3. In the wrapped segwit version, you get the advantage of lower fees, while still being able to send to the address from nearly all services.
Bech32 addresses - Starting with a bc1, these are also known as native segwit addresses, and offer the greatest savings in fees. However, a sizable number of services do not support withdrawals to these addresses.

Generally, P2SH segwit addresses offer the best of both worlds at the moment.
When sending coins to a service, your choice of address does not matter. It only plays a role when receiving coins.

Worth mentioning, re: "When sending coins to a service, your choice of address does not matter." -- it doesn't matter as far as them being able to receive the transaction, but it does matter in terms of how much you pay in tx fees. Segwit addresses (P2SH or Bech32) get a discount when spending. For quick reference: https://bitcoin.stackexchange.com/questions/62053/how-do-transaction-costs-compare-between-bech32-addresses-and-legacy-bitcoin-add


text:
Are privatekeys Case-sensitive?
I want to print privatekey into block of steel, but I have only uppercase letters, so I wonder if privatekey is case sensitive?

A private key is a 256-bit number. You can represent it using only digits (so there is no need for lowercase letters). However, if you want to use the Wallet import format to represent the key, then you will need both upper and lower case letters (keys are encoded in Base58).

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


text:
Incentive for miners to keep mining once reward get very low
Currently each winning miner receive 12.5 bitcoin or 12.5*10 000 dollar per successfully mined block and the amount of bitcoin receive is divided by 2 approximately each 4 years.
The incentive to play the game fair and keep mining is pretty high, but what will happen once that reward get very low like 1 bitcoin or even less, even if the price get big like > 100 000 dollar it will be less and less rewarding to keep adding hashing power for the miners to protect the network and more and more tempting to try a 51% attack even if it just for breaking the confidence in the network.
so what could be the solution to keep the network protected, my guess is that some miners who are pretty invested in the game and own a lot of bitcoin/hashing power will always and forever keep a sufficient amount of machines ready to be powered ON at any sign of a 51% attack attempt, keeping the network virtually protected while not costing too much

Does this answer your question? Will Bitcoin suffer from a mining Tragedy of the Commons when mining fees drop to zero?

it will be less and less rewarding to keep adding hashing power for the miners to protect the network and more and more tempting to try a 51% attack even if it just for breaking the confidence in the network.

This is a pretty weak assumption. We don't make any calls for necessity in the Bitcoin hashrate growing, there's no security assumption around that, it's just an observed property that presently it happens to be growing.
Bitcoin miners are assumed to be operating with a single goal: profit. If somehow causing the thing which is giving you profit to fail is adventurous to you, then we can just rest easily on the knowledge that the underlying basis for Bitcoin to exist is incorrect.

The incentive to play the game fair and keep mining is pretty high, but what will happen once that reward get very low like 1 bitcoin or even less, even if the price get big like > 100 000 dollar it will be less and less rewarding

If the cost for operating the hashrate exceeds the revenue generated, miners don't mine. The whole system ends up with an equilibrium of having barely profitable mining hardware- regardless of how much profit there is to be made doing it. If the fee volumes don't ultimately cover for this, there will be less mining.

forever keep a sufficient amount of machines ready to be powered ON at any sign of a 51% attack attempt

You assume incorrectly. There is not large farms of idle hardware simply laying around. Large facilities require a significant amount of upkeep, large amounts of power are not available instantaneously, and if there was large amounts of ready-to-go obsolete hardware, it would doubtlessly be so inefficient as to be worthless towards any cause.

so what could be the solution to keep the network protected

Failure of the incentives means complete failure of Bitcoin as a whole, to pretend otherwise, or to pretend that there's some secret bullet which hasn't already been deployed, is disingenuous.

Price of Bitcoin: Having very little inflation, its value as a store-of-value would likely be high. High price of bitcoins would make the rewards still worthy.
Technological advantages: Electricity price could decrease if rapid innovation occurs.
Cost of recycling: It might cost miners less to keep mining at a loss than to sell their equipment or recycle them.
Transaction fees: The most likely outcome, miners would mine for transaction fees and not the block reward.


text:
Doesn't overt AsicBoost reduce the search space for a valid block header hash?
ASICBoost is a new method to mine bitcoins with a 20% speedup, as covered in this article:
https://blog.bitmex.com/an-overview-of-the-covert-asicboost-allegation-2/
Now, consider the following diagram:

Apparently there are two versions of AsicBoost - covert and overt. Overt AsicBoost involves changing the Version section of Chunk 1 only, while Chunk 2 remains unaltered (except for the nonce, which is still incremented). This is faster than the traditional method of incrementing the nonce, and then adding the extra nonce.
However, doesn't Overt AsicBoost reduce the search space? The current Bitcoin network difficulty is 15,546,745,765,529, which means that a miner has to iterate through approximately 2^76 hashes before a valid block header hash is found. However, the Version section of the block header is only 4 bytes (32 bits), and the nonce is also 4 bytes (32 bits). Therefore, if a miner implements the Overt AsicBoost technique, the search space is only 2^32*3^32=2^64 hashes, which is far smaller than 2^76. Wouldn't this be completely insufficient to find a valid block header hash?

What difference could it possibly make? Each hash you do still has the same odds of mining a block so all that matters is how many hashes you can do per second. It makes no difference how big or small the search space is unless it's so small that the time to start a new search becomes significant, which 2^64 certainly isn't.

They still roll the merkle root ('extra nonce') and time stamp, the same as any other miner.


text:
How many bitcoins do bitcoin faucets give away per day on average?
I just found out about bitcoin faucets. Apparently they give away very small amounts of bitcoins (or satoshis, for that matter) in exchange for performing some minor tasks, like solving CAPTCHAs or rolling dices. How many bitcoins do these faucets give away per day on average? Are there any statistics? How profitable is it compared to bitcoin trading or mining?
Just curious.

Bitcoin Faucets were useful once upon a time, when 10000 BTC still bought you only a single pizza (and even by then, they were starting to die out).
Presently, you will earn next to nothing with faucets - in fact, most faucet websites usually make you earn in DOGE or other coins with much lower values, as the time taken to earn enough BTC to be able to withdraw without losing it all to tx fees is far too large.
If your goal is to acquire BTC cheaply, your best bet would be to get a regular job and simply buy it - even $10 a day would buy you more BTC than any faucet would give to you in months.


text:
Beginner questions about Smart Contracts (saving the hash)
I am new here and to Blockchain technology, so I have some tricky questions for you :).
If I want to save data, for example transactions between two, on the Blockchain.

Is it possible to save only the hash on the blockchain and the rest on a cloud?
If I save the hash of the data on the Blockchain, is the data still as save as saving all the data on the Blockchain?
What else than saving storage is the difference between saving only the hash and saving all the data on the Blockchain?

I also got some questions concerning smart contracts. For the case that I want a fully automated documentation of transactions between two.

Is it possible to create the smart contract on a cloud and save the hash on the blockchain?
Does this have any disadvantage? Will the transactions still be recorded as save as on the blockchain?

I would be very glad, if you could answer my questions :)
Best
Samy

Is it possible to save only the hash on the blockchain and the rest on a cloud?

A hash of some data can serve as a proof the data exists, but the data itself won't be available to someone who just has the hash. If you store a hash on some server ('the cloud'), only those with access to the server will have access to the data.
If the server went offline or became corrupted for any reason, users would suddenly become unable to verify transactions. As a user this is terrible: you must fully trust that the server will remain online. So why add a blockchain to the mix? The inefficiency of a blockchain is made tenable by the lack of trust required in a third party when interacting with the system. Storing pertinent info on a centralized server is the opposite of this.

If I save the hash of the data on the Blockchain, is the data still as sa(f)e as saving all the data on the Blockchain?

I don't know what you mean by 'safe', but generally a blockchain is a terribly inefficient place to store arbitrary data.

What else than saving storage is the difference between saving only the hash and saving all the data on the Blockchain?

A hash can prove that some data existed at a certain point in time, but what that data is will be unknown. Only in light of the full data can the hash be verified to be a proof of the data's existence.
For example: with bitcoin transactions we need to know the full data of the transaction, or else how can we know that the transaction is valid? (spends valid inputs, with valid signatures). A hash of the transaction data is not sufficient to determine this.

Is it possible to create the smart contract on a cloud and save the hash on the blockchain?

This question feels confused - a 'smart contract' generally refers to some code that will execute, without trust in a third party. If you must depend on some server to store and execute the code, it isn't really what would be called a 'smart contract'.

Does this have any disadvantage? Will the transactions still be recorded as sa(f)e as on the blockchain?

Huge disadvantage: users will need to trust a centralized server ('the cloud') in order to interact with the blockchain. This means the system will have the worst of both worlds: a heavy trust requirement, and an inefficient blockchain architecture.


text:
Unable to spend a script path using buidl python lib
I've been struggling to figure out how to spend a particular script path using buidl python lib. Currently I assume the problem lies in how I construct p2tr address or there's a bug (very unlikely) in how the control block is calculated.
The error I'm receiving when broadcasting a spending transaction is: Witness program hash mismatch
You can find my code in the gist or below:
from buidl.hd import HDPrivateKey
from buidl.ecc import PrivateKey
from buidl.taproot import TapLeaf, TapBranch, TapScript
from buidl.script import Script
from buidl.op import *
from buidl.tx import Tx, TxIn, TxOut
from buidl.taproot import ControlBlock
from buidl.witness import Witness
from buidl.script import P2WPKHScriptPubKey, ScriptPubKey, decode_bech32

pvt_key = PrivateKey(12345, network="regtest")
internal_pvtkey = PrivateKey(3333, network="regtest")
internal_pubkey = internal_pvtkey.point

# leaf_a = Script([op_1, op_add, op_2, op_equal])
# leaf_b = Script([op_2, op_add, op_4, op_equal])
# leaf_b = Script([op_1, op_add, op_5, op_equal])
script_a = TapScript([81, 147, 82, 135])
script_b = TapScript([82, 147, 84, 135])
script_c = TapScript([81, 147, 85, 135])

leaf_a = TapLeaf(script_a)
leaf_b = TapLeaf(script_b)
leaf_c = TapLeaf(script_c)

branch_ab = TapBranch(leaf_a, leaf_b)
branch_abc = TapBranch(branch_ab, leaf_c)

address = branch_abc.external_pubkey(internal_pubkey).p2tr_address(network="regtest")
print("Deposit funds to:", address)

# SPEND PATH B
amount = 1_000_000
cb = branch_abc.control_block(internal_pubkey, leaf_b)

tx_in = TxIn(bytes.fromhex("07fdfaf3541c26d5fc18f644f338d8ac4e47f7bcc83c41192741990d150b8d19"), 1)
tx_in.witness.items = [encode_num(2), leaf_b.tap_script.raw_serialize(), cb.serialize()]
tx_ins = [tx_in]
tx_outs = [TxOut(998000, P2TRScriptPubKey(decode_bech32("bcrt1py7e8e0q7pdkxwyp2tjn65k4kd5kgch0aqe03jzjczn96xat6nwjswsu892")[2]))]
tx = Tx(2, tx_ins, tx_outs, network="regtest", segwit=True)
tx.serialize().hex()
# 02000000000101941ea2c9c9236e92e0d94530d0de3694012f0d3902399dc680294ef2e82a0e780100000000ffffffff01301b0f0000000000160014904946363de1f2cb5ce439e5ed038492051b2785030101045293538841c04cecb33a915e2c3b189eb6ee45fa4eb3eddeff09729945c600f893bd4381b294c95c39c9307263577e8ed45b4d6ad91cf6f47f42476e0e40676b1f028be1360600000000
# I always get: `non-mandatory-script-verify-flag (Witness program hash mismatch)`

Please not that I was able to successfully create and spend a p2tr address (using same tapscripts) with bitcointx library, hence why I assume I'm most likely not using the buidl library correctly or am misunderstanding something.

I'm happy to report that I was finally able to construct an address in a way that I was also able to spend a script path!
This is how I constructed an address before:
address = branch_abc.external_pubkey(internal_pubkey).p2tr_address(network="regtest")

This is how I constructed it now:
internal_pubkey = S256Point.parse_xonly(unhexlify("f006a18d5653c4edf5391ff23a61f03ff83d237e880ee61187fa9f379a028e0a"))
internal_pubkey.p2tr_address(branch_abc.hash(), network="regtest")


text:
why is the number of confirmations rising yet i haven't been credited with the bitcoins?
I have been waiting to receive bitcoins for close to 7 hours now. The number of confirmations is currently 111, so why is it so? here is the transaction batch 95d5dcb612446d67e38ef9246fdcd20a5f500766431321ba9ff7280567d01e59

Are you using a bitcoin wallet or have an account with some website? If it is the later then you have to contact them since they control your funds.

i have a bitcoin wallet by localbitcoin> however the payment is from an investment company known as unity forex club

so who among the two has the funds?

@orwasa I think you have this address 1B84x6LM8ZC6QEu2LbGQy8XEva5jEuH9CX or rather this have at the moment the only  don't have spend the bitcoin inside your transaction hash

@orwasa as long as you don't have any access to any private keys you do not have a wallet, you have an account and no control. Contact the website owners (localbitcoin in this case) and ask them why your account is not credited.

@vincenzopalazzo that address is not the receiving wallet and i dont have access to it

@coding Enthusiast i have contacted both of them , localbitcoins is yet to reply, uh-mmh i wonder, according to that batch number, has the funds really been released?

TL;DR: when you interact with a custodial service (ie you don't own the privkeys), it is entirely up to that service to 'credit your account' appropriately.
There are many types of Bitcoin wallets, but on a fundamental level we can draw a line between two types of wallets: those that give you access to your private keys (non-custodial), and those that do not give you access to your private keys (custodial).
If you send funds to a non-custodial wallet, you will retain the ability to do whatever you please with those funds, because you own the private keys (which are what allow the software to create valid transactions). Even if the wallet software you use ends up being broken, you can always just import the keys to some different wallet to recover your funds (assuming the wallets being used follow the industry standards of BIP 32/39/44/84 etc).
If you send funds to a non-custodial wallet, there will generally be a waiting period between the transaction confirming on-chain, and the service you sent funds to 'crediting your account'. The length of this waiting period is entirely up to to the service, but generally it will be several confirmations on-chain (meaning, you have to wait for a few blocks after the one your transaction confirmed in). This waiting period is a safety mechanism for the service: it helps ensure they are protected in the case of a chain re-org that could potentially erase recent deposit transactions from their customers.

So with all that in mind, if you are waiting for your custodial account to be credited, the most you can do is contact the service in question to see what the status of your account is. Since they own the private keys for the address you deposited to, they are the only ones that can now spend the coins you sent to them.
Remember: you must fully trust a custodial service to credit your account properly. When you choose to interact with any custodial service, it is prudent to consider what recourse you will have in the case they do not properly credit your account. Are they a legitimate business located in a jurisdiction that will hold them accountable to theft or other abuses? Or are they a service run by anonymous individuals, against whom you will have no possibility of recourse?


text:
Is there a limit on the size of the block header?
I know that the current bitcoin block size limit is about 1,000,000 bytes (1 megabyte) of data. This includes both the block header as well as the transaction data.
On the other hand, the typical size of a block header is 80 bytes, or 128 bytes if padding is included (as depicted below):

Now, I have been completely unable to find any information as to whether there is a limit on the size of the block header. The block header is typically 80 bytes, but is it against protocol if a miner adds so much data that the size of the block header increases to about 192 bytes or 256 bytes?
For example, a goofy miner (for some pointless reason) adds a lot of irrelevant information after the nonce section, and the block header size increases to 256 bytes. Would this block header be considered valid?

The only valid header is 80 bytes, no more, no less.
The other stated length of 128 bytes is part of the internal SHA256 hashing algorithm (its input must be a fixed multiple of 64 bytes), it's not represented anywhere in this format. Likewise, the null padding added when hashing the header is not ever considered to be part of it.

Is it possible to store data in the padding, or is the form of the padding fixed?

The padding in your diagram is imaginary, it’s not part of the block header. In SHA256 compression it is mostly null padded in a predictable manor.


text:
Why don't bitcoin miners use the padding as extra-nonce?
The bitcoin block header is 80 bytes, but the SHA-256 input is required to be a multiple of 64 bytes; as a result, the block header needs 48 bytes of additional padding.
Therefore, why doesn't the miner use the 48 bytes of padding as extra-nonce? Instead of changing the timestamp and Merkle root, why don't miners opt to change the padding instead?

Possible dup, by the same author. https://bitcoin.stackexchange.com/questions/93814/is-there-a-limit-on-the-size-of-the-block-header/93818#93818

Changing the padding would result in a completely different digest. Other validating clients do not have access to this "extra nonce" in the padding to validate it, and modifying their clients to implement it would be a hard-fork of the protocol.
The extra-nonce as implemented currently, placed inside the input of the coinbase transaction, was a backward-compatible change which utilized an unused area of the block to place random information. Existing validating clients would still validate the block as valid because the normal process of calculating the merkle root for the block was unchanged.

so when I submit a block to the network for the validation, the padding after the block header is not included?

Correct. The block header is serialized as 80 bytes, and the transactions immediately follow (prefixed by the transaction count as a CompactSize). The padding is internal to the SHA256 function. A bitcoin developer should not need to concern themselves with it unless they are writing an optimized SHA256.

You seem to have confused history here a bit. extraNonce was part of even the first Bitcoin release. https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L2190


text:
RSA accumulator vs Merkle Proofs
For proof of inclusion (used by SPV nodes) Bitcoin relies on Merkle proofs.
Why Merkle trees were chosen and not RSA accumulators, as they can be used to provide a shorter proof?
What are the advantages/disadvantages of RSA accumulators vs. Merkle proof?

RSA accumulators are far harder to implement correctly
RSA accumulators need a trusted setup (someone, or multiple someones, must come up with a sufficiently large integer that is the product of 2 primes, and then throw those individual primes away). Bitcoin is generally designed to avoid trusted parties.
For a 128-bit security level, you need at least 3000 bits RSA moduli, meaning that a proof would be 3000 bits. That's only a win compared to Merkle paths for trees with more than 12 levels, which in the case of transactions in blocks, means over 4096 transaction. That isn't usually the case, and even when it is, it is only barely so.

how about now? Now there are quite a lot improvements in the applications of RSA accumulators in ZK: https://eprint.iacr.org/2024/395.pdf, https://eprint.iacr.org/2021/1672.pdf, https://eprint.iacr.org/2021/1672. Should RSA accumulators be considered?


text:
How to parse transaction script to address the correct way?
i am currently parsing blockchain transaction data from the raw hex blk00000.dat files downloaded by Bitcoin core. In order to validate, i compare my results with blockchain.info from time to time.
While the major part of my parsing is already correct, i came accross a problem with the conversion of the output script to the corresponding address.
Many of the addresses are already correctly parsed, as well, however there are some exceptions where the results are not the same as listed on blockchain.info. In my mind, it seems to be a problem with the transaction type. Apparently, for a transaction different from P2PKH, the output script will look differently, such that i cannot run the script through the same function that converts to the address all the time.
I think to have figured out that the public keys in P2PKH-transactions scripts begin with 76 all the time, is that enough to determine the type as P2PKH?
Furthermore, i came across some few transactions that begin with 4104 and end with ac. For those ones, I have to use a different function to convert to the address, then it works.
Lastly, i wanted to ask, what other transaction types i could come across? I need to parse every transaction script to an address 100% correctly, thus i need to cover all possible cases.
When searching on the web for pre-written code, i found many partly useful, but also false or maybe old snippets.
What i am searching for is a general function that i can parse the output script (or the complete raw transaction string) to and that delivers the output addresses and values of BTC / Satoshi sent to these.
Of course, if you can recommend an overall python parser for the rawtx hex strings from the .dat-files, i would be also glad :)
The main info i need for each transaction:
- the hash of the corresponding block
- transaction time (block time)
- number of inputs and outputs
- inputs [(block index (vout), txid), (...)]
- outputs [(value, address), (...)]
- the overall transaction hash
Thank you.

I think to have figured out that the public keys in P2PKH-transactions scripts begin with 76 all the time, is that enough to determine the type as P2PKH?

No. The 0x76 is the number of the first opcode, OP_DUP. A full P2PKH transaction has the template OP_DUP OP_HASH160 0x14 <pkh> OP_EQUALVERIFY OP_CHECKSIG.

Lastly, i wanted to ask, what other transaction types i could come across? I need to parse every transaction script to an address 100% correctly, thus i need to cover all possible cases.

Scripts can contain anything and there's not necessarily an address for them. Addresses represent specific data in standard transactions, of which there are only a few different types.

P2PKH (as above)
P2SH (OP_HASH160, 0x14 followed by the 20-byte hash of the redeem script and OP_EQUAL)
P2WPKH (witness version 0x00 followed by PKH)
P2WSH (witness version 0x00 followed by script hash)
P2MultiSig (OP_N, <pubKey1>..<pubKeyN> OP_M OP_CHECKMULTISIG where N <= 3)
OP_RETURN <data>

The first two, P2PKH and P2SH use base58 addresses beginning with 1 and 3 respectively on mainnet.
P2WPKH and P2WSH use bech32 addresses beginning with bc1 on mainnet. You can determine the difference based on their length. Witness versions > 0 are also standard, but have no known meaning - this is intended for future extensibility.
OP_RETURN and P2MS don't have standard addresses. Nor do any non-standard transactions which do not fit any of the above conventions. Addresses are intended for human readability and parsing, so that software can simply recognize what kind of output is used, and how to create the relevant scriptSig to spend them.
Standard transactions are only a policy in software used to determine which kinds of unconfirmed transactions can be accepted into the mempool. Transactions confirmed in blocks can ignore these standardness rules and contain arbitrary scripts, as long as they evaluate to true.
The full details for parsing the standard script types are defined in standard.cpp in Bitcoin Core.

P2SH transactions are HASH160 of the redeemScript so should be 20 bytes. Also they begin with OP_HASH160 0x14 <redeem_script> OP_EQUAL

There is also P2PK scripts (comp/uncomp pubkey + OP_CheckSig) which are standard and has no human readable form aka address.

Lastly, i wanted to ask, what other transaction types i could come across? I need to parse every transaction script to an address 100% correctly, thus i need to cover all possible cases.

This is not possible, as not all transaction scripts correspond to an address.
Addresses are a human convenience feature, and only cover the following formats:

p2pkh
p2sh
p2wsh
p2wpkh

Anything else is non-standard, and cannot be encoded as an address. The most common such output you would find would be p2pk (I believe), which predates the original p2pkh address system. However, many explorers display it as a p2pkh address, even though that is incorrect.
When dealing with scripts, you would need to deal with the op codes. For example, 0x76 is OP_DUP, while 0xac is OP_CHECKSIG. Addresses translate to a specific set of op codes, and the address data is embedded in it.
For example, a p2pkh address contains a 20 byte payload in the base58 address. This corresponds to the payload to be embedded into the p2pkh script OP_DUP OP_HASH160 <20 byte Public KeyHash> OP_EQUAL OP_CHECKSIG.
Similarly, a p2sh address contains a 20 byte payload. However, since the address encoding is different, wallets know to embed it into a p2sh script of OP_HASH160 [20-byte-hash-value] OP_EQUAL.
You will only be able to convert the known script formats into an address.


text:
Who store seed phrases data
Seed phrases seem to be pretty secure, approximately as strong as bitcoin private key according to this site https://en.bitcoin.it/wiki/Seed_phrase.
But who store the private key adresses of these seed phrases, I suppose it is the wallet software provider, so each one of these provider have to save this data somewhere, and what prevent them from storing it in clear text and just acting like it didnt know our private key.

The private keys are not stored, they are deterministically generated from the seed data.
The seed encodes up to 256 bits of random entropy in a human readable form with a checksum attached to it. These details are outlined in BIP39
This entropy is then passed through the PBKDF2 hash function in order to produce a master private key and a chaining key, which are both used to generate further private keys with HKDF-SHA512. These details are outlined in BIP32 - Hierarchical Deterministic Wallets.
When you input your seed phrase into some software which supports these two BIPs, the software will cache the private keys it generates locally, as recreating them each time the software is run would be expensive and inefficient.

who store the private key adresses of these seed phrases,

The private-keys are generated from the seed-phrase by a mathematical function. There is no need to store a list of seed-phrases and corresponding private-keys.

I suppose it is the wallet software provider

No, you should be the only person to know or store your seed-phrase. Ideally it should not be stored on a computer of any sort. Best practise is probably something like punch it onto metal plates - you can buy letter punch kits to help with this. Ideally you'd provide a few trusted relatives with overlapping subsets so that any two of them working together can retrieve your legacy if an airplane lands on you in five seconds from now.


text:
Unable to bind any endpoint for RPC server
I recently updated my bitcoin docker image to bitcoing v0.18.0 version and can't allow external rpc connections to it now. It binds to localhost if I set rpcallowip=X.X.X.X, then I tried to used rpcbind parameter also, but couldn't set my docker container to allow external rpc connetions.
This is what I get:
bitcoin_1       | 2019-05-23T13:39:34Z Bitcoin Core version v0.18.0 (release build)
bitcoin_1       | 2019-05-23T13:39:34Z Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
bitcoin_1       | 2019-05-23T13:39:34Z Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
bitcoin_1       | 2019-05-23T13:39:34Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
bitcoin_1       | 2019-05-23T13:39:34Z Using RdSeed as additional entropy source
bitcoin_1       | 2019-05-23T13:39:34Z Using RdRand as an additional entropy source
bitcoin_1       | 2019-05-23T13:39:34Z Default data directory /root/.bitcoin
bitcoin_1       | 2019-05-23T13:39:34Z Using data directory /home/BTC
bitcoin_1       | 2019-05-23T13:39:34Z Config file: /home/BTC/bitcoin.conf
bitcoin_1       | 2019-05-23T13:39:34Z Using at most 125 automatic connections (1048576 file descriptors available)
bitcoin_1       | 2019-05-23T13:39:34Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
bitcoin_1       | 2019-05-23T13:39:34Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
bitcoin_1       | 2019-05-23T13:39:34Z Using 0 threads for script verification
bitcoin_1       | 2019-05-23T13:39:34Z Binding RPC on address X.X.X.X port XXXX failed.
bitcoin_1       | 2019-05-23T13:39:34Z Unable to bind any endpoint for RPC server
bitcoin_1       | 2019-05-23T13:39:34Z Error: Unable to start HTTP server. See debug log for details.
bitcoin_1       | Error: Unable to start HTTP server. See debug log for details.
bitcoin_1       | 2019-05-23T13:39:34Z Shutdown: In progress...
bitcoin_1       | 2019-05-23T13:39:34Z scheduler thread start
bitcoin_1       | 2019-05-23T13:39:34Z scheduler thread interrupt
bitcoin_1       | 2019-05-23T13:39:34Z Shutdown: done

My bitcoin.conf file looks like this:
server=1
rpcbind=X.X.X.X
rpcallowip=0.0.0.0/0
rpcport=XXXX
port=XXXX
rpcuser=user
rpcpassword=password

Here's how you fix the rpcbind issue with the latest change in version 0.18.0.
Before 0.18,  if you put rpcallowip=0.0.0.0/0, the value of rpcbind didn't need to be set as it defaulted to all interfaces.
Now that is no longer the case.  Here's my setup, for running bitcoind in a container through Docker compose:
rpcallowip=0.0.0.0/0
rpcbind=127.0.0.1
# local DNS name (container name used in my Docker Compose file)
rpcbind=bitcoind

The first rpcbind is so I can make RPC calls from inside the container.  The second is so other containers can reach the bitcoind container.
I think this does what you want:

I can RPC from inside the bitcoind container
I can RPC from another container on the same network (as specified in the compose file) to the bitcoind container
I can RPC from my localhost outside the container.

For the last, I exposed port 8332 to my localhost in the compose file and I can curl to the container:
$ curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbestblockhash", "params": [] }'  -H 'content-type: text/plain;' 127.0.0.1:8332/
Enter host password for user 'user':
{"result":"0000000000000000000ece9381a7e0a4020353f4adde7b560a6b2840d5d44cfa","error":null,"id":"curltest"}

The full details of my container setup are here, in case there's something I missed in writing up my answer.

Where to write all this?

If you take a look of the release note, you will find that:

The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).

You said in comment

because I need to control my node remotely

I'm afraid for any version >= 18 this would not be doable but rightfully given rpc connection are no encrypted which mean plain-text login/password that's why it is not recommended/possible anymore see. Using one of both interface remotely RPC or REST looks like not recommended so you could still do it but has to know it is insecure.
My guess is that rpcbind should be an internal IP on the computer running bitcoin core and you should route external RPC call from the router of your internal network to the rpcbind's one.

So basically you cannot allow external ip to accept rpc calls? You can accept only local rpc calls? But is there any workaround, because I need to control my node remotely.

@IgorisSkinderis update my answer


text:
Can we determine which one of the referenced outputs corresponds to a cashback transaction in BTC transaction scripts?
let me quickly elaborate the question. The structure of a BTC transaction script looks somewhat like the following example
"01000000018190374a5a1feb54fab4417fac1a3d9185de06fd8dcac34822c7cd00083638b1000000006a4730440220237ef9d9a3908f163ee37cc65de642ba1d45e399cde840285cd1658292ee71f902201a2fa3959cf19e64308d64a052526b755e22f2efb941675bc35684de1d90e7dd012103c13dca192f1ba64265d8efca97d43b822ff24db357c13b0e6e0395cf91e9efaeffffffff0248ac0b00000000001976a9140964c6feb963ade6836e722670abbc0147ca5cec88ac08100b00000000001976a914977ae6e32349b99b72196cb62b5ef37329ed81b488ac00000000"
... where the part
"48ac0b00000000001976a9140964c6feb963ade6836e722670abbc0147ca5cec88ac08100b00000000001976a914977ae6e32349b99b72196cb62b5ef37329ed81b488ac"
... specifies the two output addresses that the money from the UTXO(s) is split and sent to.
Often, as the sum of one or several UTXO's does not perfectly equal the amount that the sender wants to transfer, as last (?) output address he references his own address, in order to receive back his remaining cash.
My question is, is it somehow ONLY from the transaction script structure as above determinable which of the referenced output addresses correspond to the(se) "cashback address(es)"?
I have a few thoughts on this myself:
Of course, the sender might have several addresses / accounts, anyways, then, we have no chance at figuring out whether he is sending money back to himself or not.
Furthermore, I suspect the answer to my question is no, as otherwise, it could be possible to identify one input address of the regarded transaction as the output address that corresponds to the cashback part. This, I guess is exactly intended not to happen, as we want to keep the anonymity of the sender.
Lastly, I am aware that it is possible to identify cashback transactions when you look at the entire history of the blockchain and keep track of which address "holds" what amount of BTC / UTXO's right now. However, in order to do so, you would need to store all the addresses named in previous transactions throughout time, which is quite computationally costly, as you proceed through time in the blockchain.
Thus, I am asking for a way to quickly identify such cashback transactions. (We can for instance always easily identify the coinbase transaction in a block from the structure of the code.)
That's about it. I am looking forward to your comments, hopefully someone can shed light on this :)
Thanks!
Best,
Jen

First, the common lingo for these "cashback transactions" is "change outputs", and "chain analysis" is a thing whole businesses have sprung up around. There are a few indicators that allow making educated guesses on which outputs may be change, e.g.

round numbers (e.g. three outputs with round amounts and one not)
wallet fingerprinting (e.g. all inputs are multisig, only one output is multisig)
address reuse (some wallets send change back to an address previously used by the wallet)
unnecessary input heuristic
probabilistic graph search
…

The Bitcoin wiki has a whole section in its article on privacy describing approaches for change address detection.

thank you for the quick answer and the info. So it seems we can only infer with uncertainty from the "properties" of the transaction which ones are the change outputs, given we look only at the transaction itself. Thank you for this. Best, Jen

Yeah, that's right. I see that you're a new user, welcome to the site! I've converted your answer to a comment since you appeared to be replying to my answer rather than actually answering the question. Things work a little different from a forum here, may I invite you to take a glance at our site's [tour]?


text:
bitcoin core test config error
I tried configuring the bitcoin core test by editing the bitcoin.conf file with the required credentials.
Earlier, before the writing the test credentials it was a running full node.
now the error is
config settings for rpcport only applied on the test network when in [test] section.
(picture uploaded for reference)

Since you are choosing to use network specific sections in your config file, Core requires you to have certain arguments in those sections, such as rpcport. So you need to move rpcport into a network specific section.

for every UTX token ( bitcoind and the beyond ) for mode test net ("testnet=1")
default port will be used and you can't change it because by default .

Default Bitcoin network protocol listen port is 18333 (instead of 8333)
  Default RPC connection port is 18332 (instead of 8332)


text:
Is it possible to mine using Asics on AWS?
As title says, I would like to know if mining with asics on aws is possible and how to do it? I don't mean profit because I don't really care and only do it for fun. Thanks!

AWS does not offer any ASICs, so no.
ASICs are special machines, with specialized hardware. You would need to physically buy one to use it. Anyone offering any form of cloud mining is trying to scam you.

Same for FPGA ?

There are some hosted FPGA options, but nothing that would be able to complete with an ASIC - mining would be a pointless waste of money

Well, if you have some ressources on it I will gladly take it even if it's a waste of money :)


text:
How do I build a webwallet soultion for BTC to allow subscribed users deposit their funds, allow to withdraw whenever required by the user?
I am new to bitcoin development. I am going through documentation and researching to build below in the webwallet solution

Create a HD Wallet which can assign addresses to subscribed users.
BackUp / Restore HD wallet on a different machine for managing any risks.
Allow user to withdraw funds as needed by processing a Withdrawal transaction if the user is sufficient funds in his account.

Could you provide a broader context? What is the target use case? There is hundreds of web wallets on the market, including some open source solutions.

Exploring to develop some functionality in an existing solution where Crypto can be used as mode of payment by consumers for exchange for services or exchange it for FIAT.

I would be interested in knowing existing open source solutions, it would be great if you could point me to any. Thanks


text:
i received BTC on testnet and the sender said that it is de-activated..it will be activated after I pay a certain fee?
a trader sent me  2 bitcoins on testnet to show that i will receive more after they activate it...I have to pay a certain fee before they activate it

a trader sent me 2 bitcoins on testnet

testnet Bitcoins are worth nothing.

I have to pay a certain fee before they activate it

You are communicating with a criminal confidence trickster who is only pretending to be a trader.

Testnet is a completely separate network, there is no way to ‘activate’ or otherwise move coins between the bitcoin testnet and bitcoin network. Testnet coins are worthless by definition, that is why they are useful to developers who want to test their code without risking funds.
As @redgrittybrick mentioned, you are dealing with a scammer. Do not send them money.


text:
Is is possible to get routing detail of a payment in c-lightning?
I want to know how my payment was routed, how many hops, nodes and fees etc. So I can prepare my channels better. I see in the listpays, it contains info like bolt11, destination, payment_hash, but lacks of details.

Older version of c-lightning used to output the routes in the sendpay command that was used by pay if you look in your log-file you would find something like sendpay via route: us -> which then included information about all the hops, channels, forwarded amounts and cltv_deltas.
Since the new pay plugin it seems indeed that they have changed the log file entries. I have just tried to make a payment and extracted the following from my log file
INFO    plugin-pay: cmd 103109 partid 1: failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)
INFO    plugin-pay: cmd 103109 partid 2: failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)

around those lines you will actually find more precise information which channels failed which is consistent with their code base at https://github.com/ElementsProject/lightning/blob/75720ad0e1690052c108fbf457ded807bf09d6c1/lightningd/pay.c#L620 says that pay will produce the following log entry:
            log_info(hout->key.channel->log,
                 "htlc %"PRIu64" "
                 "failed from %ith node "
                 "with code 0x%04x (%s)",
                 hout->key.id,
                 origin_index,
                 failcode, onion_wire_name(failcode));

However I did not see the exact information in my log file indicating along which routs the payments where attempted with what amounts making the above mentioned log entry less useful. So unless I am completely mistaking I am surprised to write that it seems as if the requested information only exists out of the box in older versions of c-lightning.


text:
Does Bitcoin-core support creating a new Bitcoin blockchain?
My goal is to add a new feature to Bitcoin, which requires changing the structure of the Bitcoin blockchain. So I was wondering if Bitcoin Core supports having a new/own Blockchain? If so, how to do it? Right now, I manage to run bitcoind but it seems to sync from the existing Bitcoin blockchain.

What do you mean by "changing the structure of the bitcoin blockchain"? It isn't really clear what you're asking here.

Sorry for the unclear question as we are not exactly sure what kind of change we are going to make yet. However, we will do it for a research purpose. Roughly speaking, we are interested in exploring security of Bitcoin in a different direction, which may require adding a new field in the block header or modify/add the hash/signature algorithms.

Bitcoin Core supports creating a custom signet and mining utility for setting up a public test network with alternative functionality. This is not meant to be used to create an altcoin with actual or perceived monetary value as I (and many others) would recommend using a sidechain rather than attempting to start a new currency.

Right now, I manage to run bitcoind but it seems to sync from the existing Bitcoin blockchain.

Yes running bitcoind is for mainnet and bitcoind -testnet and bitcoind -signet are for testnet and the default signet (not custom signets).

Thanks for the answer. We will not be creating an altcoin but will mainly do it for PoC/research purposes. For instance, if we would like to modify how transaction verification works in Bitcoin, would you recommend doing it on a custom signet or a sidechain?

A sidechain would be for locking up actual Bitcoin (with real monetary value) on mainnet. So if you want to experiment with coins with no monetary value I'd use a custom signet. You should really test what you want to do on signet/testnet before moving to mainnet regardless.


text:
What work is needed to close a block from 2013
Please could you tell me what work is needed to close a block?,also is it possible to to do this while not fully synced?could you also tell me what information would you have to have access the initial coinbase reward in a block

What is "closing" a block?

Was this development done on the testnet? If the network protocol port was 18333 (instead of 8333) then it was the testnet.

sorry Pieter i think it was definatly wrong word lol, proof or work needed to get block reward ,also was not testnet, it was main, basicly i am trying to find the information for the mining,and rewarded coins for being involved in a few ideas and different suggestions back in the days just before and after the realease of bitcoin, also was asked to keep my computer running when possible to help build bitcoin from its core, i was intrested in the idea of digital money, so to get a email from a select list i was over the moon, so done what was asked of as it was all based on being anonymous and


text:
Could this be my bitcoin?
strong textUsers
Type:
File folder
C:\Windows.old
Location:
Size:
4.33 GB (4.651,209,081 bytes)
Size on disk:
4.34 GB (4,664,881,152 bytes)
Contains:
8,350 Files, 904 Folders
Created:
14 July 2009, 04:20:08
Attribute

Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.

A Windows.old folder is created when you upgrade from one version of the Microsoft Windows operating system to a later version.
Normally, it isn't anything to do with Bitcoin.

Normally yes,but I'm looking for the bitcoin I mined back in 2009 could this be something? There lot of files/folders

Try searching for a wallet.dat file


text:
Obtaining private key from mnemonic keywords
A customer of us can't remember which wallet he has used before (in 2014), but he still knows his public wallet address and als the 12 words for recovery.
We have a choice of 3 different wallets which he might have used (at least on of those must be the right one)

Bitwallet for IOS (still available but not devooped / maintained anymore0 We manage to retostore this app from a icloud backup but id holds another wallet)
blockchain.info (we tried to import using the 12 words, but we got also another wallter address than the one which holds the 0.9 BTC)
Multibit for Windows (Als tried to import using the words, but we don;t have any backup files so  we've let it generate but also it created another walletadress)

What we really know is the correct walletadress and also the 12 words. Is this enough to recover the private key / funds?
Hope someone can help us out.
Regards, Mark

What we really know is the correct walletadress and also the 12 words. Is this enough to recover the private key / funds?

As you have found, with HD wallets, you also need to know the "derivation path"  -- which usually means knowing the software or service used and sometimes the version. You can find commonly used derivation paths using a web search.
You may also need to adjust the address gap limit so that the HD wallet can discover all addresses with funds. This may require a rescan.

Used https://iancoleman.io/bip39/ Enter your 12 / 24 Seeds Select Address and you can see address and privatekey there


text:
How to get the private keys out of old wallet.dat without syncing blockchain
I have old wallet.dat files of Bitcoin, Litecoin, Bitcoin Cash, Omnicore. My Bitcoin Cash wallet.dat has unbroadcasted transactions inside, so I am afraid that others might also have unbroadcasted transactions.
So, currently nodes are not running and I want to dump private keys of those wallets and import into new wallets in a way so that old unbroadcasted transactions are not sent.
What would be the best way to get private keys without loosing funds and without syncing blockchain (don't want to sync because of a risk that transactions will be broadcasted to the network)?
Thanks!

From bitcoin-qt, click Help->Debug and open the Console tab. Type in dumpwallet <outputFileName>, making sure that of course, the output filename isn't wallet.dat or it may overwrite your wallet.
This command creates a plain text version of your wallet with all private/public key pairs in WIF format.
You may need to configure your clients to point to the correct directory containing your wallet.dat with the -datadir command line option, or if you have a custom config file use -conf.
You can also use the dumpwallet command with bitcoin-cli if you have a bitcoind running.


text:
How to import address to a wallet which runs in pruned mode
I am running Bitcoin Cash node with prune=99000 mode enabled. So, I tried to import addresses of BCH from another BCH wallet by using importprivkey method and I am getting an error: Rescan is disabled in pruned mode.
How could I import addresses in prune mode from another wallet?
Thanks!

To import the private key, the wallet must rescan the blockchain and I think with the prune setting the import key not work because you haven't a copy of the blockchain in your local machine.

@vincenzopalazzo thanks for the answer. Could I user reindex maybe on prune mode?

What does it mean, reindex the user? ps: I don't know how work the BCH but if is work how bitcoin, it not contains the user

@vincenzopalazzo I am sorry there was a lint, I meant "Could I use reindex maybe on prune mode?"

Form bitcoin-abc I have found this
# Enable pruning to reduce storage requirements by deleting old blocks.
# This mode is incompatible with -txindex and -rescan.
# 0 = default (no pruning).
# 1 = allows manual pruning via RPC.
# >=550 = target to stay under in MiB.
#prune=550

So, the command import address should call the -rescan (in Bitcoin core yes), for reconstruct the story of the private key.
So from the moment of your error message, I believe the correct answer is.
No you cannot import a private key in prune mode

good to know after wasting almost a week for downloading and pruning the whole blockchain


text:
Keypath spending: Verify destination address across address formats
In a Tapscript Keypath Transaction (there is an unrelated Scriptpath too) I can have outputs to all possible address?
(I.e. to P2PKH, P2SH, P2WPKH / P2WSH and P2TR)
I have a list of addresses in all possible formats (including bech32(m)). How can I ensure / verify that the scriptPubKey is mappable to an address in this list?
The signing client has access to every part of transaction's construction.

I don't understand what you're trying to do.

Based off the taproot-workshop on Github I constructed this Transaction: CTransaction(nVersion=1 vin=[CTxIn(prevout=COutPoint(hash=d66a46336b05c3f1550fd0983db887f4244570c06538cb05f68afed99d84ea71 n=0) scriptSig= nSequence=0)] vout=[CTxOut(nValue=0.49999000 scriptPubKey=0014a9d0682aaa00c327dbb3fd32c9dedcfcfbec1a69)] wit=CTxWitness() nLockTime=0) I want scriptPubKey to be matchable against wallet addresses in various formats

Solved with this answer and by looking how bitcoin core does it:
https://bitcoin.stackexchange.com/a/89010/123917


text:
Taproot PTLC: Non-Multisig partly timelocked spending conditions
(Taproot environment) What I came up with is the following logic:
$alice = A;
$bob = B;

pk($bob) || (pk($alice) && older(10))

(See on Minsc).
I looked at the generated / resulting Bitcoin Script, which worked in Regtest.
What I was not able to reproduce / verify are the following question:

Could Bob batch spend UTXOs across contracts with different partners (partners like Alice, in this case) in a single transaction?

Basically Bob creates an address based off the conditions above and James or multiple Payers send their UTXOs to the Tapscript contract.
Bob now wants to spend the received coins, but to reduce fees, he wants to batch spending. So a typical transaction would contain several UXTOs from several different tapscripts. The outputs are 3rd party addresses - including Alice's.
In case Bob is not able to do those transactions, Alice should be able to claim the UXTOs remaining after 10 blocks.

Is this reproducable in Mainnet once Taproot is activated? Am I missing something?

Hi Nerrix, while the construction you describe seems feasible, it's not clear to me what you're trying to achieve.

@Murch Bob has just a normal wallet, except that Alice can spend the held UTXOs after 10 blocks. Simply speaking.

Yeah, but why would you want to do that?

@Murch I can't go into much details here but this fallback to Alice after 10 blocks is needed for circumstances outside the world of Bitcoin ;) I am very certain about the setup named tho.

Yes, assuming James sends Bob two outputs with the following spending conditions:

pk($bob) || (pk($alice) && older(10))
pk($bob) || (pk($carol) && older(10))

Bob can spend these UTXOs together in one transaction by unilaterally satisfying the first spending conditions just with his signatures. Once either of the two UTXOs has ten confirmations, either Alice or Carol respectively also gain the ability to spend said UTXO unilaterally.
If Bob's transaction tx_B has not been confirmed at that blockheight, e.g. Alice could create a conflicting transaction tx_A only using the UTXO she controls as an input and send the funds to one of her own addresses instead of whatever Bob was trying to pay. Given that Bob's transaction tx_B should be broadly present in the mempools of nodes on the network, Alice's tx_A would be dropped by nodes that already have seen tx_B under the "first-seen-safe" policy and would therefore relay poorly on the network, but Alice could hand tx_A directly to miners.
Alternatively, the relay impediment would not apply, if Bob's tx_B had signaled replaceability, and Alice attached a higher transaction fee to her tx_A in which case it would generally displace Bob's transaction in nodes' mempools.
So, while Alice and Carol would be able to produce competing spending instructions after 10 confirmations, it would not be trivial to reliably enforce that their transactions would be preferred over Bob's transaction.

Awesome answer. Am I understanding this correctly that this is the same as Bob's PubKey would be the Internal Key for Keypath spending and the Tweak to it could contain Alice's PubKey with a 10 block timelock? Actually this would be the way to go I guess?

Yes, you should make Bob's key the internal key for a keypath spend and for Alice's spending condition you could use a tapleaf via a scriptpath spend. I assume the most likely spending condition would be that Bob uses the UTXO, and locktime opcodes cannot be used in a keypath-spend anyway.


text:
Scammed in a investment website
I got scammed and invested crypto (USDT and BTC) in a website called dficoin.co. Once I sent the crypto to the internal wallet I tried to transfer it back but I couldn't. After some days, now the website is down and I don't know if I am able to retrieve the crypto from the wallet. I have the addresses (erc20 and bitcoin) and the hashes. Do you know how could I try?

I am sorry for your loss.
There are a few things you can do. None of them will necessarily get you your money back, but there is a chance. Also, you should keep in mind the cost vs. how much you have to gain.
There are professionals that can help trace the crypto you sent to a known exchange. Once they do that you can often get a court order for the exchange to reveal the owner of the account. The owner of the account may be the actual one who stole from you, or he may know them.
What you will need is

A crypto forensic analyst (disclaimer: I am one) to track your crypto and verify that there is some person using an exchange etc. that can be discovered and approached. Keep in mind that the analyst may find that your crypto was moved through a mixer or some other entity that will make tracing impossible.
If the analyst finds an exchange account or some similar info you will need a lawyer to takes the analyst's findings and get a court order from a judge to reveal the identity of the exchange account owner.
Once you find your guy the story is still not over. You must get him to give back the crypto. This can be easy (usually it isn't) if the thief sent your crypto directly to an exchange that is willing to listen to the court. The exchange will freeze his account until everything is settled.
Usually it is not so simple. The thief probably did not send it directly to the exchange, he might have used someone else who had an account, or at least claims that he is not the thief. In that case...
You will need to either prove that the owner of the exchange account is indeed the thief or get the guy to tell you who he got your crypto from. (again not usually so easy!)
Sometimes things are smoother than you'd expect. Sometimes the owner of the exchange account cannot afford to fight in court so he will just pay you. This is very sad :( beware other innocent people can get hurt in this process.

As far as i know none of the transactions are reversible once sent. Sorry to hear that, but you need to be more careful on the market many scam are going on. My advice for you is if you ever need an app to trade or exchange cryptos, the best apps would be Bybit and Binance.


text:
Running bitcoind regtest with docker containers
I am running bitcoind regtest locally with the method from this article https://medium.com/ssde/how-to-use-docker-to-setup-multiple-bitcoin-test-nodes-on-your-own-mac-phase-i-8c6e5442c189.
However, when I enter "docker-compose build" the error occurred as the following output:
Traceback (most recent call last):

File "urllib3/connectionpool.py", line 670, in urlopen
  File "urllib3/connectionpool.py", line 392, in _make_request
  File "http/client.py", line 1255, in request
  File "http/client.py", line 1301, in _send_request
  File "http/client.py", line 1250, in endheaders
  File "http/client.py", line 1010, in _send_output
  File "http/client.py", line 950, in send
  File "docker/transport/unixconn.py", line 43, in connect
ConnectionRefusedError: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "requests/adapters.py", line 439, in send
  File "urllib3/connectionpool.py", line 726, in urlopen
  File "urllib3/util/retry.py", line 410, in increment
  File "urllib3/packages/six.py", line 734, in reraise
  File "urllib3/connectionpool.py", line 670, in urlopen
  File "urllib3/connectionpool.py", line 392, in _make_request
  File "http/client.py", line 1255, in request
  File "http/client.py", line 1301, in _send_request
  File "http/client.py", line 1250, in endheaders
  File "http/client.py", line 1010, in _send_output
  File "http/client.py", line 950, in send
  File "docker/transport/unixconn.py", line 43, in connect
urllib3.exceptions.ProtocolError: ('Connection aborted.', ConnectionRefusedError(61, 'Connection refused'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "docker/api/client.py", line 214, in _retrieve_server_version
  File "docker/api/daemon.py", line 181, in version
  File "docker/utils/decorators.py", line 46, in inner
  File "docker/api/client.py", line 237, in _get
  File "requests/sessions.py", line 543, in get
  File "requests/sessions.py", line 530, in request
  File "requests/sessions.py", line 643, in send
  File "requests/adapters.py", line 498, in send
requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionRefusedError(61, 'Connection refused'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "docker-compose", line 3, in <module>
  File "compose/cli/main.py", line 81, in main
  File "compose/cli/main.py", line 200, in perform_command
  File "compose/cli/command.py", line 60, in project_from_options
  File "compose/cli/command.py", line 152, in get_project
  File "compose/cli/docker_client.py", line 41, in get_client
  File "compose/cli/docker_client.py", line 170, in docker_client
  File "docker/api/client.py", line 197, in __init__
  File "docker/api/client.py", line 221, in _retrieve_server_version
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', ConnectionRefusedError(61, 'Connection refused'))
[67810] Failed to execute script docker-compose

I am new to bitcoin core so I have no idea what's going on.

The docker desktop is not starting yet. No wander there's failure to the connection.


text:
Bitcoin transaction location
I transferred my Bitcoin from my Exodus desktop wallet to another location. How can I find out, if possible, the exchange I sent it to that has my account? Is there any way to see the transaction code to find out what exchange my BTC is sitting on? Thanks.

Is there any way to see the transaction code to find out what exchange my BTC is sitting on?

You cannot identify an exchange from a transaction-ID.

I am not sure what information you want from the adress you send your bitcoin to but you can see your transaction by using the adress of the bitcoin you send to.
you have to copy the adress you send it to, something like "1CK6KHY6MHgYvmRQ4PAafKYDrg1ejbH1cE" past it on a website like https://blockexplorer.com and then you will have some information for this adress
" Addresses are not wallets nor accounts, and do not carry balances. They only receive funds, and you do not send "from" an address at any time. Various confusing services and software display bitcoins received with an address, minus bitcoins sent in random unrelated transactions as an "address balance", but this number is not meaningful: it does not imply the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received. "
more information here: https://en.bitcoin.it/wiki/Address

I sent it to another account I own. I have no idea what account that is. How to find out if this can be accomplished?

How do you own this another account, is this a wallet, an exchange ? the only thing that make you own an account on bitcoin is the private key, and  How did you find the adress you have to sent the bitcoin to ?


text:
Can someone explains me about Liquid Network
I'm trying to integrate liquid network with my node.js application. Such that i want to create liquid wallet address, send a transaction from 1:1 on liquid network and check balance for that wallet address.
The only useful thing i found was to use bitfnex or other exchanges but they don't allow to create wallet addresses just deposit addresses.
So anyone can guide me regarding this, Do i need my own node for this and how to achieve this.


text:
P2TR Scriptpath failing (Timelocked contract)
Goal is to archive the following logic:
$alice = A;
$bob = B;

pk($bob) || (pk($alice) && older(10))

I went through The Taproot Workshop and came up with the following code:
from io import BytesIO
import random
import util
from test_framework.key import generate_key_pair, generate_bip340_key_pair, generate_schnorr_nonce, ECKey, ECPubKey, SECP256K1_FIELD_SIZE, SECP256K1, SECP256K1_ORDER
from test_framework.musig import aggregate_musig_signatures, aggregate_schnorr_nonces, generate_musig_key, musig_digest, sign_musig
from test_framework.script import TapLeaf, TapTree, TaprootSignatureHash, SIGHASH_ALL_TAPROOT
from test_framework.address import program_to_witness
from test_framework.messages import CTransaction, COutPoint, CTxIn, CTxOut, CTxInWitness
from test_framework.util import assert_equal

my_privkey, my_pubkey = generate_bip340_key_pair()
delay_privkey, delay_pubkey = generate_bip340_key_pair()

tapscript_res = TapLeaf().construct_pk_delay(delay_pubkey, 10)
taptree = TapTree(key=my_pubkey)
taptree.huffman_constructor([(1, tapscript_res)])

taproot_script, tweak, control_map = taptree.construct()
taproot_pubkey = my_pubkey.tweak_add(tweak)
program = taproot_pubkey.get_bytes()
address = program_to_witness(1, program)
print("Segwit Address:", address)

test = util.TestWrapper()
test.setup()
node = test.nodes[0]

tx = node.generate_and_send_coins(address)
node.generate(2)
print("Transaction {}, output 0\nsent to {}\n".format(tx.hash, address))
spending_tx = test.create_spending_transaction(tx.hash, version=2)

print("Spending transaction:\n{}".format(spending_tx))
sighashA = TaprootSignatureHash(spending_tx,
                               [tx.vout[0]],
                               SIGHASH_ALL_TAPROOT,
                               input_index=0,
                               scriptpath=True,
                               script=tapscript_res.script)

signatureA = delay_privkey.sign_schnorr(sighashA)

print("Signature for TapLeafA: {}\n".format(signatureA.hex()))
witness_elements = [signatureA, tapscript_res.script, control_map[tapscript_res.script]]
spending_tx.wit.vtxinwit.append(CTxInWitness(witness_elements))

# Test mempool acceptance
assert not node.test_transaction(spending_tx)
node.generate(21)
assert node.test_transaction(spending_tx)
print("Success!")
test.shutdown()

I tried numerous changes to the spending process, however the output I get is always:
Segwit Address: bcrt1p0jh5l700aqtnxtn97vhf3vqf6w700dzj5h9vahx5aqhrklu8glgqtwgnn0

Client version is /Satoshi:22.99.0(testnode0)/

Balance: 50.00000000

Transaction 78f7017342f86f03af0e27e127ce7578311f967b950f1dc65b9b928653766117, output 0
sent to bcrt1p0jh5l700aqtnxtn97vhf3vqf6w700dzj5h9vahx5aqhrklu8glgqtwgnn0

Spending transaction:
CTransaction(nVersion=2 vin=[CTxIn(prevout=COutPoint(hash=78f7017342f86f03af0e27e127ce7578311f967b950f1dc65b9b928653766117 n=0) scriptSig= nSequence=0)] vout=[CTxOut(nValue=0.50000000 scriptPubKey=001415d2012d191dbad6cf7881b1cad4af4bb72b6a57)] wit=CTxWitness() nLockTime=0)
Signature for TapLeafA: bbad433804dcdc1070894abe58e52fe38ebc87c9b337187aee0d77ca0299e78f6f212131f6bd19dbc3d7655304322b43b99ecadb64c84d3f9fcceebcc25184c6

{'txid': 'b462759670cbca3c6449fa18f0a0a45044317dadd13a58521549fc1e42219c6f', 'wtxid': '17e532c0447fe3cf6ef52b6e23f69d744e745ba7c6ccd5d53689fe3da968aa18', 'allowed': False, 'reject-reason': 'non-mandatory-script-verify-flag (Data push larger than necessary)'}
{'txid': 'b462759670cbca3c6449fa18f0a0a45044317dadd13a58521549fc1e42219c6f', 'wtxid': '17e532c0447fe3cf6ef52b6e23f69d744e745ba7c6ccd5d53689fe3da968aa18', 'allowed': False, 'reject-reason': 'non-mandatory-script-verify-flag (Data push larger than necessary)'}

Depending on how I change the code, the reject-reason varies.
Any ideas what is faulty in my code?
If there is an existing way to approach this using other languages/libraries, I am happy for hints.


text:
Why the txn_count is zero in the block message?
Why I'm receiving always zero in the txn_count field of the block message after calling it with a getdata ? Is this expected ? How can I get the transactions present in a block ?

I solved the problem, I was reading the Nonce from the block as a 64 bit integer like in the version message instead of a 32 bit integer.

great that you answered your own question, so that others can learn from this :-)

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


text:
MultiBit Password Protection - How Secure is it?
I'm new to BitCoin but a friend of mine was recently stung when a bunch of his coins were stolen. Naturally, I'm now very cautious. I've password protected my MultiBit wallet and, to test the security of this, I have copied the .wallet file to another computer and opened in a new installation of MultiBit. However, I was not asked for my password and I can see my transactions in there. Can someone explain what the password does if it doesn't stop you accessing the wallet?
Thanks in advance.
PG9

I don't know about Multibit specifically, but in bitcoin-qt the password does not protect your addressbook and transaction list, only the private keys; and a prompt for password appears when you try to send coins. So without the password people can still see what you've been up to, but cannot steal your coins.
If you want to put the wallet file in a public place you should place an additional level of encryption.

Well, people know what you've been up to anyways, just by watching the block chain.

@PyRulez: People know what your addresses have been up to, but they don't know that they're your addresses.

The password is required to spend the coins.  This is the purpose of the password.
Multibit does not consider it to be a security problem if people who steal your wallet can see the balance.  If you have a problem with that, you should encrypt your wallet with a program such as TrueCrypt.


text:
Public keys for BIP-118 SIGHASH_ANYPREVOUT
I am reading specifications of BIP-118 that introduces the new signing mode SIGHASH_ANYPREVOUT.
In the bip specifications, it is written that the addresses have length 33-bytes or 1-bytes length. In both cases, the public key starts with 0x01. If it has 33-bytes length, then we remove the 0x01 prefix and use the remaining 32 bytes, presumably as a taproot public key.
What I can't understand is actually how we use the 1-byte public key.
In the BIP's specifications, it is said that, in this case, "use the 32-byte taproot internal key, p, as defined in BIP 341". What does it mean? Is this byte transformed to a public key with some key tweak as in taproot? I think that I am missing some logic around. I am a bit new to bitcoin and, usually, BIP proposals are written to be read by people that are already very familiar.

The use of a 0x01 byte public key is discussed later in BIP118:

Because OP_0 leaves an empty vector on the stack it would not satisfy BIP 342's rules for unknown public key types. As such, it is convenient to use one of OP_1..OP_16 or OP_1NEGATE as a way to reference the taproot internal key. To keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.

BIP342 defined unknown public key types here. The public key needs to not be zero to be treated as an undefined public key.

If the public key size is not zero and not 32 bytes, the public key is of an unknown public key type and no actual signature verification is applied. During script execution of signature opcodes they behave exactly as known public key types except that signature validation is considered to be successful.

Unknown public key types allow adding new signature validation rules through softforks. A softfork could add actual signature validation which either passes or makes the script fail and terminate immediately. This way, new SIGHASH modes can be added, as well as NOINPUT-tagged public keys and a public key constant which is replaced by the taproot internal key for signature validation.

The Taproot internal key is the untweaked public key (pre Taproot tweaking).

Is this byte transformed to a public key with some key tweak as in taproot?

No as the citation says it is used to reference the Taproot internal key. The byte isn't transformed into a public key.

I recap a little. So, only to a BIP-118 addresses are allowed to "receive" BTC with anyprevout, through the script path (i.e. number of witness elements >2). The witness script is the second-last element in the witness, and the last is the control block, of which the bytes 1to33 is the untweaked public key. I suppose that this is the public key used to sign some transaction parts (possibly without the script-pubkey of the input, that is presumably the key-step of bip 118) and the signature appears in the witness script.

So, the witness script actually check the signature against the internal pubkey contained in the control block?

Anyway, thank you for your answer, you helped me a lot!

But this is a different issue, should I open another question on stack exchange?

The new signature validation rules would only be checked on a BIP118 public key assuming a soft fork activated BIP118 on the Bitcoin network. Without activating them the new signature validation rules aren't applied and the signature validation is assumed successful. Feel free to open another question, sure.

well you are completely right, BIP-118 is still not active. I was trying to understand how is supposed to work and how a transaction with only output signed would look like.

Sure, post another question

Hi Michael, posted the question.
https://bitcoin.stackexchange.com/questions/114673/qualitative-anatonomy-of-a-transaction-that-uses-anyprevout


text:
Error: Disk space is too low!
I am trying to run bitcoind on a raspberrypi.
I started by starting bitcoind on my laptop,downloading and verifying the blockchain. So far so good, bitcoind works as expected.
Then I set prune=600 in bitcoin.conf, and it pruned as expected.
Then I moved the datafiles to my raspberrypi (the whole /bitcoin directory ).
The SD card has ~7Gb of storage.  3.5Gb was available, including the /bitcoin dir.
There was a pause of some days or weeks, so I lack the blocks in between times.
When I ran bitcoind it gave me the 'Error Disk space is too low' report, and the SD card is full
root@mybox:/home/rshn# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.3G  7.0G     0 100% /

The bitcoind log seems to indicate that it is downloading from the earliest blocks
2021-05-06T08:09:10Z
UpdateTip: new best=000000000000065c0819853ac71bdda8518706b8942f6540079ad079e2dea6e4
height=193539 version=0x00000002 log2_work=68.525890 tx=5868863
date='2012-08-12T12:29:56Z' progress=0.009181 cache=261.0MiB(2279817txo)

The blocks dir indicates that there are about 460Mb of data.
root@mybox:/home/rshn/bitcoin/blocks# ls -l
total 460068
-rw------- 1 rshn rshn 134212156 Apr 30 13:07 blk00002.dat
-rw------- 1 rshn rshn 134205043 Apr 30 13:08 blk00003.dat
-rw------- 1 rshn rshn 134191619 Apr 30 13:10 blk00004.dat
-rw------- 1 rshn rshn  16777216 Apr 30 13:10 blk00005.dat
drwx------ 2 rshn rshn      4096 Apr 30 13:10 index
-rw------- 1 rshn rshn  16271929 Apr 30 13:07 rev00002.dat
-rw------- 1 rshn rshn  16501235 Apr 30 13:08 rev00003.dat
-rw------- 1 rshn rshn  16826540 Apr 30 13:10 rev00004.dat
-rw------- 1 rshn rshn   2097152 Apr 30 13:10 rev00005.dat

How do I run the pruned node in these circs?  Thank you.

The answer was
The bitcoind client/executable was owned by user rshn.
I started the bitcoind client from a terminal as root user.
bitcoind treated the process as a new install because the owner was different.
bitcoind started downloading the full blockchain,
hence I ran out of disk space quite quickly!
TIL  start the bitcoind client logged in as the owner of the executable.

The owner of the binary is irrelevant. Bitcoind will by default use a data directory in the running user's home.


text:
What to do when you genuinely don't understand anything about taxes, yet are apparently expected to pay them for your Bitcoin?
I've just read a massive webpage from Swedish Tax Agency about Bitcoin. I'm not trying to "be cute" here, but I must say that I didn't understand a single thing of it. I understand Swedish perfectly, yet have no clue whatsoever what is being said on that page.
It's this page: https://www.skatteverket.se/privat/skatter/vardepapper/andratillgangar/kryptovalutor.4.15532c7b1442f256bae11b60.html
It doesn't seem to be available in English, so maybe it's not very useful to link to it here.
All I can interpret from the page is that the government violently hates Bitcoin and I'm supposed to hand them all my money because otherwise they (supposedly) will throw me in prison. Ever since I first got into Bitcoin, I have had zero thoughts or intentions of ever giving anyone one single satoshi besides the transaction fees. The concept never even struck me. It felt like one of the main points of Bitcoin to get rid of all that stupid BS.
The rules for when and how and how much to pay, and even in what currency, are so incredibly cryptic and complex as to make me seriously unable to comprehend them.
If I cannot understand the laws/regulations, what am I supposed to do? They talk about all kinds of forms and special cases and apparently expect me to calculate all sorts of things and hand them huge portions of my hard-earned BTC. I already have so little, and now they want to take a massive chunk of that away?
I regret trying to read up on this because now it seems like I can never buy anything (such as a place to live) or even mention that I own any BTC or they'll come with the cops and drag me away to a cell and/or seize all my electronics. Or maybe "just" punish me financially with huge fees or something. Again, they make it extremely unclear, but use a very hostile and arrogant language.
I wish I were exaggerating and that I'm just "acting dumb", but I honestly cannot comprehend the information on that page. It seems to me that it has been deliberately designed to not be understandable, as to make people who read it scared and stay away from Bitcoin entirely. How on Earth can other people comprehend any of this? I'm not legally "mentally challenged".
What should I do? Re-reading the page over and over isn't going to help, just as doing the same never helps me in other contexts. I don't want to get into any trouble, but I also cannot give them any of my Bitcoin, nor pay for any theoretical "gains" that I've supposedly made, using fiat. I have virtually no fiat money at all, and if I'm going to buy a home, I want to do it directly with Bitcoin -- not converting it to fiat. I don't know if that makes a difference.
Apparently, I have the brain capacity to deal with Bitcoin Core, and even automate it with its API, but still feel like a 5-year-old child when seeing those tax rules. Not only is it "boring"; it's utterly nonsensical to me. Again, it feels like they do it in purpose. Nothing is made clear whatsoever.
If it matters: All my Bitcoin were paid either with Localbitcoins in early 2013 (prior to KYC/AML, using local bank transfer), and later Bisq (no KYC/AML, P2P, SEPA bank transfers). I have never used any centralized exchange, but it's not like I've been fully anonymous still.
I'm obviously afraid of sending them a letter and asking about my specific situation, because then they will know that I have coins and probably start pestering me about "unpaid taxes" or something. I seriously never even thought about this until quite recently, today even. To me, Bitcoin was (and is) completely separate from the fiat money system, and thus their taxes cannot apply to this. I was prompted to look into this after seeing somebody mention taxes for Bitcoin in a USA context.

If I cannot understand the laws/regulations, what am I supposed to do?

A fairly widespread legal rule is that ignorance of the law is no defence.
If you don't understand how the law applies to your situation, you are expected to seek help from someone who does.
You can contact your local tax authorities and ask them, or you can pay for advice from a tax-expert such as an accountant.
All this applies to Bitcoin as much as it does to other forms of money and other assets or investments.

I'm obviously afraid of sending them a letter and asking about my specific situation, because then they will know that I have coins and probably start pestering me about "unpaid taxes" or something.

I wouldn't have such concerns. We all like for hospitals, roads and waste-collection  to exist and be organised by government and paid for by all of us with any significant income or with assets. If you prefer, pay a tax expert for advise.