text:
How does block propagation delay not cause accidental forks?
Block propagation delay, it looks like, is about 122 seconds in some cases. If another block is formed before the first block is completed, wouldn't this accidentally create a fork? How would this fork be resolved? Someone's transactions are bound to get lost.
Example:
Let's start with a block A. Say block B was just completed, and is now being propagated.
If, during that delay, someone made a transaction and a new block C was created before block B reached them, wouldn't their blockchain become forked, with A->C and A->B? How does bitcoin prevent accidental forks like this?

The link isn't working.  But if it really did take 122 seconds for blocks to propagate between miners, then yes, you'd expect frequent forks.  However, I don't believe for a moment that this figure is correct.  In fact, major miners set up dedicated low-latency links to one another, precisely to minimize this latency.  I would guess that in practice, the propagation delay between miners is in the tens of milliseconds.

If there were a fork, it'd be resolved in the usual way: in favor of whichever block is pointed to by subsequent blocks. But forks don't result in transactions getting "lost"; any transactions that were left out of the winning block can always be added in a later block, unless a conflicting transaction gets added first.

It's possible that it takes 122 seconds for a block to propagate to some guy in the backwoods who gets Internet via tin cans and a piece of string.  But that guy is not going to be mining to any significant extent, so no forks result from this.

I guess that makes sense at first, but I know that bitcoin has a staggeringly low cap for block size that could potentially drive the time between blocks down to microscopically small numbers, especially considering the ever expanding computational power at our disposal. Wouldn't relying on this seriously bottleneck bitcoin's scalability?

Bitcoin doesn't "rely" on this; the system still works even if such mini-forks occur sometimes.  But it's in the economic best interest of miners to minimize this effect, which is why they invest in these networks.  Note that the (average) time between blocks is fixed by the protocol at 10 minutes, and is essentially unaffected by the block size.

The question of how block size limits affect the scalability of Bitcoin is an entirely separate question from the one you asked, and has been addressed many many times on this site.

How does bitcoin prevent accidental forks like this?

It doesn't. Bitcoin make little effort to prevent forks at a technical level, instead relying on the fact that when a fork does happen, it can be resolved by waiting for additional blocks and picking the chain with the most work.
As Pieter mentioned, the mining mechanism itself prevents long term forks. The act of mining extends one chain beyond the other, reducing the shorter chain to a temporary and now discarded fork.
For miners specifically, they put in a lot of effort to avoid this - mining on even a minor fork is inherently risky, as they could lose their blocks if the other side of the fork wins, thus losing the block rewards.
To reduce this risk, all serious miners join high speed links as Bitcoin Fibre. These are specially designed to minimize propagation delay.
No serious mining operation will be looking at propagation delays of 122 seconds - those would only be happening at nodes run by people with absolutely abysmal peering and internet access. For the vast majority of nodes, blocks are received in a few seconds, and for miners, usually in <1s.

Arguably, mining is the effort to prevent forks - or at least to resolve them. If synchronization of validation wasn't an issue, mining wouldn't be needed.

@PieterWuille Absolutely, perhaps my phrasing could be better, I'll edit the answer

Forks do happen.   As an example, take it to an extreme ... if one section of the internet were out of communication with the rest of the world, a chain fork would certainly happen, as this isolated segment would hear nothing from elsewhere and miners on that segment would validate different blocks than the rest of the network. Only when connectivity were restored would the longest fork be retained as the official, definitive one.
Block propagation delays may cause chain forks, but on the other hand, individual transaction propagation delays will never do this per-se.
When a user sends bitcoins, this transaction is broadcast on the P2P network. Miners hear the transaction and add it to their "mempool", a list of transactions waiting to be validated by being included in a block.
I recall reading that it takes on average no more than 12 seconds for a transaction broadcast to reach all the nodes in the network.
Since, on average, bitcoin blocks are added to the chain every 10 minutes, there is usually plenty of time for transactions to be assembled by miners onto their block: the one they are competing to validate and be added to the chain by consensus of their peers.
The larger concern for users is that they offer a large enough fee for the miners such that they are not elbowed out of the limited block space ( 1 Mb in bitcoin ) by higher-fee paying transactions.
Once a transaction is included in a validated block, which is added to the blockchain by consensus of the majority of miners, barring any longer chain forks, that block will be official and final.
Transactions that were not included in the latest block, (either because the block first filled up with higher fee paying transactions or because they were not "heard" by the miner by the time the miner's block was validated and added to the chain) will still be in the 'mempool', the list of transactions waiting to "get on a block" and will likely by included in the next block validated by the miners.


text:
Stopping bitcoind on mac
One of my kids while learning more about bitcoin started bitcoind on my mac. Now I am unable to stop it. In my activity monitor, it shows a process named "bitcoind". I have stopped that process from the activity monitor various times but that doesn't help. It starts again after some time or in the next boot session. It has been taking a lot of my laptop space (>100gb). I am running low on space and I need to stop it now. This has been happening regularly. As a temporary solution, I used to go to /Users/[name]/Library/Application Support/ and delete the "Bitcoin" folder from there. But that's no proper solution to end it completely. I have tried a bunch of stuff using bitcoin-cli in the terminal. However, I am unable to stop it.
Running
bitcoin-cli stop returns error: couldn't connect to server: unknown (code -1) (make sure server is running and you are connecting to the correct RPC port).
Can someone please tell me what should I do to stop the bitcoind?

If you do ps in the command line do you see a bitcoind process? If you don't there isn't a bitcoind process running. If you do, does it say testnet next to it?

Regardless once you do ps you can get the process PID number and then do kill insert_PID_here replacing insert_PID_here with the PID number of the bitcoind process

bitcoin is unstoppable XD

Check if you have a relevant setting in one of these

Start up app at System Preferences / Users & Groups / Login Items
Config file at ~/Library/Application Support/Bitcoin/
A bitcoind -daemon in ~/.bash_profile

You could run ps aux | grep bitcoind to check where it is executing from and then delete that folder.

You could open up the Terminal and run pkill bitcoind, it should kill it if it is still running.

source: Stack Exchange

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

sort: votes


text:
Import wallet programatically
I am using the https://www.blockchain.com/ wallet API: https://github.com/blockchain/service-my-wallet-v3
I am not very deep into crypto, but is there a way to allow the user to import his existing wallet into my app and add it as an HD wallet into my main wallet ?
I do not see any API endpoint for that, also I cannot find an apporipriate support email for contact with technical support on https://www.blockchain.com/
Whatever I searched for it showed apps for importing my wallet into existing apps, but I want to make this functionality available in my app.

is there a way to allow the user to import his existing wallet into my app

That looks a bit like this API function:
https://www.blockchain.com/api/blockchain_wallet_api says

Create Wallet API

Create blockchain wallets programmatically
The create_wallet method can be used to create a new blockchain.info bitcoin wallet.
URL: http://localhost:3000/api/v2/create
Method: POST or GET

$password The password for the new wallet. Must be at least 10
characters in length.
$api_code An API code with create wallets permission.
$priv A private key to add to the wallet (Wallet import
format preferred). (Optional)
$label A label to set for the first> address in the wallet. Alphanumeric only. (Optional)
$email An email to associate with the new wallet i.e. the email address of the user
you are creating this wallet on behalf of. (Optional)

Please create an API code here including permissions to "Create Wallets".

Your app can read an existing wallet file, extract the private key (or keys) and use this function to create blockchain wallets containing those keys (and hence allowing the spending of all money "in" that existing wallet file)
Maybe there is some feature of this that you find unsuitable - but haven't explained fully why?
It is not unusual for businesses to require a different arrangement with merchants using their services commercially as a back-end. Whether your use might fit into this category is unclear, but a read of the Terms & Conditions for commercial use of their service might clarify this.

Looks like I've overlooked this.
It looks like exactly the thing that I need.
I just an example wallet.dat to try it out, and here comes my next question.
I have a wallet in blockchain.com, how can I get my wallet.dat file to test this out ?

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


text:
I found a folder called: bitcoin-0.3.22 How do I open it?
I would really appreciate if you could explain how do I open a folder called: bitcoin-0.3.22
I am no dev so please be gentle with the instructions :)
I used to buy BTC back in 2011 and I believe I sold them all but now when i found this folder i thought it wouldn't hurt to see what's in it.
Is it even a wallet?
Your help is much appreciated

a folder called: bitcoin-0.3.22

With that name it is probably a folder containing a download of an early version of the Bitcoin software. It may be a kind of compressed file called a ZIP file which Windows Explorer treats as a kind of folder. It may be the results of extracting the contents of a zip file.
Bitcoin version 0.3.22 was released on 5th June 2011
That folder isn't a wallet, there's no money in it.

Any remaining money would be associated with a file named wallet.dat probably in your %APPDATA%\Bitcoin\ folder.  It may have been kept in a different place back ten years ago but that's where it is normally found in current versions.

Thank you RedGrittyBrick, I appreciate your time!


text:
What would stop some major company from blacklisting specific Bitcoins based on the "inputs" used and their "origins"?
I remember news about some exchange actually banning users based on some kind of "reputation score" on the inputs/coin parts they controlled/used, or got Bitcoin sent to them from. So even years and years back, they had this mapped out somehow.
Why can't they do the same today? Aren't they? If not, why? Why do they not take this obvious path to harassing and restricting people to only use Bitcoin in "approved" ways with "approved" people/entities?
Did they stop doing it for some reason? What stops them from doing this and thus locking out tons of people who have "dealt with undesirables"?

See this answer to a different question for an example of what MCCCS has explained below.

Because a transactions with 5 inputs and 5 outputs is possible and it doesn't make sense to ask the question "the output to me comes from which input?"
Simply, transactions are about total input value and total output value and the rest is miner fees. Tracking a coin's origin is not technically possible.


text:
Can an account define conditional tags to blockchain
Let me try to specify my question with an example:
Consider that there are 4 accounts ( AccountA and AccountB and AccountC (Taged as Store) and and AccountD (Taged as Night Club)), and AccountA wants to send let's say $100 to AccountB with a specified condition (i.e. $100 can be spent only at Accounts taged as Store ).
Can i implement above case?
If i can, how?

