What is the difference between policy and consensus when it comes to a Bitcoin Core node validating scripts? What is the difference between policy and consensus when it comes to a Bitcoin Core node validating transaction scripts? Can you give some examples of checks that are considered policy and checks that are considered consensus?
This question was asked during this Bitcoin Core PR review club session on PR 19698.

The term "consensus checks" refers to the rules that determine whether a block is valid; specifically, if a consensus check on a block (or a transaction contained within a block) fails, then the block is considered invalid.  If we get to the end of the block and none of the consensus checks has failed, then the block is valid.
Policy checks are a superset of consensus checks (meaning that policy checks are in addition to consensus checks, so that passing policy checks implies passing consensus checks), and policy checks only apply to transactions that are being considered for addition to the mempool. The purpose of policy checks is generally to (a) close off DoS vectors and (b) to make future consensus changes safer to deploy, by preventing relay of transactions that would violate such future consensus changes well in advance.
You're specifically asking about transaction script checks, but note that there are many policy (and consensus) checks on transactions that occur outside of just script validation.  Also, the links in your question are to the "policy/" and "consensus/" subdirectories in Bitcoin Core's source tree, but there are many policy and consensus checks that happen outside of those directories.
Here are some examples of policy checks in script validation, that are not (yet) consensus checks. These first ones are from BIP62, which proposed a set of rules to limit transaction malleability.

STRICTENC
LOW_S
SIG_PUSHONLY
MINIMALDATA
CLEANSTACK

Here are some policy checks relating to making softfork deployment safe in the future:

DISCOURAGE_UPGRADABLE_NOPS
DISCOURAGE_UPGRADABLE_WITNESS

There are some miscellaneous other policy script checks, such as requiring that all pubkeys in segwit scripts be compressed, or that inputs to OP_IF/OP_NOTIF be minimally encoded. And then of course all future consensus changes (such as Taproot changes) that have not yet been activated on the network are policy checks as well. An (almost) full list of what transaction script validation checks are performed as part of policy checks when a transaction is being validated for the mempool can be found here. (Note that this list includes consensus checks as well.)
However that is not quite a complete set of transaction script validation rules that are enforced as policy checks. During mempool acceptance, we perform other checks on a transaction as well, some of which depend on a transaction's scripts. Some examples of these include:

Non-p2sh, non-segwit spends must be P2PKH, P2PK, or bare multisig
scriptSig or witness must be no more than a given size
Various rules on outputs created (no more than one OP_RETURN, must be P2SH/v0 segwit/P2PKH/P2PK/MULTISIG, value must be above dust threshold)
Limits on how many signature checks are performed by the transaction

There are a lot of these to list, but tracing the code in mempool acceptance (particularly here) and inspecting functions like CheckTransaction, IsStandardTx, and CheckTxInputs should yield the remaining policy script checks, on top of the ones enforced inside the script interpreter.
Transaction script consensus checks are a much smaller set. Some of the script flags that are now consensus checks include:

P2SH
DERSIG
NULLDUMMY
CHECKLOCKTIMEVERIFY
CHECKSEQUENCEVERIFY
WITNESS

The full list (with enabling conditions) can be seen here. Note that as consensus rules have changed in Bitcoin's history, not all the script flags mentioned in that function are enabled on all blocks.
Most (all?) of the remaining consensus checks performed on transactions can be found in ConnectBlock(), CheckBlock(), and ContextualCheckBlock().


gettransaction (The remote server returned an error: (500) Internal Server Error.) Im trying to get how many confirmations a transaction has. However I just get error when I try to get gettransaction.

http://block-explorer.com/tx/e15e0edd6d6b07531c146a91528ba628b28d37acb28e6a271a563a2284092e16
GetBlock works fine with the transaction here.. also getrawtransaction works.

However when I try gettransaction I get this error.
The remote server returned an error: (500) Internal Server Error.

This is how my request looks like
{"id":"0","method":"gettransaction","params":["e15e0edd6d6b07531c146a91528ba628b28d37acb28e6a271a563a2284092e16"]}

Any ideas of what Im doing wrong here?

Doesnt work for transactions that are not your own.


What is the Design of Bitcoin storage? How is bitcoin network stored and shared across the network? For instance, where is the data of UTXOs for each wallet is maintained?

What is the Design of Bitcoin storage?
  where is the data of UTXOs for each wallet is maintained?

There's no need for every wallet to use the same storage format. The precise details of the storage format may be proprietary secrets or may be undocumented other than in the source code for that specific wallet.

This question could only be answered with some certainty for a specific version of a specific wallet.

  How is [the blockchain] stored ... across the network?

Every full node keeps a complete separate copy.

Lightweight nodes (SPV etc nodes) each maintain a pruned copy of the blockchain that only contains blocks with unspent transaction outputs.

  How is [the blockchain] ... shared across the network?

That is a rather separate question, there's probably an answer already here for that. Its probably described in Nakamoto's original whitepaper which is easy to find.

See also

How are transactions broadcast to the rest of the network?
https://en.bitcoin.it/wiki/Network
https://en.bitcoin.it/wiki/Protocol_documentation

which contains information of this sort:


How does Ethereum achieve consensus? It appears that Ethereum will start out with PoW and switch to PoS later. If I remember correctly, the block interval is planned to be fairly short in Ethereum. How does Ethereum manage to achieve consensus?

Ethereum achieves consensus using Proof-of-Work. This was true in the initial "Olympic" testnet (0.9), in the first "Frontier" release (1.0) and in the second "Homestead" release (1.1).

The upcoming "Metropolis" release (1.2) will also keep the consensus to be achieved by Proof-of-Work. The used algorithm is called Ethash, and it was created specifically for Ethereum.

It's hard to speculate about how the roadmap after that will be, but it is announced that at some point a release called "Serenity" will introduce a hardfork which updates the network to find consensus by utilizing Proof-of-Stake.

The Proof-of-Stake algorithm is still being developed by Vlad Zamfir and is called Casper. which is a security-deposit based economic consensus protocol. This means that nodes, so called bonded validators, have to place a security deposit, an action called bonding, in order to serve the consensus by producing blocks.

In Casper style proof of stake anyone can participate in block production by posting a bond. After posting a bond you have an opportunity to bet on which block will be included next. The incentives are such that you make money by betting with the eventual consensus and lose money by betting against the consensus. Any cryptographically provable misbehavior results in the forfeit of the bond.

At the bottom line of this post, it's worth to note that the Ethereum network is poised with a difficulty bomb which increases the difficulty exponential after a certain time of mining and it will hit around the beginning of 2017. This will make the network basicly stop mining if no hardfork to Proof-of-Stake or any other solution will be scheduled before.


what is wrong with this litecoin transaction? getting "tx rejected: (code -22") raw hex:

0100000001390210797248b4f5a4a6c0fbcbde14a3ea132bdbfedb07aea35bff5cfc0766b1000000008a4730450220035db00b2bed0e4e97b92b9ee3610587110041c0e71f99b4563fe990d1a5a2b0022100ded70700477d36e7867dfb11842e86ef95e06e5fe910f4334730195493b362da41041862f45bcd7f2a0a8b2f1d24effdcede809ba4f46a78e5baac43ae0c0f6c651ceb02db5a9527ca9e722a4aca51284d6ee36408625b3463c68abfe3b5740aa42cffffffff0140420f00000000001976a914bee3bbfdad113a061739375edcfe6a908c096c7088ac00000000

I got this handcrafted tx from somewhere. I want to know why it is not being accepted.
From sendrawtransaction in litecoin-qt, I get TX rejected (code -22)

EDIT: I missed a zero in the beginning. Fixed it

Here is what I get using decoderawtransaction

{
"txid" : "a3de612bfa175d4c688648e205644305561f7d2cd96ae6a4ad23cabac4e3b887",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "b16607fc5cff5ba3ae07dbfedb2b13eaa314decbfbc0a6a4f5b4487279100239",
"vout" : 0,
"scriptSig" : {
"asm" : "30450220035db00b2bed0e4e97b92b9ee3610587110041c0e71f99b4563fe990d1a5a2b0022100ded70700477d36e7867dfb11842e86ef95e06e5fe910f4334730195493b362da 041862f45bcd7f2a0a8b2f1d24effdcede809ba4f46a78e5baac43ae0c0f6c651ceb02db5a9527ca9e722a4aca51284d6ee36408625b3463c68abfe3b5740aa42c",
"hex" : "4730450220035db00b2bed0e4e97b92b9ee3610587110041c0e71f99b4563fe990d1a5a2b0022100ded70700477d36e7867dfb11842e86ef95e06e5fe910f4334730195493b362da41041862f45bcd7f2a0a8b2f1d24effdcede809ba4f46a78e5baac43ae0c0f6c651ceb02db5a9527ca9e722a4aca51284d6ee36408625b3463c68abfe3b5740aa42c"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.01000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 bee3bbfdad113a061739375edcfe6a908c096c70 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914bee3bbfdad113a061739375edcfe6a908c096c7088ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"LcdHTvKV5PNBbhcHrd1h3QRNcJLsxkfUfd"
]
}
}
]
}

EDIT: could be a problem with signatures. Can someone verify if the signatures are correct. I don't know enough about the litecoin protocol to do it myself.

It looks like these are freshly mined Litecoins that have not matured yet, you need to wait until they mature to spend them. Maturity refers to the number of confirmations that newly mined coins need to have. For Litecoin (and Bitcoin) this is 120 blocks.

