text:
How does merkle tree verification of transaction work?
From what I have read, suppose B sends 1 bitcoin to C. C wishes to verify B's payment and asks C for the block number (location) that input transaction is located at. (Is this correct understanding/procedure?) Then C checks whether transaction is actually in the block mentioned using Merkle tree.
And this is where my understanding stops. I know that Merkle tree has nice property such that if one has transaction itself and some trde hashes, you do not have to check all subtree hashes to check validity of transaction in the block. But this still requires receiving hashes from full node that knows what transactions are in the block. If all C knows is the block number plus transaction, then how is this different from just receiving the answer yes from the full node? The full node would still have to search where the transaction is located at the merkle tree in order to send subtree hashes. I just do not see how merkle tree helps to verify efficiently.
But given the level of my confusion, I do think that it may be better to answer by giving detailed procedures on what happens when B sends bitcoin to C.

http://bitcoin.stackexchange.com/a/36388/18196

http://bitcoin.stackexchange.com/a/38420/18196

I am going to try and answer to know if I truly understood.

You send Bitcoin to another wallet
Your request will be added on a block (let's call Block X)
Inside that block are transactions in a Linked List structure
The full node will give your wallet the the right/left hashed transaction & its Merkle Root (MR = h(h(hash|hash)|h(yours|yours)))
Your wallet upon receiving Block X's relevant hashed transaction will then be used to generate a Markle Root to be compared against the Merkle Root that came from Block X

My answer was based on this answer source:
https://bitcoin.stackexchange.com/a/38420


text:
How does bitcoin prevent tampering of blockchain?
Suppose C is starting bitcoin full node for the first time. C would have to download blockchain from some place. Could not this leave bitcoin susceptible for tampering? If blockchain stored in decentralized way or if blockchain full node constantly check their blockchain, wouldn't this still leave bitcoin susceptible to tempering? For example, if people downloaded blockchain more from a particular group of nodes intending to tamper blockchain, would not blockchain be  compromised? If resolution is done based on bitcoin wealth, this also seems to leave serious issues..

there are too many questions, and derivated questions... here are more developpers, but: www.bitcoin.org: "the block chain is a shared public ledger on which the entire Bitcoin network relies." Many nodes and miners make sure, that this blockchain get's only updated with validated data. When you download the blockchain to your PC, then data could be tampered, and you'd have  invalid LOCAL data. That doesn't harm the shared public ledger (blockchain). recommended reading: https://bitcoin.org/en/developer-guide#block-chain, or the book „Mastering Bitcoin“ by Andreas M. Antonopoulos.

https://bitcoin.stackexchange.com/questions/52354/is-there-a-robust-way-to-test-for-a-corrupted-blockchain

source: Stack Exchange

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

sort: votes


text:
BITCOIN ADDRESS
My 0.01673232 BTC SENT to the following Address automatically when last time I opened my Blockchain Wallet and now Balance shows 0.00
Sent to this Address: 3CKJ3Q49vfCB8MhhA9wtS1uXsBhoYHiAqh
Now my Question is that What should I do to recover my BTC.
Thanks
Muneer

What should I do to recover my BTC.

nothing. but you should check your system for malware and clean it before using bitcoin again.

You cannot recover your bitcoins once they have been stolen there is nothing you can do.

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


text:
calling importaddress with same address
While experimenting with importing addresses and keys via json rpc I noticed that importing an address twice triggers two rescans. This strikes me as very odd. My question is:

Is this intended behaviour and if so, what is the reasoning behind it?
OR: Is this a bug? If so, is it a known bug?

Calling importaddress will rescan the whole blockchain in default according to bitcoin.org

Set rescan parameter to false to not rescan the block database
  (rescanning can be performed at any time by restarting Bitcoin Core
  with the -rescan command-line argument). Rescanning may take several
  minutes.

help importaddress
importaddress "address" ( "label" rescan p2sh )
Adds a script (in hex) or address that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup.
Arguments:
  1. "script"           (string, required) The hex-encoded script (or address)
  2. "label"            (string, optional, default="") An optional label
  3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
  4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well
Note: This call can take minutes to complete if rescan is true, during that time, other rpc calls may report that the imported address exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes.
  If you have the full public key, you should call importpubkey instead of this.
Note: If you import a non-standard raw script in hex form, outputs sending to it will be treated as change, and not show up in many RPCs.
Examples:
Import a script with rescan
bitcoin-cli importaddress "myscript"
Import using a label without rescan
bitcoin-cli importaddress "myscript" "testing" false

UPDATE Since Bitcoin core v0.14 you can use importmulti to import addresses.
bitcoin-cli importmulti '
  [
    {
      "scriptPubKey" : { "address": "1NL9w5fP9kX2D9ToNZPxaiwFJCngNYEYJo" },
      "timestamp" : "0",
      "label" : "Personal",
      "watchonly": true
    },
    {
      "scriptPubKey" : "76a9149e857da0a5b397559c78c98c9d3f7f655d19c68688ac",
      "timestamp" : 1493912405,
      "label" : "TestFailure"
    }
  ]' '{ "rescan": true }'

Response:
 [
{
  "success": true
},
{
  "success": false,
  "error": {
  "code": -8,
  "message": "Internal must be set for hex scriptPubKey"
  }
}
]

Note:

Bech32 addresses are not supported using this method until the moment. (You're free to edit this answer when it's available.)
importmulti will not speed up importing progress since this method locks your wallet and block any further RPC calls.

But if an address has already been imported earlier why would it trigger the rescan again? That seems very odd. The node could simply do nothing in that case and all would be fine, and a lot of CPU time saved.

Bitcoin core commands is like for advanced users and it's not an interface you can just use bitcoin-qt instead.
in your case if you would like to use bitcoin-cli you can check if address not exist you can call importaddress

So what you are telling me is that it is a bug, but a workaround exists by checking first? A rescan of an address that is already in the wallet and was rescanned for before can never result in any new information.

I have taken the liberty of adding further info about importaddress to your answer.

Now it's even better! @Willtech

This is not entirely correct. importmulti is not supposed to rescan the whole change, but only the part affected by the keys being imported (you can specify their birth time). I would say this is a bug.


text:
ScriptSig in bip65 escrow example
In the bip65 there is an example how it can be used for escrow in combination with a multisig. See: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Escrow
There it claims that the funds can be spent with the following scriptSig:
0 <Alice's signature> <Bob's signature> 0 but when working through the example it always seems like the is one 0 to many. I am aware of the bug where one item too many is popped of the stack, and that is why a multisig script usually has a 0 first, but why does this one also have on at the end?

The scriptSig part is first on stack, so there would be:
0 <Alice's signature> <Bob's signature> 0

and this for the payout into the CLTV branch:
0 <Alice/Bob's signature> <Lenny's signature> 1

After the sig part follows the pubkey script, with the first Opcode "IF". This "IF" verifies the value befor on the stack (which is "0" or "1" from the sciptSig before), and branches accordingly:
IF
   <now + 3 months> CHECKLOCKTIMEVERIFY DROP
   <Lenny's pubkey> CHECKSIGVERIFY
   1
ELSE
   2
ENDIF
<Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG

Assuming the first branch is chosen, then the last item in the if clause is a "1", followed by the line after "ENDIF", so this becomes a 1-of-2 multisig, where only one person needs to sign. But this person has then to wait for the time lock (via CSV parameter). Here in the example: Lenny can spend after timeout is reached.
If there is a "0" on the stack before the IF clause, then the second part is executed, and this becomes a "2-of-2" multisig, which means, Alice and Bob can spend anytime.
Et voilà - smart contracts easy :-)


text:
How to create a deterministic wallet using bitcoinjs-lib
I'm new to bitcoin technology, however, I'm trying to develop a web wallet using bitcoinjs-lib that works like that of blockchain.info. I've gone through the code samples on the github repo but couldn't make out the one I could us to create a deterministic wallet.
I intend to make the wallet users enter a long and strong password from which the private key can be generated from.
Any code sample or link would be highly appreciated.

See Blockchain.info wallet source code
https://github.com/blockchain/My-Wallet-V3
Also check the bitcoinjs-lib's list of projects


text:
Building many btc adress on your website for users?
Hi I am new in this financial trend. I had some experience with exchange trading and investment for Ico. I have an idea and therefore i need to create a ıco website.How can ı add on my ıco site many btc adresses for user who will get invest on my project.

run a bitcoin client with json-rpc enabled. you can then communicate from you backend with this bitcoin rpc interface. See
https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list


text:
Buying Ripple XRP with Bitcoin BTC
I have Bitcoin in my Coinbase wallet.  I want to buy Ripple on another exchange since Coinbase does not trade Ripple.
Do I copy and paste my Bitcoin alphanumeric key code from Coinbase to the other exchange?
or
Do I hand write the Coinbase Bitcoin alphanumeric key code in the address window in the other exchange that trades Ripple in order to deposit my Coinbase Bitcoin into the other exchange so I can buy Ripple with Bitcoin?

The usual process is this:

You create an account on the exchange.
You go through their menus to deposit bitcoins.
They give you an address to send bitcoins to.
You withdraw from Coinbase to that deposit address.
You wait about an hour.
You now have a bitcoin balance on that exchange that you can trade.

You can use https://shapeshift.io/#/coins to convert your Bitcoin to Ripple and other cryptocurrencies.

I would suggest this, but you also have to have a Ripple wallet to store your bitcoins. Sorry I don't know much else about Ripple or a good wallet.

For GateHub, I had to ask them to deposit 20 XRP into my account so I can begin trading in XRP. This is on top of buying BTC, LTC, or ETH first on CoinBase and then sending to GateHub exchange address for that specific altcoin.

If you already have a coinbase account then you just need to set up an account at an exchange, this step by step guide shows the process of buying ripple using coinbase and binance.

Welcome to Bitcoin.SE! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.