Not directly.  The Bitcoin protocol doesn't allow you to place restrictions on how a transaction can be spent.  The input script doesn't get to see the output script.
However, the net effect of what you describe would be as follows: after B decides to send the funds, they are in the control of C, who can spend them as desired.  In other words, the approval of both B and C is needed in order to move the funds onward.  You can get this effect with a 2-of-2 multisig transaction that requires signatures from both B and C, and can then be spent in any way they agree to.

Do you have  any idea about other blockchain Protocol allow this features

@wikix: Sorry, I don't know whether there are other coins / protocols where such a feature exists.

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


text:
Why mining pools miners need to choose their difficulty?
I read this and this.
It said: "The traditional method involves assigning members a work unit comprised of a particular range of nonce, the number that blockchain miners are computing for. Once the pool member completes the work on the assigned range, he places a request for a new work unit to be assigned."
From what I understand, the nonce range is the same for all miners and in order to proof their work, miner need to send the share with the difficulty fixed.
So I don't understand the interest to increase the difficulty for a miner. If he keep the minimum difficulty, why would he reduce his lucks to proof his work with a higher difficulty?

Having a different difficluty and thus have lower luck does not reduce the payout at all. Payouts are proportional to a miner's hashrate. So with higher difficulty shares, the payout will be higher per share which compensates for having fewer shares.
However a miner will want to use an appropriate difficulty level even though the payouts are the same. Although the payouts will be the same in theory, in practice, there is a difference. If a miner mines at too low of a difficulty, the mining hardware may spend a lot of time having to send and receive data from the pool server that it remains idle for so long it can't submit as many shares as it should so the payout isn't as high.
Conversely, if the difficulty is too high, the hardware won't ever be able to find a share so the payout will be basically 0. So a miner should choose a difficulty which matches his hardware so that it is at 100% utilization almost all the time but still be able to submit shares frequently.
The pool difficulty itself has no effect on the luck a miner has on finding a share at the actual network frequency. Pool difficulty is just a way for pools to keep track of how much work each miner is doing.

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


text:
Can a miner not find a share in his work unit?
I understand that a mining pool operator distribute work units at it miners.
Is it possible that a miner can find no share in his work unit?
If is the case, this mean a miner can work for nothing?

A good pool should manage difficulty levels so that every qualified
1 worker finds at least some share.  It may be a very small share, but something should be counted.
1 By qualified, I mean a processor in the same league as the rest of the pool.  If you join an Intel CPU miner to a pool of ASIC miners, your miner would not be qualified, and it would be appropriate to not get any shares.


text:
Confirming transactions in the Merkle root and SegWit
I'm trying to find out how exactly transactions are confirmed in a block.  I understand that to confirm a transaction, you hash it with its associated transaction and then the associated hashes until you get the Merkle root, and if the Merkle root is the same as that which is in the block, the transaction is legitimate.
But how would someone know which associated transaction is required to hash with your transaction to confirm its validity?  And where would you get it from?
Also, i'm a little confused about Segregated Witness.  As I understand it, the signatures are separated from the transactions and the signatures are hashed in the same manner as transactions.  This final signature hashed is either hashed with the final transaction hash to form a Merkle root, or it is contained as another Merkle root in a separate field in the block.  But if the Merkle root is always the same size (I assume) how does this save space?  If the Merkle root is always 256 bits, why does it matter if the signatures are hashed with the transactions or hashed separately?
I can't find clear answers to my questions so any help will be appreciated.

But how would someone know which associated transaction is required to hash with your transaction to confirm its validity? And where would you get it from?

Your question is a little vague, it sounds like you are asking how a lite client confirms that a transaction they care about is indeed in a block. The party trying to convince them the transaction is included can give them the required information.
Full nodes already have all the data and don't need to have it provided.

Also, i'm a little confused about Segregated Witness. As I understand it, the signatures are separated from the transactions and the signatures are hashed in the same manner as transactions. This final signature hashed is either hashed with the final transaction hash to form a Merkle root, or it is contained as another Merkle root in a separate field in the block. But if the Merkle root is always the same size (I assume) how does this save space? If the Merkle root is always 256 bits,

The segwit commitment is down lower in the tree not at the top. This doesn't make any real functional difference but it answers your question about the root always being the same size.

why does it matter if the signatures are hashed with the transactions or hashed separately?

Because when transactions specify which coins they are spending they refer to it by the txid. If the signature data is part of the txid then changes to the signature (like third party malleation or resigning) invalidate subsequent transactions.  If the signatures are excluded from those txids this problem does not happen.


text:
Transactions in a shorter blockchain branch
As I understand it, in a situation where two miners solve a block at the same time, a branch is created on the blockchain which is resolved when one branch is built upon, and thus becomes longer than the other branch.  The longer blockchain is then regarded as the de facto blockchain.
But what happens to the confirmed transactions in the shorter branch?  If this shorter branch is now disregarded, are the transactions lost?  If so, are bitcoins lost as a result?  Are the transaction sent back to the miners' mempool?  If so, is there a risk of double-spending?

The transactions on the sort - or orphaned - branch are not considered confirmed. They are considered never having happened at all and are returned to the mempool, unless they were also included on the other, de facto branch.
Any bitcoins mined in an orphan block is never considered to having existed in the first place, to be able to be considered 'lost'. All the effort and electricity spent mining an orphan block is literally wasted.
There's a risk of double spend for every merchant or recipient of a transaction who didn't wait enough time to see the transaction confirmed in a block and several successive blocks. If he or she accepts a transaction in a block A, then delivers the product sold, the another transaction with the same input but other output is included in block B, then block A get orphaned, the merchant delivered the product and didn't receive the money. He or she can contact the buyer to settle this somehow, but that's the definition of a double spend.


text:
How to check the balance of a person when his public keys are different on different input transactions?
A person can use a different public key/private key generated from his eWallet for each transaction. How the miner check the balance of that person from his multi-input transactions with different public keys?

Welcome to Bitcoin.SE! You can help the site by marking quality answers as accepted so that the question does not remain as "unanswered".

Contrary to popular belief, Bitcoin does not use an accounts system with balances nor do addresses actually exist on a technical level.
A transaction spends transaction outputs and it creates transaction outputs. It directly references which transaction outputs it is spending, so when verifying a transaction, you just need to lookup what the previous transaction output is. There is no need to know any balances (except that of the transaction output which is provided in the output itself) nor anything else about the wallet of the sender(s).


text:
How can I recover btc that did not register to address
I sent btc to davor coin from coinbase the night it crashed. Coinbase shows the transaction was accepted but I don't see my btc on the davor website. How can I recover my btc when davor is not responding
https://blockchain.info/address/16WArqNTvEYiZWgXXdfAPEQsgEubgNuYAq

Possible duplicate of Why is my transaction not getting confirmed and what can I do about it?

Both the transactions shown in the link are confirmed.

The transactions to/from the address you linked have been confirmed and cannot be reversed.  If you click on the transaction IDs (e.g. cbbae668...), you will see the number of confirmations; currently in the thousands.

How can I recover my btc when davor is not responding?

You cannot.  Davor owns those coins now, and any attempt to do anything with them will need their cooperation.  All you can do is ask them to credit your account and/or refund their coins.  You can ask politely, or rudely, or with the assistance of the legal system (i.e. try to sue them).  But this is no longer a problem that can be solved via technology.


text:
How does Bitcoin Core know that your private key relates to your public address? Are the private keys stored?
When a user creates an account on Bitcoin Core, he is assigned private keys. And he needs to use these private keys in order to send transactions onto the network.
Does Bitcoin Core store these private keys in the application or in the public ledger? Are these private keys store on a private server by Bitcoin Core developers?
When you sign a transaction with your private key, how does Bitcoin Core know that this private key is related to your public address?

Does Bitcoin Core store these private keys in the application or in
  the public ledger?

the private keys are stored in the wallet, along with the public keys. Never (!) ever you would show the private keys to someone else, otherwise you'll loose the funds! This is why wallets are also secured...

Are these private keys store on a private server by Bitcoin Core
  developers?

No, as mentioned before, in the wallet software. If the developpers had access to the private keys, they could steal all funds... doesn't make sense.

When you sign a transaction with your private key, how does Bitcoin
  Core know that this private key is related to your public address?

The link between priv and pub keys is by the ECDSA logic.
The answers here are fairly generic, and deserve probably a whole chapter of a book, but I think I'll reference to Andreas' book "Mastering Bitcoin". It is an amazing book that'll definitely get you to go. It's freely available online here: http://chimera.labs.oreilly.com/books/1234000001802/index.html

You did answer fairly generically. As I know you shouldn't share your keys with anyone. I'm just trying to understand how the technology works. How does Bitcoin Core know that your private key is valid if it is not stored anywhere? I'd like to know more about ECDSA logic if that is in relation to my question. Do you have other links on what that is? Or a way to explain in rather basic terms as well as the actual mathematical algorithm?

The private keys are stored in the file "wallet.dat", which is located in your home directory. The bitcoin core wallet itself creates the private keys, and from this private key a public key is derived (which is also stored in the wallet) via ECDSA logic. I provided a link to Andreas' book, which explains in detail the ECDSA logic (chapter 4), and in chapter 5 the way how wallets handle the keys.


text:
Without IP address, are there any other identities considered for banning nodes
Does a node only ban the IP address of a malicious node? or, there are other identities included. I mean, if a malicious user can generate multiple IP addresses to send fake tx, what will be the countermeasure then? Suppose, the other node, which will verify this tx, also a malicious attacker.