(See a discussion related to this here: https://github.com/litecoin-project/litecoin/issues/26)

So you won't be able to spend these coins until those blocks get mined. But at the rate that Litecoin blocks get solved that would be around 4 hours, which means that same transaction might work now.


In Math or Python notation - How to convert bits to difficulty? Questions

What are the equations to convert between bits and difficulty?

&

understanding bits and difficulty in a block header

ask how to convert between bits and difficulty. Unfortunately, I do not get the answers because I do not know C (I think it's C) and apparently lack CS knowledge.

Could anyone show in mathematical notation or in high-level code (Python?) how to convert for example the 392009692 bits to the difficulty of 3,007,383,866,429.73? as in block

https://blockchain.info/block/00000000000000000025c089d0a7b2bf6241888c4dd90ab7a4c4baa6a2823551

Thanks a lot!

This snippet converts the nbits integer as appearing in your blockchain.info link to the difficulty

def nbits(num):
    # Convert integer to hex
    hexstr = format(num, 'x')
    first_byte, last_bytes = hexstr[0:2], hexstr[2:]
    # convert bytes back to int
    first, last = int(first_byte, 16), int(last_bytes, 16)
    return last * 256 ** (first - 3)

def difficulty(num):
    # Difficulty of genesis block / current
    return 0x00ffff0000000000000000000000000000000000000000000000000000 / nbits(num)

>>> difficulty(392009692)
3007383866429.732


How do I reduce the loglevel on rippled? By default, rippled seems to log at the NFO level, which spits out many megabytes of log files each day. How do I reduce this level? According to the Ripple wiki, we can edit pass arguments to rippled when starting it, or edit the configuration file via [rpc_startup], but neither of these methods had any effect for me (on v0.23.0).

You can put the following in your rippled.cfg file:

[rpc_startup]
{ "command" : "log_level", "severity" : "error" }


Where can I register a domain and pay with bitcoins? Where can I register a domain name and pay with bitcoins?

(The question is about usual domain names, not .bit maintained by the namecoin network.)

Note that all services need to be checked by you somehow to decide whether you can trust them!
There is a list of such services at https://en.bitcoin.it/wiki/Trade#Domain_Name_and_DNS_Hosting; for example:

http://www.domains4bitcoins.com (com, net, org, co, co.uk, in, biz, us, eu, mobi, asia, name, tel, co.in, tv, me, info, ws, bz, cc, org.uk, me.uk, net.in, org.in, ind.in, firm.in, gen.in, mn, us.com, eu.com, uk.com, uk.net, gb.com, gb.net, de.com, cn.com, qc.com, kr.com, ae.org, br.com, hu.com, jpn.com, no.com, ru.com, sa.com, se.com, se.net, uy.com, za.com, gr.com, co.nz, net.nz, org.nz, com.co, net.co, nom.co, ca, de, es, com.au, net.au, xxx)
http://bitdomain.biz (biz, com, com, org, info, us, eu, in, mobi, asia, name, tel, tv, me, ws, bz, cc, mn, ca, de, es, com.au, net.au, xxx)
http://www.cinfu.com/domains/ (com, net, org, biz, info, eu, in, us, de, ru, es, asia, bz, ca, cc, co, mn, mobi, name, me, tel, tv, xxx, *.uk, ws, la, tw, cn, ac, io, sh, nu, be, tc, vg, ms, gs, jp, at, am and more 2nd level domain)
http://www.exoware.net/domainregistration.xhtml (com, eu, me, org, me.uk, de, es, co.uk, net, name, info, org.uk, cc, tel, ca, biz, tv, co)
https://www.kalyhost.com/domain.html (many different top-level domains
https://clients.microtronix-tech.com/domainchecker.php (not so many top-level domains)
https://secure.orangewebsite.com/cart.php?a=add&domain=register (not so many top-level domains)
http://www.privacyshark.com/ (anonymous, but not clear which top-level domains are offred)
http://www.frankdomains.com/btc (all top-level domains and all European TLDs e.g. .com, .xxx, .travel, .at (Austria) through to .com.ua (Ukraine) and all countries inbetween Also all New gTLDs as they come online)
https://www.namecheap.com/support/payment-options/bitcoin.aspx (Namecheap: Many TLD's)
...

More offers:

https://www.domenburg.com (Instant registration after 1 btc confirmation, 500+ TLDs: ru, com, net, org, co, pro, in, biz, us, eu, mobi, asia, name, tel, co.in, tv, me, info, ws, bz, cc, ca, de, es, ...)


How do I run Separate Mining Devices With BFGMINER? I have 2 devices plug into my computer.
The 1st device is the USB block erupter.
The 2nd device is the BFL machine.

When I run the BFGminer, I only want one device to mine at one pool and the other device to mine at another pool?

How do I do that using BFGminer?

I do this by running two copies of BFGMiner and using the --scan parameter to specify which devices are used by each miner.  In my case, I have a bunch of USB Block Erupters and a BE Cube.

One BFGMiner specifies '--scan none' and '--http-port 8330' to support the BE Cube (which connects over the local network).

The other BFGMiner specifies '--scan-serial erupter:all' to support the USB erupters.

This is also useful when the devices vary in hash power.  I set the USB erupters to difficulty 4 while the BE Cube is set to difficulty 16.


Is guadagnarebitcoins a scam? I found this site:

http://guadagnarebitcoins.altervista.org

What do you think? Is it a scam? Are the things listed on it scams?

The site covers two topics:

A basic introduction to Bitcoin
How one might be able to obtain Bitcoin for "free"

I'll discuss only item 2.  Several possibilities for earning Bitcoin are presented:

Mining
Performing sponsored actions
Using certain services that offer Bitcoin as an incentive
Performing mechanical turk tasks
Investing
Betting

The page at guadagnarebitcoins.altervista.org does not itself offer any service, and appears to simply offer information.  Therefore, the site itself is not a "scam."

However, as the site references a number of different third-party sites and services, you may find that your experience with those individual sites  will vary along a continuum of legitimacy (or lack thereof).

All of the proposed methods involve some non-zero amount of effort.

Considering the proposed methods ideally involves a good deal of judgment, self-knowledge, and reflection with questions like:

Will mining result in the profit I think it will?
Is this a good ROI for my time and money?
How much do I know about investing?
How much time and/or money can I afford to lose?
Is gambling a good way to earn money for me?
Do I have reasonable confidence that the service will pay me?

And so on.


If you trade with bitcoins, how do you manage to "explain" anti-laundering authorities the money-in & money-out? When trading with bitcoins using mtgox, or bitcoin-24, or bitcoin.de, you will have in your account many transfers of money, to many people and from many people. In europe if the sum of the transactions is more than 10.000 €, your bank should send a notice to anty-laundering authorities.

How do you manage it?

I think your premise is flawed - when trading on Mtgox or other exchanges, there will only be transfers between you and Mtgox. If you're a day trader most trades will be internal on Mtgox and not be settled by the banks at all.

Even if they do "send a notice to anti-laundering authorities", it doesn't mean the next day they will show up at your doorstep to arrest you, it just means those authorities are aware of the transactions, and if they detect a suspicious pattern they may ask you questions. In this case you can just tell the truth.


Do sigops count towards the block weight in SegWit? I was just rereading the SegWit benefits page and noticed that the section Moving towards a single combined block limit contains an example in which sigops count towards the blockweight.

Did this become part of the final version of SegWit? If not, what happened to this idea?

No. The block weight is only calculated from the bytes themselves, not the sigops. Accounting for the sigops would need a hard fork, as explained by the section above the example:

  It is not possible to solve this problem without either a hardfork, or substantially decreasing the block size. Since segwit can’t fix the problem, it settles on not making it worse: in particular, rather than introducing an independent limit for the segregated witness data, instead a single limit is applied to the weighted sum of the UTXO data and the witness data, allowing both to be limited simultaneously as a combined entity.


How do buy and sell orders work? How does buying and selling bitcoins work once the order is placed?

I just know that the order-matching engine is used for this purpose, but more information regarding this will be helpful.

New offers and orders are matched respectively with the best order and offer available until they are fulfilled. If there is more than one entry at the same price, the oldest entry will be matched first. If a new entry cannot be matched completely, it will remain in the order book until the remainder is matched or it expires.

See an example below:

The initial order book

Offers:

[Bob] sell 1 BTC at $1000
[Charlie] sell 2 BTC at $1001, [Dolph] sell 1 BTC at $1001
[Emilio] sell 1 BTC at $1002

Orders:

[Fabienne] buy 1 BTC at $999
[George] buy 1 BTC at $998
[Harry] buy 1 BTC at $996, [Ivan] buy 5 BTC at $996

Alice wants to buy some Bitcoins.

Alice wants to buy 2 BTC and is willing to pay up to $2020. She adds an order for 2 BTC at $1010.

The system will now try to match her order to offers already in the system, of course matching the best offer first.

As seen above, Bob is offering to sell at $1000 and Charlie offers to sell at $1001, her order matches with Bob's offer using it up completely. Her order has a second BTC though, which will be matched against Charlie's offer next, because Charlie entered his offer before Dolph, who is offering the same price.

After Alice's order was matched there are the following offers:

[Charlie] sell 1 BTC at $1001, [Dolph] sell 1 BTC at $1001
[Emilio] sell 1 BTC at $1002

and the following orders:

[Fabienne] buy 1 BTC at $999
[George] buy 1 BTC at $998
[Harry] buy 1 BTC at $996, [Ivan] buy 5 BTC at $996

Note that Alice's order and Bob's offer are gone, and Charlie's offer is reduced by 1 BTC.

Afterwards, Jeremy wants to sell some Bitcoins

Now Jeremy wants $9,970 and has 10 BTC for sale. He creates an offer for 10 BTC at $997. Currently there are only two orders that will buy at or over that price: His offer matches the orders of Fabienne and George. He gains $999 and $998 for two of his BTC, the remaining 8 BTC will stay as an offer.

After Jeremy's offer was partially matched there are the following offers:

[Jeremy] sell 8 BTC at $997
[Charlie] sell 1 BTC at $1001, [Dolph] sell 1 BTC at $1001
[Emilio] sell 1 BTC at $1002

and the following orders:

[Harry] buy 1 BTC at $996, [Ivan] buy 5 BTC at $996


What bitcoin mining software is easy to use and start mining immediately with a pool & new ASIC boards? I'm looking to just start mining with my cheap laptop, but wanted to just ask whats the easiest mining software to setup and let it run in the background when my machine is idle. And the software has to be compatible with the new ASIC boards coming out too. I guess which software do you recommend without much configuration besides putting in your btc address.

I would argue BitMinter client is the easiest miner. You go to bitminter.com and click the "start engine" button to start it. You may have to go by java.com and install Java if you don't have it already.

Once the window pops up click "devices" -> "probe all ports" in the pulldown menus to detect connected FPGAs and ASICs. Then click the "start engine" button to start mining.

There will be an update soon to support BFL (Butterfly Labs) ASICs.

If you want to mine on Avalon it has a builtin computer with mining software preinstalled.

disclaimer: I am the author of BitMinter client.


bitcoin testnet daemon stuck I am running bitcoin testnet daemon for development, but lately I have trouble with starting the daemon. Blockchain is downloaded and it seems that everything runs fine till

  init message: Verifying blocks... Verifying last 288 blocks at level 3

then it seems stuck or takes hours before doing anything. Interesting is that restarting the daemon helped me couple times and daemon started in several minutes as usual. In this time i cant obviously use RPC commands.
I dont have trouble starting mainnet daemon. Anybody has any idea what might cause and how to fix this overly long verification?

I found out that long verification at start of bitcoin daemon can be caused by large number of keys generated and stored in wallet.dat. in my case >1600 keys can take more than 30min of verification.


Identifying the type of wallet that's being used? Is there any way to identify what type of a wallet a Bitcoin address is associated with?

For example, if you created an address via Blockchain.info, would anyone know it was created through them or know that you're wallet was located there?

No, you cannot identify what wallet software was used to create an address. This is impossible to do as all addresses are the same type of data.


Storing Provenance details in Bitcoin Blockchain I am quite new to the blockchain and bitcoin world. I was looking at some ProofOfExistance (PoE) solutions (Digital Notary) for documents.
While these solutions store the hash of document+timestamp, they mention that they store the document hash in "the bitcoin blockchain". Does the bitcoin blockchain allow you to store this document hash (or anything else), is it not meant specifically to store the bitcoin crypto currency transaction details?? I would have thought these solutions will use their own blockchain.

Asking the question in this forum as PoE documentation mentioned "bitcoin clockchain".

Does the bitcoin blockchain allow you to store this document hash (or
  anything else), is it not meant specifically to store the bitcoin
  crypto currency transaction details??

Yes, the Bitcoin blockchain isn't projected to store the data inside it, but it is possible with the type of transaction called Transaction NULL data, and it uses the OPT_RETURN operator of Bitcoin script.

Transaction NULL data (OP_RETUNR)

It was introduced in version Bitcoin Core 0.9 in 2014, this transaction marked the transaction of how not correlated with moving of bitcoins.

The scriptPubKey is simple with OPT_RETURN, the example is like how this:

OPT_RETURN <data>

From documentation of Proof of Existence that I have read quickly say this

  Calculate the document's SHA256 digest.

  Find a transaction in the bitcoin blockchain containing an OP_RETURN output with the document's
  hash prepended by our marker bytes, which are 0x444f4350524f4f46 (or
  'DOCPROOF' in ascii).

  Some online services like Coin Secrets or blockchain.info's list can help you locate OP_RETURN transactions more easily.

  The existence of that transaction in the blockchain proves
  that the document existed at the time the transaction got included
  into a block

So the ScriptPubKey started with this code

OPT_RETURN 0x444f4350524f4f46...

With this method, the System of Proof of Existence can found all transactions generated and the quantity of data stored with the System can be calculated with a simple parsing of blockchain (it can be is a good exercise).

There are other information on Transaction NULL data, like

You can not store a lot data, because exist a limit fixed to 80 bytes.
These transactions are not indicated by Bitcoin core (official Client Bitcoin)
You can read more details on the transaction null data on BitcoinBook

  I would have thought these solutions will use their own blockchain.

It can be is a solution to implement this System, but the develope an own blockchain that work is difficult.
I want to add another information on the implementation of this system, for storing the document is necessary a blockchain system?
I think is a good solution a distributed database because with document there are different problems, like:

The document, an example a certificate can contain some error (This was an problem that happened to me) and if this certificate was stored inside the blockchain is immutable and it can not be invalidated because the base of blockchain is immutability.

But this was only my think.


My first bitcoin transaction with core and coldcard I use coldcard and bitcoin core 0.20.1. I have checked how to do it with HWI at https://github.com/bitcoin-core/HWI/blob/master/docs/bitcoin-core-usage.md.
It appears more complex than needed.
With the core's GUI, I can create a PSBT, save it, and then sign it with an SD card and coldcard. The latter will create a TXN file with the finalized transaction, that I can just broadcast with core.
No need for HWI and only 1 console command (sendrawtransaction) needed.
I am afraid: am I missing something?
Thank you for any suggestion.

That is a viable method for using a Coldcard with Bitcoin Core. HWI is intended for the case where the hardware wallet is plugged into the machine running your wallet software. For the Coldcard, it is just an alternate way to use it. However for other hardware wallets, the MicroSD card method is not available so HWI provides a way to use them with Core.


What is a hard fork? When people talk about possible changes to how Bitcoin works they sometimes say a particular change would require a hard fork. What does that mean? Can a hard fork cause problems?

Simply put, a so-called hard fork is a change of the Bitcoin protocol that is not backwards-compatible; i.e., older client versions would not accept blocks created by the updated client, considering them invalid. Obviously, this can create a blockchain fork when nodes running the new version create a separate blockchain incompatible with the older software.

For potential future changes that would require a hard fork, see the associated wiki page.


Why does an exchange of bitcoin transaction not need to be over a secure connection? I apologise for my rather ignorant question and maybe my question is completely wrong. But my impression about one of the advantages of bitcoin (digital currencies) is that when a customer pays a client, that payment gateway does not need to be over a secure protocol merely because of the way the bitcoin works.

If this is true, can I have a more technical explanation of why this is the case?

Conventional banking relies on you and your bank both knowing some sort of secret, like a PIN or your mother's maiden name. This requires encryption, because otherwise someone listening in on the connection can capture the information and impersonate you.

Bitcoin uses only public key cryptography to identify accounts. It is possible to prove that the creator of a transaction had access to a private key without revealing what that private key is. See also How does the ECDSA verification algorithm work during transaction?

Also, although Bitcoin connections are usually not encrypted, there are circumstances where they probably should be, like if you want to make sure that the administrator of the local network doesn't know which Bitcoins you're spending.


Do you need to change 'rpcuser' and 'rpcpassword' for each bitcoind node you run? When running several bitcoind nodes on different machines, can I simply keep the same bitcoin.conf file everywhere, or do I need to ensure that a different rpcuser is set up for each?

The rpc user/pass is only needed if you're planning to access the node via RPC. If you're running Armory on top of it, for example, that requires RPC and hence you would need it (Armory auto-creates the rpcuser/password for you, though).

If you're running a node and don't need the RPC functionality, no, you don't need those parameters set.


Lightning Network: what happens if parties lose their txs? Let's take the classical example of Alice and Bob with 0.5BTC each. Commitment Txs are exchanged for a new balance sheet: Alice has 0.6BTC, and Bob 0.4BTC.

If Alice loses Bob's Breach Remedy Tx, she can still publish a Commitment Tx and get her 0.6BTC, but if Bob acts maliciously, she is not able to defraud him. Is that correct?

Yes that is correct. Bob's revocation secret is used as an insurance policy for Alice. If she loses it, Bob will be able to act maliciously and get away with it.

However, I want to add two things:

At least in c-lightning, there is the HSM secret. This serves as a 256-bit seed for an HD wallet from which all key pairs (for Commitment Txs as well as for Breach Remedy Txs) are being derived. Since the derivation in the lightning network is also deterministic, Alice should be able to reconstruct her keys (which she still needs in order to spend the output of her Commitment Tx).
If eltoo gets implemented (which requires a bitcoin soft-fork and acceptance of BIP118), the situation changes since there are no revocation keys needed anymore.


15 day funds hold on Coinbase I've linked my Copay wallet to my Coinbase account. I wasn't aware of the 15 day hold from my bank account on the funds I purchased.

Has anyone had that happen before? If so, did it take the full 15 days or did it clear sooner than that?

Also, my Coinbase account shows that my Copay account is connected to it when I'm logged in on a computer but not the app. And the Copay app doesn't show my Coinbase account is connected to it. I've completed the authorization process and I still don't see my Coinbase on my Copay app.

I would recommend to call coinbase support. They will point you in the right direction, usually its dramatic time saver :) Happened with me before that they would clear/release funds right away for some cases (unfortunately had a bunch within the last year). Their support staff is very responsive, doing its best since the platform has problems with scaling and code quality.


Debugging OP_EQUALVERIFY: non-equal data: how to get uncompressed public key and address from scriptSig This is the top ranking result on google for OP_EQUALVERIFY: non-equal data error.

In the answer, the person gets the uncompressed public key and its address from the scriptSig.

Is there a website link I can be pointed to where I can give scriptSig as input, and receive the uncompressed public key and address please?

This answer provides a good description of a task similar to what you are trying to accomplish.

This wiki page shows how scripts are serialized and deserialized. It's actually not very hard to extract the raw opcodes from the script by hand, especially if you know it's a standard type of script.

But, you may use https://chainquery.com/bitcoin-api/decodescript and paste in the raw hex of the scriptSig for a more automated solution. The parsed opcodes will be in the result.asm field, including any raw data (such as signatures and pubkeys) separated by spaces. If you look for the element(s) of the script that start with 02/03/04, that will be the public key.


Compared to Slush's pool, how exactly does Eligius payout owed bitcoins to the miners? I have mined a bit on both pools. Slush builds up an amount in your account and once it passes a threshold that you set, Slush sends you a payout that comes from another wallet. Eligius sets the threshold (and it is quite low too), and once your "account" passes it, Eligius sends out the payment directly from the newly generated coins.

I have enough imagination to see how Slush's pool and site manage the workers and send out the payments, but I cannot wrap my head around how Eligius does it that way.

How does Eligius pay miners directly from the newly generated coins? What are the pros and cons of this compared to how Slush does it? Are there other pools that do the same thing? Is this only possible with BTC and it's clones or can Litecoin pools do it too?

How does Eligius pay miners directly from the newly generated coins?

It simply generates the coinbase transaction to include payments directly to its miners, instead of only a transaction to itself.

  What are the pros and cons of this compared to how Slush does it?

Here are some I can think of:

Pros:

No transaction fees necessary for these payouts (except for the opportunity cost of some transactions you're not including in the block; but unless the block is at the max size, this is 0 cost)
Some people like having freshly minted coins, for anonymity and just because it's cool

Cons:

Harder to predict when you'll get a payout (because you have to wait for the pool to find a block)
If you're far down the queue, it might take several blocks and/or a manual payout before you finally get your payment

  Are there other pools that do the same thing?

Yes, at least a few. BitPenny and P2Pool, for instance.

  Is this only possible with BTC and it's clones or can Litecoin pools do it too?

It's possible with any Bitcoin-like coin, including Litecoin.


Proving the margin of error of a block timestamp In the Bitcoin wiki:

  Block times are accurate only to within an hour or two.

is a bit vague. Is it possible to prove that an arbitrary accepted block timestamp is within x seconds of the real-world time? How?

Block timestamps are whatever time the miner wants to put in there, within some loose bounds, so there isn't a real guarantee.

For more info on what those bounds are, check out this answer:

https://bitcoin.stackexchange.com/a/917/18196


LND can't connect to ZMQ I want to run my LND instance (again) and have some trouble with connecting to bitcoin's ZMQ.

Here is what I do:

$ bitcoin-cli getblockcount
575704

$ lnd --bitcoin.mainnet --bitcoin.active --debuglevel=debug --bitcoin.node=bitcoind --bitcoind.rpcuser=tepo --bitcoind.rpcpass=**** --bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 --bitcoind.zmqpubrawtx=8332

after unlocking lnd wallet I get:

2019-05-12 18:33:03.842 [INF] LTND: Version: 0.5.2-99-beta commit=, build=production, logging=default
2019-05-12 18:33:03.842 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-05-12 18:33:03.842 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8
2019-05-12 18:33:03.853 [INF] RPCS: password gRPC proxy started at [::]:8080
2019-05-12 18:33:03.853 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
2019-05-12 18:33:03.853 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2019-05-12 18:33:10.105 [INF] LNWL: Opened wallet
2019-05-12 18:33:10.204 [INF] LTND: Primary chain is set to: bitcoin
unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq tx events: dial tcp 0.0.32.140:0: connect: invalid argument
2019-05-12 18:33:10.207 [INF] LTND: Shutdown complete
unable to connect to bitcoind: unable to subscribe for zmq tx events: dial tcp 0.0.32.140:0: connect: invalid argument

bitcoin.conf:

server=1
txindex=1
daemon=1
rpcconnect=127.0.0.1
rpcport=8332
rpcuser=tepo
rpcpassword=****
dbcache=1024
rpcallowip=0.0.0.0/0
rpcthreads=4
rpctimeout=300
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

lnd.conf:

Application Options]
debuglevel=info
#debughtlc=true
#listen=0.0.0.0:9735
externalip=188.167.56.214
#rpclisten=0.0.0.0:8332
alias=axon
color=#ff9200
maxpendingchannels=10
restlisten=0.0.0.0:8080

[Bitcoin]
bitcoin.mainnet=1
bitcoin.active=1
bitcoin.node=bitcoind

[Bitcoind]
bitcoind.rpchost=127.0.0.1:8332
bitcoind.rpcuser=tepo
bitcoind.rpcpass=****
bitcoind.zmqpubrawblock=127.0.0.1:28332
bitcoind.zmqpubrawtx=127.0.0.1:28333
#bitcoind.zmqpath=tcp://127.0.0.1:18501

$ ldd /usr/bin/bitcoind | grep -i mq
    libzmq.so.5 => /usr/lib/libzmq.so.5 (0x00007f9ce53c1000)

if I missed something to show you, please tell me.

Help appreciated

I believe that your configs are ok, but when you launch lnd with the command like flags, you overwrite one parameter to a broken value.

Specifically, I am talking about the flag --bitcoind.zmqpubrawtx=8332, which should be --bitcoind.zmqpubrawtx=127.0.0.1:28333 instead.


Does the bitcoin testnet3 network support Segwit and OP_CSV? As far as I know, Segregated Witness and OP_CHECKSEQUENCEVERIFY are the last features needed to be able to fully implement a trustless bi-directional payment channel, from start to finish. (Technically you don't need OP_CHECKSEQUENCEVERIFY, it just makes channels a lot better)

Does testnet3 support those features?

If not, is there another public development chain which has those features?

Yes, testnet3 supports SegWit as of block 834624.
Yes, testnet3 supports both OP_CSV and OP_CLTV.

You might also be interested to know that there is a segnet test network on another port number. See https://bitcointalk.org/index.php?topic=1453392.0 for more details.


How do I fetch the price data from CoinGecko? I don't understand their API: https://www.coingecko.com/en/api

It says:

  /simple/price    Get the current price of any cryptocurrencies in any
  other supported currencies that you need.

But then you click it and it doesn't spit out any JSON at all. Instead, it shows a number of id fields and other things. I can't make it open the actual URL for displaying the Bitcoin price.

Here is an example that will give you the simple price:

https://api.coingecko.com/api/v3/simple/price?ids=bitcoin&vs_currencies=usd

The page lets you try out the API by filling in the form fields. You can get the list of coin ids from:

https://api.coingecko.com/api/v3/coins/list

and the compare currencies from:

https://api.coingecko.com/api/v3/simple/supported_vs_currencies


How could the bitcoin protocol be changed? Has this ever occurred? I keep coming across answers in questions on this site and on the wiki saying that the protocol might need to be changed in the future to create more scalability / security.

It seems to me that it is difficult to update the protocol now that there are so many different people involved and so much invested in the current protocol.

How could the bitcoin protocol be updated?  Has this ever occurred to date?

Easy.  In the source code add a conditional.  For example, if the protocol were needing to be changed for all verifications after block 200,000 then the pseudo code for that is:

If block <= 200,000:
 # Do it the old way.
Else:
 # Do it the new way.

The problem isn't technical it is political.  If that change causes me pain (e.g., inflate the currency at a higher rate) then I am not going to want to accept any version of the code that does something that I don't want to see happen.

So any change needs to get buy in (concensus), from the developers, miners and ... most importantly, those who will accept bitcoins under the new rules in exchange for something of value.

If an unwanted change is pushed forward without being widely accepted, a blockchain fork will occur, and the losing side (generally the fork with the new rules) essentially gets ignored as if it didn't even exist by the rest of the network.

There have been several changes to the protocol as well as changes to the implementation in the client. Some are planned well in advance (e.g., BIP 16), and some are in response to a problem (e.g., Aug 2010's value overflow).

https://en.bitcoin.it/wiki/Incidents


Why do transactions send coins to the same address as they spent it from? I often notice transactions such as:

364efe5a906de5971e242f9711008e58a5ab79f136a8044b66615e8662d35f09

Where funds from the address 3PU with 1.38 BTC are split to itself (1.35 BTC) and 37Ek (0.027BTC):

3PUui (1.38 BTC) -> 37Ekc (0.0278 BTC)
                 -> 3Puui (1.3519 BTC)

I am wondering why the transaction doesn't look like:

3PUui (0.0279 BTC) -> 37Ekc (0.0278 BTC)

I read from this question that an input must be completely consumed in the transaction, so if I have received 1.35 BTC during the last transaction, if I refer to it, I must consume the 1.35 BTC.

However on https://coinb.in/#newTransaction I can see the amount can be specified for each input. So why should I need to mention the input amount if it is already set by the previous transaction?

Likely the sender didn't have an unspent output that had exactly the amount he wanted to send. So he choose an unspent output that had enough and sent the remainder back to himself.

Accounts do not automatically combine the funds they receive. They have a bundle of unspent transaction outputs which they can only use by completely consuming them.

You might ask the same question if you see a person pay with a $10 bill and get a $5 bill back. You might wonder why they didn't just pay with a $5 bill. Well, probably it's because they didn't have one, so they got a $5 bill back as change. Essentially, each of the transactions you have received remains available to you as an input to a future transaction. But using an output as an input consumes it, so if it has too much, you send the remains back to yourself as "change".


How do we "exchange coins on one blockchain for those on the other"? With Segwit and BIP-148 coming, I have been trying to figure out what's exactly gonna happen with Bitcoin after August 1, by watching videos and reading articles. One thing (among many others) confuses me ..

Some are saying that you can exchange Bitcoins on one blockchain (say, the Legacy blockchain) for Bitcoins on the other (say, the BIP-148 blockchain). I don't understand how this can be done. I actually don't think that this would be possible. This is my reasoning:

Say I have 20 BTC on the (Legacy) blockchain before August 1. Now, August 1 arrives, and we have a BIP-148 soft fork. Now, I have 20 BTC on both, the Legacy blockchain and the BIP-148 blockchain. Now, to "exchange Bitcoins on one blockchain for other" (or for any other transfer), I have to make a transaction - a send or a receive.

Suppose, I send 15 BTC to some person P. This transaction will be broadcast to all the nodes/miners in the network, irrespective of the fact whether that node/miner runs BIP-148 software or not. If:

A BIP-148 miner solves the transaction first: That block will be attached to both the blockchains. The Legacy miner will stop trying to solve that transaction.
A Legacy miner solves the transaction first: The block will be attached to the Legacy blockchain, and all the BIP-148 nodes will reject this block. But, BIP-148 miners still have this transaction in their mempool. They will keep on trying to solve it and eventually will solve it.

In both of the above cases, the BTC balance of both myself and person P is the same in both the blockchains.

The only way, it seems to me, to have different balances for a particular account (public key), is, if someone tries to do double-spending. (I have arrived at this conclusion after doing some analysis.)

So, how do exchange coins on one blockchain for coins on the other, reliably?

There are two ways to avoid transaction replay (besides something being built into the fork to begin with). You can taint your coins or double spend.

Tainting your coins requires you to get access to coins created after the fork on at least one of the chains. If you create a transaction which includes an input from a coinbase transaction created on the BIP 148 chain, then that transaction is invalid on the non-BIP 148 chain. And vice versa. Then any transaction which spends from this tainting transaction will only be valid on one chain.

The other way is to perform a double spend. Let's assume that the BIP 148 chain has less hashrate (and thus slower blocks). You make a transaction which signals for RBF which is likely to confirm in the next block on the non-BIP 148 chain. Since the non-BIP 148 chain produces blocks more quickly, your transaction will likely confirm on the non-BIP 148 chain before it does on the BIP 148 chain. Once you have a confirmation on the non-BIP 148 chain, create a double spend which pays a higher fee (to take advantage of RBF) and sends the coins to a different address. This transaction will then confirm on the BIP 148 chain since it is invalid on the non-BIP 148 chain and has replaced the original. Your coins are now separate and won't be at risk for transaction replay.


Why does namecoin have the redundant name_firstupdate step? I am trying to understand the namecoin protocol. As can be read in the namecoin documentation, in order to register a domain, you need to execute the following steps:

Execute the command name_new, this pre-oders a domain name.
Execute the command name_firstupdate, this finalizes the registration, name becomes public.

Why does this second redundant step exist? Wouldn't it make more sense to merge these two commands, and enable users to finalize a registration by updating a domain directly when registering it with name_new?

The reason is to prevent frontrunning: When a victim registers abc.com, the attacker might notice the TXN with the name_new abc.com request on Namecoin's P2P network. Then, he might issue the same request but with a higher TXN fee, and "steal" the domain from the victim, who was trying to register.

The solution is simple:

Rather than sending name_new abc.com requests that reveal the domain, send a name_new SHA256(r, 'abc.com') request that commits to the domain without revealing it. This way, an attacker learns nothing about what domain is being registered.
Reveal the domain later using a name_firstupdate r, abc.com request which reveals the domain, preventing people from stealing it. By this point, the attacker can do nothing because abc.com has already been assigned ownership using the name_new request.


bitcoind just hangs (no output at all) I do realize that in the early stages bitcoin has to download a lot (How long does it take to download the blockchain?), however, I assume this is like wget or rsync where it displays the progress. Right now, when I issue the command bitcoind, it just hangs and outputs nothing. Could this be due to closed ports? Is it sufficient that I opened ports on my Ubuntu router, or must I forward those ports? Alternatively, is there a command line parameter I have to issue to get the output of bitcoind?

No output is normal, it's meant to be run as a daemon. If you want to see progress however, try bitcoind -printtoconsole or tail -f ~/.bitcoin/debug.log.


Have there been any successful "airdrops"? Starting with Auroracoin, a lot of coins aimed to perform an "airdrop" and distribute their coins to certain groups of people. I am wondering, have there been any successful airdrops? If so, how did they accomplish this task? I was trying to follow these at some point, but I have never heard of any coin pulling it off.

I remmeber there was BitcoinTalkCoin - the one with BCC ticker, in fact there were few sharing the same idea). They successfully "airdropped" the coins to BTT users, registered before the coin anouncement. I received some myself :) although it was pennies, you can say that the mission was accomplished.


getrawtransaction - find destination and "change" addresses How to get destination address and amount from result of getrawtransaction and how to distinguish it from "change" address using rpc api.

The getrawtransaction RPC will provide you with details about a particular transaction.  However, answering your question further is complicated by several issues:

Transactions are not required to have change addresses.  Good wallets will attempt to avoid using change addresses when change isn't necessary.
Transactions may have more than two outputs, so there's not necessarily a single payment address.
Transactions may pay a bare (non-P2SH) multisig output which comprises several public keys.  GetRawTransaction will display these as multiple addresses.
In a well-implemented wallet, change should be indistinguishable from a payment within a single transaction.  You would need to analyze multiple transactions or have information from the party that received payment in order to be able to determine which output is a change address.

In short, I don't think GetRawTransaction or any other RPC will provide you with the information you want for arbitrary block chain transactions.  However, if you're only interested in information about transactions in the local wallet, the gettransaction RPC is what you're looking for.


Does bitcoin-qt support mining in a pool? I am having difficulty getting guiminer to share a pool with me but if I mine on bitcoin-qt -gen 1 it starts hashing straight away. So I'd like to know if the official bitcoin client supports pooling?

No. Also the hashing implementation in the client is very, very limited. It is not optimized for different architectures AFAIK and does not support any other calculation medium other than regular CPU. That means no GPU, FPGA or ASIC mining. And CPU are extremely slow in comparison with these (see for example Why a GPU mines faster than a CPU).

For this reason the standard Bitcoin GUI client (bitcoin-qt) does not support mining anymore.


Is there any way to install a GPU miner on ubuntu without using the proprietary drivers? The question pretty much says it all. Any way to install a GPU miner (ATI) without

A) Installing fglrx (which is a very bad driver for everyday use, and breaks my dual-monitor setup)