I set up a wallet for XRP on CRYPTONATOR, then used Changelly, which allows you to move your BTC or LTC or ETH from Coinbase into the XRP wallet. But first I think you need to move some ETH or BTC into a CRYPTONATOR wallet and use that to open the XRP wallet because you need to deposit at least 20 XRP to start the XRP wallet. Then you can use the XRP wallet id from CRYPTONATOR to set up a transfer id from Changelly (ie BTC to XRP then it asks your XRP wallet destination and gives you a transaction code).  It's kind of a hassle, but it worked.


text:
Bitcoin transactions validation process
I have a general understanding of building blocks. But am hoping someone can fill in the details/gaps. Also, can you correct if something is not right? Thanks.
Scenario:

Bitcoin transactions are broadcast to the bitcoin network.
Nodes receive the transactions.
Each node puts the transactions into their own internal mempool - or is it a network mempool that all nodes draw transactions from?
At some point, some nodes begin mining (hashing to find correct hash with leading zeros). When does this begin? I assume as soon as possible since it is a race. So then, it does not necessarily use the data in a fully built block, right?
At some point, the mining nodes fill up a block with transactions from mempool (they pull the ones with highest fees). Each node validates each transaction it puts into its block against the entire blockchain.
When a node finds a winning hash, it announces the winning parameters to the network.
The network can easily check the hash using the parameters (dataset, nonce
value, etc.) that the winning node sends out.

So here's where I am a bit unclear. How/when do the transactions in the winning block get verified by the rest of the network? Is it during the time when they verify the winning hash? Do they also verify that all transactions are good at that time?
How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?
Thanks.

Everything MCCCS wrote is good, but just to clarify on your last question:

How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?

This question is slightly misguided: there is no 'accepting a block into the bitcoin network', because this assumes there is some network-wide threshold of acceptance that must be reached, or some sort of central yes/no switch for a block's acceptance.
The reality is that the network is made up of independently acting nodes. Each node decides for itself whether or not a block is valid, and it is by these 'consensus rules' that the network happens to come to agree on what the longest (most work) blockchain is. Once a valid block is broadcast, each node will independently work to verify that it is valid, and then add it to their local copy of the blockchain if it passes all the tests. The network is designed such that we expect all nodes that follow these consensus rules will remain in consensus, even though they are acting independently.

3: Each node has its own mempool. Each node validates the new transactions that they receive when they receive.
4-5-6: Nodes don't mine, miners do. Miners never stop, and each [some interval] they fetch a new block template from the pool operator's node, wh[ose merkle hash] includes new transactions. When they find a block, it is published and transactions in that block can't be changed.
Q: When nodes receive new blocks, they verify its hash (whether it's lower than the target difficulty), the previous block's hash it contains, and the transactions it has. (Notice that most of the accepted transactions are received twice by each node, which is what Compact Blocks] aims to solve)
Q: It doesn't matter, blocks propogate rapidly, and even if a (wrongly-designed) client rejects it, that block is still a part of the blockchain (as it is valid and there are no competing blocks)

I think if you add two more steps at the start then it makes more sense.

Transaction creation. (when User A sends coin to user B)
Transaction verification.

The transaction is transmitted to the neighbouring nodes and those nodes verify the transaction. If the transaction is valid those nodes transmit it further to their neighbouring nodes in the network. If the transaction is not valid it does not get populated in the network.

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


text:
Proof of work - lottery approach
I'm sure I am missing something here. But not sure what ...
Proof of work - after all is said and done, when a hash is found (about 10 min), it is said to be like someone hitting the lottery. Anyone that wins the lottery should be able to prove that a cost was incurred. So there are two things:

Include a cost to finding the hash.
The winner is considered "random" because finding the hash is an iterative guessing process.

The result is a huge energy burn and the result "mimics" a random winner.
QUESTION: Can the bitcoin network randomly select a subset of the existing nodes, for each block, who then compete to solve the hash? For example, if there are 100,000 nodes, the network randomly selects 10% or 10,000 nodes who are allowed to compete to find the hash. Or take it to a smaller number like 1% or 1,000 nodes, etc.
The burning question is: Why can we not mimic the proof of work process and save a ton of energy along the way?
Why not have all the nodes that wish to enter each block lottery pay a small fee. They all currently incur electricity cost so from a financial standpoint, does it matter whether they pay a small lottery fee or pay a small fee to the electric company?
EXAMPLE: for the next block, here is the process:

All 100,000 nodes pay (arbitrary number for now to make point) 1000
satoshis.
The bitcoin network randomly (maybe this is tricky part)
selects a subset percentage. Say 10% or 10,000 nodes. These are the nodes that compete for the next block entry.

BENEFITS:

There is still a cost incurred by each participant without the energy usage.
The energy usage is now a fraction of the total network participation for the iterative hash search.
It can allow more node participation by less powerful computers. A laptop will still be at a disadvantage, but is now competing against 9,999 other computers instead of the hashing power of the entire network.

To make sense of this is the fact that the end result of the current process is a "random" winner that can prove a cost has been incurred.
Can the lottery fee approach achieve the same goal without sacrificing security?

How would you determine who is a node?

You're assuming the lottery losers will let their mining hardware sit idle, and only those who won the lottery will hash.  But the lottery winners have every incentive to rent as much hash power as possible from the losers, so as to have a better chance of actually mining the block and collecting the reward.  So I'd expect that in fact, all the hashing hardware will still run, just on behalf of different miners from one round to the next, and the same amount of energy will be burned.

You might be interested in looking at Proof of Stake algorithms.  They're still under development, but they were designed from the start to solve these energy issues.

There's a lot going, but I'll do my best.

QUESTION: Can the bitcoin network randomly select a subset of the existing nodes, for each block, who then compete to solve the hash?

Selecting a subset of existing nodes isn't easy as it seems. The vast majority of bitcoin nodes aren't reachable at all, in fact. That's why every website that counts those are different from each other. (The best probably being Luke Dashjr's one).
So you might: "Well, you could make it so that in order to participate you have to public announce your node". But that opens up (from the top of my head) a big attack vector: DDoS's. If every node participating in the consensus is known and reachable then you could hit them once they are selected and cause a network failure.
But that's not even the most important part: This approach would be extremely easy to gamble. Any person could run thousands or millions of nodes (Amazon Web Service has 1 million business customers) and change the odds to their favor.
Proof-of-Work is not a consensus algorithm, but rather an Anti-Sybil protocol. Sybil being the attack that I described in the last paragraph.

Can the lottery fee approach achieve the same goal without sacrificing
  security?

Absolutely and 100% no, if you take "without sacrificing security" serious. And (1) I'm not sure if it can be done at all or (2) if it would work, but regardless: no.

The result is a huge energy burn

This is a little off-topic but I feel that might be worth commenting. Bitcoin energy usage is far from "deadly" or something like that. Most researches point to +70% use of renewable energy in the industry, highest than any other.

Yeah, I figured my approach was too simplistic and had to have been considered and rejected at some point. My understanding of bitcoin is conceptual without knowing well the granular details. Appreciate your comments, thanks.

Sure! The thing that I love about Bitcoin is that everyday I learn something new!

If you had to pay to enter the lottery, a Sybil attack would be of little value. more nodes would not be of benefit if you had to pay for a ticket to the lottery.

QUESTION: Can the bitcoin network randomly select a subset of the existing nodes, for each block, who then compete to solve the hash?

No.
Consider this: if there were a way to fairly and reliably 'select a subset of miners', then why not just select a single miner, and allow them to create the next block without any PoW energy expenditure? Why even have the mining process at all? Well... the answer is that it is very hard to randomly elect a peer in a distributed network, in a provably 'fair' way that is not game-able. And so we have slightly contrived solutions, like Bitcoin's PoW process.

First of all, there is the problem of how to randomly select a subset of nodes, in a way that isn't game-able. Whats to stop me from just running/spoofing 1 million nodes? Stopping sybil attacks is not trivial in a network like this.
Further, what is the definition of a 'selected node'? Is it a mining pool? An actual network node? An individual? A single ASIC mining rig? Even if you decide on a definition, how on earth would you enforce it? Having some sort of registry is antithetical to Bitcoin's design. Some of the above definitions may also create a trend towards miner centralization, which is bad for maintaining censorship resistance.
But lets just imagine that there is a technical solution, that allows a perfectly fair selection process that maps nodes 1:1 to 'actual miners'. In that case, if my node weren't selected for a mining round, then I would still have a few options: rent my hashing power out to a node that was selected (as @Nate Eldridge suggested), or just continue mining, and if I find a valid block, I sell it to a node that was selected, so that they can publish it to the network. In both examples, the network's energy usage hasn't diminished, but rather it has likely increased, due to the increased friction of participation.

BENEFITS:
  There is still a cost incurred by each participant without the energy usage.

Downside: this doesn't actually solve the issue of a Sybil attack, it just makes a sybil attack more expensive to pull off, and generally we want to avoid any game theoretical situations that favour one user over another for extrinsic economic reasons.

The energy usage is now a fraction of the total network participation for the iterative hash search.

This is false, as mentioned we should expect rational miners to rent their hashpower out to one another, etc.

It can allow more node participation by less powerful computers. A laptop will still be at a disadvantage, but is now competing against 9,999 other computers instead of the hashing power of the entire network.

This is false, a laptop would still be useless, especially considering the ability of miners to rent out hashpower, etc.

This question seems to stem from the narrative that "Bitcoin mining uses energy and that is bad!", but this narrative ignores the fact that the benefits of Bitcoin are perhaps worth the costs of running the system. Security cannot be faked, and PoW offers what is perhaps the most efficient and transparent method of creating security for a decentralized network in this regard.

Your last sentence is missing the word "decentralized".  A central authority would be far more efficient at creating security.

@Mark true, the sentence was written in the context of the rest of the answer, but I think that’s a worthy edit. I’ll add it in.