First of all, IP addresses are not stored in transactions nor can a node just "generate IP addresses".
How banning works is that nodes connect to each other via TCP sockets which are stream sockets so both nodes know the IP address of the other node. So when a node is banned, the banning node refuses to open a connection to the banned node. Nothing else is involved in banning, so if a node connects through another IP address (not by "generating IP addresses", that's not a thing, but rather by using proxies or VPNs), it would not be banned.


text:
How to get a wallet feerate (sat/byte) of an unconfirmed transaction?
On block explorers such as blockchain.com, each unconfirmed transaction has a desired feerate set by the wallet such as 58.000 sat/B. This is not to be confused with the actual final fee calculation.
My question is how do they obtain/calculate the feerate desired by the users wallet that submitted the transaction?
Is this possible via the bitcoin JSON RPC api?
From what I understand, getrawtransaction() does not provide any details of the feerate set by the sender. Moreover, you can also get the feerate set by a user by getting their wallet details. If so, how is the wallet feerate set calculated if there are two inputs to the transaction?

The fee rate is not related to the confirmation status of the transaction.
As far as the bitcoin protocol is concerned, fee rate is simply transaction fee (in sats)/transaction size (in bytes). So for a 100 byte transaction, paying 10000 satoshis as a fee, the fee rate is 10000/1000, or 10 sats/byte.
Currently, you have two possible fee rates: Segwit and non-segwit.
The Fee Rate/weight unit, instead of fee rate/byte, measure is intended to provide a consistent view of fee rates, regardless of whether a transaction has segwit inputs or not.
The calculation remains the same - weight units/total fee gives you the fee rate per weight unit, with a non-segwit byte counting as 4 weight units, and a segwit byte counting as 1 (this is a simplification, full details are outside the scope of fee rates).
To calculate this using Bitcoin Core, simply get the transaction details via RPC. A decoded response contains a weight field, which you then divide by the total fees paid to determine the fee rate per weight unit.
If a transaction has multiple inputs from distinct wallets, the fee is still paid at a transaction level - to determine how much of a fee was "paid" by a particular input, you'd need to determine who received the outputs, and where the change went. Once you know the output break up, you can attempt to distribute the total fee among the participants.


text:
Can transaction id be used to verify a transaction?
I have seen alot of questions here on "Transaction Malleability issue". Editing of transaction id can be done by miners or nodes which relay the transaction.
What I want to know is

whether the tx_id can be used to verify whether a transfer occurred successfully or not?
Is the issue restricted to bitcoin only? What are other coins in which transaction malleability can occur ?
Will it be solved in future upgrades of bitcoin core ?
Can tx_id be used to retrieve raw transaction info (as it is public) ?

Indeed malleability means that the tx_id can change as long as the transaction is not in the blockchain yet. That means you can NOT rely on the tx_id. But:

Once the transaction is in a block that is part of the blockchain, the tx_id does uniquely identify it and can be reliably used forever in the future to refer to it.
Basically all other coins ever forked from Bitcoin have the same (and many more) problems.
In Bitcoin it's already fixed by SegWit. The tx_id for SegWit transactions can not be malleated anymore (except by the person who has the private keys).

do popular exchanges use SegWit ?

More and more do. It was activated September last year (2017) but there was hardly any pressure to start using it until the fees became very high for a little while in December. Now SegWit adoption is up a lot and many more companies are working on adopting it.


text:
How to connect to a public node through json RPC?
I found a list of public bitcoin nodes here.  I am using a php library. How can I connect to these nodes via JSON RPC? Is it safe to connect to public nodes? What should I give as username and password?
I had tried a bitcoin node on my ec2 instance. It is taking too long to sync and blockchain size is also increasing. I want to communicate with bitcoin network without running a bitcoin daemon.

Not all nodes will have the JSON-RPC enabled, and especially without private credentials. You will probably find a block explorer API much more accessible, because they are built to handle public traffic. There are many blockchain explorers online that have public apis, they are easy to find.

actually I need to generate address and push transactions into the blockchain.. most blockchain explorers give block height and related info.. iam new to cryptocurrencies so i might be incorrect

You can run an SPV node (light node)

You'd be very foolish to trust a random node in the network to make private keys for you.


text:
how Bitcoin Benefits from giving u s currency(other then money from ads)
Now, I have a pretty simple question to ask , How does Bitcoin benefit from giving us money for solving math problems? Another question is that why does it want us to do it? & is there a bigger purpose behind it???

Possible duplicate of Who are you solving algorithms for and why?

Also: What value does mining provide?

I'm voting to close this question as off-topic because too broad. Next to the two links, you may also look at bitcoin.org, and understand the design goals of bitcoin (censorship resistant payment network ...)

"Bitcoin" is not a company. Bitcoin is an open-source project and a lot of people are working on it. And an open-source project does not need to get rich. The intention of a big part of that community is more like "changing something".

How does Bitcoin benefit from giving us money for solving math problems?

You did probably not understand that "solving the sha256-algorithm (that's what solving math problems means)" secures the network by preventing double-spends.


text:
If I have a join shared wallet and my partner lost the backup, can we recover this if i can i see the BTC yet?
I had a Join Shared Wallet. I can see my BTC; but my partner can´t because she lost the back up words. We aere trying to send this to an other wallet but it´s imposible if the other account doesn´t authorized it. What can I do for recovering these wallet?

Assuming this is a 2-of-2 multisig shared wallet, it is not possible to do anything with the coins without signatures from both wallets.  Bitcoin uses strong crytography, and when signatures are required, they're really, really required.  That's why it's secure.
If your partner has irretrievably lost the wallet and backup phrase, then the two of you have irretrievably lost the coins.  Sure, you can see them, but you'll never be able to spend or transfer them.
Sorry.


text:
how to dump private key from multisig address
how to dump private key from multisig address ?
I tried with dumpprivkey RPC function but return error : Address does not refer to a key

You can't dump the private key for a multisig address because there are multiple key pairs (thus multiple possible private keys) assigned to the address. You need to specify which key pair you want. First, get the public keys belonging to that address by using:
$ bitcoin-cli getaddressinfo <your address>
{
  "address": "<your address>",
  ...
  "embedded": {
    ...
    "pubkeys": [
      "<pubkey 1>",
      "<pubkey n>",
      "..."
    ],
   ...
}

Assuming you want the private key corresponding to <pubkey 1>, you can convert it to a simple P2PKH address and then use dumpprivkey, for example:
$ hash160 <pubkey 1>
  <pubkey 1 hash>
$ echo 00<pubkey 1 hash> | xxd -r -p | base58 -c
  <P2PKH address>
$ bitcoin-cli dumpprivkey <P2PKH address>
  <privkey>

Where hash160 is just a bash script that uses openssl:
#!/bin/bash
## Command Line parsing
#######################

if [[ $# -lt 1 ]]; then
    echo "Usage: $ hash160 <input-hex>"
    exit 1
fi

inputHex=$1

hash1="$(printf $inputHex | xxd -r -p | openssl sha256 | cut -c 10-)"
printf $hash1 | xxd -r -p | openssl ripemd160 | cut -c 10-

very usefull, work on my case


text:
decoded raw transaction size & vsize mean?
I have decoded my raw transaction using decoderawtransaction, I got these value
"size" => 259
"vsize" => 259

is that block size ?
if it does, is that byte or killo byte ?
I want to calculate miners fee based of block size

You probably want to calculate fees on transaction size, not block size. And size is the value you use as a basis, if you have non-segwit transaction. If segwit, use vsize and verify the underlying logic (quick search here in the forum!)

possible duplicate of https://bitcoin.stackexchange.com/q/53623/5406


text:
Sendrawtransaction error with locktime : 64: non-final txid
I have created raw transaction with locktime and sign it. The lock time is already passed but still got error like this when sendrawtransaction

64: non-final txid

the locktime value is 1523515709 .
and here hex transaction after sign if anyone willing to check it, I created with testnet BTC. How to fix it ?
02000000031e86fe4a8edf79ec3de22ab4208e9285bc55414c3b57053258e70651ee59ee85000000006b483045022100ecf1b03bf565358ebf25c5b2a1cf8a7f9bb6f6629c3fe12dbeb76b94e7d3f1ba02201d77ac1ba3092f90e360551fa3ac03cacda97c9d7d490e33e93248c76d5ee874012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff39994c9f8f0109f0e4c66fe5206dedc9844249cbff373ecd99def0903d36dcbc000000006b483045022100a68935c9df63462c1a4637aa3c63170c4dc396dbb2da67337d1937836148b51502201e1e294cfad8b393c35fb8405c72ee9e46f9495b86019b03760cdde06cf8a9ed012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff6c81ebda296a42ff4215b3b14055dc3d42d382cceefd118e229512aa1b88eb75020000006a473044022011ae505b77a67a41a3f1ee99b378493f9f5739ba5522ce6a1659cfb2ef129fd80220589d24a28593be57319e9dd058f08ce2ace74ccd3d3ab0edf81487878895f682012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff0302ca9700000000001976a914dc1ded71f0c85710f65b3426137e2d4a5784eed588ac50c30000000000001976a9141ca93028446df6bd23778047417c8447ceb4ab3488ace0533104000000001976a914f084173109b9547db4781e8e1a3a52a0cc709d9888ac3d01cf5a

Looks like a timelock issue. Have you managed to get it though?

Locktime in (reversed) hex 3D01CF5A is 1523515709 decimal, which is >= 500mio, so it is a time stamp (date -r 1523515709 --> 12Apr2018). This is roughly when you posted the question. Sure it has passed? Have you tried to change to "00000000", and see if error remains? Error might also indicate n issue with the signature, as it is a multisig tx (though I can see all three signatures).

@pebwindkraft What is mio?

500mio is five hundred millions... based on here: https://bitcoin.org/en/transactions-guide#locktime-and-sequence-number: "Locktime itself is an unsigned 4-byte integer which can be parsed two ways ...". basically, if greater than 500mio it is interpreted as unix epoche time, if less than 500mio, then block height.

I just encountered the same problem and the solution is almost stupid. Since the hint is not found elsewhere, I'd add my two cents in case others stepped upon the same trap.
It turns out that, besides the usual reasons related to time (e.g., time lock hasn't expired, the sequence number is not properly set etc.), trying to spend an unconfirmed UTXO also causes non-final error. I didn't dig into the source code to see why this happens, but the misleading error message cost me a good afternoon.
Why would you ever attempt to spend unconfirmed outputs? Well, when you're busy testing things out and are gradually losing ur patience...

If this is true, it's a bug. Finality has nothing to do with confirmed or not.

@PieterWuille yep it can be reliably reproduced on Bitcoin Core v0.17.1.0-gef70f9b52b851c7997a9f1a0834714e3eebc1fd8. Is GitHub issue the preferred way to report?

Yes, please. I wonder what condition triggers it. Spending unconfirmed outputs is an intended features, and there are several tests for it.


text:
Is Bitcoin truly scarce?
I'm a newbie to crypto/blockchain, but I'm very excited about the possibilities.  Given how passionate folks can be about the subject, I want to be very clear that I'm not trying to indict Bitcoin or cryptocurrencies in general. I'm trying to understand how the whole thing works.
My understanding is that there is a limit on the number of Bitcoin that can ever exist;  21 million bitcoin.  Therefore, one of the merits of Bitcoin as a store of value is that more Bitcoin can't be "printed" like the Fed "prints" dollars.
I have also learned that one can exchange Bitcoin for other cryptocurrencies with limited issuance like Litecoin.  And, presumably, nothing prevents another cryptocurrency from being created with similar rules...etc.
So, is Bitcoin - as a store of value - really limited?  If all the currencies like Bitcoin are interchangeable, what is the effective difference between them?  In 10 years, why do I need to have value stored in Bitcoin vs. Litecoin vs. any other similarly constructed asset?  In theory, shouldn't all the capital flow evenly into all these currencies?  Again, assuming they are interchangeable.

Yes Bitcoin is deliberately limited in that there can never be more than about 21 million BTC.
No the existence of other forms of money does not affect this characteristic of this particular form of money. It is an intrinsic characteristic.
Yes the potential for new forms of money means that money in general is unlimited in terms of the sum of the numbers printed on the front of banknotes etc - but this number isn't especially meaningful. The actual collective value of all available forms of money is determined by external factors.
None of this affects that there can never be more than about 21 million BTC. Bitcoin is truly scarce in that sense. This is true whether it takes 10,000 BTC to buy a pizza or a nanosatoshi to buy a Ferrari.
There's little point in indulging in philosophical wrangling over this. The only significant effect of this form of scarcity is a deflationary influence on the value of Bitcoin. Or at least the lack of an inflationary influence at a large scale or in the longer term. There are other things that have inflationary or deflationary influences on Bitcoin. That is, external factors that influence its value either way.

This text should come with notice, scarcity doesn't mean that it can only go up.


text:
% of full nodes running Bitcoin Core versus other node software
Is anybody able to tell me a credible source (for an article) that can show me the percentage of all bitcoin full nodes that are running Bitcoin Core (as opposed to other software)?
I could not find this information at bitcoincore.org or at bitnodes.io.
Thank you.

bitnodes.io, in its user agents chart, show an "Other" category, but probably it will include also older versions of Bitcoin Core.

On blockchair.com you can find details of which clients are used by full nodes, but they are grouped by user agents, so you need to manually count Bitcoin Core version and other clients.
on coin.dance you find exactly what you looking for, but right now is in maintenance, here there is a snapshot from archive.org: https://web.archive.org/web/20210124183839/https://coin.dance/nodes

These sites only show listening nodes.

how can we count nodes that do not listen?


text:
What are the Blockchain Transactions Status possible values?
Very noob at this.
I'm seeing that a transaction in Bitcoin has a field called 'status':
Example from blockchain:

I was wondering, what are all the possible values that this field can get (or where to search for them)?

I don't know. As an approximation, we can look at what's written in Bitcoin Core:
/** New transactions start as UNCONFIRMED. At BlockConnected,
 * they will transition to CONFIRMED. In case of reorg, at BlockDisconnected,
 * they roll back to UNCONFIRMED. If we detect a conflicting transaction at
 * block connection, we update conflicted tx and its dependencies as CONFLICTED.
 * If tx isn't confirmed and outside of mempool, the user may switch it to ABANDONED
 * by using the abandontransaction call. This last status may be override by a CONFLICTED
 * or CONFIRMED transition.
 */
enum Status {
    UNCONFIRMED,
    CONFIRMED,
    CONFLICTED,
    ABANDONED
};

Source: https://github.com/bitcoin/bitcoin/blob/571bb94dfb5047c9be8fcbae5dae71de7256b86c/src/wallet/transaction.h#L148-L153

I'm very unsure that these are the exact same possibilities that blockchain.info uses.


text:
Bitcoin cli Error: too few parameters OS X Big Sur
I'm running Bitcoin core,I struggled for bitcoin conf file till I found this and this is what I just have in it
server=1
rpcuser=username
rpcpassword=password
rpcallowip=127.0.0.1
rpcport=1300
I have problem with bitcoin cli. I couldn't find any solution to fix it since I have no idea about coding. This is what I see when I try to run it
"Error: too few parameters [Process completed]"
any idea?
I have been searching for solution! let me know if there is anything missing.

What are you trying to do with bitcoin-cli? "Too few parameters" means that you aren't giving it any options for it to know what to do. Usually this means you failed to provide an actual RPC command that you want to run. If you are trying to get Bitcoin Core running, the command is bitcoind not bitcoin-cli.

I'm trying to make it work. I tried help on the wallet counsel, I did as I saw for generateblock and that's what happened. For bitcoind this is what I get Error: Cannot obtain a lock on data director. I'm really confused.

What exactly are you trying to do? bitcoin-cli is for sending specific commands to bitcoind. It doesn't have a user interface and isn't interactive. Each command has its own arguments, some have many, some have none at all. So what are you trying to do? Too few parameters means that you aren't providing enough arguments to the command you are using.


text:
Questions RE soft forks
I’m trying to understand how the Bitcoin network works a bit better and the main thing I’m having trouble with is forks, particularly soft forks. I have a few questions about how exactly a soft fork works. If you can provide an answer for any of them I'd be most grateful! Apologies if I butcher a load of terminology in the process of asking these questions.
1 – Some things that I've read seem to suggest that during a soft fork, all blocks produced by legacy miners would be rejected by nodes running forked software. Other things seem to suggest that legacy miners would be able to get a subset of the blocks they produce accepted by nodes running forked software; I.E. any blocks they produce which happened to comply with forked rules, as well as legacy rules. Who is correct?
For example, if bitcoin still had a 1 MB file size limit on blocks and someone proposed a soft fork to change the file size limit to 0.5MB, would legacy miners be able to get any blocks that they produce which happened to be under 0.5MB in file size, accepted by nodes running forked software and nodes running legacy software, as those blocks would abide by the legacy rules (max file size 1MB) and the forked rules (max file size 0.5MB)? Or would any blocks produced by legacy miners be rejected outright by nodes running forked software, because they were produced by miners running their hardware on the legacy chain and not the forked chain?
2 – I want to make sure I understand this part correctly. After a soft fork activates, if during one of the checks of the latest blocks added to the consensus version of the blockchain, 95+% of the latest blocks have come from miners running on the forked chain, then the forked chain has ‘won’ (I don’t know the proper term) and the changes to Bitcoin made by that fork will be ‘locked in’ for a small grace period. Is this correct?
3 – If the forked chain ‘wins’ in one of the checks of the latest blocks added to the blockchain, is the forked chain then taken to be the chain with the most work put into its creation, I.E. the correct, consensus version of Bitcoin's blockchain? How does this work?
If 95+% of blocks in one check come from the forked chain, is the forked chain then recognised by all full node software as the chain with the most work put into its creation? Then does legacy full node software send a notification to legacy full node users and miners on the legacy chain telling them they’re now operating on a chain that is not the chain with the most work put into its creation and they should reconfigure to run on the forked chain? After the grace period to give legacy full nodes and miners a chance to reconfigure, is the legacy chain then considered ‘stale’ and the forked chain then considered to be the only consensus, correct version of Bitcoin’s blockchain?
4 – If the above is correct, what would happen to any transactions that were made on the legacy chain, added to the legacy chain by legacy nodes, but were not added to the forked chain by forked nodes as the blocks they were mined in did not comply with forked rules? If someone made a transaction like that, would their wallet software warn them at the time that their transaction appeared on the legacy chain, but not the forked chain, so therefore their transaction hadn’t been added to the consensus version of the blockchain, meaning it was technically still ‘pending’ and would be unlikely to get ‘confirmed’?
Is the possibility of this scenario an incentive for development teams of wallet software to make sure their software runs correctly on the forked chain and not on the legacy chain, when a soft fork activates?
Thank you very much if you read this far!


text:
What is the best free iOS wallet out there?
I only ask this question because there's so many kinds of wallets out there and I understand the difference between wallets(hardware wallets, iOS and Desktop wallets). But what is the best wallet in your opinion? would you be recommending that wallet to someone that's located in Asia?

https://bitcoin.org/en/choose-your-wallet?step=5&platform=ios

I personally like Blockstream Green as in addition to being simple to use, it has many features about security and privacy

I like Blockstream Green (they have multisig, with 2FA for larger payments, so extra security) and BlueWallet (sometimes you might prefer singlesig for enhanced privacy + they have Lightning Network support in addition to on-chain Bitcoin).


text:
What is the difference between a push-based transaction model and a pull-based transaction model?
What is a pull-based transaction model? What is a push-based transaction model?
I've heard people describe bitcoin as a push-based transaction model.
I've heard people describe traditional financial transactions (eg IBAN/SEPA, ACH, credit card, etc) as pull-based.
This fundamental difference appears to me to be one of the most important features of bitcoin over traditional financial money transfers, but I've struggled to find much information on the Internet that explains these differences and why it matters to the security of funds in long-term storage.
I'm looking for a simple (yet thorough) explanation of these two distinct transaction models. Ideally, I'd like an infographic that shoes visually the difference between [a] giving your credentials to someone else and allowing them to take funds out of our account (pull-based) vs [b] using asymmetric cryptography; keeping the keys to yourself, and sending transactions to others (push-based).

See also https://www.coincenter.org/education/crypto-regulation-faq/how-are-payments-with-bitcoin-different-than-credit-cards/

Let's say you sign up for a monthly subscription to an online newspaper or magazine. A pull based system would take the payment out of your bank account every month until you canceled the subscription. A push based system would require you to agree to or "push" the payment every month as the online newspaper would not have the ability to take the payment otherwise. Blockchains like Bitcoin are generally push based as the only way for funds to move are if the owner constructs and signs a transaction with their private key. With bank accounts the bank can technically move or freeze funds without the owner's permission. Obviously they are constrained by regulation and laws but from a technical perspective they can do whatever they want with your funds.

Bitcoin is push-based because the holder of some BTC must take action to make it move - by signing a set of his UTXOs and publishing the transaction.
It is not possible to pre-approve some recipients so they may alone take the money when some agreed-upon conditions would be met.
Pull transactions would be possible if Bitcoin Script would support covenants through some opcodes that would give the running script access to local transaction context. That way, you could make a contract that specifies something like: owner A can take funds at any time OR service B can take 0.001 BTC when N blocks have passed since this transaction was mined and in that case he also MUST return the change back to the same contract address.
That way, service B could know that there's funding for some X months of service, and could alone construct the transaction to take the money at regular intervals. If A wanted to cancel the service, he'd simply withdraw all the funds from the contract at which moment the service monitoring the address would see that and stop delivery of the service.


text:
Historical miner fees per transaction
Where can I find accurate data showing the average amount that people paid in miner transaction fees per transaction per day?
I found a chart titled Fees Per Transaction (USD) on Blockchain.com. I downloaded the dataset (csv) and calculated the average daily fee per transaction in 2021 to be $10.22.
But that doesn't make sense. I usually spend 1-3 s/B. If the volume is abnormally high, then maybe I spend at most 20 s/B. I don't think I've ever spent more than $1 for a bitcoin transaction in 2021, but the data on blockchain.com suggests that the day with the lowest average fee per transaction in all of 2021 was $1.51. How is this possible?
Why is the data reported by blockchain.com for average transaction fee per transaction so high? Where can I find accurate data that shows the average transaction fee per transaction?

See also here: https://bitinfocharts.com/comparison/bitcoin-transactionfees.html#alltime
They have median, too: https://bitinfocharts.com/comparison/bitcoin-median_transaction_fee.html#alltime
If you don't trust the data then I suppose you could scan the blockchain yourself and multiply it with some average BTCUSD price for the day.


text:
Has money ever been stolen in bitcoin due to a design flaw in the protocol?
Is there an example of a single historical case of theft of bitcoin due to a flaw in the design of the bitcoin protocol?
When googling "is bitcoin secure?" it's easy to get confused because you can read endless stories about a lot of people having lots of bitcoins lost or stolen. As far as I can tell, most of these cases occur when the victim:

Forgot their private key
Lost control of their private key
Gave their balance to a custodian, and that custodian lost control of their private key(s)
Other user error

I'm also aware that, in the history of bitcoin, there have been fundemental flaws, such as the 1 RETURN bug that would allow anyone to spend anyone else's bitcoin with a maliciously crafted transaction.
My question is: is there a single documented case of theft happening due to such a flaw in the actual design of bitcoin that can't be attributed to user error?

To be clear - you are separating protocol flaws from software implementation flaws in any implementation including Bitcoin core? This might be problematic since some people regard Bitcoin core's code as part of the definition of handling network communications and applying rules to those communications. In other words, the Bitcoin protocol is arguably more than the list of messages and message formats.

I'd maybe consider implementation flaws in Bitcoin Core (only) to be a "flaw in the actual design of bitcoin," but not third party wallets.

One story I know:
Not long ago user has transferred 900 mBTC to address known as generated from empty string. This amount has been immediately transferred elsewhere.
Seems like someone has lost 900 mBTC because of poor implementation of their software.

"address known as generated from empty string" what? Please clarify what happened and on what software. And also please cite your source.

You can use empty string to hash it to sha256, then base58check it and you have private key derived from empty string and that was used to sent 900 mBTC. That's all I know.

Please delete your answer as it doesn't answer this question. Anyone can design a malicious or poorly-designed bitcoin wallet. This is not a flaw in the bitcoin protocol, so it is not a valid answer to this question.

@MichaelAltfield it is valid because the BTC was stolen.

did you read the question?? Has money ever been stolen in bitcoin due to a design flaw in the protocol? Bitcoin gets stolen all the time, we all know that. The purpose of this question was to identify a historical case where bitcoin was stolen due to a design flaw in the protocol. Your questions suggests an uncited case where an implementation of an unknown bitcoin wallet caused lost of funds. That is not a case of loss of funds due to a design flaw in the protocol.

@MichaelAltfield how would you know how this person implemented the protocol?


text:
Why do not all the coinbase texts have the block heigh in it?
The coinbase text of #511329 starts with a, #511330 starts with b, #511331 starts with c... (and so on until z), but #511426 for example starts with F, the next one with m, the next one with "... regarding https://coin.dance/blocks
Why do some of them follow the rules, but others not?

All coinbase transactions do contain the block height, and have done so since block 227,835.  It's required by BIP 34.  Since all other miners enforce this rule, a block which broke it would get orphaned and would not become part of the block chain.
You're simply not looking at the right thing.   The height is encoded by a single byte giving the number of bytes to follow (currently 0x03) and then the height as a little-endian binary number.  Blockchain.info displays the coinbase transaction scriptsig both in hex and as characters, but not all bytes correspond to a printable ASCII character, so it displays a � character for such bytes (there seems to not be a one-to-one correspondence between bytes and characters, so it may be trying to parse it as Unicode or something).
Decimal 511329 is hex 0x07cd61, so its coinbase starts with the bytes 0x03 0x61 0xcd 0x07 (remember, little endian).  Now 0x03 is unprintable and 0x61 is a, so you see an a in that text.  Decimal 511330 is hex 0x08cd62, so you see 0x03 0x62 0xcd 0x07, and 0x62 is b.
But decimal 511426 is hex 0x07cdc2, so the coinbase starts 0x03 0xc2 0xcd 0x07.  None of these correspond to any printable character.  The transaction goes on as 03c2cd07ce46... and 0x46 is ASCII F.  This happens to be the first printable character in the coinbase transaction, but it isn't part of the block height at all; just part of whatever other data the miner felt like including.  You've ignored the bytes which were not printable, but you can't do that.
Likewise the coinbase for 511247 starts out 03c3cd07fabe6d6d...  Again, the block height is included exactly as it should be, since decimal 511427 is hex 0x07cdc3.  It so happens that the first printable character is 0x6d, ASCII m.  But again  that has nothing to do with the block height.


text:
Bitcoin Transfer Not Done

I send 0.043 bitcoin to the 1Fhpf5bA95zBPzsPezozDYf9h2jCYD31TA address. But it didn't reach to this address. When I click the address on TX page you can view the pic that Sent : 0 BTC
What's the problem? Thanks.

The screenshot you included also says: "Received: 0.0434 BTC", which is consistent with what I see. The transaction has thirty confirmations, and 0.434 BTC were signed over to the address 1Fhpf5bA95zBPzsPezozDYf9h2jCYD31TA.
In case you mean that your wallet doesn't show the transaction yet, perhaps your wallet is still synchronizing?

Just wait for the 6 confirmations. It looks like it is there: https://blockstream.info/address/1Fhpf5bA95zBPzsPezozDYf9h2jCYD31TA
Just a bit patience.


text:
Binance API Error Code: "code": -1022, "msg": "Signature for this request is not valid."
I have a problem with the Binance API. I use HTTP request from Integromat, but I always get the following error message:
"code": -1022,
"msg": "Signature for this request is not valid."
URL I use: https://api.binance.com/api/v3/account
I created the signature with HMAC SHA256 and verified it via this website: https://www.freeformatter.com/hmac-generator.html#ad-output
I used this example (https://dev.binance.vision/t/faq-signature-for-this-request-is-not-valid/176) and compared the output code, it matches exactly, so mine should be correct too.
I requested the timestamp from Binance via HTTP request and added +1000 milli seconds.
I don't understand why I still get this error message although the SHA256 hash is correct.
Does anyone have any idea? Attached are a image from integromat.

I finally made this work :)   in integromat you calc the sha correct but the req should be made in url otherwise the output is not sha hmac
url url//../v3/account?timestamp={{2.timestamp}}

Your error is that you forgot to include the &recvWindow=5000 in the SHA256 operation so the signature isn't correct.


text:
Why is the block header version value different from the getblocktemplate version value in the bitcoin blockchain?
When looking at block header for block 746632 I see that the version is 1073676292 or 3fff0004 or when reversed 0400ff3f, but the version I received from a getblocktemplate request is 536870912 or 20000000 or when reversed 00000020
My understanding is that the version field can not be different from the one in the block template.
getblockhash 746632
0000000000000000000573b8d27491283652e993c390d7be8a38129ec46672fa

getblockheader 0000000000000000000573b8d27491283652e993c390d7be8a38129ec46672fa
{
  "hash": "0000000000000000000573b8d27491283652e993c390d7be8a38129ec46672fa",
  "confirmations": 14,
  "height": 746632,
  "version": 1073676292,
  "versionHex": "3fff0004",
  "merkleroot": "24619c38bcd737edccbcce809692b66c374a0a81c148aa5e9eca45607fbf3f28",
  "time": 1658845216,
  "mediantime": 1658841797,
  "nonce": 1738315485,
  "bits": "170a2a04",
  "difficulty": 27692567959233.59,
  "chainwork": "0000000000000000000000000000000000000000321828fef78edcbcaa328aba",
  "nTx": 1089,
  "previousblockhash": "00000000000000000002d7a16b995df4b79deae619175f853efc68643a6eabea",
  "nextblockhash": "00000000000000000002a995ef37e16105a966e65face571aff76b2b88025a6b"
}

getblockheader 0000000000000000000573b8d27491283652e993c390d7be8a38129ec46672fa false
0400ff3feaab6e3a6468fc3e855f1719e6ea9db7f45d996ba1d702000000000000000000283fbf7f6045ca9e5eaa48c1810a4a376cb6929680cebccced37d7bc389c612420f8df62042a0a17dd969c67

There is no requirement that a miner must follow the block template. They can construct their own blocks as they see fit, so long as their block follows the consensus rules. There cannot be a requirement that blocks match block templates as each node can produce a different template depending on the transactions that they are aware of. If every node produced the same block template, then we wouldn't need mining in order to form consensus on the ordering of transactions.
The block version can largely be any value that the miner wants. There are only a few limitations on it, and these are largely that it cannot be specific values, not that it must be a specific value. 3fff0004 is a completely valid value.
Miners may choose to change the version number in order to use an optimization known as ASICBoost. Using the version number as an additional nonce field allows them to have a higher hashrate, so many miners will do this.

Specifically, only BIP16, BIP65, and BIP66 have put constraints on the block version number (together they imply that interpreted as a signed 32-bit integer, the block version must be >= 4). BIP9 and related deployments have specified criteria under which nodes may emit warnings, but no strict rules.


text:
Easy, low fee way to move fro one paper wallet to another?
Newbie here.
I am looking for an online wallet that will support me to import Bitcoin paper wallets, then sweep each one to a new paper wallet, at the lowest fee.
I had a few accounts from three years ago and finally acted on getting my modest Bitcoin on paper wallets. After much research I chose paper, printer, method and BitCoinPaperWallet to generate the keys. A few days ago I read on Coindesk.com that there have been many reports of people losing large amounts of  Bitcoin due to a probable back door problem with BitCoinPaperwallets servers. I do not have large amounts, but still want to be cautious.
So, I want to move my several paper wallets to ones generated by BitAddress.org. I want to import the wallet to an online wallet and then sweep each one to my replacement wallet. My logic is that importing can be done without miner fees. With Bitcoin miner fees being upwards of $20 and taking 8 hours at that, at least using the import function would cut fees and time in half.
I signed up with Trust Wallet, owned by Binance and after many hours and finally submitting a question was informed that they do not support importing Bitcoin wallets. They do support importing Etherium and many others. Odd.
Can anyone recommend an online android smartphone app for me?

My logic is that importing can be done without miner fees

Depends what is happening. Are you importing or sweeping? Importing means the wallet is just saving the private key, which means funds have not moved. Sweeping simply means taking all the funds from one address and moving them to a new address. This is a transaction on the blockchain and will require a fee.
Sweeping is the easiest way to move funds from a paper wallet. Many wallets have an import or sweep feature. You can do your own research on that as this is not the forum for product suggestions.

If you simply import your paper wallet's private key to another wallet, then you will not be protected against the backdoor that is being used to steal funds stored on paper wallets created with the code you mentioned. This is because importing the key will not move the BTC to a new address, it will simply allow the new wallet to spend the coins that are stored at the paper wallet address. Nothing would stop the thief from also being able to move those coins.
To protect yourself, you need to move the BTC to a new address, which was generated using secure software/hardware.
I would strongly recommend against using a web-wallet. Instead, I would recommend starting here: https://bitcoin.org/en/choose-your-wallet

Thank you for your response. I chose Blockchain wallet to do the import, sweep, send (to new paper wallet). It seemed to successfully reduce the total amount of fees by starting with an Import function. But it appears that, of course,  one cannot send without paying miner fees and those fees, on this platform, need to come out of the same wallet/address (?verbage) as the coin being sent. I could have sent the "maximum " available but I prefer to keep a set amount on each new paper wallet.

@SueSy I would recommend learning about what the ‘UTXO model’ that bitcoin uses is, and how transaction fees are calculated and paid. Your reply indicates some small misconceptions, but you’re on the right track. Happy to help.


text:
Flooding mempool with fake high fees transactions
Suppose, A is a malicious attacker. He wants to flood the mempool with fake transactions. I know if an attacker broadcasts fake transactions with no fees, then mining nodes will simply increase the transaction fees to be accepted.So, that type of transactions won't be accepted. But, suppose, if an attacker broadcasts fake transactions with high fees. Is it possible to flood the memory pools with this type of transactions?

What do you mean by "fake transaction"? There aren't "fake transactions", only valid and invalid transactions.

Yes, Invalid transactions

Invalid transactions are rejected, they never get to the mempool.

I know that the transaction rules in the attacker software won't allow to broadcast the invalid transaction. But, if they change that rules and then broadcast those transactions. My point is not whether it will be accepted or not, but to flood the mempool of a miner.

A miner won't accept invalid transaction into the mempool so it won't be flooded.

You're probably trying to figure out if a denial of service attack becomes more effective if you use invalid transactions instead of just spamming spurious data.

I see the question you have, and thought I put some more info in this reply, cause comments are too short.
You seem to postulate, that it might be possible to spam the net, by sending messages with high fee, and you consider this as a possible attack vector (with "fake transaction").
To understand how the network works, it is essentially necessary to look into the validation rules of transactions, when they are sent over the network. The fees are calculated by substracting the output value from the input value. If it is above 0, then ok, else invalid.
As a particular person anyone can craft a malformed tx. The question is now, how could you do this? Again, looking at the rules, it seems impossible. When you send it, the receiving nodes and all other full nodes will verify this tx. If the tx is malformed, they will reject it, and your node will be marked as a node, which sent wrong data into the network. At a certain point in time your node will get added to the blacklist of each full node, so this malfunctioning node cannot disturb the network further.
So you would need to find a way on how to send invalid tx to other full nodes, and as Andrew and Osias replied, to the current knowledge this is impossible.

Unless A intends to bear the cost of the fees and be disruptive by sending valid transactions with high fees? But, that is not in the question.


text:
Signing transactions can not find private key
Please I need help. I have made an transaction online using bitcoin, but the order cancelled and now my bitcoins are stuck. I've been using coinb.in the first time a while ago and was able to do it successfully. Now the private key is not letting me pass the same one I used last time. What can I do to get back my bitcoins?

I've been using Electrum wallet since.
I'm trying to explain my situation better.
So this is where it starts this is my cancelled order. I've redacted parts of them, but you hopefully get the idea.
My order site has refund information as you can see from the picture. So what I did last time was using coinb.in and it worked. I copy this
code of numbers given to coinb.in.
https://postimg.cc/34wht4xM
Coinb.in recognizes the transaction. The address I used with my Electrum wallet is there.
https://postimg.cc/grq5xkz8
The next step is to sign the transaction with my private key. I remembered I have a file saved on my computer with my private key information. I have saved my private key and all PGP key password information on my computer and been using this the last 3-4 years. So I opened it and used the private key to which it wasn't recognized.
This is my saved private key information.
https://postimg.cc/bG9Csm88
Previously on the vendors website I'd save my bitcoin refund address and public key. The public key matches, but the address is different, because the new Electrum I updated in the past changes my Electrum receive address.
https://postimg.cc/62DYPgfr
Anyway, when I enter the private key from my saved note the following occurs:
https://postimg.cc/627MYtn6
So then what I did was I looked up all my addresses on my Electrum wallet and I found the one I did the transaction and it has the private key next to it like in the picture here:
https://postimg.cc/3kK9zgmc
I typed in this private key, but I still can't verify:
https://postimg.cc/627MYtn6
So my bitcoins are stuck now and I don't know what to do how to get them back IF.....
I hope I've explained myself better. What do you think I should do now?

Try copying the transaction into electrum and see if you can sign & broadcast it there yourself.
It's under Tools -> Load transaction -> From text. It opens a new window where you can paste the transaction. If electrum has the correct private key available, it will offer you the options to sign & broadcast the transaction.
Ideally always avoid sending your private keys to third parties.


text:
Is the hash of ZMQ channel blockhash a merkleroot hash?
I am using the ZMQ interface of my node to keep track of wallet activity like incoming transactions. I want to know the number of confirmations of my transaction but, to do that, I would need to know in which block the tx is included and calculate from that block onwards.
I was thinking that I could watch for the ZMQ channel hashblock but there is not much documentation about these channels. Is this hashblock a merkle root hash?

As the name suggests, it is the block hash, not the merkle root hash. It is the hash of the block header which includes the merkle root hash. To learn whether your tx is included in a block, you will need to fetch the block with that hash and then search for your transaction within that block. You can do this by using the getblock RPC after receiving the ZMQ message. You could also use the rawblock ZMQ channel and receive the entire block in full, but that will also mean that you need to implement block parsing.
Even if you could just get the merkle root, the merkle root itself does not contain sufficient information to determine whether a particular transaction is included in that block. You still need to get the full block and search the transactions list for your transaction.


text:
Shared crypto hardware wallet
We were all newbs at the beginning, and did things the wrong way.
My partner and I bought crypto separately with our own exchange accounts, but transferred our hodl coins to a single shared hardward wallet address.
Using Koinly, we can easily determine which transaction in is for which (only 15-20 or so)
Problem/challenge is, how will this work when i transfer the coins out using FIFO, LIFO. We Koinly know which "coins" are which?
I have never actually transferred out from the hardware wallet, and i want to fix this.
I thought about transferring all coins out to our respective exchanges (at the same time), then back into new separate wallets. Will this work and be cool to the ATO?
Second question. Can you have a share wallet address for a masternode and split payouts/cost by the % coin holdings.
Thanks

Taxes are going to be more straightforward, and less inviting to being questioned by the tax authorities, if you keep your accounts separate, unless you and your partner are married filing jointly.

Bitcoins exist as 'unspent transaction outputs' (UTXOs), not as an 'address with a balance'. If you really feel the need, you could import your keys into some wallet software which will allow you to exercise 'coin control', which means you will be able to pick and choose which UTXOs are used as inputs when creating a transaction. So then you could just choose all your UTXOs and send them to a new address in a single transaction, and then do the same for your wife's UTXOs.
But doing so will put your funds at additional risk, as you'll have to trust the new wallet software/device you import your wallet into. Mishandling private keys can lead to a loss of funds (theft), so you shouldn't do this unless you feel it is absolutely necessary.
Really, I would just create a transaction that pays you your share of the coins, and another transaction paying the remaining coins to your wife. Within a bitcoin transaction, it does not make any sense to point to some specific output and say "these bitcoins came from this specific input". Rather, it is as if all of the input coins are melted down into one blob, and then the output coins are forged anew from this blob. So it doesn't make too much sense to worry about tracking 'your specific coins' through time, as each 'specific coin' is 'melted down' when it is used as input to a transaction.
Think about it like this: when you do your accounting, do you worry about the serial numbers printed on the $20 bills, or the value of them? Your bitcoin accounting can work in much the same way: how much bitcoin did you buy? How much did you sell? This is the relevant information.

Will this work and be cool to the ATO?

Questions about how to satiate the demands of any particular tax authority are going to be off-topic here, you'd do better asking an accountant or tax lawyer if you need such advice.


text:
Why aren't more empty blocks mined?
So currently only a tiny amount of empty blocks are mined
A total of 71 empty blocks were mined in the first five months of 2020,
accounting for 0.3% of the total blocks produced — less than half of the
0.79% figure from the same period last year

source: https://www.theblockcrypto.com/post/67928/bitcoin-miners-are-mining-fewer-empty-blocks-in-2020-and-it-may-not-all-because-of-chance

I agree that it does not make sense from a game theoretic perspective for anyone to just mine empty blocks all the time (which would mean we would be close to 100% of empty blocks). As a miner you want to sell your btc in other blocks etc.
But I think a fair question to ask is why this number is so low. My intuition here is that the bitcoin mining race is extremely competitive. And anything that could give you some sort of advantage is always used.
If you just ignore txs you do not have to validate them and do not have to include them in one block and therefore can same some amount of time for mining the new block. This would be a competitive advantage over miners that include txs. Therefore I was surprised that the number of empty blocks is so low.

The overhead of validating transactions is relatively insignificant. If it is felt desirable to do so, it can be performed by a separate machine from that performing the mining.
Say 2000 transactions need validating every 10 minutes. That is 3 or 4 transaction validations a second. Meanwhile the mining rig is performing billions of hashes a second.
So there is effectively no disadvantage and as halving of mining rewards continues, the transaction fees are increasingly significant

Hmm but I do not see how you can parallelize this. First you have to validate and decide which transactions you are going to include (takes some time) and then you can start mining this block. But yes with time txs are going to gain in importance because of the block reward halving.

I see no reason why one computer can't continually be receiving and validating transactions, adding them to a mempool and assembling mempool entries into the next block template while another computer is controlling a set of ASICs that are searching for a nonce that produces an acceptable hash for a current block template. The workload for validating 3-4 transactions a second is low enough that most ordinary wallets like bitcoin-core do it in the background while the computer is primarily used for other tasks.

Yes you are correct. The validation can be parallelized. But not the decision which txs you are going to include in the block, because you have to check for each new block, that the validated txs were not already included in the previous block. So every time a new mining "race" starts you have to at least filter out all txs that were already mined.

There is some kind of relationship between empty blocks and difficulty increase/decrease that I have not been able to formulate properly.  The fewer the empty blocks, the closer to the 10 minutes average per block we are, meaing that every set of 2016 blocks were closer to the estimated time of confirmation.
Last year, 2021, China banned those confirming blocks in their country and that had an impact on difficulty that reflected on the amount of empty blocks 'mined', in my humble opinion.
My theory is that every time a block is taking more than 40-60 minutes, there is a candidate block, with no transactions, waiting in the shadows to be 'mined' in order to be the first afterwards.  When you analize a series of blocks, you can easily differ how many empty blocks follow those blocks that took a lot of time to confirm and you will realize that most, if not all, follow this pattern of being confirm just after a very slow and laggy one.
In a side note, it is true that renouncing to the fees is pointless because what @RedGrittyBrick said about the halving every 210,000 Blocks, but confirming that empty block would make sense if you have an edge at confirming the next immediate block afterwards for the full subsidy.
I would suggest a PR to the core developers in order to prevent the mining of empty blocks unless the mempool is empty, of course.


text:
Does Bitcoin Core Validate ECDSA Signature Component r Using Mod N?
In the book Programming Bitcoin (2019) by Jimmy Song (pg's 61-72) the ECDSA signing/verification procedure for message hash z, private/public key pair (e, P), generator point G = (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8), elliptic curve cyclic group order

N = |<G>| = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, field order p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F, and ephemeral private key k is defined by :

Signature (r, s) created as follows :
r = x coordinate of the point R = kG (so r is in the range [0, p - 1]),
s = (z + re) / k mod N (so s is in range [0, N - 1])

Signature (r, s) is validated as follows :
Calculate the point Q = (z/s)G + (r/s)P.
(r, s) is valid if x coordinate of Q equals r

This is implemented in the book code at :
https://github.com/jimmysong/programmingbitcoin/blob/master/code-ch13/ecc.py
in the methods PrivateKey.sign and S256Point.verify.
However in other sources, eg :
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm
https://andrea.corbellini.name/2015/05/30/elliptic-curve-cryptography-ecdh-and-ecdsa/
https://www.secg.org/sec1-v2.pdf
the algorithm is slightly different :

r is taken to be mod N (so r is in the range [0, N - 1]),

(r, s) is considered valid if (x coordinate of Q mod N) equals r

My question is which approach does Bitcoin itself adopt ?
If Bitcoin adopts the latter approach then if we sign as in Jimmy's book, and if the x coordinate of R is in the range [N, p - 1], which is possible as N < p, then our r value is in the range [N, p - 1]. However then, on validation using the second approach we compute (x coordinate of Q mod N), which must lie in the range [0, N - 1] and thus it can never equal r, and the validation fails.
The probability of obtaining the x coord of R in the range [N, p - 1] is very small as N is proportionately very close to p, however is it good practice in Bitcoin programming to assume this can never happen ?

The ECDSA verification algorithm (in general, and as implemented in Bitcoin) unambiguously requires both r and s to be less than the group order, so descriptions of signature generation algorithms usually include taking r to be the X coordinate of R modulo the curve order. In the extraordinaly unlikely case that r falls between n and p - 1, omitting the modulo step would just result in an invalid signature (which all Bitcoin nodes would recognize as invalid).
Note that in the Schnorr signature algorithm as described in BIP340, r is not required to be less than the curve order (meaning it can go up to p - 1).


text:
How to Recovery passphrase bitcoincore
i dont remeber my passphrase of my  bitcoincore wallet.
I try with an hex editor but i don’t know wich string i have to search.
how can i recover it?
Thanks to all can help me.
I’ve followed some post in various forums but I find only instructions for various wallet but nothing for bitcoincore.
I know that is possible to find a pass phrase with an hex editor but I don’t know what searching for

You cannot. The passphrase is not stored directly in the wallet. It is directly used as an encryption key.

No it is not possible to find the passphrase with a hex editor.
Bitcoin core encrypts your private keys with a random key. This random key is encrypted (AES-256-CBC) with a key derived from your passphrase.
If you remember something from the key (parts of it, letters, even length) you need a program that permutates what you know. If not you can try brute force starting with 1 character and up. Unfortunately when you chose a good key (length>15 characters) this is a near impossible task.

Maybe I remember a little of my password. Wich kind of program you talk?

btcrecover if you know most of the password, it's open source

anyway, a good starting page is wallet-dat.com


text:
Blockchain data indexing: key-value or relational database?
I'm building a hobby project with bitcoin-style data storage: I'm going to write block data into one large file. I need to decide how to represent the file in app's memory. Bitcoin uses key-value storage to associate entity hashes with places in data files where they are stored. If I want to do the same, are there any serious performance differences between key-value and relational databases for such a use-case?

bitcoin stores the data of blockchain not in a database "key-value", but in raw file data. However, Bitcoin uses the levelbd (and in the last update it could be supported also SQLite) to store the information about the mempool a.k.a chainstate directory.

and maybe this post answer at your question https://bitcoin.stackexchange.com/q/85864/91194

Unfortunately, your link is not enough for me. I will rephrase my question for you: why bitcoin still uses level-db to store the chain-state and not SQLite from the start? Did developers had performance or personal convenience considerations in mind?
Thanks for a fast response.

I'm not a Bitcoin core developer (unfortunately) but I think that the main motivation is related to history. However, the chain state contains only small information regarding the UTXO and nothings else. All the information is stored on the disk because it is impossible (in my knowledge) to store in a faster way the information in any type of database.


text:
where is transaction confirmation number in bitcoin source?
I have try to check in bitcoin source code.
i want to see confirmation number code but i have not found.
where is transaction transaction confirmation number in bitcoin source ? how to update it ?
Thanks you

What do you need that isn't found by downloading, unzipping and then using findstr /s confirmation *.cpp *.h?

i did not see as your guidance. normally when we transfer bitcoin we need to till 6 confirmations ? where it is in source code ? can we reduce to 3 confirmations ?


text:
Question about “Lost” Bitcoin
I understand bitcoin is a ledger.  Everything is accounted for.  If something is debited from one side, it is credited to the other, and vice versa.
If a coin is sent to a wallet, with a public key, that doesn’t exist, the coins are considered “lost”.  But they are still debited from the wallet that sent it and credited to the wallet that doesn’t exist.
If a new wallet is created, and by mere chance, is the same address as the one the “lost” coins were sent, would those coins there when the wallet was created?
Example: coins were sent to wallet “...xyz”.  The coins were dedicated to xyz wallet, which does not exist.  I create a wallet that just happens to be xyz.  Would I have access to those bitcoin?

Would I have access to those bitcoin?

Pieter has answered this but see answers to Is it possible to brute force bitcoin address creation in order to steal money? for an idea of how likely this sort of thing is.
There's some other points raised by your question that I think are worth examining.

I understand bitcoin is a ledger

We all say that but really, in accounting terms, it's not a ledger it's a journal. A transaction journal.

Everything is accounted for.

That is not exactly true. The transaction journal known as the blockchain keeps a record of all the amounts but there's a lot it doesn't account for.

If something is debited from one side, it is credited to the other, and vice versa.

There are no debits and credits in the Bitcoin network itself. That is, there is no carried-forward number in the Blockchain from which an amount is subtracted (debited) or added to (credited).

If a coin is sent to a wallet ...

Coins aren't really sent to wallets, we say they are sent to Bitcoin addresses. A Wallet will have many Bitcoin addresses. But really coins are not sent to addresses, they are locked by a locking script, a kind of simple program. Bitcoin addresses are just a kind of abstraction of a standard script.

... with a public key, that doesn’t exist, ...

That is certainly possible. Though "exists" isn't quite right. You mean a public-key for which no-one knows a corresponding private key.

... the coins are considered “lost”.

Actually, no one can tell the difference between a lost coin and one that is safely stored in a wallet. If someone doesn't know the private-key corresponding to a public key associated only with unspent coins, they have no way to tell if someone else ever did or currently does know such a private key.

But they are still debited from the wallet that sent it and credited to the wallet that doesn’t exist

Yes, but coins are not debited from wallets. The Bitcoin network protocol doesn't know about wallets. It doesn't really do any debiting or crediting. It just keeps track of the creation and destruction of coins and makes sure that only the right number of coins are created when other coins are destroyed. The Blockchain has no information about wallets.

The above will seem like nit-picking. But we regularly see people ask questions here because they have been tricked out of money by people exploiting slight misunderstanding of how Bitcoin actually works.
the kinds of wallets I mean when I write the word wallet are programs like Bitcoin-core or Electrum. Some businesses provide accounts and provide a web-based interface or an app to manage the account and call these a wallet - that is not what I mean.

I create a wallet that just happens to be xyz. Would I have access to those bitcoin?

If you could do that, indeed you would get access to those coins.
But you can't. Doing so requires breaking the security assumptions underlying the signature algorithm. This must be true: if it wasn't, Bitcoin overall would be utterly broken.


text:
How do I actually USE this Lightning Network?
https://lightning.network/
I've clicked every link. There is no download. Not even some beta CLI thing which requires Bitcoin Core to function, or anything whatsoever.
If this is a thing and people are allegedly making "more money running a channel than I do at my day job", why is it that it doesn't seem to have anything to actually, you know, use?
This is actually a recurring question I have for many of these "crypto projects". They seem like utter vaporware with nothing to actually download and run and use. And yet, at the same time, I keep seeing people claim that it's this big thing and tons of people are already using it.
But how can they be using it when the official website has nothing whatsoever to use in practice?

It isn't safe to assume https://lightning.network/ is the official website for the Lightning Network. Just as we shouldn't assume https://dollar.com is the official website for the US Dollar. Bitcoin.com certainly is not the official website for Bitcoin and Blockchain.com is certainly not the official website for Blockchain technology.

I think one might need to do a bit more research than looking at a single site before declaring a whole ecosystem a fad. If you widen your search a bit, you will find that even the Lightning Network wikipedia page lists implementations, either "lightning network beginner" or "lightning network getting started" finds a list of articles and videos that explains exactly what you are asking here, and "lightning network wallet" finds me e.g. this list of 31 wallets.
If all of that is a bit of a flood of content, you could get started with Jameson Lopp's Lightning resource overview:
https://www.lopp.net/lightning-information.html


text:
Blockchain transaction verification
I watched the 3Blue1Brown video about the blockchain and a question arose.
How is it ever guaranteed that if I send out a broadcast it will ever be put in a block that gets verified. For example it (my transaction) could reach miners who start verifying the block with my transaction but other blocks without my transaction get verified first therefore my block becomes obsolete because the everyone else is on another fork.
It seems like catching a moving train but with the chance that you run at the exact same speed as the train and never can get on it.

When blocks become stale, transactions in them are returned to the pool.
Transactions in the pool are available for inclusion in a subsequent block on the winning fork.

If there are two competing blocks at the same height (which happens rather infrequently), each node will only consider one of the two the best chaintip. The other block is not part of their best chain, so it is irrelevant what transactions it included. Therefore, the same transaction can be in multiple competing blocks at the same time. If the transaction paid a high enough transaction fee rate, it'll probably be in all of them.


text:
How to generate a bitcoin address from a hexadecimal private key using openssl in swift
I have an iOS app which can generate Bitcoin private keys in either a hexadecimal or base64 output.  I'd like take the resulting private key and generate the Bitcoin address from it.  I've included the openssl library in my project but am confused as to which methods I should use and how to reference opaque pointers that come along with openssL methods when using them in swift.

Maybe use a iOS compatible bitcoin library like https://github.com/libbtc/libbtc?

I would love to get this to work in my iOS project but I'm not keen enough to understand how I can create a framework to include this library in iOS

I wanted to put this as a short comment, but it get’s unreadable. I also don’t go into segwit.
I am not clear on your question: are you looking how to use the OpenSSL library for iOS (then this might not be the right forum - review of parameters to an OpenSSL library is not bitcoin specific...), or more at the conceptual steps to come to an address? Then read on:-)
Searching for OpenSSL and keys in the forum reveals lots of hints on how to use OpenSSL at the command line. I put here some links, that I find useful for creation and conversion of keys:
Bitcoin Address generation
What are steps 4-9 in bitcoin address generation for?
Then you‘ll have to go some additional steps, as described in bitcoin wiki.
And finally, if you want to check the addresses, this is a useful page:
http://gobittest.appspot.com/Address
Let us know how it goes, and see where we can bring you to your goal!


text:
QUESTION ABOUT SLOW API
do you know about api requests cryptocurrency exchanges? Simple ticker request may be viewed like this: https://api.kucoin.com/v1/open/tick or like this: https://www.okex.com/api/v1/ticker.do?symbol=ltc_btc
Different: in first case we get info about all currencies in one request and then pick up certain symbols and parameters, we need. Symbols are the keys of dictionaries or lists and other params are their values.
In second case I should create new request for each currencies I considering. Is it neccesary? If I consider, for instance 60 symbols, and do operations with them in Python - programm bot become slow enough. One-two ticker requests are long about 30 sec - for compare, in first case - 5 sec.
How can I solve this problem? Thanks.

You can solve this problem by making a request to https://www.okex.com/api/v1/tickers.do (without the symbol parameter). This will give you all the tickers in one request.

Genius! But why I can't find this way on https://www.okex.com/rest_api.html#spapi   page?

It's not completely documented, but the closest thing I found was on https://github.com/okcoin-okex/OKEx.com-api-docs/blob/master/API-For-Spot-EN/REST%20API%20for%20SPOT.md#spot-price-api.

authors: Кирилл Вишняков


text:
Is there a lightningd equivalent to bitcoind's -walletnotify or -blocknotify?
I'm looking at the docs, and I see they have lightning-notifications, but it looks like you can't configure where they go, and you can't trigger a shell script with them. Does this mean I have to have all notifications sent to a shell script and filter them, or is there a method/configuration I'm overlooking?

You can trigger a shell script with them, and more.
This is related to the plugin functionalities provided by lightningd and not bitcoind.
lightningd allows you to run plugins to deeply modify its behaviour, or extend its possibilities. It idiomatically (small and robust core, customizable functionalities) relies a lot on them and therefore directed the event mechanisms toward them as well.
This is the reason why you don't see [*]notify= startup options for lightningd.
To use lightningd's notifications you have to write a plugin, but it can be a pretty simple script. For example, here is the handler of the invoice_payment notification in the HelloWorld showcase plugin:
@plugin.subscribe("invoice_payment")
def on_payment(plugin, invoice_payment, **kwargs):
    plugin.log("Received invoice_payment event for label {label}, preimage {preimage},"
               " and amount of {msat}".format(**invoice_payment))

The previous example used the Python library, but the communication is pretty straightforward (JSONRPC 2.0) so you can technically use a shell script :-).
For reference, there is an available and curated list of community plugins.

Ah, I understand now. It's not there because the ability to add new functionality through plugins is instead.


text:
Speeding up walletnotify
In the case of a notice at 0 confirmations, I'm seeing the transaction end up on blockchain.info a lot faster than bitcoind is calling the walletnotify callback - about 10 minutes faster. Is it possible to speed this up?

How well connected is your node? 10 minutes is a long delay

is your wallet synced? because bitcoind send the notification once they received your transaction. make sure your bitcoind is synced.

Yes, it seems to be synched (blockcount is accurate).

@RaghavSood 124 from getconnectioncount

When you see the transaction on blockchain.info, are you sure the transaction is not in bitcoin already? Is it possible that whatever is being called just takes a long time to respond?

I'd suggest log a timestamped message with the callback, and the exact message as well to see its confirmations. Also test with sending bitcoin, in which case, walletnotify is called twice with confirmations=0, and once with confirmations=1. See if there's any delay. You could also test with blocknotify and log the timestamp when you receive the block containing your transaction. It'd be odd that blocknotify is triggered but your walletnotify is not


text:
How to correctly implement the FEE increase using bitcoind?
I have read that once a Bitcoin transaction is created, it never automatically expires. In theory, a transaction could be created, get stuck at 0 confirmations for some years, and then all of a sudden confirm.
The proper way of increasing the fee would be to send another transaction that uses exactly the same coins as the first transaction.
How can I program the correct way via bitcoind?
Which commands should I use?

You can use Opt-in Replace By Fee to do this. Bitcoin Core already implements support for signaling Opt-in RBF and for increasing the fee later (with some caveats).
When creating a transaction from the command line, the send* commands have an optional argument named replaceable. If you set that to true, then the transaction created will automatically signal that it can be replaced in the future. To increase your fee, you then use the bumpfee command. Note that the command currently only works if the transaction has a change output. The fee will be deducted from the change output.
Note that these commands and the arguments are not necessarily listed on the bitcoin wiki (it is frequently out of date). To actually get the full listing of RPC commands, their arguments, and how to use them, use the help and help <command> commands.