B) Installing stream app sdk (which, if I understand correctly, requires fglrx)

Please? Anyway? I would like to start mining bitcoins...

No there is not. The ATI Catalyst driver implements OpenCL, which is what GPU miners use to accelerate the SHA256 hashing used in mining. The open source driver does not implement OpenCL. There are experimental projects that aim to implement OpenCL in the open source driver (Clover is an example) - as a Gallium3D state tracker - but so far these only run on the CPU.

GPU drivers are very complex pieces of software. Even if an open source implementation of OpenCL, that runs on the GPU, were to become available, it would likely be orders of magnitude slower than ATI's proprietary implementation, which basically undermines the whole purpose of using the GPU in the first place -- to gain speed.


How was the blockchain's "hard fork" automatically resolved? As a result of an "official" change in back-end databases from BDB in v0.7 to LevelDB in v0.8, in addition to an increase (by some mining pools) to a higher block size limit, there was recent "hard fork" at blockchain height 225430.

Miners were originally told to switch back to v0.7, but then later informed that v0.8 was fine as long as they don't increase the default (256kb -- soft limit) block size.

So what happens to block 225430 for v0.8 miners? Are they required to reload the database from <225430 with new "max block size" limits? How did this problem supposedly just fix itself (as has been reported here), or is this still a problem as blockchain.info continues to "sequentially" report orphaned blocks here? My last question would be what happens to the transactions that were linked to block 225430 (and are now UTXO), won't v0.8 still consider them spendable?

  I'm sure this all would make a lot more sense if I had a better
  understanding of Bitcoin's block reorg logic. Perhaps a pseudo-code
  walk-through of the process might help.