Your suggestion 'proof of lottery win' replaces one of the features of bitcoin, but there are other security features which are provided by proof of work.
To be the next node to certify a block you need to be lucky to hit the right hash, but you also need to expend an awful lot of work to find it. The next block after that has a lot of work invested in it too, and so forth up the chain of blocks.
If you want to start an 'alternative history attack' where you go back in time down the block chain to when you had heaps of bitcoin and fork off a new block in front of that block and start processing transactions, with the objective being to get longer than the existing blockchain so that you can claim it as the authoritative ledger, then you are going to struggle under the proof of work algorithm because you will need a lot of colluding cpu's to catch up to the existing chain.
With proof of lottery - you would be able to re run the lottery on a historical block of your choosing (very quickly as there is no proof of work component) - if the winner of the corrupt lottery did not comply for whatever reason you could re run the lottery on that block again until you found a corrupt accomplice and continue this process up the chain until you had the authoritative ledger.
Your suggestion would work in reducing cpu cycles, and would replace the 'next person picked at random' feature, however there would be another set of issues that you would need to consider to make this fly.

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


text:
What is the rationale for inclusion of previous amount in SegWit signing process?
When spending a P2PKH output, the "data" we hash only includes the output script from previous transaction but when spending a P2WPKH (the new serialization) we also include the amount field from previous transaction (#6 in BIP-143 specification). Why?

It's not particularly required and may be considered redundant as that information is generally implied from the transaction outpoints referenced in the input. However, this form of transaction serialization allows wallet softwares to explicitly commit to the fees involved in the transaction. This is particularly useful if say you are using a hardware wallet where you have your private keys and at the same time you use a watch-only online wallet. Since the online wallets knows all the UTXOs that your private keys control, it can effectively create a transaction consuming some inputs.
To know how much fee you are committing to the transaction, the hardware wallet would have to query the input referenced, grab all the outputs of that transactions (which may be very large) and then only it will know what the fee is for this particular transaction. Otherwise, if it doesn't, the software that created the transaction could lie, and in fact convert a giant portion of the bitcoins consumed into fee without you knowing it. However, keeping the input amount as part of the message that signature commits to means the hardware wallet software knows the amount explicitly and hence can provide the user with an accurate measurement of the fees.


text:
Would I be able to recover coins if Trezor went out of business?
I'm considering a Trezor wallet. I've read through their info about recovering if I lose the device or forget my PIN. What if the company were to go out of business. Would I still be able to recover my coins?

Yes. Trezor uses BIP39 and is compatible with any other wallet  that would. You can in fact import your seed into electrum, though this to some extent defeats the purpose of having a hardware wallet.

This is answered in their documentation:

What happens if the SatoshiLabs shuts down?
There are no such plans because we love bitcoin, but even if we had to
  close down, there’s nothing to worry about. You can use your TREZOR
  together with other BIP32, BIP39 and BIP44 compatible wallets. Since
  our code is opensource, developers from around the world can maintain
  it and add new functionalities.

You will loose all your coins*.
The Trezor wallet relies on the trezor software running from their website (wallet.trezor.io) for all user interaction.
Yes - your private keys will be safe inside that blob of plastic, but *unless you made a copy of their python github before they went away, there will not be anything you can plug your trezor into in order to get those keys out of there.
Also take a look at the Trezor CTO's replies on their website as to why they do not digitally sign their executable: They refuse to produce identification documents to Apple: https://www.reddit.com/r/TREZOR/comments/6kzj7z/trezor_bridge_mac_version_why_isnt_it_available/
IMHO: Their security and firmware are nice.  Their business practices and risk exposure is horrific.

There is no risk, if they indeed use BIP39 as Thax says so. I cant say much about the Trezor itself, I'm using ledger(which also uses BIP39) and there's a wordlist you get that's basically your private key that they highly recommend to write down on a piece of paper they even provide, in order you lose your ledger or even if ledger stops existing.

Downvoting because this is entirely incorrect. There are several other software that support the Trezor (connecting to it and creating transactions with it) that are not created by Trezor themselves or associated with them in any way. You do not need to use their web wallet at all. Furthermore, the Trezor follows the BIP 39 and BIP 32 standards for seed mnemonic generation and private key generation, so the mnemonic that you write down when initializing the Trezor can be used in any wallet which supports BIP 39 and BIP 32, and there are lots of those.

This is incorrect. Since posting my question I've done a bit more research. There are reports of users recovering their Trezor wallet with Mycelium on Android. I also found a guide for recovering a Trezor wallet with Copay. And in their docs Trezor themselves provide a list of compatible wallets & instructions on how to recover without a Trezor device.


text:
Bitcoin Cash Wallet Recovery
I just realized that I have an old Electrum wallet with a small amount of Bitcoin. I'd like to claim the Bitcoin Cash, but I'm having a hard time figuring out how to do this. I do have the original wallet password & seed phrase. I've also transferred the associated Bitcoin to a new address.
According to the Electrum site, I shouldn't install Electrum Cash on the same computer as Electrum. Unfortunately I don't have another computer to work with. I do have an iPhone & a Trezor, but I haven't figured out how to sweep my Electrum address into one of those devices.
What are my options for recovering the Bitcoin Cash without installing Electrum Cash?

If you still have the seed of the electrum wallet, you could setup the trezor using that seed, then use it to send the bcash wherever you want.

Easy steps :
1.  Start up Electrum where your Bitcoin is.
2.  Save the Wallet Private Key somewhere safe.
3.  Move your Bitcoin to your Trezor or Ledger (you really should have a hardware cold wallet).
4.  Now install ElectronCash from electroncash.org (it's fine on same PC)
5.  Start up ElectronCash & login with SAME password as your Electrum.
6.  You'll see the Bitcoin Cash sitting there.
7.  Transfer Bitcoin Cash into Ledger or Trezor (using the Beta Trezor Wallet here : https://beta-wallet.trezor.io/)
8.  You're all set.
Cheers!

WARNING: "Electron Cash" will copy all your Electrum wallets to its own directory, and their binaries are anonymous:

Just did it. Easy Pezzy work.
Copy the Seed/secret key from my electrum (original BTC) wallet and used it in "I already have a seed" option in electrum cash wallet. It will login and show you your remaining Bitcoin Cash.
Ps: I have Electrum and Electrum Cash wallets installed in the same PC. Didnt have any problem during transfer.
I did transfer my original BTC to another wallet for safety. But i doubt i needed to do that coz i doubt any reply problem will occur since they are separate blockchains.


text:
Why "double spent" can only happen if attacker controls 51% (or more) of the network compute power?
As per many descriptions block hash is calculated based on it's headers and nonce field. The latter gives a chance to get the value that is less then a target by incrementing it. If it's a lottery why is it necessary for an attacker to have more compute power then the rest of the network? Can it have a chance to get ahead of main blockchain generation if it is just lucky? I.e. nonce's it uses for own blocks generation will be always giving him desired block hash too soon? Or is it just that probability is so low that we can safely assume that this never happen?

If it's a lottery why is it necessary for an attacker to have more compute power then the rest of the network? Can it have a chance to get ahead of main blockchain generation if it is just lucky?

Yes, a miner could attempt to 'get lucky' and pull of this attack with less than 51% of the hashing power. Keep in mind, if the attack fails, then the miner will have lost money attempting it. 51% is the point at which the miner should succeed on average.
Note: mining is not a lottery by definition, it is only comparable to one in certain ways.

"51% is the point at which the miner should succeed on average.". Thanks, this phrase confirms my understanding.


text:
My Bitcoin transaction timed out on CoinGate but payment/BC disappeared and merchant denies receiving it...how can I track it down?
So I sent a payment from my Blockchain wallet to a merchant late one night last week and found out in the morning it had "timed out" but the BC was gone and there was no option for a refund.  Naturally, I assumed the merchant had claimed the BC payment but they deny having received it.  CoinGate is not helping me figure out what happened, and I had copied and pasted the address from the CoinGate invoice so I don't see how it could have gone to the wrong address.
Coincidentally, the trail of the payment has it ending up in a wallet/account that the first payment I had made to this same merchant (which went through with no problem) also passed through.  The merchant says this is not an indication that they received the second payment and that the account through which both payments passed is likely a CoinGate account.  Here is the address that the payment that is MIA was sent to (copied and pasted from invoice in CoinGate):
36kHjTRjHLXKkyZa85VRKJqbswXi7vAZ1J
The BC amount:  0.05049452 BTC
217.16 USD @2018-11-30T05:36:16Z
This is the transaction ID:
93d7087f7e7f1fbca60ca3cb03eb65a43109876672e589664cf687d67113c5e4
The merchant has kindly agreed to ship my product despite not having received the payment.  We are hoping to be able to track it down through CoinGate, but so far they are less than helpful.  If anyone has insight into how to track this payment, I would greatly appreciate it.  Bitcoin is so widely used, I can't understand how it can just vanish in the midst of a transaction.  Makes me wary of using it ever again as I just spent the better part of 5 days trying to sort this out.

Your bitcoin did not vanish; that is not possible. Either Coingate or the merchant will have the coins, and they certainly should be able to deal with a situation of a timed-out payment request being confirmed (this 'time out' period is written into the payment gateway code, not the bitcoin network code). In any case, I'm voting to close this as off topic because it is a customer service issue.

The transaction is clearly here: https://longhorn.bullpay.com/?gateway=2&data=93d7087f7e7f1fbca60ca3cb03eb65a43109876672e589664cf687d67113c5e4 However, when asking questions like this i'd suggest "I sent money from my wallet (put wallet address here) to this wallet address (put wallet address here). I sent "this much", how do i prove it. That's agnostic and the answer would be the link above. The transaction exists on the blockchain, the proof is: it exists, it is in the wallet you were told to send it to. The options there are have the owner of the wallet return it, or honor the payment.


text:
Bitcoin Pay-to-PubKeyHash (P2PKH) in multi-sig addresses
Can we send Pay-to-PubKeyHash (P2PKH) to an address which starts from 3 . I tried to send raw transaction to one of my coinbase address which starts from 3 but it send to completely different address which starts from 1 . How can I send transaction to address which starts from 3 ?

Sounds like you are trying to sent bitcoin to a P2SH address (beginning with a 3) at Coinbase.com ?  How are you constructing the transaction?

Can we send Pay-to-PubKeyHash (P2PKH) to an address which starts from 3

No.

How can I send transaction to address which starts from 3 ?

Construct scriptPub as OP_DUP OP_PUSH(bytes20) OP_EQUAL where bytes20 decoded from 3-address


text:
How does Bitcoin ETF is different from normal cryptocurrency investments?
I know ETF is a basket of securities which fund managers buys and then sell it to investors which contains percentage of each securities but in case of bitcoin ETF how does it operate since it contain only one asset Bitcoin ?

On one hand, you can purchase bitcoin (BTC). It is an asset that you can personally hold and verify as being authentic, and it allows you to engage in a censorship-resistant digital economy, making payments/etc to anyone, anywhere in the world.
On the other hand, you can buy a 'bitcoin ETF', or similar financial product. Such assets are generally purchased through traditional brokers, who are going to demand all of your personal information, and then they will hold the asset for you, so you will always be exposed to counterparty risk. As a holder of a bitcoin ETF, you can't really do anything with it, other than watch as the price of the ETF shares fluctuate (hopefully in line with the price of the underlying asset (BTC)), so that you can presumedly later sell it for more dollars/etc.

To put it differently, buying an ETF is like paying the post office to deliver your printouts of you email communications to your physical mailbox. You will get 'exposure to digital communication', while missing out on all of the actual utility of digital communication.

Thankyou for your detail answer. So for example GrayScale offers bitcoin ETF. Shouldnt there share value be pegged to bitcoin value  rather than hovering over 30$? https://grayscale.com/products/grayscale-bitcoin-trust/

@mohammadobaid, Grayscale has a lockup period and a maintenance fee which allows for market inefficiency.  Eventually the premium will go back to zero provided nothing dumb happens to their hodl.  ETFs are great for institutions who can't buy the real thing because of regulatory reasons.  But if you can buy gold bars, why buy certificates of gold bars.  Same thing with BTC.

Your definition of an ETF is partial. An ETF can also be a security "that can be structured to track the price of an individual commodity", like the BTC. Thant means "it has an associated price that allows it to be easily bought and sold". An ETF will be traded as a stock, in stock exchanges. It will allow traditional investors to invest in a commodity, without holding it and just because they need an exposition to it.
If we take Apple for example, they sell products which prices can be around 2000$. But, an Apple stock is traded around 172$, which means its value is not pegged to its products price, but rather to a mix of qualitative and quantitative informaton around Apple and its business.
That's the same thing for the Bitcoin ETF. Some fund managers want to be exposed to Bitcoin, but they don't want to buy it and hold it. Grascale would price an ETF, based on some information they are the only one to know, legally make it like a stock and link it to Bitcoin price. So, this ETF will kind of replicate Bitcoin performance on ups and downs as "the price of an ETF’s shares will change throughout the trading day as the shares are bought and sold on the market". So, for those investors and fund managers, buying a bunch of Bitcoin ETFs at 30$ each is like waiting for them to replicate the mouvement of the Bitcoin price at 40k$, as investors in both stock markets and crypto space have the same mindset and behavior, and also sensible to the same news (good or bad).


text:
How does Bitcoin get over the capital controls problem?
So, people now talk about Bitcoin as a store of value instead of as a currency. I'm confused as to how central banks will respond to this? Right now, bitcoin is not widespread. Assuming bitcoin becomes more used by financial institutes and ordinary people and starts to be comparable to Gold as a store of value (in terms of number of users), wouldn't central banks lose capital controls? That would be against the interests of every government on earth and wouldn't that create a huge incentive for governments to ban bitcoin? Thanks.

Bitcoin is hard, but not impossible, to censor so if governments really wanted to censor bitcoin transactions they could do it. Right now governments seem more interested in wooing bitcoin related businesses to their countries because they see it as something that can contribute to economic growth. But, yes, if they changed their minds they could shut it down.
However, what would happen if they shut it down? Would developers and users just give up? The answer is that we won't. We'll switch to crypto currencies that are even harder to shut down. Crypto currencies with anonymous ledgers like Monero. I don't think governments want that to happen. At least with bitcoin the ledger is transparent.
There is a historical precedent to this. Bitcoin isn't the first attempt to make a digital currency. I suggest you read about digicash and the problems it encountered getting traction. If governments push people will push back!

Upvoted, but note: there is a difference between censoring bitcoin use, and shutting down the network. It is extremely difficult (if not impossible) to completely censor bitcoin use: there are already several ways to interact with the network that don't depend on an internet connection (SMS, satellite, etc), and more ways could be invented if need be. Shutting down the network would be even more difficult, perhaps almost impossible.


text:
Failed to start lightningd.service: Unit bitcoind.service not found
I followed the tutorial https://medium.com/@meeDamian/c-lightning-node-on-rbp3-b950660fb835 without error.
When I type:
 sudo systemctl start lightningd
I get
 Failed to start lightningd.service: Unit bitcoind.service not found.
Note: Blockchain syncronization is not finished
Any idea?
thank you

At the top of this tutorial they say: This guide assumes you’re on MacOS, comfortable with terminal, already have a Bitcoin Full Node running on Raspberry Pi 3 (optionally with Tor) and now you want to also add a c-lightning node to it.
bitcoind.service not found means that you don't have bitcoin-core installed.

I have launched bitcoind as user "pi" and I can see the progressive blockchain syncronization (not still ended) in debug.log.


text:
Needing Instant (1-2 minutes) API / IPN for bitcoin payments
Basically I'm creating a autobuy in PHP.
I'm currently using coinpayments.net but their payments take 1-12 hours to send (which defeats the object of my autobuy). I'm needing to know of any way I can allow my payments to be done after 1-2 minutes so I can send the buyer their email with their order automatically.
I wrote to coinpayments.net and am waiting for a reply.
This should help you understand what I'm needing:

I'm creating a autobuy shop and am using your API / IPN to get callbacks from the users payments to determine the status (successful, or unsuccessful) payment. The problem is that when a user pays the bitcoins to the address on the autobuy, (in coinpayments), it takes about 6-12 hours for the payment to clear. This defeats the whole object of my website (an autobuy). Is there any way I can make payments be completed after 1-2 minutes if a user actually does pay correctly ?

I'm voting to close this question as off-topic because it's both 1) something concerning customer relationship with a company 2) it seeks for alternatives, which is "product or service reviews are off topic"

I'm guessing that your payment processor (coinpayments.net) is trying to construct bitcoin transactions with with lower fees, and therefore de-prioritizing confirmation times.  Perhaps their API offers the ability for you to prioritize your transactions by paying extra on the fee.  I know blockchain.info allows you to specify a fee if you are using their wallet API.  I'm sure others do as well.
Alternatively, you could run your own wallet/node and construct your transactions yourself with a higher fee.  It's a lot more effort, but depending on what you are trying to accomplish, it might be worth your time.
In any case, keep in mind that the bitcoin network averages a 10-minute block time, but does not guarantee it.  On top of that, the best rule of thumb is to allow for 6 blocks blocks of confirmation before considering a transaction irreversible.  For most payment systems, the values being transferred are so low that it's not necessary to wait for 6 blocks.  There are even plenty of types of purchases where so-called "zero-confirmation transactions" are perfectly acceptable.  This is what you will need to use if you want to send your email in less than 10 minutes.  You will have to judge for yourself how many confirmations you need, and what level of risk you are willing to accept.

authors: Ольга Лунина


text:
What should I do if my friend runs a Bitcoin business but doesn't understand how it works?
My friend doesn't listen to his head of engineering and doesn't fully understand how decentralized consensus based systems like Bitcoin really work. He seems to think a new untested/buggy implementation with conflicting consensus rules can be made to work with the existing implementations that follow existing consensus rules.
What advice can I give to him?

To your friend: "listen to your engineers or they'll quit";
To his engineers: "FYI: there are other crypto jobs where you'd be listened to"
¯_(ツ)_/¯

come on... can you keep the political attacks on other channels - this isn't even a technical question so much as it's rehashing what you do on twitter :(

He should listen to his engineer. I think that's just about it.

You may be approaching this from the wrong angle, if you want to directly jump to giving your friend advice.
It is my experience that conversations addressing strong convictions that aren't based on evidence can easily make people feel patronized or even antagonized. You'd have to find time with your friend to really share opinions in a non-confrontational way. This works best in a private setting and with a small group.
Try to create an open-minded atmosphere. You must be willing to listen to your friend, in order to find out what his understanding of the situation is and what he hopes to achieve. You may need to allow them to discover for themselves that they don't have a full understanding of the situation. Only when they actually question their conviction, there is a chance to introduce some new thoughts without them being dismissed. This is when you offer them a few points or question to think about, but don't ambush them with a compendium of information.
Alternatively, if your friend has very little time, you could get someone to compile a succinct yet encompassing report with presenting a balanced overview of all important aspects of the situation.
Alas, it may be that your friend will not be convinced by your effort. He may already assessed the available evidence and come to a different conclusion, or perhaps have different priorities in this situation than you. At that point you might find it expedient to agree to disagree, and let them make their own decisions. Perhaps they turn out to be right, or they'll have a chance to learn from their mistake.

People regularly confuse definitions of the word 'consensus'.  Consensus, the word generally used in conversation, can be construed as agreement reached after negotiation.  The term consensus in computer science applies multi-agent systems, and is everyone agreeing on something before all enforcing it.  You don't 'reach consensus' in computer science consensus, you enforce it.
Knowing this, the ability to change consensus rules in multi-agent systems is therefore difficult.  In order to change consensus rules, you even need to have a consensus mechanism for how you change.  There are two main ways you change consensus in a multi-agent system.  The easy way when there is no damage to be caused by stopping and starting the system, is to simply stop all agents, and replace all of the consensus rules with new consensus rules, and re-start the system.  In practice, however, with a consensus system like bitcoin, you don't have any control over the agent software (i.e. the client) that people are using.  They might, or might not, agree to your consensus change.  The second way is to have a consensus changing mechanism that allows the agents to change their rules over time, and only after an agreed time or agent version (again, consensus), and start enforcing the new consensus rules.
If you don't follow either of these processes, you will have agents that do not agree to your new consensus rules.  Whether you stop and re-start with the new rules (hard fork) or roll the changes out over time (can be soft or hard fork), if the agents in your system don't agree to the new consensus rules you're applying, you will never be sure that validation is occurring consistently.  In the case of bitcoin, where validation leads to blocks being added to the blockchain, if these validation rules are not consistently followed, nodes with different consensus rules will reject changes being applied by other agents, and start building on alternate blockchains.  This leads to a fork of the chains, where the different consensus systems only build on blocks that meet an agents consensus rules are considered valid.  There could be multiple chains caused in this eventuality.
In order to make a consensus change in a multi-agent system, you have to actually get agreement with the agents of your system (tough work) before you implement the change, and then hope that the agents agree with your consensus changes and change them in their agent software (i.e. their client).  So you need to ensure that your consensus changes are rigorously tested, because once they're out in the wild, it's very difficult to change them, even if there is a critical fault.

authors: قناه الاسطوره


text:
Time stamping of Transactions
In Bitcoin Blockchain, every block has a time stamp. My question is, Is there any time stamp on an individual transaction, once it is propagated on the network, and once it was included in the Block?

no, a transaction has no time stamp. Details can be found here: https://bitcoin.org/en/developer-guide#transactions


text:
Send payment from one user to another via API?
I am looking to have users on my website submit their  bitcoin id and be able to accept bitcoin from other bitcoin user as donations.
I am brand new to this. I'm using PHP.
So basically this is what I want to happen.
User A signs up on my website and gets a profile
User A enters their bitcoin address that they want to accept payments to
User B goes to User A's profile and selects to send bitcoin to them
My backend PHP code facilitates the payment from User B to User A and gets notified of a successful transaction.
From what I'm reading there are multiple places someone can have a wallet. Is there a centralized way to send to and from any wallet?

If User A enters their bitcoin address to where they want to receive payment, User B can directly send to User A. There's no need for you to facilitate the transaction.


text:
I need a bitcoin or usd payment for my site
Just service with simple API. I want to allow clients to pay usd or bitcoin. Then after payment complete i need to add my custom value on my site client purse. Is there simple system for it?
Back end server on java

Checkout the Coinbase API: https://developers.coinbase.com/
Coinbase is very well known and trusted.
Then for the USD option you could have another button that links to Paypal, Stripe, 2Checkout, etc..


text:
Do we have to pay transaction fee if we transfer bitcoins from one wallet to another ?
Can this be done for free?
also please mention wallets who do not charge transaction fee (if they exists)

also please mention wallets who do not charge transaction fee there are none. The wallets are not responsible for the transaction fees.

If you have the option to export the private keys from one wallet and import them to another, you can transfer funds between wallets for free. You should only consider this option if you fully control both wallets as any private key known to another party should be considered insecure and not used any further, so you'd want to move the coins to a key fully under your control anyway.
If you transfer funds by means of sending them from one address to another, it will always require a transaction fee to buy the necessary blockchain space to get the transaction confirmed. If you go this route, you may want to consider sending at a low feerate if you have the patience to wait longer for a confirmation to pay a lower relative fee.
Note: Many web-wallet services take full custody of your bitcoins, and do not keep funds in separate addresses for each user. Thus, they will be both unwilling and unable to provide you the private key for importing elsewhere.

So I have an Exodus Wallet - but you can’t cash out to your bank account on Exodus. I’m thinking of getting a coin base wallet to use moving forwards. If I want to move my existing coins from my exodus wallet to a coin base wallet, that would be free?

No, I doubt that Coinbase offers a wallet import. You will need to send a transaction. Unless you urgently want to sell, I would suggest that you use a lower feerate and wait, if you want to pay low fees.

I've added some more information to my original answer so that it would have better addressed your follow-up question.


text:
How can I recover my "unspent" bitcoin
I made a transaction since 10days ago to my Brother, But still not delivered to the receiver. It still remain "unspent" help me out on how to retrieve it.

can you provide the transaction id?


text:
How to get transaction fee
I have transaction id, how can I get a fee of this transaction from blockchain.info? For example I see that
this transaction https://blockchain.info/tx/https://blockchain.info/tx/963b9f407aabf8ebca660763bc5d3e8800eb6a5dffaf692cd061f0525ee770e1 has 0.00105453 BTC fee, but there is no such number in json data https://blockchain.info/tx/963b9f407aabf8ebca660763bc5d3e8800eb6a5dffaf692cd061f0525ee770e1?format=json
I'm new in bitcoin and I'm trying to write some scripts.
Thanks.

Sorry, I think I have found how to calculate transaction fee.
So we have to subtract sum of out values from inputs.prev_out.value.

it should be calculate from json out and input value subtract.


text:
Unconfirmed after 48 hours and counting still ... Someone please help me
https://blockchain.info/tx/ad9f5be7f893c8a2e6d977dce0367dcdaae20074c7eaa1f3ff288baf8f3a0059
I am new to this i have seen someone else accelerate anothers transaction can someone please help me with this i am new i didnt know about fees i left everything the way it was

The transaction has been broadcast and nodes have viewed it, so as for the moment; you'll simply have to wait.
If there are a number of blocks found quickly; which happens... there will be less transactions transmittted due to the short time interval / blocks found, and the node that mined the block will accept and confirm funds sent with low TX fees.
But the reason it's stuck is your fee is too low.
If it's not confirmed after another day or two, it will likely be rejected back and ignored, thus returned to the original address.
The BTC isn't lost, it's just the block size is only so big, and there are so many transactions taking place, that if you do not "bid" a high enough fee you don't make the cut list.
The nodes are all programmed now to accept transactions based on "highest fee first, downward, until max block size is reached.
There is no work around.

So how much of a fee would i have to add next time for the same amount of btc


text:
What are segwit extended key prefix bytes for regtest?
I need the HD version bytes for equivalent of ypub, zpub, Ypub, Zpub but on the regtest network.
I also need Ypub on testnet.
All the rest I can find in slip132, but it is incomplete.
thanks.


text:
Why doesn't bitcoin use bech32 encoding for transaction_id and block hash?
If I understand correctly, transaction IDs and block digests are typically hex-encoded in the bitcoin ecosystem including bitcoin-core RPC calls, block explorers, etc.
Meanwhile, bech32 encoding would result in smaller strings and also provides checksums.
I am wondering if there is any technical reason for hex encoding, or it is just a status-quo situation.
In other words, if bitcoin-core were to be written from scratch today, would we likely choose hex, bech32, base58, or something else for encoding hashes, eg block and transaction?

Bitcoin has used the same hex encoding for hashes since the very beginning. Any software written since then therefore also expects that same hex encoding. Bech32 was introduced nearly a decade into Bitcoin's life. To change all of the existing encodings to something else would simply break all software written for Bitcoin up to that point. That is simply not a reasonable tradeoff for something that is relatively unimportant.
Also bech32 is not much shorter than hex for representing 32 bytes of data. Although base32 is, bech32 includes a human readable part and a checksum, both of which make the length almost as long as the hex encoding, and neither of those is particularly useful to users.


text:
Low fee set by client
Hello I am using an old BitCoin client named MultiBit v.0.5.18. There is no option to change a fee. My transactions that I was send two days ago still in 'Unconfirmed status' and I guess here is a problem because I cannot move money from this wallet and may will never can do it.
The wallet set the default fee to 44.843 sat/B. It is lower for current time. I see the middle fee is 220 sat/b for now from https://bitcoinfees.21.co/.
How can I solve the problem? Is it possible to open wallet through another client? Electrum for example. Or I should wait when fees will go down (if not?).

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

I know that you are running multibit, not core, but the duplicate question still contains useful information.  You may want to think about asking a new question, like how to perform a --zapwallettxs with multibit.

A transaction with 44.8 sat/B should probably confirm most weekends, the fees had been dropping down to 5-10 in the last weekends. Sometimes even 1 sat/B transactions confirmed. This weekend the mempool seems pretty full, though.
AFAIK, MultiBit has an option to export private keys. However, MultiBit uses compressed private keys, while Electrum uses uncompressed private keys. Bitcoin Core understands either, so if you don't want to wait for the transaction to confirm, you could install Bitcoin Core to doublespend them. This comes with a wait time though, as you'd have to wait for Bitcoin Core to synchronize with the Bitcoin network which can take a few days. If you're time-pressed, I think Blockchain.info does allow importing keys also, although I would just use it then to send your money to electrum, so that you only relinquish control of your own funds as briefly as possible.

Can you elaborate about "transaction to clear"?. AFAIK unconfirmed transactions can not be "cleared". They stay around until eventually confirmed. Transferring the keys would not undo or clear a transaction neither, to my understanding.


text:
How do I flush the keypool?
After the heartbleed vulnerability, I'm concerned that my private keys could have been compromised.  I want to send all my coins to a new address with a freshly generated key.
However, if I just ask the Bitcoin Core client to generate a new address, it will just select one from the existing keypool.  The keypool keys may also have been compromised, so I don't want to use them.  I want a key that is really brand new.
Short of asking Bitcoin to generate hundreds of new addresses to exhaust the keypool, is there a way to flush the keypool and start getting fresh addresses?
I understand this happens when you encrypt a wallet, but I prefer not to do that.  (Anyway, if my wallet was already encrypted, that wouldn't be an option.)

Did you ever use the -rpcssl optiond of bitcoind, exposed to the Internet? Or did you ever use the Payment Protocol functionality in Bitcoin-Qt? If not, you're not at risk.

What I ended up doing was more or less what Pieter Wuille suggests: write a small shell script to call bitcoind getrawchangeaddress more than 100 times.  (Using getnewaddress would have cluttered my list of receiving addresses.)

If you call getnewaddress 100 times (via RPC for bitcoind, in the debug console for Bitcoin-Qt), the key pool is flushed.
After that, you can request one more new address and send all your funds there.

You have probably considered it already, but the only thing I can think of, is to create a new wallet.
Make a new wallet, and get an address from it

Backup your old wallet
Delete the old wallet from the Bitcoin directory
Start Bitcoin Core (it'll create a new wallet).
Copy a receive address from the new wallet.
Close Bitcoin Core

Transfer the bitcoins from the old wallet

Backup your new wallet.
Replace the new wallet in the Bitcoin directory with your old wallet.
Start Bitcoin Core
Send your Bitcoins to the previously copied address from the new wallet
Close Bitcoin Core
Replace the old wallet in the Bitcoin directory with your new wallet.

Keep the backup of the old wallet, to be able to check old transactional data, and addresses you've sent to, or if someone unexpectedly sends you bitcoins to an old address.

Of course you'd know the step-by-step, but maybe someone else would find it useful.


text:
How to determine first byte (recovery ID) for signatures (message signing)?
I do realize that in bitcoin when we return the signature result for signing a message the first byte includes information for recovering the public key required for verification using a formula like this:
27 + (4 if comp. 0 if not) + (0<=num<=3)

What I am struggling with is how do we determine that num number?
According to section 4.1.6 of SEC:1 for recovering public keys:

x = r + jn
Calculate Q based on R if invalid move to next
Calculate Q based on -R

Since j (cofactor of secp256k1) is 0 and 1 and there are two values for R. So there should be 4 possible public keys. Is num the number of public keys that we rejected before reaching the correct one? Because that is the only explanation that I can come up with based on comparisons I have made between signatures generated using Electrum and public key recovery I have done myself using SEC1.
Bonus question: Why was 27 chosen?

I'm not sure what num means there either, but I wrote this a while ago which might interest you.  It explains exactly how to encode and decode the recid byte :
https://github.com/fivepiece/sign-verify-message/blob/master/signverifymessage.md#encoding-of-a-recoverable-signature

@arubi Thanks for the reply. Based on your comment and another answer I've received on bitcointalk, I believe the main cause of my confusion is that I was thinking you find that num after signing and finding r,s. But it seems like you must find it during using the y coordinate of r which is discarded and doesn't come out of sign function. Now I am trying to figure out the details...

Dupe https://bitcoin.stackexchange.com/a/38909

FWIW this is what I have found regarding this question. Basically there are two ways of finding what libraries call "recid" or recovery ID. Most of them use the first method but there is another way:
Method 1:

Only requires r and s so it can be performed by anyone as long as you have the signature and the "message" that was signed.
It is so much slower because it has 3 scalar multiplication and based on cofactor of the elliptic curve used the whole operation may be repeated 2*(h+1) times, which is up to 4 times for bitcoin with secp256k1 curve (99% of the time it is 1 or 2 times).

The steps are explained in section 4.1.6 of SEC:1, I won't repeat them here.
To find recid you check the calculated public key with the given public key or hash of it and report number of rejected public keys as recid. For example if x=r+(0*order) and Q was used then recid=0 and if -Q was used then recid=1 and so on.
method 2:

It requires full r or R=(xR, yR) so it can only be done while signing (requires having the private key).
It is much faster because there is no additional calculations. It just needs value checks which are fast.
This is usually referred to as v in libraries

byte v = if(R.X > curve.N) then 2 else 0) | (if R.Y.IsEven then 0 else 1);
Basically it is check to see if xR is bigger than curve order (N) and whether yR is even or odd. Something that should not be forgotten is a "flip" that is performed based on s and whether s was used in the signature or -s
if s > curve.N/2 then v^=1 else do nothing
** Note that in the end you need to calculate the following:
recid = 27 + v + (if compressed 4 else 0)

IMO you should also accept this as the answer

This will be less of a theoretical answer and more of practical guidance; while developing Secp256k1 or Bitcoin libraries, I always found the following table handy:

y-parity
x-order
compression
recovery id
v

even
less than n
false
0
27

odd
less than n
false
1
28

even
more than n
false
2
29

odd
more than n
false
3
30

even
less than n
true
0
31

odd
less than n
true
1
32

even
more than n
true
2
33

odd
more than n
true
3
34

let me explain the columns:

y-parity or often just parity describes whether the y-coordinate of the public key point R(x, y) is even. this is important because in most cases, the signature only contains r = R.x and not R.y. This speeds up signature recovery. (Secp256k1)
x-order is a super rare edge-case where a point's x-coordinate is actually above the order of the curve n. In 99.99999999% of the cases, this is false. (Secp256k1)
compression is just an indicator whether you want a compressed or an uncompressed public key. (Bitcoin)
recovery_id just indicates which of the four potential point's y-coordinates is to be used. (Secp256k1)
v is how we encode this value. For uncompressed keys we use v = recovery_id + 27 and for compressed v = recovery_id + 31. (Bitcoin)

If you want to understand how this works for Ethereum, you would have to read EIP-155 which also introduces an additional variable of chain_id for replay protection: v = 2 * chain_id + 35 + recovery_id. (Ethereum)

What I am struggling with is how do we determine that num number?

That's the recovery ID from the table above.

There may be another method to determine the Recovery ID(rec_id). Since the Recovery ID can only have 4 possible values(0/1/2/3), if you already have the message to sign, public key, and signature, you can try each Recovery ID value and determine which one yields the correct public key value.
There is already an implementation of this function called "ecRecover". For example, in Python, you can use ecdsa_raw_recover from py_ecc library(source code). This function allows you to derive possible public key from the given Recovery ID:
def ecdsa_raw_recover(msghash: bytes, vrs: Tuple[int, int, int]) -> "PlainPoint2D":
    v, r, s = vrs
    if not (27 <= v <= 34):
        raise ValueError("%d must in range 27-31" % v)
    x = r
    xcubedaxb = (x * x * x + A * x + B) % P
    beta = pow(xcubedaxb, (P + 1) // 4, P)
    y = beta if v % 2 ^ beta % 2 else (P - beta)
    # If xcubedaxb is not a quadratic residue, then r cannot be the x coord
    # for a point on the curve, and so the sig is invalid
    if (xcubedaxb - y * y) % P != 0 or not (r % N) or not (s % N):
        raise ValueError("sig is invalid, %d cannot be the x coord for point on curve" % r)
    z = bytes_to_int(msghash)
    Gz = jacobian_multiply(cast("PlainPoint3D", (Gx, Gy, 1)), (N - z) % N)
    XY = jacobian_multiply(cast("PlainPoint3D", (x, y, 1)), s)
    Qr = jacobian_add(Gz, XY)
    Q = jacobian_multiply(Qr, inv(r, N))
    Q_jacobian = from_jacobian(Q)

    return Q_jacobian


text:
why did blockchain .info recovery not recover all transactions?
My phone was stolen. I went to recover my bitcoins that were in my Blockchain.info wallet with my pass phrase. I recover the wallet but it doesn't contain any of the transactions of the last 7 months. I was told the pass phrase would recover all my coins! What happened?

Check your address and see if the coins are there.

Yes they are there at the address I used to give out to receive them but they haven't been transferred to my new wallet in the recovery

Maybe you used an imported address or an old address thus it can't be found by the wallet software. Only the addresses generated using the new format (bip-39) can be discovered(are deterministic). Shortly said if you used legacy addresses the wallet won't discover them because they were not derived from  a bip-39 master/wallet key.

authors: Открытая Дорога маркетплейс


text:
Unable to remove bitcoins from watch-only address
I'm new to bitcoin and my situation is this: I installed Bitcoin Classic wallet, then sent bitcoins to it from Coinbase before the entire blockchain was finished syncing. The transaction timed out and the bitcoins never appeared in my wallet. A week later I tried reloading the entire blockchain, and the transaction came through to my wallet at that time. However, the bitcoins are listed as watch-only. I have tried dumping the private key for that address on console for my wallet, but the results continue to say that the private key for that address is unknown. What do I do about this? How can I make my bitcoins spendable? Any help would be appreciated.

See if your priv key really matches the address. You extract the priv key from the wallet with the dumpprivkey command. This should return the private key which will start with the number 5. This is the private key, that you can use to spend bitcoins. Attention: you will never (!) enter your priv key on a website to see if it is correct... You may also want to check the value of bitcoins on your address on blockchain.info. See if values are displayed. If yes, the privkey could be used to be imported in a new wallet, and then you'd be able to spend from there...

Thanks so much for the info.  So when I use the dumpprivkey command, the results always say "Private key for address ___ is not known."  So it seems I'm not able to extract the private key at all??

yup :-( Somehow the connection between your privkey and pubkey is broken, and the root cause can be many... I guess somewhere in the installation. Do you have a backup, that you could use, to bring back the first installation of your bitcoin wallet? This would be the only tip I have. Otherwise you'd run into data recovery issues, that certainly go beyon the communities goal here.

Thanks again. I guess I'll have to see if I can find a backup. If that doesn't work, or if I don't have one, do you have any recommendations of someone I can contact for help with data recovery?

@pebwindkraft No connection is broken. By definition a watch-only address is one you don't have (and never had) the private key for.

@PieterWuille  Do you know why the connection would have broken? I originally sent the BTC to an address that was not watch-only. I still have not resolved this problem.

@lobake Addresses never change from normal to watch-only. The only way it can have become watch-only is by you using the importaddress RPC. If you have not ever used that, please file a detailed bug report on https://github.com/bitcoin/bitcoin/issues. If you have, that's likely the issue and you likely never had the key for that address.


text:
Where does the US Dollar go when you buy a bitcoin? Not From Anyone but from CoinBase ect.
Ok, So I see A lot of people say that the bitcoin when purchased from one person to another that money gets sent to that other person in exchange for the BitCoin. Example If Bob has a bitcoin for 10 dollars and sold it to Jim, Jim would Pay 10 dollars to Bob for that Bitcoin. So what happens to the dollar when someone buys a bitcoin from cryptocurrency market. That money doesnt not vanish, so where does it go? It has to go somewhere. Its really confusing question hopefully someone can help me understand. Thank you.

"The Market" is not the one that sells and buys, it is a place (like an actual market) where sellers and buyers meet. So if you buy bitcoins in "The Market" you pay someone who owns those bitcoins and wants to exchange them for dollars.
After all transactions there are persons or entities selling and buying them.

When you buy a book from Amazon (directly, not from its marketplace), who gets the money?  Amazon gets it.  They can use the money to buy more books to sell to other customers, pay their employees, power their servers, etc.
When you buy Bitcoins from Coinbase, who gets the money?  Coinbase gets it.  They can use the money to buy more Bitcoins to sell to other customers, pay their employees, power their servers, etc.

Most commonly you buy Bitcoin through an exchange platform (BTChina, Huobi, Bitfinex, Bitstamp, etc.). Then, the dollar amount you pay is debited to the bank account that you previously connected to your exchange account.

@B.Marsh did I answer your question? You neither accepted my answer nor accepted it.


text:
How does the prune target size work?
Judging from the docs I understand that pruning, in laymen terms, only allows to get rid of information that cannot have any follow up transaction.
Now, how/why is it possible to set the prune option to a custom value?
What if 550 MiB would be too small, "cutting out" important information?

Judging from the docs I understand that pruning, in laymen terms, only allows to get rid of information that cannot have any follow up transaction.

That's incorrect.
The process for block validation (simplified) is:

Receive a block
Find all the block's inputs in the database of unspent outputs (the "UTXO set"), and verify them (signature checking etc)
Remove all the block's inputs from the UTXO set (as those outputs now become spent)
Add all the block's outputs to the UTXO set.

Once a block has been validated, and its effects been applied to the UTXO set, we don't generally need the contents of the block anymore, at all. Except for:

Giving it to other nodes on the network that are trying to figure out what happened in the past (which you can't do yet when in pruning mode)
Rescanning to find historical transactions in the wallet (e.g. after importing an address or a key), which is a feature you give up when pruning.
Reorganizations. Sometimes a block is found that is not a successor of the previous block we saw, but one that branches off further back. In this case we need to be able to roll back the effects of the last block(s) before validating the new block(s). In order to roll back, we do need the contents of the blocks again. This is the reason why the client forces you to keep at least 550 MB of block data, so that you can always rewind the last few days.

So TL;DR: It's technically possible to create a client that prunes to an arbitrarily small value, but to prevent clients from tripping over when a reorganization happens, the code forces you to keep a few days worth of data regardless.


text:
Is it safe to show the QR code to his friends?
I was opening my Jaxx wallet this morning and some of my friend made a pun saying they would take a phoyo of tmy QR code to buy some tickets with it. I was therefore wondering if it was safe to show the QR code ? What does it stands for ? Here is an example from the ETH forum.

It is your wallet QR code, so no, there are no problems that they have seen it..
Only thing they can do with this QR code is they can scan it and send you money :)
This QR code works like copy/paste on computer, so that user don't have to type in that long wallet address characters he can scan your QR code and the scan will return your wallet address code :)


text:
Which is more anonymous?
About bitcoin,
Which is more anonymous?
1.using mixing service(I heard there are many fraud)
2.buying with amazon gift card in Paxful

In some cases. Mixing services have actually been shown to be able to trace the inputs all the way through the many outputs until its final destinations.
Its hard work for a person, but there is software available that can do it with good success rate on several mixers
Buying some giftcard is closer to the more obscured route of transfers, where you simply change your currency into another, and use this until you need to change it back some other place. A gift card would probably give to big a loss. A far better improvement to this technique, would be to use one of the few cryptocurrencies that offer anonymity, like Monero or Dash. Then you could use the route:
BTC (1) -> Monero (1) ---anon-send---> Monero (2) --> BTC (2)
Of course if you are able to use Monero or Dash instead of Bitcoin, you can simply just keep these and skip the last conversion back to BTC. This will make it cheaper when using it as payment, since you don't get stuck with the extreme-fees situation that Bitcoin is facing right now.


text:
Electrum - low fee
Please help! I received .116 BitCoin into my Electrum account and then sent .115 BitCoin to my Dream market account. Annoyingly a low fee has appeared on Electrum (see screenshot).

I added another .0108 BitCoin to the Electrum account, believing it will force the payment through as there would be enough balance to see it through - but to no avail!The message I'm getting on Dream market is 'You have a pending incoming deposit of ฿0.115. The confirmation takes 20 minutes (2 confirmations) in average.' (see screenshot 2)

Is there a way to either cancel this payment and retry and force it through as it's been 27 hours now and I don't think that this'll right itself?
I've read other BitCoin forums with similar problems to what I'm experiencing, but I'm a real novice and reading some of the replies is like learning a completely different language.
Any easy solution with basic step-by-step guide would be much appreciated


text:
Copay Multi-Sig Wallet 2 of 3, possible issues
Copay wallet was created by one of the co signers. Is it possible for this co signer to change the 2 of 3 rule without approval from other co signers? Or add another new co signer without existing co signer approvals?

If such changes were made, the address would change so it would not effect you. You give out addresses that have a specific set of signers and that cannot change. A different set of signers would be a different address, and if you do not know about this different set of signers, you would not have these other addresses to even give out.
So no, it is impossible for a co-signer to change the other signers nor is it possible to add more co-signers to a given wallet.
It is possible for a co-signer to create a new set of addresses with other co-signers added and then give out those addresses. But unless you were specifically told about this, you would not be aware that you could sign for those addresses.


text:
Ardor Lightweight Contracts: (Almost) trustless way with new Phased Transaction type?
I asked that question on Bitcointalk, but got no response so far. As Lior has proposed to make Stackexchange the main medium of exchange about Ardor I'm asking here.
As I read in the FAQ, the main drawback of Lightweight Contracts is that they are not totally trustless, because you cannot guarantee the "contract owner" really runs the contract.
So for example, if the contract is an "exchange contract" that should give you some token for ARDR (e.g. this IGNIS/ARDR exchange), then if the contract owner doesn't run the contract, you won't get the tokens (and the contract owner could steal your ARDR).
You can run the contract yourself, but AFAIK you can't achieve that the "contract owner" signs the exchange transaction without himself running it - you can only validate that the contract does what he should do according to the source code. (Correct me if I'm wrong here.)
But perhaps you could do the following:

You first run the contract yourself and calculate the "expected transaction" that should result from it, based on the input from your planned transaction (in this case, the transaction that rewards you with tokens from your ARDR).
You now issue a phased transaction ("conditional transaction") with the condition of the "expected transaction" - in the exchange case, that you receive the calculated token amount from the contract account.
If the contract doesn't run or doesn't give you the expected token amount, the transaction expires at some block in the future.

This way, the contract owner can only spend the resulting coins when the contract owner runs the contract. So you are safe from "selective scammers" that run contracts once and then never again.
The contract owner is also safe: The contract should be possible to be constructed in a way to check first that it really is able to produce the desired transaction. If not, then he simply doesn't issue the "expected transaction". So nothing happens (only that we have an useless phased transaction recorded on the blockchain, but I think that is a minor issue, and it creates the incentive to only trigger the contract with possible conditions).
Is this scenario possible? I haven't read it in the discussions about Lightweight contracts. If not, I think it would be a nice addition, as then Lighweight Contracts would be as trustless (or almost as trustless) as Ethereum Smart Contracts (or even more, as Ethereum contracts can run out of gas).
AFAIK it would need a new type of Phased Transaction - one similar to the one requiring a linked transaction, but with the ability to not  require the complete transaction hash (which is impossible to calculate in this situation) but the "unsigned" transaction or the amount of a token/coin to receive.
Cheers, d5000

One idea how to solve it works like this:

The sender submits the contract trigger transaction as phased with a reveal secret approval model based on the hash of a secret it generates.
The contract activated by this trigger transaction, submits the response transaction(s) with a composite approval model composed of the same hash of the secret used by the trigger transaction and the trigger transaction full hash.

What happens next is the following:
If the sender approves the trigger transaction, it can also approve the contract transaction since they rely on the same secret.
If the sender does not approve the trigger transaction both the trigger transaction and the transaction submitted by the contract expire.
If the sender tries to approve the contract transaction but not approve his own transaction, the the contract transaction won't be approved since it also relies on the trigger transaction full hash which is not approved in the blockchain.
To implement this we need at least two changes to the existing design:
1. Trigger a contract by a phased transaction which is not approved yet, which is currently not supported.
2. Enhance the by transaction full hash approval model so it has an option to only become approved if the full hash represents a phased approved transaction and not just a transaction stored in the blockchain like it is now.

Thanks! Your solution looks much better than my original proposal, because the complicated checks for the contract runner to be safe from disapproval by the sender would not be necessary.
If the sender is satisfied with the response, everything gets approved - and if not, then everything gets discarded.
Looking forward for this to be implemented :)


text:
How to make data inside blockchain immutable
I want to do simple blockchain implementation on golang, i have mongodb database with user info (Name, cardID, etc.) i want to store several information inside blockchain, and to put it inside another database BoltDB. But idk how to make this data immutable I mean how to make changes visible, for example I insert one user with (Name: Jhon, CardId: '777845') inside blockchain and after some time another guy will change this User's fileds (Name: 'Jhon', CardId: '1111'), and inside my blockchain it still will be (Name: Jhon, CardId: '777845')

A blockchain's data is immutable by definition. What are you trying to do that's not working?

I have one database (MongoDb) from that db I am fetching New coming users, and store it 'in a blockchain' another DB (BoltDb) -> i did it exactly like here https://github.com/Jeiwan/blockchain_go, my issue is it possible to check for changes in mongodb. if  someone will change data inside MongoDb, but i have already stored this data inside my second db, i want to see what have changed

A blockchain has nothing to do with mongodb. As long as your data is in the chain, it is not possible to retroactively edit it. You can add new blocks with other data, but the existing blocks are immutable. You should be able to compare the data in existing blocks with the data in your mongodb to check if it has changed

A blockchain is not intrinsically immutable. What prevents malicious people propagating altered data in the blockchain is that all nodes validate received blocks.
In particular they check the checksums and they check the signatures match the public keys. They check the references (hashes of prior blocks) and they examine the length of competing branches to decide which blocks to trust.
The integrity depends on there being a large number of nodes with no central trusted authority and with no one person or organisation controlling a majority of the computing power.
If you only have a handful of nodes, the blockchain may not be inherently trustworthy.

so to validate if changes happend i have to iteratete through each block inside blockchain and calculate hash again?

@CreatingDED: Essentially yes. You can cache stuff locally and securely for later reuse.

@CreatingDED That is not the only way to do it, but that is one way to do it. You want, somehow, to arrange it such that every machine relying on the data to be immutable verifies that every proposed change to the data is permitted by the system's rules such that no honest node that correctly executes the system's rules itself can ever be tricked into accepting data that is not valid according to the system's rules.


text:
How to convert fee_estimates.dat into a human-readable format?
I would like to take a look inside fee_estimates.dat to understand a bit better how the RPC command estimatesmartfee works. However, when I open the file in a text editor, the content is not readable.
Is there a way to read the information inside fee_estimates.dat?

You need to take a look at how fee_estimates.dat is written and interpreted. It is a binary file composed of:
MIN_VERSION
CURRENT_VERSION
CURRENT_TIP
TIP_AT_LAST_START
TIP_AT_LAST_STOP
[ESTIMATES]
[STATS]

With CURRENT being "when writing", i.e. when stopping bitcoind.
Here is the method writing the file, and here is the method reading this file (at startup). I think the latter can help you to parse it.


text:
Flatpak bitcoin-core not generating .cookie file
I'm using the version of Bitcoin-Qt 0.18.1 that comes with Flatpak. I've looked in the Bitcoin datadir, which is in ~/.var/app/org.bitcoincore.bitcoin-qt/data/ and there isn't any .cookie file there. This is preventing me from running Electrum Personal Server.
My Linux distro is MX Linux.
My bitcoin.conf is empty.

The GUI does not start the RPC server by default. To make sure the RPC server is running, pass the -server=1 flag on the command line or set server=1 in the Bitcoin Core config file.

I ran bitcoind from Flatpak and it outputted the .cookie file


text:
How to achieve fast mempool synchronization at startup?
I just started my 'occasional' full-node and I am watching the size of the mempool grow after full block synchronization - watch -n 3 'bitcoin-cli getrawmempool true |jq "length"' - it has around 4000 pending transactions. My 'continuous' full-node, however, has around 18000 pending transactions which seem to never become available to my 'ocasional' node.
Looks like that when a node starts up it will receive the new transactions that arrive at the mempool, but the old transactions that had been laying there are never 'synchronized'. How can I synchronize the mempool of a recently launched node with the one of its peers?
I could shut down my other full-node and copy past mempool.dat into my other node but this solution is very ugly as I need to shut down a long-running node with many connections.

Why do you think it matters?

off the top of my head: fee recommendations with custom code, setting up your electrum server and proving up-to-date intormation, fee bumping transactions made on your mobile wallet through bitcoin core,...

Fee estimation wouldn’t work if you stuffed the men pool suddenly with old transaction. Electrum servers won’t be started and stopped frequently.

Fee estimations made by looking at the current size of the mempool would work with old transactions (not bitcoin core recommendations, that's why I wrote 'custom code'). For example you could recommend a fee that is at the top 0.8 vMB of the mempool.

If you're writing custom code you can surely just not have an "occasional" node.

Yes, but like I mentioned I have a continuous node and an occasional one. Anyway, I think I found a solution, which is far from ideal but it works. It is to get raw transactions from the mempool through an external API and then broadcast through my node.

You have a perceived issue with a piece of software you running in a bizarre way given your intentions. The easy solution to your perceived issue is to not do that.

mempoolcp command line utility is what you are looking for:
https://github.com/dev7ba/mempoolcp

Cheers, I'm surprised someone tackled this 3 years after! Ideally a tool like this would be integrated into bitcoin core, but we all know it's hard to get code merged there.


text:
bitcoin-cli not working
Whenever I try running some command like:
bitcoin-cli getinfo
The prompt just hangs and does not return anything, similar to SQL interface if you do not enter semicolon.
Running only "bitcoin-cli" returns the help screen but running any command just hangs and need to press CTRL+C to get back.

Many commands block the daemon from responding to requests, and during startup you'll not get responses while the node is initializing.

actually the bitcoind was restarting continuously in background due to error, once the error was fixed, everything worked.


text:
Can two related "spends" be in the same block?
Consider the case where:

Address A has some BTC.
Address B is empty/zero.
Address C is the intended recipient.

B sending to C is invalid on its own, but does make sense if associated with A sending to B first
Can two dependent transactions be put into the same block and accepted?

A ==> B
B ==> C

(Since the net result will be OK, even though the second transaction does not make sense until the first one is completed)

Yes, but only if A -> B is placed before B -> C in the list of transactions.
Here is a graph of the percentage of transactions spending each other in the same block, it is usually around 10%.

So even within a block, there is a strict ordering of transactions?  I had been under the impression that blocks were ordered, but transactions within a block were unordered!  Very interesting. Thanks.

Actually, there are a substantial amount of such transactions :) Slightly related: https://eprint.iacr.org/2019/611 discusses those transactions as UTXOs created and spent in the same block reduce the size of the proofs

@abelenky No, there is no strict ordering, at least for Bitcoin. The answer states one of the three requirements: 1) this answer 2) the coinbase tx comes first 3) no duplicate/invalid/double-spend transactions. There are usually multiple possible orderings satisfying these requirements.