Edit: the 2 chains seemed to have merged here (after 32 sequentially orphaned blocks). So how exactly did v.0.8 clients handle the reorg for 32 blocks? Is there a maximum reorg that Bitcoin can handle? Was it easier to double-spend during the 5+ hour blockchain correction?

The highest blockchain containing only valid blocks is always the "correct" blockchain.

The first 225430-block was accepted by 0.8 clients/miners, but due to a flaw in 0.7 clients/miners couldn't accept the block.

The 0.7-fork was accepted by all client and miners, and the 0.8-fork was only accepted by 0.8 clients/miners. The core Bitcoin developers decided they wanted the 0.7-fork to be highest, however 0.8 had the most mining power, so the developers asked mining pools to switch back to the 0.7 client.

After some time, the 0.7 blockchain (which didn't have the "flawed" transaction) was highest, and 0.8 clients/miners would treat this as being the "real" blockchain (and stop mining on the blockchain with the transaction 0.7 clients didn't accept).

The 0.8 fork is simply treat as many orphaned blocks and is not worth anything (it can't be spend, etc).


What OP code can I use in the scripting system to make a smart contract that acts similar to a lottery I am trying to make a smart contract that acts similar to a lottery or gambling game. Here is an example:

Alice and Bob send funds to a P2SH address. Bob is the lottery. The funds needs to be locked for some time (until the draw for example, like 5 days). For this we can use OP_CHECKLOCKTIMEVERIFY. After the nLockTime expires, if Alice guessed 3 numbers, she will get 50% of her deposit back. If she guesses 6 numbers, she will get 200% of her deposit back.

How can Bob (the lottery) commit to some numbers that Alice needs to guess before Alice funds the deposit address? Bob needs to be able to prove that the numbers were chosen before she funded the deposit address, and cannot simply deny any numbers Alice would guess.

On the other side, how can we enforce the funds go back to Alice if she guesses the numbers that were previously committed to by Bob in case Bob disappears before the draw (nLickTime expiration) time comes?

The simplest thing I can think of is Bob puts a hash of the numbers he committed to in OP_RETURN in the transaction funding the deposit address, but this is kind of a PITA and annoying and it does not offer a guarantee for Alice that she will take her money if she guesses the numbers Bob committed to even if he disappears until the draw (nLockTime expire) time comes.

Thank you.

You might be able to combine a hash lock with a conditional payout.

Here's a somewhat simplified example that shows how to make a payout depend on knowledge of a secret. Bob makes a bet with Alice that she can't guess Bob's secret before a deadline. Alice proves she knows the secret by publishing the preimage to its hash value, which Bob publishes. Alice and Bob each contribute one bitcoin. The winner receives two bitcoin. If Bob doesn't reveal the secret after the deadline, Alice takes all the money.

There are two one-bitcoin inputs, signed respectively by Alice and Bob.

There is one two-bitcoin output. It is protected by a nested conditional challenge script that looks something like this:

IF
  // Alice spends with secret before deadline
  OP_HASH256 <hash> OP_EQUALVERIFY <Alice pubkey> OP_CHECKSIG
ELSE
  // deadline has expired
  <deadline> OP_CHECKLOCKTIMEVERIFY OP_DROP

  IF
    // Bob spends by revealing the secret
    OP_HASH256 <hash> OP_EQUALVERIFY <Bob pubkey> OP_CHECKSIG
  ELSE
    // Alice spends if Bob refuses to publish the secret
    <Alice pubkey> OP_CHECKSIG
  ENDIF
ENDIF

To spend the output before the deadline, Alice uses this response script:

<Alice signature> <secret> <1>

After the deadline, Bob uses this response script:

<0> <Bob signature> <secret> <1> <0>

If Bob fails to spend the output after the deadline (revealing the secret), Alice takes all the money with this response script:

<0> <Alice signature> <0> <0>

There's a problem with this approach, though. If Alice doesn't guess the secret and Bob publishes it, Alice can use the secret to make her own transaction claiming the output. This sets up a race condition in which Alice and Bob each have pending transactions trying to spend the output.

One way to fix this problem would be to give Bob a grace period immediately after the deadline (say, one day). During the grace period, Alice would be unable to spend, but Bob could.


Do pools distribute "jobs" to miners based on "failed" solutions which have already been submitted? My question is this: How exactly does the stratum protocol distribute "work" to miners? More specifically, since mining can be compared (in many regards) to "brute forcing" a cryptographic hash (i.e. hashing random inputs until, by luck, a random input matches a desired output), wouldn't it make sense to keep track of potential solutions submitted and confirmed as invalid for a particular block, and to somehow communicate that to miners so the same work is not being done over and over again?

I realize this would require a lot of overhead, but it would seem worthwhile. Is there any mechanism to ensure two independent miners do not waste time working on the same inputs? Could sending a different seed for random number generation to every miner upon the start of a new round of mining have effect? I've read simplistic descriptions of mining as simply incrementing the nonce until a solution is found, but I've also read much more detailed explanations which would imply much more is involved. Even if only the nonce is changed in the input, the pool would still need to assign each miner a unique nonce to try after each submission, no?

As a final, semi-unrelated question regarding the implications of storing solutions: Say a pool stored every solution it had ever received, considering the massive size of the bitcoin network, would this not eventually become a statistically significant (in terms of usability) database of sha256 collisions? And eventually, could enough data be collected to come up with a derivation for SHA256? At minimum, could a pool with malicious intent temporarily divert unknowing miners's computing power to crack SHA256 based TLS signatures or PGP public keys? Especially a pool which also controlled the hardware and software on the majority of its devices (e.g. Antpool).

I've read simplistic descriptions of mining as simply incrementing the nonce until a solution is found, but I've also read much more detailed explanations which would imply much more is involved. Even if only the nonce is changed in the input, the pool would still need to assign each miner a unique nonce to try after each submission, no?

Miners do change more than just the nonce, and it is this fact that allows a mining pool to ensure that two miners don't produce the same work twice.

Because mining always involves the transactions used in the block, changing those transactions will effect the merkle root and thus the result. One of those transactions is the coinbase transaction which is something that miners have control over. In particular, the input script for the coinbase transaction's input can contain up to 100 bytes of aribtrary data. So miners will use this space as an extra nonce (known as the extranonce). They will have a nonce there too in order produce new coinbase transactions which lets them produce different merkle roots and thus different block headers. The extranonce allows miners to have more nonces than from just the 32 bit nonce in the block header.

Mining pools make use of this extranonce to ensure unique work. They will give a miner part of an extranonce (e.g the first half). Then the miner can use the rest of the extranonce as an extranonce for themselves. This lets miners still have a large search space so that they are not constantly asking the pool for more work. By giving miners different extranonce halves, the pool can be sure that two miners will not be hashing the same thing multiple times.

  Say a pool stored every solution it had ever received, considering the massive size of the bitcoin network, would this not eventually become a statistically significant (in terms of usability) database of sha256 collisions?

Eventually, yes. But it's going to be a very long time before that happens. The entire Bitcoin network has done ~2^90 hashes total. However to even get to a 50% chance of a collision, you need ~2^128 hashes. 2^90 is 1/274877906944 of 2^128. So the amount of time to even get to 2^128 hashes is many times the number of years that the universe has even existed. So in theory, yes, there could be enough hashes computed that a collision is found be sheer brute force. But for all intents and purposes, it isn't going to happen.


Risks in joining websites that offers bitcoins for trade I have joined a website in our country that offers buy and sell of bitcoins,the only one that offers our currency. When joining websites like this, what should be the right way in terms of getting or obtaining the bitcoin address?

Upon registration, you are given your on address by them. You can buy/sell bitcoin on their website. For me that sounds fair, nothing strange. But then, last week, I bought an amount of bitcoins from them and I can see it when I logged in to their website. But checking https://blockchain.info/address/<my bitcoin address> shows no bitcoin balance.

I have checked a friend of mine's account which has transaction outside the website and can see it receiving bitcoins but the final balance is zero. But looking at their website, the balance is there. If I bought that bitcoin, why is it not in my wallet?

In addition, if you transfer to a bitcoin address outside their website, the fee is likely more than twice than using others like coinbase. I think this is for keeping you inside their website. Like for example I tried transferring 10 USD, and the fee is 15 USD. I have to cut out 25 USD on my address just for that. Crazy.

Are these things which I should be worried about?

It is likely that the address you were given upon joining is a deposit address, that you would send bitcoins to when you want to sell them. When buying bitcoins, the site will hold them for you until you withdraw them to an address you provide. Usually that would be a separate wallet, e.g. a program on your computer, hardware wallet like TREZOR, or a wallet website like the one offered on blockchain.info. Until you withdraw the bitcoins from the website, they hold them for you, which means there is more risk of losing the coins if the site gets hacked, goes rogue or goes bankrupt. There is a saying in the bitcoin community, that if you do not have the private keys then you do not own the coins. So the safest route for you is to get your own wallet and withdraw the coins there, and then make a backup of your private keys for that wallet.

And yes sites like that can set their own fee, some might be ridiculously high unfortunately, but there is not a lot you can do if that is what they ask


How to determine the last 1k blocks and their Miner Software? Basically the idea was to create a tiny service such as nodecounter.com.

Now I would appreciate your help on the following questions:

How to determine the Software (Core, Classic, XT, etc.) and quantity on the whole network?
How to determine the last 1k blocks and their Miner Software?

I would start from scratch, but if you know about any open source projects, preferably in NodeJS or PHP, I would really appreciate a hint.

How to determine the Software (Core, Classic, XT, etc.) and quantity
  on the whole network?

connect to host and take the 'user-agent' string from 'version' packet

  How to determine the last 1k blocks and their Miner Software?

the miner can be determined by analyzing coinbase transaction.

the software can not be determined


Reject all other Blocks and allow only my own mined blocks I am looking at the source code and I want to know how a person can reject all blocks except the ones mined by himself? I want to be still able to add transaction to my blocks but reject all other mined blocks except mine, where do I need to look in the source code?

I suspect that this is an instance of the XY problem, but I'll answer anyway.

If you modify ProcessMessage so that it drops any inbound block messages, that would do it.

Change

    else if (strCommand == NetMsgType::BLOCK && !fImporting && !fReindex) // Ignore blocks received while importing
    {

to

    else if (false) // Ignore all blocks
    {


Why do we use CLTV instead of CSV in the HTLC output of the commitment transaction? In lightning network commitment transactions, the HTLC offered/received outputs generally pay the offering node after a timeout which is scripted using CLTV. In other parts of the commitment transactions (such a to_self_delay) we use CSV to ensure it the output is unspendable until a certain time has passed. Why was CLTV chosen as the design choice for HTLC outputs?

As you have said yourself, CSV is relative to when the transaction appears in the blockchain, while CLTV is absolute. They just have different meanings, which are useful for different things:

The RSMC timeout is meant to only start when someone pushes a commitment tx to the blockchain. So it needs to be relative.

The HTLC timeout, on the other hand, is meant to actually make an HTLC temporary, even if in most cases if will never hit the blockchain. So it needs to be absolute.


Order of Exchanging Revocation Keys during Lightning Transactions How do Alice and Bob share their ephemeral private keys simultaneously? If they don't, and let's say Alice first sends Bob her private key. At this point, Bob can broadcast his current commitment transaction, and the previous commitment transaction (as he still has not sent his previous commitment transaction's private key to Alice yet). But Alice can only broadcast her current commitment transaction, as she has sent her revocation private key of her previous commitment transaction to Bob already. This asymmetry is a bit baffling.

If the previous commitment transaction favored Bob, what prevents him from broadcasting it - knowing that Alice cannot penalize him.

My guess of an answer for this is that they share their private keys based on whether value is flowing from Alice to Bob or Bob to Alice. As in, if the previous commitment transaction favors Bob, then he has to share his private key first. Or some such.

Alice and Bob jointly create a public key R for each revocable output (RSMC output script).

They each privately generate r-1 and r-2, and derive public keys R-1 and R-2 from these. R is the sum of R-1 and R-2. No secrets have been exchanges, only public keys. So R is unspendable by either. However, it is spendable by r = r-1 + r-2

When a new commitment tx is created, this RSMC must be revoked. If the new tx commitment favors Bob, then Alice must share r-1 with Bob. Now bob knows that he can spend this revoked output if Alice broadcasts it. Bob doesnt need to share r-2 with Alice as he would rather broadcast the subsequent tx favoring him.

Pre-images are used for routing (htlc output scripts) See later slides in chapter: https://teachbitcoin.github.io/payment_channels.html#/


Address reuse, one address per person I know about the privacy and security implications of address reuse. But I was thinking about a scenario where I have one address for every person I receive transactions from. This would still have the security problems, but not the privacy problems? Did I overlook something here?

but not the privacy problems? Did I overlook something here?

Yes, unfortunately.   When you later spend you often need to use coins originating from multiple transactions that previously paid you and these co-spends will link together your transactions.

For example.  Say Alice pays you 1 bitcoin to address A and then Bob pays you 1 bitcoin to addess B. You then spend 2 bitcoin and use those to coins, indicating to the world that the same party probably controls A and B.  Later Bob pays you 1 bitcoin again and Charlie pays you 1 bitcoin to address C.  You make another 2 BTC payment using the coins from Bob's second payment and Charlie's payment, now the world has reason to believe A, B, and C are all controlled by the same party.  Without the reuse people would know less.

This privacy loss doesn't just hurt you, but also A, B, and C and potentially the people they interact with so even if privacy isn't very important to you today it's still better to not gratuitously lose privacy.

Bitcoin Core has some logic to try to spend all payments to the same address at once (though in 0.17 it isn't enabled by default) but even that won't help you if the payments/spending are spread out over time. If you are forced to reuse addresses it's preferable to delay spending payments to a particular address until its unlikely to get any more and to then spend them all at once.

Using one address per paying party is the bare minimum needed to even know who paid you but doesn't provide particularly great privacy.


How to estimate optimal fees for transaction in bitcoind? As I understand, with the network congestion it's sometimes advisable to set a higher fee to process a transaction within a block or two. Is there some way to estimate the optimal fee through calls to bitcoind? I know there are some online services that do those estimations, but I'd rather not rely on such external factors.

The other answer is outdated. estimatefee is deprecated.
You should use estimatesmartfee

  Please use estimatesmartfee for more intelligent estimates.
  Estimates the approximate fee per kilobyte needed for a transaction to begin
  confirmation within nblocks blocks. Uses virtual transaction size of transaction
  as defined in BIP 141 (witness data is discounted).

  Arguments:
  1. nblocks     (numeric, required)

Example:

bitcoin-cli estimatesmartfee 6


Why does Bitcoin uses a Script language? From what I heard is that Bitcoin use Script to verify transactions (I'm probably wrong).

Wouldn't be sufficient just signing the transaction with the private key and append the signature to the transaction? This way everyone could verify if the transaction was sent form that public key.

Is this insecure?

I imagine that Script is used for other things too. But If I only wanted to verify the transaction, I could do it with a simple signature right?

Thanks

Yes it does use a language called script. The transactions have both a locking and unlocking script and it is there to allow the specification of simple conditions for spending so that transaction validation is not based on a static pattern and allows the spending of money to be programmable. The locking script normally contains the public key hash while the unlocking script normally contains a digital signature. The scripting language also caters for more complex multisignature scripts. If you just limited the processing to a signature verification then it would not allow for richer functionality and multisignature functionality.


Why should I care about my transactions ever reaching the blockchain if I can spend them while unconfirmed? From what I understand, I can use unconfirmed transactions because they are essentially already confirmed, they just need to reach the blockchain. This can create a chain of unconfirmed transactions, but that's fine because they will all eventually be confirmed and added to the blockchain.
If that is the case, why should I care about my transactions ever reaching the blockchain? I don't see a reason why I should care, and with that, I don't see a reason to include a fee with my transactions.

The flaw in your thinking is that you assume your transactions will be confirmed. That is not the case. There is no guarantee that a transaction will ever be confirmed, and in fact, if the fee is too low, it is almost guaranteed that the transaction will never confirm.
You should care because the person you are sending Bitcoin to cares that it confirms. You should care because you won't receive what you are paying for until your transaction confirms. Most merchants will not consider the payment complete until at least one confirmation. If they do not consider the payment complete, you aren't going to be receiving any good or service that you have paid for.
Merchants (and other recipients) care about transactions confirming because it guarantees that the Bitcoin has actually been transferred. While a transaction is unconfirmed, it could be double spent and a different transaction that uses the same inputs and sends the Bitcoin elsewhere could be confirmed. If they accept the payment, provide the goods or service, and then find out that the transaction has been double spent, then they have both not made any money and lost the value of whatever has been provided to you. So receivers almost always wait for confirmations before considering a payment to be complete.


How to file bitcoin income to the IRS I want to check if there is any specific tips how to properly file income from speculation with BTC to the IRS.

Also is there any specific report from the Coinbase available?

The IRS just issued a preliminary ruling on this and it will be treated as property.  The Q&A portion is particularly useful.

SECTION 4. FREQUENTLY ASKED QUESTIONS

Q-1: How is virtual currency treated for federal tax purposes?

A-1: For federal tax purposes, virtual currency is treated as property. General tax principles applicable to property transactions apply to transactions using virtual currency.

Q-2: Is virtual currency treated as currency for purposes of determining whether a transaction results in foreign currency gain or loss under U.S. federal tax laws?

A-2: No. Under currently applicable law, virtual currency is not treated as currency that could generate foreign currency gain or loss for U.S. federal tax purposes.

Q-3: Must a taxpayer who receives virtual currency as payment for goods or services include in computing gross income the fair market value of the virtual currency?

A-3: Yes. A taxpayer who receives virtual currency as payment for goods or services must, in computing gross income, include the fair market value of the virtual currency, measured in U.S. dollars, as of the date that the virtual currency was received. See Publication 525, Taxable and Nontaxable Income, for more information on miscellaneous income from exchanges involving property or services.

Q-4: What is the basis of virtual currency received as payment for goods or services in Q&A-3?

A-4: The basis of virtual currency that a taxpayer receives as payment for goods or services in Q&A-3 is the fair market value of the virtual currency in U.S. dollars as of the date of receipt. See Publication 551, Basis of Assets, for more information on the computation of basis when property is received for goods or services.

Q-5: How is the fair market value of virtual currency determined?

A-5: For U.S. tax purposes, transactions using virtual currency must be reported in U.S. dollars. Therefore, taxpayers will be required to determine the fair market value of virtual currency in U.S. dollars as of the date of payment or receipt. If a virtual currency is listed on an exchange and the exchange rate is established by market supply and demand, the fair market value of the virtual currency is determined by converting the virtual currency into U.S. dollars (or into another real currency which in turn can be converted into U.S. dollars) at the exchange rate, in a reasonable manner that is consistently applied.

Q-6: Does a taxpayer have gain or loss upon an exchange of virtual currency for other property?

A-6: Yes. If the fair market value of property received in exchange for virtual currency exceeds the taxpayer's adjusted basis of the virtual currency, the taxpayer has taxable gain. The taxpayer has a loss if the fair market value of the property received is less than the adjusted basis of the virtual currency. See Publication 544, Sales and Other Dispositions of Assets, for information about the tax treatment of sales and exchanges, such as whether a loss is deductible.

Q-7: What type of gain or loss does a taxpayer realize on the sale or exchange of virtual currency?

A-7: The character of the gain or loss generally depends on whether the virtual currency is a capital asset in the hands of the taxpayer. A taxpayer generally realizes capital gain or loss on the sale or exchange of virtual currency that is a capital asset in the hands of the taxpayer. For example, stocks, bonds, and other investment property are generally capital assets. A taxpayer generally realizes ordinary gain or loss on the sale or exchange of virtual currency that is not a capital asset in the hands of the taxpayer. Inventory and other property held mainly for sale to customers in a trade or business are examples of property that is not a capital asset. See Publication 544 for more information about capital assets and the character of gain or loss.

Q-8: Does a taxpayer who "mines" virtual currency (for example, uses computer resources to validate Bitcoin transactions and maintain the public Bitcoin transaction ledger) realize gross income upon receipt of the virtual currency resulting from those activities?

A-8: Yes, when a taxpayer successfully "mines" virtual currency, the fair market value of the virtual currency as of the date of receipt is includible in gross income. See Publication 525, Taxable and Nontaxable Income, for more information on taxable income.

Q-9: Is an individual who "mines" virtual currency as a trade or business subject to self-employment tax on the income derived from those activities?

A-9: If a taxpayer's "mining" of virtual currency constitutes a trade or business, and the "mining" activity is not undertaken by the taxpayer as an employee, the net earnings from self-employment (generally, gross income derived from carrying on a trade or business less allowable deductions) resulting from those activities constitute self-employment income and are subject to the self-employment tax. See Chapter 10 of Publication 334, Tax Guide for Small Business, for more information on self-employment tax and Publication 535, Business Expenses, for more information on determining whether expenses are from a business activity carried on to make a profit.

Q-10: Does virtual currency received by an independent contractor for performing services constitute self‑employment income?

A-10: Yes. Generally, self‑employment income includes all gross income derived by an individual from any trade or business carried on by the individual as other than an employee. Consequently, the fair market value of virtual currency received for services performed as an independent contractor, measured in U.S. dollars as of the date of receipt, constitutes self‑employment income and is subject to the self-employment tax. See FS-2007-18, April 2007, Business or Hobby? Answer Has Implications for Deductions, for information on determining whether an activity is a business or a hobby.

Q-11: Does virtual currency paid by an employer as remuneration for services constitute wages for employment tax purposes?

A-11: Yes. Generally, the medium in which remuneration for services is paid is immaterial to the determination of whether the remuneration constitutes wages for employment tax purposes. Consequently, the fair market value of virtual currency paid as wages is subject to federal income tax withholding, Federal Insurance Contributions Act (FICA) tax, and Federal Unemployment Tax Act (FUTA) tax and must be reported on Form W-2, Wage and Tax Statement. See Publication 15 (Circular E), Employer's Tax Guide, for information on the withholding, depositing, reporting, and paying of employment taxes.

Q-12: Is a payment made using virtual currency subject to information reporting?

A-12: A payment made using virtual currency is subject to information reporting to the same extent as any other payment made in property. For example, a person who in the course of a trade or business makes a payment of fixed and determinable income using virtual currency with a value of $600 or more to a U.S. non-exempt recipient in a taxable year is required to report the payment to the IRS and to the payee. Examples of payments of fixed and determinable income include rent, salaries, wages, premiums, annuities, and compensation.

Q-13: Is a person who in the course of a trade or business makes a payment using virtual currency worth $600 or more to an independent contractor for performing services required to file an information return with the IRS?

A-13: Generally, a person who in the course of a trade or business makes a payment of $600 or more in a taxable year to an independent contractor for the performance of services is required to report that payment to the IRS and to the payee on Form 1099-MISC, Miscellaneous Income. Payments of virtual currency required to be reported on Form 1099-MISC should be reported using the fair market value of the virtual currency in U.S. dollars as of the date of payment. The payment recipient may have income even if the recipient does not receive a Form 1099-MISC. See the Instructions to Form 1099-MISC and the General Instructions for Certain Information Returns for more information. For payments to non-U.S. persons, see Publication 515, Withholding of Tax on Nonresident Aliens and Foreign Entities.

Q-14: Are payments made using virtual currency subject to backup withholding?

A-14: Payments made using virtual currency are subject to backup withholding to the same extent as other payments made in property. Therefore, payors making reportable payments using virtual currency must solicit a taxpayer identification number (TIN) from the payee. The payor must backup withhold from the payment if a TIN is not obtained prior to payment or if the payor receives notification from the IRS that backup withholding is required. See Publication 1281, Backup Withholding for Missing and Incorrect Name/TINs, for more information.

Q-15: Are there IRS information reporting requirements for a person who settles payments made in virtual currency on behalf of merchants that accept virtual currency from their customers?

A-15: Yes, if certain requirements are met. In general, a third party that contracts with a substantial number of unrelated merchants to settle payments between the merchants and their customers is a third party settlement organization (TPSO). A TPSO is required to report payments made to a merchant on a Form 1099-K, Payment Card and Third Party Network Transactions, if, for the calendar year, both (1) the number of transactions settled for the merchant exceeds 200, and (2) the gross amount of payments made to the merchant exceeds $20,000. When completing Boxes 1, 3, and 5a-1 on the Form 1099-K, transactions where the TPSO settles payments made with virtual currency are aggregated with transactions where the TPSO settles payments made with real currency to determine the total amounts to be reported in those boxes. When determining whether the transactions are reportable, the value of the virtual currency is the fair market value of the virtual currency in U.S. dollars on the date of payment.

See The Third Party Information Reporting Center, http://www.irs.gov/Tax-Profession..., for more information on reporting transactions on Form 1099-K.

Q-16: Will taxpayers be subject to penalties for having treated a virtual currency transaction in a manner that is inconsistent with this notice prior to March 25, 2014?

A-16: Taxpayers may be subject to penalties for failure to comply with tax laws. For example, underpayments attributable to virtual currency transactions may be subject to penalties, such as accuracy-related penalties under section 6662. In addition, failure to timely or correctly report virtual currency transactions when required to do so may be subject to information reporting penalties under section 6721 and 6722. However, penalty relief may be available to taxpayers and persons required to file an information return who are able to establish that the underpayment or failure to properly file information returns is due to reasonable cause.

source: http://www.businessinsider.com/irs-bitcoin-is-property-not-currency-full-release-2014-3?op=1


Is it possible to download all blockchain raw data? I'm interested in doing some analysis on the blockchain that would require specific information about all individual transactions within each block. I don't need the data to be updating in real-time, but I am looking for something that at least encompasses all the transactions made in the past year. I've tried to find downloads for this kind of dataset, but I haven't had any luck. Any ideas?

Any (full) Bitcoin client will download the entire blockchain. It's stored in files on disk which you can look at after it's been downloaded. The current blockchain size is 115 GB of raw data (the size on disk will be a bit larger because of indexes created by the client).


I used the wallet out of sync and cannot find my adress This is the first time I am buying BTC, I used my bitcoin core wallet out of sync to generate and address and then I shut down the PC after the full sync has been made. Now I cannot find the address in the file anywhere. I still have the address and if I search it on blockchain.info it says that the payment has been made. Although, my wallet balance is zero. Can someone please explain how can I redeem my BTCs?

Thank you

Bitcoin Core doesn't check if it's in sync with the network or not. Try using rescan to make the client go through all the blocks in the blockchain and find the transactions affecting your wallet.


Bitcoin mining algorithm I was looking at some sample mining algorithms and also some sample code and there was something which I didnt really understand. In Simple bitcoin mining algorithm he says ,
The simplest miner would work like this:

The simplest miner would work like this:

     1. Request a new [Getwork][1] from a given pool/bitcoind with specified credentials
     2. For nonce=0;nonce<0xFFFFFFFF;nonce++
     - Set Getwork Data nonce
     - SHA-256 hash the Getwork Data ([block header][2])
     - Check if hash result is smaller than Getwork Target, if so, submit a share
     - If more than 1 second passed since you received Getwork, stop the loop
     3. GOTO: 1

What I dont understand is step 2, part 4. Lets consider the above script is connected to an FPGA through a uart port. Wont I wait until the FPGA actually finds a valid nonce and submits the none through the UART line? Why would I exit out of the loop after 1 second and then go through the entire process again. This doesnt make sense to me because then the fpga has only a few seconds to increment the nonce for the given work and it then moves on to the next piece of work? How is this even realistic since even if the same work is submitted again it will go through the same loop and will end up doing nothing productive. What error am I making here? Sample code that I am talking about:

https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/projects/Verilog_Xilinx_Port/sources/software/miner.py does the same thing. It says golden.wait(timeout) instead of just calling golden.wait() and blocking till a nonce is found

The data being hashed is constantly updated. The block header contains a time field and is updated every few seconds. If it doesn't timeout and reset (get new work), the algorithm will be working on a stale header.
"When generating, you constantly hash the block header. The block is also occasionally updated as you are working on it."
https://en.bitcoin.it/wiki/Block_hashing_algorithm


Aborting/cancelling a transfer transaction I'm running Bitcoin Core and I'm 7 days behind syncing currently.

Last night, I initiated a transfer of some bitcoins to another person (He bought it from me) However, 4 hours later, he closed his account, and hence, the money he paid me was returned to him automatically without my approval. Since that is the case, I needed to cancel/abort the transfer.

As the bitcoin network is very busy at this time (there were over 10000 unconfirmed transactions), I have no idea whether my transaction will eventually get confirmed or not.

I shutdown the Bitcoin Core app then deleted the mempool.dat file and restarted the Bitcoin Core app with the -zapwallettxes command so as to tell the Bitcoin Core app to delete the transaction. The app is currently rescanning.

Before the shutdown,  I can see that the transaction is still unconfirmed.

UPDATE: Bitcoin Core app has finished rescanning, and the unconfirmed transfer transaction has came back.

How can I abort this transaction?

You can't cancel a transaction even if your node has not yet synced. Your transaction is immediately broadcast to the network.

If the tx is still in the mempool, you send the coins to yourself with a higher fee... and pray.


Multiple inputs with one signature From this question I've learned that a transaction with N inputs requires N sign operations.

But what if there a huge amount of inputs? E.g. I have a coffee shop and I sell 5000 pcs coffee every day for $1 each. If I want to transfer my daily income I'll end up with a transaction with 5000 inputs.

Counting with 100kB max transaction size ~300..400 inputs can be included in one transaction. So I need to make 10..15 transactions every day. In addition, if I have a hardware wallet that needs let's say 500 ms to make a signature it will take 5000*0.5 sec = 41 min to sign all the inputs.

What is the correct way to handle this?

Is there an option to sign the transaction only once and use this signature for all the inputs?

The current signature scheme that bitcoin is using (ECDSA) doesn't support signature aggregation, so you will have to sign each input and provide one signature per input (assuming it requires only one signature) and your transaction size will grow accordingly.

  sell 5000 pcs coffee every day for $1 each

Then you might want to look into Lightning Network. It works on top of bitcoin as a second layer and for micro and frequent payments it is the better choice:
https://lightning.network
How does the Lightning network work in simple terms?


How do I get number of pending transactions for an arbitrary blockchain How do I get number of pending transactions (queued and waiting for confirmation) for an arbitrary blockchain? Do I need to download that blockchain? There should be a more adequate way.

Due to the decentralized nature of blockchains, the state of transactions is relative.  A pending transaction is one that your node has seen and verified as valid, yet your node has not seen a block that includes it.  This might not be the same state that other nodes see.

For example, one-block chain forks are a common occurrence, where there is a disagreement on the network as to which block is the next valid block.  This will usually resolve itself when a block is found on top of one of these two blocks, but in the meantime, there is disagreement about which transactions have been included in a block.

There is also the possibility that your node has not seen a transaction, whereas other nodes (including mining nodes) have.  You wouldn't have this transaction in your list of pending transactions, even though there are miners actively attempting to include it in a block.  The opposite is also true, where you have seen a transaction, but miners are ignoring it for whatever reason.  Bitcoin is actually pretty good about these scenarios, so it normally isn't an issue, but it is a possibility.

In addition, there is the question of a transaction's validity.  Even though you can be fairly certain that a transaction is valid without independently verifying it with a downloaded copy of the blockchain, you can only be completely sure if you do independently verify it.  If your node is ever wrong or in disagreement with the network about a transaction's validity, then you may consider it pending whereas mining nodes will never include it in a block.  Again, the opposite is also possible.

In order to see which transactions your node (assuming Bitcoin or Bitcoin-based) has "pending", you can use the getrawmempool RPC command.

Further reading:

bitcoind getrawmempool without downloading the full blockchain

Is it possible to view unconfirmed transactions with the bitcoin client?


How OP_EQUALVERIFY works in a standard transaction? 3 weeks ago I began learning about Bitcoins, and now I'm analyzing how it works internally. My problem is that I can't understand what two public key hashes are compare to use de OP_EQUALVERIFY, because I understand that sender's public key is compare with receiver's public key, but they aren't the same hash.

Here is an example:
A script is: the scriptSig of your tx + the scriptPubkey of the tx you spent

In the same example:
The scriptSig of your tx is: Sig + your pubkey
The scriptPubkey of the tx you spent is (according to blockexplorer):

OP_DUP OP_HASH160 fc88853163ab2a9646908a82e8a87b6f185c2047 OP_EQUALVERIFY OP_CHECKSIG

I hope

ripemd160(sha256('0x0457d7d7af586aaad529b5770bb43295051e7090e2bc884181d608dae2517c7812b25e326753cbe0b767f579bbcb5cffe492d22b93f2ff5501074eb9e8f8547c4a'))
 = fc88853163ab2a9646908a82e8a87b6f185c2047...

I read that but I can't understand that the stack and scripts function.
The stack is empty. On the first step the Sender’s Signature and Public Key are combined. Then these two constants are added in the stack. Then the Public Key is duplicated. After that this duplicated item is hashed. Now the Receiver´s Public Key Hash is added to the stack. The script compares the equality between the two slack items and finally the signature is checked for two slack items.

Is that correct? I think that i'm wrong with something.
If it is posible to someone answer or reply me

Thanks.

The script in the output is created first. Its form is typically:

OP_DUP, OP_HASH160, pubKeyHash, OP_EQUALVERIFY, OP_CHECKSIG

pubKeyHash is the hash contained in the address being sent to. So it is the hash of the public key of the receiver.

When this receiver wants to spend this output, he must construct an input to claim it, and provide the actual public key that corresponded to his hash, and signature using it:

signature, pubKey

Twice, the same public key data is used. Once by the sender, stating the hash of the public key of the receiver, and when the receiver becomes a sender himself, he provides his full public key.


On the Bitcoin testnet, will transactions with higher fees get mined quicker? I wonder if anyone here has spent enough time on the Bitcoin testnet to give me some insight on how the market forces there work. I am a teaching assistant in a university blockchain course with ~75 students, and I plan to start an assignment in a few days where students acquire testnet BTC from faucets and start crafting transactions. There are currently about 14,000 unconfirmed transactions in the testnet mempool, and I wonder whether you can avoid waiting long if you increase your fee. Larger fees would obviously help on the Bitcoin mainnet, but I'm less sure about how miners behave on the testnet.

Because the testnet bitcoins have no financial value, the transaction fees aren't really an incentive for miners there. But we assume that miners will run similar software to that on the mainnet and make sensible decisions regarding the fees they put in a block, so higher fees should make the transactions mined faster yes.