text:
Reward seems to be wrong?
I understand the current BTC "reward" for mining is 12.5 BTC.
I found these two blocks (one , two) where the newly generated coins seems to be 13.5 and 14.5.
I don't see a 12.5 BTC reward, and these transactions look like rewards, but have the wrong amount.
What am I mis-understanding?

fees?..........

I do not think fees should show up under "No Inputs (Newly Generated Coins)"; I believe fees should come from each transaction, yes?

Yes, and they do, but the address that receives them is not listed in the individual transactions.  They are simply tacked on to the coinbase transaction.

the fees of other transactions from this block go to the miner adding to the block reward

I should point out, however, that any value added to the coinbase transaction is still restricted in use, so can't be used again for another 100 blocks.  In that way, this value is very much like newly generated coins.

The block reward is collected as one or multiple outputs in the coinbase transaction. These funds are subject to a 100 block maturation period.
The block reward is composed of two parts: The block subsidy, which is 12.5 BTC currently, and the collective transaction fees from all transactions in the block. Since the transaction fees are about one and two bitcoins in the blocks that you cite, block rewards amount to 13.5 and 14.5 BTC respectively.
Unfortunately, "block reward" is used inconsistently. Some use it for the "block subsidy" while others use it for the total coinbase output.

I think you forgot to read this:

and this:

Remember that fees from the transactions get added to the coinbase transaction and sent to the coinbase address.  It's a bit confusing, since Blockchain.info is labelling the whole coinbase transaction as (Newly Generated Coins), even though some of that value comes from fees, and therefore pre-existing bitcoin.

authors: هادی قره گوزلو


text:
How can i check bulk BTC address balance?
I'll appreciate some suggestions for online resources or software that can be used to check/monitor a few thousands of BTC address. Thanks

Easiest way would be to simple import the addresses into Electrum.  It's an SPV (light-weight) wallet with no need for blockchain downloads.

Go to Bitcoin.org and select "choose wallet"
Click Electrum from the list and follow the installation instructions.
When you start Electrum choose to start a new wallet (default, hit next)
Choose "Import Bitcoin Address" then hit next
Hit the folder icon in the bottom of the import window and import the file containing the thousands of addresses.

Since you are only dealing with public addresses you don't need to worry.  To future readers... always be cautious of downloading wallet SW.  It is a primary target for those looking to defraud you.  There are some browser plug-ins that can help and some good common sense.  Just be cautious.

To check multiple crypto addresses, consider these free online tools:
https://bitcoindata.science/bitcoin-balance-check
(can check up to 480 addresses).

https://www.homebitcoin.com/easybalance/
https://awebanalysis.com/en/bitcoin-multiple-address-check-balance/

Monitoring in real time or maybe regular snapshots....not sure. Another post suggested importing addresses into Electrum wallet.


text:
Question about modify Vanitygen
I follow the instruction on this post to create bitcoin address from given hex private key
In vanitygen.c
Replace
EC_KEY_generate_key(pkey);

with
  BIGNUM *res;
        BN_init(&start);
        res = &start;
        BN_hex2bn(&res, "3B1BCC5A67F38853810972B1DA8A67148FAD78C6CD6F22B2C823D141BE59C81C"); //Set up hex private key
        vg_set_privkey(res, pkey);

& remove case
if (++npoints >= rekey_at){}else{}

The input key will be replace with hashcat feature like this
"?1?1?1?1?1?1?1"+"A67F38853810972B1DA8A67148FAD78C6CD6F22B2C823D141BE59C81C"

I test it with single key first & notice the function still multiply the key which give a slightly different private key from the original & use my restore function, it only generate few hundreds actual private key & multiply the rest. No matter how i edit the "ptarraysize" value, it doesn't make CPU run on 100% power. Is anybody know to how to adjust the code to check address from mutiple generated key without multiply it. If possible, the performance will stay around like original vanitygen code or at least decline to 1-20 times, i wouldn't mind that. Thank You


text:
Bitcoin core's estimatesmartfee gives same estimate on ECONOMICAL and CONSERVATIVE mode
I have observed this behavior several times before now, the commands bitcoin-cli estimatesmartfee 2 ECONOMICAL and bitcoin-cli estimatesmartfee 2 CONSERVATIVE give the same estimates.
For example, now I get:
>bitcoin-cli estimatesmartfee 2 ECONOMICAL
{
  "feerate": 0.00173558,
  "blocks": 2
}

>bitcoin-cli estimatesmartfee 2 CONSERVATIVE
{
  "feerate": 0.00173558,
  "blocks": 2
}

>bitcoin-cli estimatesmartfee 144 ECONOMICAL
{
  "feerate": 0.00036069,
  "blocks": 2
}

>bitcoin-cli estimatesmartfee 144 CONSERVATIVE
{
  "feerate": 0.00036069,
  "blocks": 2
}

I can increase the number of blocks even higher than 144 and I get the same result both. My node has been running uninterrupted for a long time so I found no reason for these values to be wrong. However, what's the point of having two modes of estimating fees if they give the same

The two modes don't just unconditionally return the same thing. They do different calculations and can return different results under certain conditions, particularly when fees are very variable for low confirmation targets. The current fee situation just makes it so that the estimator ends up using the same values for both modes.