txout script criteria (scriptpubkey critieria)

Absolutely no consensus validity checks are done on a scriptPubKey. Nodes have soft requirements called IsStandard for what they will relay to their peers as a transaction (a completely junk script or very large OP_RETURN output for example will not pass) but these are not consensus rules. Some miners will mine non-standard transactions into their blocks, but generally to get a transaction to them a transport other than the P2P network needs to be used.

OP_RETURN is a special case refereed to as "provably un-spendable", this is a response to people jamming hashes and other data into PubKeyHash outputs as a way of pegging them in time to the block chain. Due to there being no way of knowing if the output is actually valid or not these outputs must be stored forever in the UTXO pool. An OP_RETURN prefixed output can absolutely never be spent, so nodes can safely forget that they ever existed.


Online Bitcoin Script simulator or debugger?

Highly recommend btcdeb by kallewoof. Among other things, you can step through scripts including verify signatures. It is written in c++ and compiles using autotools.

btcdeb

Bitcoin Script debugging utilities.

This is a set of tools used to debug or construct scripts for use in Bitcoin.

btcdeb> help
step     Execute one instruction and iterate in the script.
rewind   Go back in time one instruction.
stack    Print stack content.
altstack Print altstack content.
vfexec   Print vfexec content.
exec     Execute command.
tf       Transform a value using a given function.
print    Print script.
help     Show help information.


How hard it is to destroy BitCoin system if the government leaders decide to do this?

since the government controls the physical internet

They do not (at least in North America or Europe). The internet is a network of communication. An Internet Service Provider (ISP) can be private or public, but either way it's function is to direct addressed transmissions to those addresses (IP addresses).

This network is a kind of base layer. The early days of Bitcoin/crypto found heavy usage in illicit online activities, meaning not allowed by the government. How were these activities carried out in a controlled network? By taking advantage of networks built on top of this base layer internet. TOR, I2P are some examples of these.

If Bitcoin/crypto were to be heavily prosecuted, nodes could (and have) take refuge in these hidden networks.


I'm digging further into the open Taproot PR. Can you explain the bip340_test_vectors?

These bip340_test_vectors are used in two places: the unit tests (src/test/key_tests.cpp) and the functional tests (test/functional/test_framework/key.py).
The Python code for testing the bip340_test_vectors is here.
There are 15 test cases in all but only 4 distinct secret keys, 7 distinct public keys (3 of them don't have secret keys) and 15 distinct signatures.
The public key DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659 is reused 9 times for example but the distinct signatures are generated using different messages, auxiliary randomness etc.
The first five test cases have valid signatures (a verification result of TRUE) although the fourth test case (index = 3) has a comment of test fails if msg is reduced modulo p or n (I'm not sure what this means)
That leaves the remaining test cases that fail the signature verification:
The elliptic curve that BIP 340 signatures are defined upon is secp256k1 (the same curve that we use for ECDSA) which is:
y2 = x3 + 7 (mod p)
where the field size p = 2256 - 232 - 977 or
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F in hex and is prime.
The generator point G (on the curve) that we use is (Gx, Gy) where
Gx=0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy=0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
The curve order of secp256k1 is:
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
(The curve order n is such that nG = point at infinity. Every n times we cycle back to the point at infinity. The point at infinity is defined here. It is not on the curve and is defined by (x,y) + (x,-y) = infinity.)
The public key P (point) associated with a secret (private) key is calculated using:
P = d (mod n).G
where d is the private key (scalar) and G is the generator point (point).
A BIP 340 Schnorr signature is a 64 byte array (Rx , s).
The first 32 bytes is the X coordinate of R.
R = k'⋅G
R is a point (Rx, Ry)
k' is randomness (mod n) as specified by BIP 340
G is the generator point defined earlier
The second 32 bytes is the s that satisfies:
s⋅G = R + H(r | pk | m)⋅P (mod n)
This can be written as s.G = R + e.P where e = H(r | pk | m)
Or alternatively s = k' + e.d where d is the private key (scalar).
G is the generator point defined earlier (point)
R is calculated earlier (point)
H is the hash function (function)
r is the the X coordinate of R, Rx  (scalar)
pk is the X coordinate of the public key P, Px (scalar)
m is the message (scalar). The message in Bitcoin's case is the part of the Bitcoin transaction that needs to be signed according to the SIGHASH flag.
P is the public key (point)
Index 5 has a public key that is not on the secp256k1 curve that Bitcoin uses. The public key is calculated by multiplying the private key (scalar) by the generator point and so it must be on the elliptic curve. If it isn't it is not possible to generate a valid signature. Indeed the secret key is not provided for this public key as there is no secret key that can multiply with the generator point to get the public key.
Index 6 is referring to the BIP 340 design choice to implicitly choose the Y coordinate that is even (each valid X coordinate has two possible Y coordinates, one that is odd and one that is even). If the Y coordinate is odd then it is not following the BIP 340 specification and the signature verification should fail.
Index 7 uses a negated message to verify a signature of an original message. Negated means taking the complement with the group order n. The signature won't be valid if you verify it using the negated message rather than the actual message used in the signature.
-m = n-m (mod n)
Obviously there are no actual "negative" numbers in the ring of integers (mod n).
Index 8 has a negated s value. See Index 7 for the definition of negated. If you validate with a negated s rather than the initial s the signature validation will fail.
Index 9 states R = sG - eP is infinite and that the test fails if has_even_y(inf) is TRUE and x(inf)=0. The point at infinity is not on the curve, has no coordinates at all but implementations need a representation of it. If an implementation uses (0,0) as the point at infinity then this test will fail if has_even_y returns TRUE (which it shouldn't) and x(inf) returns 0.
Index 10 states R = sG - eP is infinite.
Index 11 states sig[0:32] is not an X coordinate on the curve. If the first 32 bytes of the BIP 340 Schnorr signature is not an X coordinate on the elliptic curve then this is not a valid signature.
Index 12 also refers to first 32 bytes of the signature. But this time the 32 bytes are equal to the field size of the curve p. This is not possible under mod p (all values must be between 0 and p-1) so no valid signature is possible here.
Index 13 refers to the second 32 bytes of the 64 byte signature. s can't be equal to the curve order n because it is defined mod n which means it can only take a value between 0 and n-1.
Index 14 has a public key with a X coordinate that exceeds the field size (p = 2^256 - 2^32 - 977). This is not possible under mod p (all values must be between 0 and p-1) so no valid signature is possible here.
(Jimmy Song's Chapter 3 on Elliptic Curve Cryptography of his book Programming Bitcoin is helpful for explaining the secp256k1 curve. It was published before BIP 340 was finalized and so only covers ECDSA signatures, not Schnorr signatures. For an introduction to Schnorr signatures see Elichai Turkel's presentation at Chaincode Labs or this London BitDevs Socratic Seminar on BIP 340)
Thanks to Pieter Wuille and Jonas Nick for suggested edits on the initial post.


If SHA256 produces an alphanumeric hash, how can a hash be "less than a certain value"?

Not that other answers are wrong here, but just to approach your confusion from another angle:

  SHA256 hashing algorithm, which produces alphanumeric hashes.

That's not true. The hashing algorithm produces a stream of bytes. Only when you display that bunch of bytes on your screen it's common for it to be in hexadecimal (containing "alphanumeric" characters A to F) but that's just for display purposes to make it human-readable.

You may as well display that same bytes as a large decimal number (requires more screen space and doesn't have the advantage that each two digits represent exactly one byte from the original. Or you could display it in binary: 256 zeroes and ones.

  My question is, how can one alphanumeric hash output be "less than" another?

Even disregarding the above, what stops you from sorting a list of words alphabetically? One word will be "less than" another word.


Newbie restrictions - you need to be logged in for 4 hours and post 5 posts to the Newbie section in order to be allowed elsewhere.


How to generate a Bitcoin Private Key Checksum

F29E9187 are indeed the first four bytes of the double sha256 of the bytes:

802CF24DBA5FB0A30E26E83B2AC5B9E29E1B161E5C1FA7425E73043362938B982401

In order to check this, you need to compute the double sha256 of this array of bytes. However, as already discussed, passing the string 802CF2... to the hash function will not yield the right answer, as this string is not the array of bytes itself (it is a hexadecimal encoding of the array). So let us create a binary file which corresponds to the hex encoding above:

$ echo -n 802CF24DBA5FB0A30E26E83B2AC5B9E29E1B161E5C1FA7425E73043362938B982401 \
   | xxd -r -p > temp

Let us check our binary file temp has the correct bytes:

$ hexdump -C temp

00000000  80 2c f2 4d ba 5f b0 a3  0e 26 e8 3b 2a c5 b9 e2  |.,.M._...&.;*...|
00000010  9e 1b 16 1e 5c 1f a7 42  5e 73 04 33 62 93 8b 98  |....\..B^s.3b...|
00000020  24 01                                             |$.|
00000022

So far so good. We can now compute the first sha256 hash of these bytes:

$ sha256sum temp
08a9d3e1296633b2a4071316eaf597f1c93a0ec2f4b68b24c6e0ad2e7c06540c  temp

Again, we are faced with a hex encoding which we need to convert to actual bytes:

$ echo -n 08a9d3e1296633b2a4071316eaf597f1c93a0ec2f4b68b24c6e0ad2e7c06540c \
  | xxd -r -p > temp

Checking once more:

$ hexdump -C temp

00000000  08 a9 d3 e1 29 66 33 b2  a4 07 13 16 ea f5 97 f1  |....)f3.........|
00000010  c9 3a 0e c2 f4 b6 8b 24  c6 e0 ad 2e 7c 06 54 0c  |.:.....$....|.T.|
00000020

So let's compute the sha256 hash of these bytes:

$ sha256sum temp
f29e9187a566a24502d7cd2eae948e74bc4dfafc7deff44cce80e1256ef12a3e  temp

you can see that the first 4 bytes are indeed F29E9187.


Insufficient money, need xxxxxx Satoshis

Seems others have had similar problems with that wallet

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

Support
Issue


Prioritize transaction with low fee [regtest]

The issue got resolved. I had to prioritize the transaction before bumping fee, so the correct order of things mentioned in question will be:

Tx1

Prioritize Tx1

Bump fee

Tx2

Mine a block

Reason: Maybe we can't prioritize a transaction that is already replaced with a new transaction. I think prioritisetransaction should have returned some error or at least false in this case. However, I noticed it returns true for almost any transaction id. I copied a transaction id from testnet explorer and even that returns true when I use it with prioritisetransaction on regtest.


How can I create a list of X richest bitcoin addresses?

Have an up-to-date blockchain in ~/.bitcoin
Download and compile blockparser.
Run ./parser allBalances >allBalances.txt


Can I cancel a transaction that has no confirmations due to low satoshis?

The only way to cancel it is to replace it with a newly created transaction that overrides the previous one, and hope that by the higher fee this one gets confirmed earlier.


You may want to check BTCPay Server

More links for source and documentation.

In the past I would have recommended BitPay, but they've had too many red-flags that show that this company does not have the best interest of Bitcoin in mind.


How can I find the transaction that spends a specific output via an API?

I would parse the blockchain. There are libraries for almost any programming language. You can in a 5-liner scan through all transactions and see which input they spent. You need to do this with a local parser and not via an remote api as remote api calls would take way too much time.
If the input txid is an element of your funding txset wich you collected before it is a channel close (for now while we don't have Splicing)

On the other side 1ml.com has a history of channels with the closing tx. So you might be able to get the data you seek from them.


Deriving payable address from mnemonic using BIP44

When you say simplified code it's hard to tell where you are going wrong.
Here's an example of how you can derive a bip44 key pair from a mnemonic using bitcoinjs-lib v3.3.2
let mnemonicInput = 'width bicycle axis tell burst outdoor tray episode where they forest meadow enhance twin focus';
let seedHex = bip39.mnemonicToSeedSync(mnemonicInput).toString('hex');

//"14a3235efb14b096e8cc3082b89e0b629ec5c7b2c6621343b2657cb61853b0830623e97b8aeac416d3377b4da90a4838d9aea4d83e0117fd833049305af46f10"

let root = bitcoin.HDNode.fromSeedHex(seedHex);
let deriv = 44;
let account = 0;
let change = 0;
let index = 0;

let acct = root.derivePath("m/"+deriv+"'/0'/"+account+"'");
let xpub = acct.neutered().toBase58();
let pair = acct.derivePath(change+"/"+index).keyPair;

let wifkey = pair.toWIF();
let address = pair.getAddress();

//"address":"1BogrbApan5Q9xEFEzwPioRu3ogYkzAQZU"
//"wifkey":"L46hcht5ue2tsSKmPEV2v41CrGU8DEJAP1w7XYPbvJ72v5NBPsPF"


What is the origin of insecure 64-bit nonces in signatures in the Bitcoin chain?

Based on the time-frame and my impression of the capabilities of the various groups developing wallet software during that period my initial guess was that the Bitpay copay software might be the source of these signatures. Copay is a multi-signature wallet which was initially released around that time.

As I'm not a javascript developer it took me a bit of effort to dig through the historical dependencies to find the code that was applicable at that time, but I believe my suspicion is likely confirmed:

[If there exists some tool to go grab all of the dependencies of a JS application as of some date that would have been super useful.]

  return new bignum(SecureRandom.getRandomBuffer(8));

This code chooses an 8-byte (64-bit) nonce.  I'm unclear as to how exactly this mistake came about--sending 32 to a function that took bits as a size argument, for example, would have made sense--but however it happened it wasn't caught in review and appears to have been shipped.

The pull-request that introduced the vulnerability was making the javascript cryptography implementation faster by switching the underlying EC operations to a different library, 'elliptic'.  At the time elliptic featured its own signing functions which included RFC6979 deterministic nonce generation. I don't see why bitcore wasn't changed to use the elliptic signing function even with the author of elliptic commenting in support of the PR but since there was pre-existing 'home rolled' signing code it just may not have occurred to anyone to switch to the library routines. There isn't a lot of discussion on the pull-request.

The vulnerability was subsequently fixed but weak signatures continued being created for some time.  Because Bitpay's bitcore was promoted as an all purpose Bitcoin library it's possible that other software than copay had adopted it.

I'm unable to find any announcement of or discussion about this vulnerability other than the fix in the repository.

Though I haven't carefully analyzed it, I noticed that prior to switching to elliptic that codebase previously used "bitcoin-js" which--at least in some versions--used a random number generator which was weak due to a review-evading subtle type error so it may well be the case that the error-introducing change simply changed the software from one form of weakness to another.

It's also possible that although bitcore had exactly the right vulnerability introduced at the right time that it was coincidental and the bad signatures found in the paper were created by some other implementation. If so, I think the parallel breakage is still informative.

I think the research and the relevant code make for a fine example of how easy it is to get these things wrong, how even small errors can result in total security breaks, and that the mere fact that something is open source does not automatically ensure that it has received adequate review.


Can someone explain what is a mining RPC?

RPC stands for Remote Procedure Call and it is a technology that allows you to perform actions on a machine being on another machine (or on the same machine but in a different process).

The new RPC calls from the update are calls related to Bitcoin mining. Most mining software will use these calls to get information from the bitcoind client running on the same machine.

So, nothing to do with crypto, just an extension of the API you don't have to worry about.


Buying BTC with PayPal, preferably automatic, mid 2015

I don't know of any services, especially automatic, which accept PayPal. LocalBitcoins will rarely have vendors accepting PayPal, and even then, it's going to be very much a reputation based judgement call. A vendor accepting PayPal has everything to lose (the Bitcoins and the PayPal money), so I'd be highly doubtful any service would even accept PayPal, let alone without identification or oversight. (Which begs the question, if you want privacy why are you using PayPal?)

Maybe try Bitcoin-OTC or BTCJam if you don't like LocalBitcoins


Should you protect your Bitcoin address like your credit card number?

A bitcoin address is not like a credit card number. You can safely give your bitcoin address out publicly.

What the email is asking for is something you should never give out publicly: the mnemonic that you use (e.g. if you use Electrum, they have a 12-word mnemonic code), from which you can calculate your private keys. With this, they can easily steal all bitcoins on any address that was generated using that mnemonic.

If they actually wanted to know that you are the owner of an address, they could ask you to sign a message. There's not normally much of a reason to do this, though: I don't see a scenario in which a signed message is needed in order to give you money, instead of just the address.

If they actually just wanted to send you money (as they claim), all they need is your address.


The transaction has a lot of outputs. On of the outputs is the address you mentioned. The tx lookup in www.blockchain.info says, that 0.0579332 BTC was sent successfully with 2175 confirmations (as per today) to 17tmL8Jsa4Hv9ZVVwtKCgrpqr1TbaNxgMp.

There is also a "return address", which transfers 57.68039601 BTC to a SegWit address (bc1qgukqed6kdae4hjgdz9cm7xhrp2mu39054mwa2m). So I assume the funds come from an exchange or similar institution.

If you are the owner of the address 17tmL8Jsa4Hv9ZVVwtKCgrpqr1TbaNxgMp (aka: you have the private key for this address), then you own these funds, and can spend it.


How is the Leaf node weakness in Merkle Trees exploitable?

In Bitcoin, inner nodes of the merkle tree are constructed by concatenating two 32 byte SHA256d hashes together. The resulting 64 byte value is hashed to get the next node in the tree. The leaf nodes are the transactions themselves. Merkle trees are used to prove that a transaction is part of a block as the merkle root is placed in the block header for the proof of work.

However, given just a merkle branch to prove a transaction's existence in a block (as SPV wallets need), it is impossible to distinguish which node in the branch is an inner node and which is a leaf node. Thus a special 64 byte transaction can be constructed which tricks SPV nodes into thinking it is actually an inner node of the tree and not a leaf node.

The last 32 bytes of that special transaction are constructed in such a way that it is also a valid hash of another fake transaction. Both the fake transaction and the last 32 bytes of the special transaction can be modified in order to brute force a transaction hash that is also valid as the last 32 bytes of the special transaction.

Once the special transaction is included in a block, the attacker can provide a fake proof to an SPV node that "proves" the fake transaction is part of the blockchain. This fake proof would be the legititmate merkle branch to the special transaction, but also includes the special transaction as if it were an inner node of the merkle tree and the fake transaction becomes the leaf node.

To protect against this attack, SPV nodes can simply verify that no inner nodes of a merkle branch are also valid transactions. Such an event is extremely unlikely, and such transactions are also non-standard so unlikely to be included in a block unless this specific attack were being performed.


Finding nonce resulting in more zeros than the target

Nothing special happens in this case.

If you find a nonce for which the hash has at least the necessary number of zeros (or more precisely, is numerically less than the target value), you have a valid block.  That's all.  As far as I know, the Bitcoin protocol pays no attention to whether there are "extra" zeros.

Of course, if someone submits a block header with a drastically large number of extra zeros, people might reasonably take this as evidence that they have broken the SHA256 hash function in some way, perhaps with some sort of preimage attack.  This might lead to developers wanting to phase out the use of SHA256.  But that's beyond the scope of the protocol or the software.


Are Bulletproofs fully implemented into liquid?

No, the Liquid system isn't using Bulletproofs yet.

The code has been written to use them, but switching over will require more review, and a hardfork upgrade once deployed.


Yes, the difference between the input and the output is the transaction fee, and there's no way for you to get it back once it has been mined (except for building a fork that results in a stronger chain---not likely unless you have >50% of network hash rate).

In the future, I highly recommend experimenting on testnet (bitcoind -testnet) or using regtest mode.  That way you don't lose any wealth when you make a mistake.


Armory paper backup without private keys

Yes. To move BTC OUT of the wallet you need to access the wallet and issue the send command (type in password if you set one) to send coins to another address.

You can send coins to your paper backed up address without having that wallet online, even if you created the wallet offline and it never touched the internet once.

This is a security design to keep your coins as safe as possible. Otherwise anybody else could just move your coins.

If you lost your keys or passwords then the coins are lost, even if you know the address.


ncdns uses the wrong nameserver to resolve .bit domain

I needed to put a trailing period into the "ns" record in the blockchain.  Then the correct nameserver was used.

Also, ncdns is NOT a recursive nameserver, so it returned the correct NS record but did not reach out to the nameserver for the IP.  I had to set up Unbound as described in the ncdns readme in order to actually resolve my .bit domain to an IP.


In LN, how could a payer prove to 3rd party that he indeedly made a payment to the payee?

In lightning the receiver of the money comes up with a random secret and comits to it via the payment hash. Once all the hashed time lock contracts (htlcs) are set up along a path through the network from the sender to the receiver the recipient will release the secret preimage for the chain of htlcs to settle. The preimage can be seen as a proof of payment. However as with the onchain case there is some doubt. Every node along the route who participated in the payment will know the primage of the payment hash and could thus argue that they initiate the payment


Does any university accept bitcoin to take course fee?

University of Cumbria, a British University, is the first Public University accepting bitcoin in the UK for two of its courses. “Certificate of Achievement in Sustainable Exchange”, will be taught at Cumbria’s London campus, and the “Postgraduate Certificate in Sustainable Leadership”, which will take place at the Lake District campus. http://www.independent.co.uk/student/news/cumbria-becomes-first-public-university-in-the-world-to-accept-bitcoin-in-tuition-fees-9074700.html

Other options globally include the University of Nicosia in Cyprus (http://www.unic.ac.cy/news-and-events/73/unic-to-be-the-first-university-in-the-world-to-accept-bitcoin/112831#.UuFCG9LnaUk) and there are unsubstantiated rumors that Novi Sad in Serbia takes them as well.


Is there a reward or penalty for validators in proof-of-stake (PoS)?

To give an example i know, in Tezos which has a variant of POS called LPOS (liquid proof of stake), at high level and without giving too much details:

the incentive to participate is offered by block (and endorsement) rewards which act de facto as a form of inflation
in order to keep bakers in check to avoid bad behavior (confirm bad transactions, double baking etc...) there's a bond/penalty system where the network locks some amount of your capital (the bond which is equal to 32x the block reward) for a period of time (2 weeks in practice). During this period if some other node can show evidence (through the protocol) that the baker was behaving bad then the bond is forfeited.

More details about LPOS is available in this medium article

https://medium.com/tezos/liquid-proof-of-stake-aec2f7ef1da7


Getting error while running Blockchain.info api

Blockchain.info is really not working anymore, seems to be they are stopping API service or there's something wrong. Since API don't work anymore (callbacks - gap limit so far).


Using a Bitcoin or Litecoin miner for attacking PBKDF2 / SHA-256

Would it be possible to reprogram a miner to do this work, or are all the current miners too specialized to perform such operations?

A Bitcoin mining ASIC can only do a single task, mining, it has no ability to do anything further than take an 80 byte header, hash it, and return a nonce if it has a large enough of zero bits. In terms of applicability to general SHA256 computing tasks, it has no relevance whatsoever. They can not do single SHA256, return under any circumstance but a low hash, and can not hash arbitrary data. Scrypt based ASICs do exist, but they are hardcoded to stupidly low parameters nobody would use for password hashing in the real world, the other caveats also apply.

  Is there a - possibly older - miner that can be reprogrammed to do this work?

A FPGA can be reprogrammed to do almost any task you take the time to author a bitstream for, it would be possible in some circumstances use FPGA for attacking hashes. The Bitcoin mining FPGA that were used in around 2013 do not have much relevance however, as they were never designed for high bandwidth performance between the host and the chip. You might have been communicating over a 9600 baud serial connection which is too slow to send any significant amount of data across.

GPUs are generally used for this sort of task instead, where you have extremely fast and low latency connections to the CPU and a high degree of concurrency for computing hashes. The efficiency is not as high as dedicated hardware (FPGA or ASIC), but they are commodity devices which can be used for a lot more of these sort of tasks. A high end card can compute in the order of half a billion SHA256 hashes a second when the input is only several compression rounds long, though it will burn upwards of 400W while doing so.


How to find my private key! Please help!

If you never had the private key for the bitcoin account you are trying to use, then you can't just recover or "find" it.
This is one-way algorithm: private key -> public key. You can get public from private, but not another way around.


The best way to transfer between exchanges without fees is bitcoin.

Coupons (like mtgoxusd) used to be very nice, but now it seems fees are often charged in addition to some of the coupons becoming unreliable.

An arrangement in #bitcoin-otc may work well at a low fee, but -otc isn't often quick.

In consideration of these two facts, I've come to the conclusion that it's typically quick and cheap enough to convert to BTC and transfer that.


Is a bank account sufficient to receive money in Bitcoins?

Bitcoin is a form of money, asking if you can "receive it to your bank account" is like asking if you can "receive gold to your bank account".
The answer is generally going to be "no, you have to first exchange the bitcoin for your local currency, and then you can deposit that money to your bank account".
Be aware: bitcoin is a borderless digital asset, so while transferring it across the world is generally quite quick and easy compared to legacy financial instruments, if your goal is to use it as an intermediary (eg USD -> BTC -> INR), then you'll likely encounter exchange fees (ie, the service fees of the exchange service you use) and other friction (KYC, etc). It is very possible to use BTC in this way, but it is a lot clunkier than just using BTC alone to settle payments.


How do I print unspent transaction outputs of an address using pybitcointools

>     print bitcoin.unspent('16jn6k2FJqwrNLDpbZmmmpf4TCW7uM6LED')

Sovled the issue.


Historical transaction/trade ratio. Available? Useful?

You can access the data for each currency on each exchange with the Markets API from BitcoinCharts:

For example, for USD:

http://bitcoincharts.com/charts/chart.json?m=thUSD
http://bitcoincharts.com/charts/chart.json?m=mtgoxUSD


How does getblocktemplate select transactions?

The whole mempool won't fit in a block; getblocktemplate returns enough transactions for a block. Blocks are, by default, limited to 750kb by policy, but many miners increase the size to the block limit of 1mb (which can be done by command-line flag).

The specific piece of code that decides on the transactions that should be included in a block can be found here. It's reasonably well documented, and not terrible to read, I'd suggest taking a look through it to see where your script operates differently.


Did any customers lose money with the Mt Gox / Dwolla legal situation?

Here is the timeline for my deposit, which shows that at least one deposit was honored:

May 14 @ 10:14 AM CST --> Dwolla notified me that money was sent
May 14 @ 12:16 PM CST --> Dwolla notified me that DHS seized Mt Gox's account
May 14 @ 08:53 PM CST --> Mt. Gox notified me that funds from dwolla were deposited

I can't speak about other transactions with certainty, but from the fact that my deposit went through and the lack of any major "I lost $3,700 during the DHS crackdown" news stories, my guess is that all transactions that happened around this time were either honored or rolled back.


Subscribe for market depth updates using Mt.Gox streaming API

Heres how I do it in node.js

var events = require('events');
var io = require('socket.io-client');

var MTGOX = function(){
    var self = this;
    var socket = io.connect('https://socketio.mtgox.com/mtgox');

    socket.on('message', function(data){

        var message = data;

        if( message.private == "depth"){
            self.emit('depth', data.depth);
        } else if( message.private == "ticker" ){
            self.emit('ticker', data.ticker);
        } else if( message.private == "trade" ){
            self.emit('trade', data.trade);
        }

    });
};

MTGOX.prototype.__proto__ = events.EventEmitter.prototype;

and then I just listen to the depth event. Also I found this project helpful when I was first figuring this out.


What benefits does Tau-Chain add over conventional solutions?

Turing complete languages are undecidable: it can be proved that some algorithm cannot always work as expected for all possible inputs. I believe that most of these problems have to do with deciding if another algorithm can or cannot do something.

An undecidable (programming language) grammar means that you cannot be certain what the meaning of a given program (source code) is just by looking at the code. Look at the answers of this question for examples.

A classic example of undecidability is the halting problem:

  In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running or continue to run forever.

For completeness also read this, especially the "Mathematical theory" section.

In contrast a decidable programming language can mathematically prove that a program will always have the expected results; e.g. a smart contract written for Tau-chains can be proved that it will not suffer the halting problem before deploying it. It is my understanding that it just helps you reduce possible bugs.

Note, that in Ethereum the halting problem is not a such a big issue since the contract will eventually run out of gas, but it would be good to catch it before deploying it forever in the blockchain!

Having said that, in Tau-Chain they use Ontologies and RDF and in my experience it is much much harder to code anything using RDF and reasoners (although reasoners do allow for smarter programs but I cannot comment more since I do not know the Tau-Chain language's semantics).

Also read this for a comparison between Ethereum and Tau-Chain, from the Tau-Chain guys perspective.


The number of confirmations a transaction has is a measure of how many blocks make this transaction permanent. The number of confirmations a transaction has minus one is a measure of how deep a transaction is in the blockchain.

The deeper a block is in the blockchain – that is: the bigger the difference between its block number and the highest block number in the longest blockchain it is apart of is. –, the exceedingly less likely it is that it is ever going to not be part of the longest blockchain.

For a transaction, this means that they are more permanent the further down they are because it then becomes exceedingly unlikely that the block it's in is ever going to not be part of the longest blockchain.

In any valid blockchain, a transaction can only appear at most once.

If a transaction is not part in any block of the longest blockchain, it has 0 confirmations. If it is included in the newest block, it has 1 confirmation. Once there is another block on top of that block, it has 2 confirmations. Another block on top of that one, and it has 3 confirmations, etc.

A transaction's fee can only be collected my the miner of the block it is included in. And it usually is collected by that miner, of course.


Can I win some money mining bitcoin with an old computer

The short answer: No, you cannot. Sorry.

The longer answer can be found here: https://en.bitcoinwiki.org/wiki/Difficulty_in_Mining#How_soon_might_I_expect_to_generate_a_block.3F

Applying some common sense: If an old computer could mine for 50 USD / EUR / GBP per month, what do you think how many old computers would your neighbor have bought already and was running in his garage?

Bitcoin mining is only possible on specialized hardware these days. Your milage may vary on very, very recent high end GPUs, but this is far from an old unused PCs CPU power.


wallet.dat backup and 100 pregenerated keys

Better yet, bitcoin-qt should have a permanent pool of 100 addresses, and add a new random address when you use one, in a FIFO style. That way you should be quite safe if you do less than 100 outgoing transactions between backups!.

That's what it does.


how to insert new checkpoints in a bitcoin clone

It's in form of

{block_height, uint256S("0xblock_hash")},

For example,

{134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe")},

If you search for "00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe", that block's hash on Blockchair,
you'll find the block with the height 134444.

Simple, huh?

EDIT: Your edit is partly corrected. Note that when you add a checkpoint, you don't hardcode the block into the client. When a user opens it for the first time, they'll download all blocks starting with the first block. Checkpoints allow the clients to verify if someone who created his/her block chain completely different than the main chain is sending you the fake chain. The clients do download the whole chain and verify the blocks with checkpoints (also see: assumevalid)


When a difficulty change reaches the upper or lower bound (4x current), what is the implied impact on time per block?

The network doesn't "throttle" the blocks found. Rather, it simply doesn't change the difficulty by a factor of more than x4 in every adjustment (which is once every 2016 blocks). There is no limit on the rate of block generation.

Let's say you were in an equilibrium where a block is found every 10 minutes. Right after a difficulty adjustment, more power joins the network and the hashrate is x100 the original. The difficulty didn't change yet so now a block will be found every 6 seconds. This will go on for 2016 blocks (~3 hours) and then the difficulty will go up by x4. Now a block will be found every 24 seconds; after 2016 more blocks (~13 hours) the difficulty will go up again by x4. Then a block will be found every 96 seconds, for 53 hours; then a block will be found every 384 seconds, for 215 hours; then the hardcoded limit will not be active, the difficulty will go up by a factor of (600/384), and now a block will be found every 10 minutes.

In those times that the total hashrate is too high for the current difficulty, the level of forking will be as if the time constant was shorter. So forking will indeed be high if the total hashrate has just rapidly increased.


What are the next forks of the Blockchain that have been announced?

Just to be clear, anyone can "announce a fork", but adoption and news of said fork depends on the market demand for the new coin. Most recently, Bitcoin was forked to create Bitcoin Cash (BCH).

Bitcoin SegWit2x (a bitcoin hard fork), Bitcoin gold (a bitcoin hard fork), and Bitcoin ABC (a Bitcoin Cash hard fork) are upcoming hard forks. (note: Bitcoin SegWit2x may or may not result in a currency split, depending on how miner support plays out)

  When will they occur?

Bitcoin SegWit2x at block number 494,784 (no way of knowing exact date) and Bitcoin ABC on November 13th, 2017. Expect many more in the future!

  Where can you be kept updated?

Twitter, reddit, or a google alert with keyword "Bitcoin" :)

Previous Forks:

Bitcoin Cash forked from Bitcoin on Aug 1st, 2017.
Bitcoin Gold forked from Bitcoin at block number 491,407


Is there any statistical analysis of the security of a "Brain Wallet"?

There are roughly 170,000 words in the english dictionary according to this link. If you combine 4 random words (170,000^4) , you get 8.3*10^20 potential combinations which is more than 2^64 (1.8*10^19). However 64 bits of security is generally considered weak these days.  Bitcoin uses 256 bit keys (1.1*10^77 combinations) so if you want that level of security you need to use at least 15 words (2.8*10^78). Altering cases will obviously increase the potential combinations by a significant factor. Different languages have different number of words so that will change the calculations as well.

This calculation only applies if you choose the words completely randomly. People keep ignoring this important detail, and is the reason why brain wallets are not recommended. There are many cases of people getting their bitcoin cleaned out because they choose common phrases or include commonly used words in their private key.


Is mining hardware particular to specific mining algorithm(s)?

Different currencies have different mining algorithms. What you should do is to use coinwarz.com to calculate the most profitable one, by filling in the details of the mining hardware's specs of the miners you're thinking about buying.

Be sure to put cryptocurrencies' future values (predict them!) and when the next miner may be released (predict!) into account (which coinwarz can't)


where can I get realtime ticker data for robots?

Poloniex has a PUSH API, check their API FAQ here: https://poloniex.com/support/api/

The other API requests they have said to have 6 request/sec rate limitation, which in my opinion is still pretty close to real-time if you update the Ticker this way.

Kraken does not provide PUSH API, from their FAQ it looks like a normal user (Tier 2) has a limitation on ticker of 1 request per 3 seconds (0.33 request/sec), but will be blocked for 15 minutes when exceeded.

Coinbase has only a PULL API with a 10,000 request per hour (2.7 request/sec) based on their Developer guide, although they operate a separate business called GDAX which has a WebSocket based real-time API.


Difference between Sign Message and Sign Transaction

Is the difference that for "Sign Message", first a digest is created, which is then signed, while for "Sign Transaction" (in the meaning written above), the input is already a digest, so it shouldn't be hashed again?

No. It has nothing to do with the hashing. Furthermore, the input is not already a digest, it must be hashed before signing. Both the message and the input data are hashed twice with SHA256.

The difference between message signing and transaction input signing is that message signing prepends the string Bitcoin Signed Message:\n (with \n being a newline character, not literally \n) to the message before it is hashed.

Additionally, the 65 byte signature produced by message signing has a byte at the beginning that is not part of the cryptographic signature itself. Instead it is a recovery id so that the correct public key can be recovered from the signature during signed message verification. In transaction signatures, there is a different byte appended to the end of the signature which is the sighash type, usually it is the byte 0x01.


Service that displays how many inputs/outputs there are in the blockchain?

http://webbtc.com/stats

This website displays statistics about its own output database, though it should be very rare that any developer need to maintain an index in this way. Most people will only need to interact with their own, unspent outputs rather than the entire history of the mostly unrelated chain.


How come the fees were higher than the actual amount in the bitcoin transaction?

Basic explanation:

Two things are happening here, first, the transaction is quite big (2903 bytes). And second, the inputs of the transaction hold really low value (
27982 Satoshi each). If we put together this two facts, what happens is what you have seen, that the most of the transaction value is spent in fees.

Extended explanation:

When a previous transaction output (utxo) is used to create an input of a new transaction, there is a minimum amount of data that it will add to the transaction. This data can be split in two parts, a fixed_size that will be non-dependant of the input type, and a variable_size,that will depend on the input type (and therefore in the utxo type).

The fixed_size can be defined as follows:

fixed_size = prev_tx_id + prev_out_index + nSequence = 32 + 4 + 4 = 40

In the transaction you are referencing, all inputs are P2PKH, which means that the minimum amount of variable_size data that creating an input will contribute to the transaction can be expressed as follows:

min_variable_size = scriptSig_len + PUSH signature + signature + PUSH public_key + public_key

Signatures can be 71-73 bytes depending on their r and s components, and public keys can be 33/65 bytes, depending whether they are compressed or uncompressed. If we take the minimum signature size, and compressed public keys, the result is as follow:

min_variable_size = 1 + 1 + 71 + 1 + 33 = 107

and therefore:

min_size = fixed_size + min_variable_size = 147

Then, if we check how big was the transaction (2093 bytes) and how much was paid as fees (408400 Satoshi) we get that the fee ratio paid is around 141 sat/b. Now, if we check how much we should pay just for including one of our inputs in the best case we get:

min_size * fee_ratio = 107 * 141 = 20727

So, around the 74% (20727/27982 * 100) of each input value is spent just for paying the fees required to spend itself. If you take into account the rest of the transaction (version, outputs and nLockTime), we got that around the 85% of the inputs value is paid as fee:

total_value = 475694
fee = 408400

perc = fee / total_value * 100 = 85.85


Transaction Sent Taking almost 2 days , what's wrong? Help pls

For the block 441662, actual block, the medium fees are around 0.0007 BTC per a transaction's size equal to 226 byte.

Your transaction has 0.0001 BTC as fees for a transaction's size equal to 520 byte.

So, miners will ignore your transaction until one of them pick it up in his block or stay ignored and finally refused (if it'll take a long time or if there is something with your transaction) and the coin will return to the sender.

You can also rebrocast your transaction again untill it'll be confirmed as soon as possible.

Next time try to put more fees in order to have fast confirmations.


Where can I find a graph of average transactions per block over time?

For a chart of the average number of transactions per block per day:

http://blockchain.info/charts/n-transactions-per-block


Try starting with the -reindex command-line flag. That will rebuild the database on disk (as it seems corrupted), without redownloading the blocks you already have.

It's strange that wiping your datadir didn't help though.


Can I still use that version, or do I have to upgrade to the latest Bitcoin Core?

You can still use that version. I would upgrade to the latest stable version, though.

  Besides backing up my wallet, should I do anything in preparation before I reconnect the old computer to the Internet, or before upgrading software?

No, you're good.


Purpose of token standard interfaces when implement smart contract

It's a standard.

ALL those ERC20 based tokens have (at least) the same attribute names, the same method names.

So I do automaticly know that I need to call the method "transfer" when I want to transfer my tokens. No one would name it "transfer_tokens_hello_world". Irrelevant which of the thousands of token I want to transfer: It's always the same method.

The advantage for exchanges and/or user interfaces is that it's really easy to implement. If an exchange list token A and B, then token C has the same structure and it's easy to implement it, too.


How do I find out what block a transaction is in?

./src/bitcoin-cli getrawtransaction 4ef653dc90aa25e1a0cc8a45f0484524010e5cc77b8159df6916466c07036482 1 (mind the 1 at the end which means you wish verbose output)

...
    "blockhash" : "000000000000000009e865d07f75341a5f3dc15f0e149055a241eedd552c3b88",
    "confirmations" : 1,
    "time" : 1433965052,
    "blocktime" : 1433965052
}


Is it normal all testnet p2wsh cosigners have same master public key?

Not normal, each cosigner should have a unique master public key.

There is a reported bug in Electrum 3.3.6 that causes the issue on macOS.

Until a fix is pushed to production, it’s possible to get master public keys using the Electrum console (View/Show Console).

[k.xpub for k in wallet.get_keystores()]


Ledger 8 pin number how hard in terms of entropy is it to guess?

With an 8-digit PIN, the number of possible PIN combinations is 10^8 (100,000,000), ranging from 00000000 to 99999999.

So you chance of just guessing the PIN correctly within three tries is about 1 in 33,333,333. So it is of course possible, but extremely unlikely.

Note that an attacker could perhaps increase their chances by eliminating some possibilities (eg, assume nobody would just choose 00000000 as their unlock PIN), and/or by making a more educated guess based on knowledge of the victim (eg their birthday is 19 Jan 1980, so try the PIN 19011980).

Entropy is often described in terms of bits. To find the total entropy, take the binary logarithm of the total number of combinations. This turns out to be 26.575 bits of entropy.


How is this procedure a proof of reserve?

What i don't understand is: What purpose has the signing of a selected message by the third party, described at the end of the first page?

Without this step, it is possible that the transfer you're observing is entirely unrelated to Bitstamp. They could have watched the chain for a while, waiting for a transfer of sufficient amount, and then claim that it was theirs.

Assuming you trust the third party is in fact a third party, and is not colluding with Bitstamp, the signature proves that BitStamp in fact has control over the private key the funds were sent to, meaning they also have control over the funds.

Note that there is research around more advanced cryptographic techniques that do not rely on a third party, and don't require moving all funds around. For example, see this paper: http://www.jbonneau.com/doc/DBBCB15-CCS-provisions.pdf.


Where can I go to read up on encryption methods used in Bitcoin?

Here's a short explanation that might help you understand it. It's grossly oversimplified but just designed to help you get the general idea.

Imagine a world in which multiplication and addition were irreversible. That is, division and subtraction do not exist. It is not too difficult mathematically to create a world where division and subtraction are trillions of times more difficult than multiplication and addition, so for practical purposes, division and subtraction are impossible.

Now, let's say we all agreed on a very large number. Call it G. It's some big number we all agree on.

Now, you can pick a random number and store this someplace very safe. Call it your "private key", S (for secret). Now, multiply it by G. Call the result your "public key", P. You can tell anyone your public key. Since they can't divide it by G, your private key will stay private.

Now, say you want to "sign" something, O. What you do is you take that something, add your secret key to it, and publish the resulting number. So you publish: O+S, that's your signature

First, nobody can tell your private key from that number. They'd have to subtract, and that's not practical. And nobody else can produce that number, they'd have to know your private key to know what to add to O.

So all we need is for someone to be able to prove that's the "right" number and we're there -- and they can do that. Why? Because G * (O+S) = G * O + G * S.

They know what you claim is O+S ... the signature. G*S is your public key. And they know O. So with just some addition and multiplication, they can compute both G * (O+S) and G*O + G*S. So they can check if the number you published really is O+S if those two are equal, thus that the person who computed it knew your private key, and thus it functions as a signature.

The challenge, of course, is to create systems in which multiplication and addition are possible but subtraction and division are not. And there the math gets complicated. Bitcoin uses a system where division requires discrete logarithms and a change to the algorithm so that it doesn't matter if addition is reversible.


Why do mining pools require 120 confirms for a solved block before payout?

There is a protocol rule which prohibits generated BTC from being spent until it has 100 confirmations. The Satoshi client has an additional safety margin: it won't let you spend generated BTC until it has 120 confirmations. The purpose of this rule is to prevent long chain splits from invalidating lots of transactions that spend newly-generated BTC. For example, this rule prevented non-coinbase transactions from being invalidated after the overflow incident invalidated 50+ blocks.

Some pools (e.g. Eligius) pay people by putting the payments in generation transactions. The recipients still won't be able to spend this BTC for 100 blocks, but at least the payments will appear in their Bitcoin clients right away.


As the lightning network is a specified protocol and as both implementations are open source and spec compliant it should theoretically be possible to migrate from one implementation to another.

However practically spoken you will need a software tool that transforms all the internal data formats of lnd to the ones used in c-lightning without messing the nodes state. I am not aware of any tool that converts the internal data formats. That being said either you go out and create such a tool or you will have to install a new node (even with a new nodeid)


Don't miners control who is allowed to make transactions?

The stakeholders of bitcoin don't want miners to do that. If miners do that, the stakeholders (the people who are paying for the miners to mine) would change the rules. For example, they'd change the mining algorithm. That would turn the miners expensive ASICs into space heaters (a little faster).

  Don't miners have way to much power in the current system? Especially since crypto is supposed to be decentralized

The miners only have power because the people paying for their mining hardware and electricity like the job they're doing. If they don't provide the censorship resistance and forward progress without double spends that the stakeholders want, the rules will change.

Miners know this and such a scenario would cost them a huge amount of money, so they are strongly incentivized not to let it happen.


Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.

That's not correct.

SegWit replaces the concept of size and maximum block size with weight. The weight of a transaction is defined as 3 times the stripped_size in bytes (excluding the witness) plus the total_size in bytes (including the witness). The maximum weight of all transactions in a block is 4000000. This is the only limit that matters. Due to the way the weight formula is constructed, it implies that the old rule (stripped_size <= 1000000) is always satisfied. Miners try to get as much fees out of the weight limit they have available, and as a result optimize for fee per weight.

So, transaction sizes don't matter anymore. What matters is their weight. Unfortunately, there is a factor 4 scaling between the two, so you can't easily convert feerates from before SegWit to after. For this reason, the concept of vsize (virtual size) was introduced. It's equal to weight/4. For non-SegWit transactions, their size and vsize are identical. The easiest way to express fees is now to see them as BTC per vbyte (vsize byte).

  How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?

In your example, the weight of your transaction is 3*400 + 500 = 1700. This means its vsize is 425 vbytes. As a result, its feerate is 1000 / 425 = 2.35 sat/vbyte, and it would compete with other transactions at that level.


My mate received and then sent a Bitcoin transaction before his wallet was synchronised and it worked perfectly

You don't have to do anything to receive Bitcoins. That's entirely passive. Your client doesn't have to be running.

To send Bitcoins, you just need enough information to form the transaction. If you have the transaction that sent them to you and you know it was confirmed, that's sufficient.


Remember to restart bitcoind again after you make any change in bitcoin.conf file. It seems as if you set an rpcpassword in the conf but didnt restart the bitcoind service. You have everything set up properly i guess.


Since we have the ephemeral private key which has to be random how can I sign two times the same transaction and get the same signature as Bitcoin RPC does.

This "ephemeral private key" is known as a nonce. Bitcoin Core, and most other wallet software, use a technique called Deterministic Nonces. Specifically, they use the algorithm defined in RFC 6979 to produce the nonce deterministically. It essentially hashes together the message and the private key being used and uses that hash as the nonce. If you sign the same message with the same private key multiple times, the same nonce will be used and thus you always get the same signature.

  What is the hash that should be signed, the whole transaction without the signature, do I have to exclude any fields?

For non-segwit inputs, the message that is signed is the entire transaction with all other input scripts empty. For the particular input being signed, the scriptPubKey or the redeemScript if there is one, is put in the input script. Then the sighash type is appended to the end. This is hashed twice and that hash is then signed.

For segwit, the message is a bit more complicated and described in BIP 143.


As I commented, with the psbt package from btcsuite/btcutil it is possible.

I have created an example of how to use it. I don't know if this is the best/most efficient way of doing it. But I hope this gives you a template and example to work with. But it is relatively low-level and without some deeper technical understanding of Bitcoin it may be difficult to follow.

It spends the second (0-indexed) output from this transaction on Testnet.

package main

import (
    "bytes"
    "encoding/hex"
    "fmt"

    "github.com/btcsuite/btcd/chaincfg"
    "github.com/btcsuite/btcd/chaincfg/chainhash"
    "github.com/btcsuite/btcd/txscript"
    "github.com/btcsuite/btcd/wire"
    "github.com/btcsuite/btcutil"
    "github.com/btcsuite/btcutil/hdkeychain"
    "github.com/btcsuite/btcutil/psbt"
)

const (
    // Provided PSBT with one P2PKH input. Created in part 1 below.
    psbtBase64 = "cHNidP8BAFIBAAAAAX7Mj1abZbFtfUYFYBIFRKxCOxs8wfMRu3NhVBHTbnFfAQAAAAAAAAAAAayEAQAAAAAAFgAU8yFPpRndMpAJ7aO+RtRN4Nh3mbYAAAAAAAEBH6CGAQAAAAAAFgAUJw/E3xSMUU+8VVGHXk7Dc4vGNjkiBgOoVLKI2rj2DMlswSDkSf0KR7jQHULLPOWS/x3q8b3MqQyj8e/WAAAAAAMAAAAAAA=="

    // Extended Private Key.
    extPrivateKeyStr = "vprv9GpFMh8VMAXKgdZVFGXFvsexjr25MHKvtCY7vKHbRr8A6xCm4bQYbQrJmLz6h3F9MGf5edwxQuZR7DCLFVvjMxgfJ9so9mcN2SHGR3QFr3S"
)

// Part 1: Creating the PSBT (will be returned as base64)
func part1() string {
    // The extended private key was generated with Electrum and we derive the
    // specific key used.
    // `keyC` contains the private key that _contains_ the coins to be spend.
    keyC, _ := hdkeychain.NewKeyFromString(extPrivateKeyStr)
    fingerprint := keyC.ParentFingerprint()
    keyC, _ = keyC.Child(0)
    keyC, _ = keyC.Child(3) // Electrum derivation of the 4th address.
    pubKeyC, _ := keyC.ECPubKey()

    // Create a brand new PSBT spending the following outpoint.
    txhash, _ := chainhash.NewHashFromStr("5f716ed311546173bb11f3c13c1b3b42ac4405126005467d6db1659b568fcc7e")
    outpoint := wire.NewOutPoint(txhash, 1)
    inputs := []*wire.OutPoint{outpoint}
    pubkeyScript, _ := hex.DecodeString("0014270fc4df148c514fbc5551875e4ec3738bc63639")
    spendTxOut := wire.NewTxOut(100000, pubkeyScript)

    // The address and amount to send funds to.
    outAddress, err := btcutil.DecodeAddress("tb1q7vs5lfgem5efqz0d5wlyd4zdurv80xdkfkf3cn", &chaincfg.TestNet3Params)
    // The witnessScript consists of a `0x00`, followed by the size of the
    // pubkey-hash `0x20` and the pubkey-hash itself.
    witnessScript := append([]byte{0, 20}, outAddress.ScriptAddress()...)
    outputs := []*wire.TxOut{wire.NewTxOut(99500, witnessScript)}

    // Create the psbt instance.
    pC, err := psbt.New(inputs, outputs, wire.TxVersion, 0, []uint32{0}) // Note: typically the sequence is `0xffffffff`!
    if err != nil {
        panic(err)
    }

    // Use the Updater to add information to the input.
    u, err := psbt.NewUpdater(pC)
    if err != nil {
        panic(err)
    }

    u.AddInBip32Derivation(fingerprint, []uint32{0, 3}, pubKeyC.SerializeCompressed(), 0)
    u.AddInWitnessUtxo(spendTxOut, 0)
    u.AddInSighashType(0, 0)

    // Show the base64 encoding of the unsigned PSBT.
    b64, _ := pC.B64Encode()
    return b64

}

// Part 2: Sign the PSBT in base64 encoding and return it.
func part2(psbtBase64 string) string {
    // Reader for the PSBT.
    psbtBytes := []byte(psbtBase64)
    r := bytes.NewReader(psbtBytes)

    // Create instance of a PSBT.
    p, err := psbt.NewFromRawBytes(r, true)
    if err != nil {
        panic(err)
    }

    // Load the extended private key.
    bip32Key, err := hdkeychain.NewKeyFromString(extPrivateKeyStr)
    if err != nil {
        panic(err)
    }

    // Derivation path should be read from PSBT.
    // Note: We ignore checking the fingerprint, etc.
    path := p.Inputs[0].Bip32Derivation[0]
    for _, d := range path.Bip32Path {
        bip32Key, _ = bip32Key.Child(d)
    }

    pubKey, err := bip32Key.ECPubKey()
    if err != nil {
        panic(err)
    }

    privKey, err := bip32Key.ECPrivKey()
    if err != nil {
        panic(err)
    }

    // Manually creating the signature.
    sigHashes := txscript.NewTxSigHashes(p.UnsignedTx)
    sig, err := txscript.RawTxInWitnessSignature(p.UnsignedTx, sigHashes, 0,
        p.Inputs[0].WitnessUtxo.Value, p.Inputs[0].WitnessUtxo.PkScript,
        txscript.SigHashAll, privKey)

    // Use the Updater to add the signature to the input.
    u, err := psbt.NewUpdater(p)
    if err != nil {
        panic(err)
    }
    sucess, err := u.Sign(0, sig, pubKey.SerializeCompressed(), nil, nil)
    if err != nil {
        panic(err)
    }
    if sucess != psbt.SignSuccesful {
        panic("could not sucessfully sign for some reason")
    }

    // Finalize PSBT.
    err = psbt.Finalize(p, 0)
    tx, err := psbt.Extract(p)

    var buf bytes.Buffer
    tx.Serialize(&buf)
    return hex.EncodeToString(buf.Bytes())
}

func main() {
    fmt.Println("Base64 PSBT: ", part1())

    fmt.Println("Signed tx: ", part2(psbtBase64))
}


HyperLedger Fabric from IBM is fork of Tangle or Etherium?

No, they are not related at all. The Hyperledger documentation is not short. The Hyperledger Github project does not mention Tangle as far as I can see. The only similarity with the Hyperledger documentation and Etherium documentation is that they are hosted on Read the Docs and look similar, the content is completely different. Hyperledger, Tangle, and Etherium are developed completely independently.


There are many possible explanations and many possible ways to investigate
Possible causes

The sender mis-typed the receiving address. This is hard to do if the
sender scanned a QR code. There are usually checksums built in that
make it hard to get a mis-typed address accepted. Nevertheless it is
possible

You gave the sender a different address than the one you think you did.
This can happen as many wallets issue a different receiving address
for each transaction.

You accidentally gave the sender the address of a wallet that uses
a different crypto-currency than the crypto-currency the sender sent.
This is fairly common. It is arguably too easy to confuse Bitcoin cash
for Bitcoin.

The sender didn't pay a sufficient mining fee

Your wallet is no longer synchronising

You didn't wait long enough

Fraud

If you are using a web-wallet where you depend on a third party, there are also a lot of other ways in which things can go wrong. Especially if the
provider of the service aggregates transactions. (This is one reason I would prefer to use a standalone wallet).
Ways to investigate.

Go to a blockchain explorer website and enter the transaction-ID.
Do the same for the receiving address. Check that your transaction appears.
Check that everything is as you would expect it to be.

Re-check the address you used, letter by letter. re-check the currency.

If your wallet is hosted by a third party, raise the issue with their
customer support service.


How does the miner efficiently check that an address has required amount of data?

So the miner has to look up all the blocks form block 1 to the end, which has over 500,000 blocks (and will grow even bigger), for each transaction. And a block contains thousand of transactions. This sounds impossible to me.

No, it just maintains a set of all unspent outputs. For each output in each transaction in a block, an entry is added to that set. For every input, one is removed.

It doesn't need to go through the entirety of history for each input; it just looks it up in the database.

Also, this is not restricted to miners. Every node performs this operation. Miners are only kept honest by the rest of the ecosystem verifying that the blocks they produce are valid.

  "A node maintains a list of all unspent transaction outputs." This request each node to maintain billions of address and their unspent transaction outputs. Is this even possible

No, addresses aren't relevant here. The UTXO set is just a set of UTXOs. Each UTXO has an address (or more precisely a scriptPubKey or locking script), but they are identified by the transaction that created them and the position within that transaction.

Every transaction refers to actual UTXOs being spent (by listing the txid and index of the transaction that created them). They're not looked up by address.

The address (script) is only involved in determining whether a particular spend was authorized, by runni g the script with the signatures provided in the input, and checking it evaluates to True.

At the time of writing (July 2018) there are about 49 million entries in the UTXO set. For many systems the entire set easily fits in memory.

You are correct in being concerned about the future though. There are no real incentives in the system to keep this set small, and its growth is effectively unbounded.

There is research into moving to models where nodes don't actually maintain this set themselves anymore, but transactions instead contain proofs that the UTXOs being spent exist and aren't spent yet. Useful search keywords are Bram Cohen's bitset model or Peter Todd's Merkle mountain ranges.


Is there a limit on the number of characters in a wallet.dat file?

There has never been a limitation on the characters or number of characters that could be used in the passphrase.


How are bitcoin trade profits taxed in Poland?

Although I am no polish or live in Poland, I would recommend to claim it as you would do for a investment. If the government finds out your not paying tax, the consequences are far greater than the tax you would pay.

If your not sure then just call the tax department of the Polish government.
On Forbes Cameron Keng has written this  article, check it out and see if it answers your question. I've red it and it does give me a vague answer.

Hope this has helped


For all transactions, "transaction time" is effectively 0. A transaction is created nearly instantaneously and broadcast to the network with no noticeable delay to a human.

What you are confirmed about are confirmation times. The time it takes to get a confirmation is only related to the transaction fee rate paid and the time it takes to mine a block. The size of the transaction is irrelevant.


There is at least one totally "offline" backup of blockchain?

This question in Skeptics SE asks "Will the Sun's magnetic activity disrupt electronics on Earth?"

As I understand it, the disruption has a limited geographical area of effect, and protection for a device can be achieved by simply disconnecting the power and network cables to disconnect it from long-distance grids (which amplify the effect).

I'm sure there would be some offline backups available even if every PC that was plugged in was fried. I would assume servers in data centres would mostly have adequate protection already. For the vast majority of people with an interest in Bitcoin, the other effects that might come with widespread power and network outages would almost certainly be a bigger worry than any issues with bitcoin.

All that said, I recommend keeping multiple backups of your wallet in a variety of locations. Maybe you should keep a reasonable amount of cash handy in case of emergency too, if you're worried about geomagnetic storms...


How do I extract my private keys from a protobuf wallet?

Since "when you're a developer it's easy" is probably not sufficient for most people, here is the full step-by-step from a Android Bitcoin Wallet to importing the private keys in Electrum which (finally...) worked for me. This solution uses bitcoinj. The approach using the .proto definition file and opening the wallet in Python was also tested, but seems more error-prone.

Requirements:

Android Bitcoin Wallet in a new version (to my knowledge, some older versions do not allow a backup).
Bash shell: tested with the Windows Bash, but should work on native Linux or OS X. Basic knowledge (cd etc.) helps.
On my system, maven and openjfx were required. Install them with sudo apt-get install maven, sudo apt-get install openjfx
Electrum (current: 2.9.2)

Step by step:

Backup: save the encrypted wallet (Safety -> Back up wallet) and move the backup file to your computer (e.g. via file transfer, Dropbox, e-mail...).
Decrypt: open the bash, move to your data directory and use openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-backup > bitcoin_decrypted as stated above, which will ask for the encryption password.
Install bitcoinj:

git clone https://github.com/bitcoinj/bitcoinj.git
cd bitcoinj
git fetch --all
git checkout v0.14.4
mvn install (fails at GroupTest in Windows bash, but works anyway)
cd tools
./wallet-tool

load the decrypted wallet and dump the private keys:

./wallet-tool dump --wallet=/mnt/d/path/to/wallet/bitcoin_decrypted --dump-privkeys > /mnt/d/path/to/wallet/bitcoin_decrypted_dump.

Please note that this saves the unencrypted private keys in the file "bitcoin_decrypted_dump". Move this file to a save location (e.g. TrueCrypt/VeraCrypt container) or delete it after use.

Create a new wallet with the private keys in Electrum: File - New/Restore - filename - 'Standard wallet' - 'Use public or private keys', then list the 'priv WIF' keys from the dump file.

On handling the BTC/BCH question with Electrum and Electron Cash, please read the notes on the Electrum webpage.

If there are any questions, feel free to ask. Good luck!

Sources:

This page
https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.recover.md


How can someone get my private data (such as email, name, IP ...) from bitcoin transaction?

IP addresses are not private information. As for email and name no one can get that information based on the blockchain data alone unless you go out of your way to publicly associate your identity with a specific address. For example by mentioning your email, name and address together on some website. Another possibility is that you reveal your identity to some service like a bitcoin exchange or payment processor and then send or receive bitcoin using that service. That service will now have some idea of what addresses belong to you simply because you used their service. The world at large will not know though.

Note also that you have many addresses in your wallet not just one address. Ideally you use a different address each time you want to receive bitcoin. This is better from a privacy and security standpoint. It also makes it easy for you to track who sent you how much by giving each person a different address for every transaction.


Passphrase works in Bitcoin QT, but does not in Bitcoin Core

The problem described seems quite strange. I don't know what's preventing you from unlocking the wallet.dat. I think this might be caused by InputMethod/halfwidth and fullwidth forms/CapsLock/NumLock... Double check these things before typing your passphrase.

At last, if you still cannot figure out what's preventing you from unlocking the wallet, you could try to export your private keys on your old PC, one by one.

On your new PC, if you have finished the initial syncing with latest version of Bitcoin Core, you may open the debug window, switch to the console tab, then try the rescanblockchain command. This should make your wallet balance up-to-date, which would take some time to complete.

Then, listunspent command would indicate which addresses your bitcoins are currently stored in. You may save the text, then copy it to the old PC.

On your old PC, launch bitcoin-qt. It doesn't matter whether the blockchain syncing is complete or not. Open the console, first use walletpassphrase 'YOUR_PASSPHRASE_HERE' 3600 to keep your wallet unlocked for one hour, then use dumpprivkey ONE_OF_YOUR_BITCOIN_ADDRESSES_HERE for each of your Bitcoin addresses.

Once you get all the private keys, you will be able to import them to almost any Bitcoin wallet.


Are competing blocks a problem to weak participant of the network?

That is essentially a 51% attack. It is a very real, but unlikely threat to the Bitcoin network. Historically as it turns out, it is more lucrative to simply add more processing power to the network than fight it.


I have not heard about an API that would return averages per se. But there are APIs that will provide you with a historical price data which you can use to calculate averages on your own.

One example would be CoinDesk, but I am pretty sure there are more. They have a JSON endpoint that will return closing prices for a given period (1 month by default). Examples:

Default (one months period): https://api.coindesk.com/v1/bpi/historical/close.json

Custom date range: https://api.coindesk.com/v1/bpi/historical/close.json?start=2018-01-01&end=2018-07-01


The attack is this simple:

You connect to both the merchant and every major mining pool.
At the same time, you send a transaction paying the merchant to the merchant and a conflicting transaction that pays yourself to every major mining pool.
The merchant sees the transaction paying them, and accepts it with zero confirmations.
The mining pools see the transaction paying yourself first, so they try to work that transaction into blocks. Eventually, one of them succeeds and the merchant will never get paid.

If you accept payments with zero confirmations, you should connect directly to multiple points in the Bitcoin network as close to major mining pools as possible and monitor for any conflicting transactions -- even if seen later. (There are other things you must do too. It's not trivial.)


I had an account on a website, but don't remember which one
Search your email account for an account creation confirmation email. Helpful search terms may include "bitcoin", "wallet", "exchange", "btc", "blockchain", or "cryptocurrency". If you purchased bitcoins, you may want to look at your old bank statements as well. There is no global register of bitcoin users or services, so if you cannot find anything you may be out of luck—we cannot help you, because we don't know either.
I had a web wallet, but the service shut down since
If the service had custody of your bitcoin balance, it is likely lost. Research the name of the service to determine what happened to the service, in case it just rebranded and is still around.
My wallet service still exists, but I lost access
We don't have insight into your customer relationship with services, so we cannot help you. Contact the service and initiate an account recovery process.
I had a self-custodial wallet, have lost the wallet, and have no backup
Bitcoin balances are tracked via the blockchain, and a user's bitcoin wallet primary purpose is to secure the private keys which are used to establish ownership and to track any transactions related to those keys. The key space is enormous. If you have lost your wallet, the same keys will likely never be regenerated and no one will ever be able to spend the associated funds.
I had a self-custodial wallet, and still have the device that it was installed on
Looking over this selection of wallets may help you remember which one you used. If you still have the wallet files, you may be able to recover your funds. The name of the relevant files depends on the software that you used, but one of the most common file names is wallet.dat. If you find a wallet file, create a backup first before trying to recover the wallet.
I have a 12 or 24 word backup, what do I do?
This is called a mnemonic seed phrase. It is a standardized way to backup a wallet's private keys. Keep the words confidential, do not enter the words in a website or untrustworthy software. You should be able to recover your wallet from the phrase. You can find instructions how to recover the wallet from it on this site.


Bitcoin Transaction Stuck, Attempt to double spend with higher fees

The problem has been resolved.

My second transaction, although only listed on LocalBitcoinschain and nowhere else has been approved.


Is there a way to allow use of unconfirmed RBF outputs in transaction building?

Bitcoin Core will happily spend RBF marked inputs it doesn't avoid them much less prohibit them.

Perhaps you're being confused by the fact that it will not spend an unconfirmed input created by a third party? Or maybe you have spendzeroconfchange set off or only have long-chain unspents?


Should I keep my bitcoin-qt wallet running all the time?

The first time you load the client, it can take some time to download the whole blockchain (currently something like 15 GB). However, if you close the client and then reopen it, the client will only download the new blocks from the blockchain that it hasn't seen yet. The previous part of the blockchain is already stored on your computer.

To catch up a day's worth of blocks should only take a minute or two. It's perfectly reasonable to close the client when you're not using it.


What app should I use to import my wallet keys?

Since I don't know what wallet app on Android you're using, I'll give an answer that should work for any:

If you create an account at Coinbase, you can import your private keys and then send them to an address on your Android wallet. This requires the private keys being in plain text. If your private key export is encrypted (with a password you gave it) or encoded in some non-obvious fashion, you'll need something to decode it before using this option.

If it's encrypted in a way that's compatible with the desktop Bitcoin-QT client, you can reclaim it that way.

If it's encrypted some other way, you'll likely need to restore it to your Android phone and enter a password there to get access to your bitcoins. This would be specific to the app you're using.

If you're using Bitcoin Wallet, which seems to be the closest thing to an "official" Android client, choose "Back up Keys" from the menu (on my device, I press the Menu hardkey to open that), and then click "Restore private keys".


Can one wallet send/receive bitcoins from/to multiple sources simultaneously?

You seem to be missing Unspent Transaction Outputs (UTXO) as a piece of the puzzle here:
Every transaction on the network results in one or more UTXO. You can think of them as a bill with the value of the received transaction. Every time you make a transaction,  the UTXO you put in get destroyed and new ones spendable by the recipient get created. Since each UTXO is unique, they cannot clash with each other (you getting a bill from one person doesn't stop you from getting another from someone else), and you can only spend them once you have received them.


Suppose I have an online Bitcoin wallet. Now, someone breaks into my computer and steals my Bitcoin wallet.

It is generally not recommended to store Bitcoin in any online wallet or exchange. Mostly because it is unlikely that you are in full control of your private keys. In the event the website is compromised, hacked, or you become victim of some sort of man-in-the-middle attack, you are at risk of losing your funds. This is especially true if the service is poorly managed (Mt. Gox had a similar fate).

  Fortunately I have a backup of my wallet on another computer. Now, What determines who has the bitcoins now?

Anyone who obtains your private key(s) have full control of your funds. The only variable in this case is time (who can spend the funds faster). If you are even slightly concerned your keys may have been stolen but have not yet been spent, you should defiantly move them out of that wallet and into a freshly generated one.


My Bitcoin.com wallet is asking for a password to confirm send that was never established. So im screwed or file a class action for this?

If you really never set a PIN, and obvious things like "0000" don't work, then this might be a bug in the app software.  You could report the bug at https://github.com/bitcoin-com/wallet/issues, and include full details about what you did.  They might have suggestions about what to do, but there may or may not be a workaround.

I suggest that you avoid expressing anger, frustration, or legal threats in your bug report.  The developers probably want to fix the bug, and they would rather work with people who seem motivated and cooperative.  If you seem like a difficult person to work with, they won't want to, and you can't force or intimidate them into doing so.

You could try deleting or resetting the app and restoring it using the 12-word recovery phrase that you created when you first installed the wallet.  It should also be possible to use the recovery phrase to access your coins from different wallet software.

If you didn't save the recovery phrase, or you have lost it, then you may have just learned an expensive lesson about the importance of backups.  Software bugs are just one of the many things that can go wrong when using Bitcoin; you can also lose or break your device, get coins stolen by malware, etc, etc.  These are the risks you take, and backups are one of the prudent ways to reduce those risks.  (Actually setting a PIN is another.)

As to whether you can sue, you'd have to consult a lawyer who knows about consumer law in your jurisdiction.  Personally, I doubt that you would be successful.  It's likely that the app's terms of use were carefully written by Bitcoin.com's lawyers to shield them from legal liability in case of software bugs.  In general, when you use free software, you should assume that it's at your own risk, and that nobody will compensate you if things go wrong.


How accurate is 'estimatesmartfee' in bitcoin-core?

I have found this article https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0 which give you a pretty good summary of this bitcoin function.
Notice that estimatesmartfee return is based on the data of what happened in the past in the blockchain, it is not trying to predict what will happen in the future but what should happen based on what happened before, maybe you will find a better algorithm if you think that there will be something new that will disturb the market.
From the article:

A more sophisticated algorithm may attempt to be more forward-looking.
However, the more complex the algorithm, the more difficult it becomes
to describe its operation and results, and the more difficult it is to
argue that the algorithm is safe against manipulation.


How do I find out if an address belongs to me

An address cannot 'belong to someone', but you could be in possession of the private key which allows you to spend from it. So if you have the private key (ie, you have access to the wallet that created that address, or a backup of it), then you can claim any coins held at that address.


Blockchain.info's My Wallet stores your Bitcoin wallet in encrypted form. This means that anyone that knows your wallet identifier can retrieve the encrypted form of your wallet. One can of course only use/open the wallet with the encryption password.

This does however mean that anyone that retrieved your wallet identifier can try to guess your password as many times as they want. Once they got the encrypted version of your wallet, they can use smart brute force techniques to crack your password.

So, you could have been hacked if both

Someone got hands on your wallet identifier. Maybe you mailed it or mentioned it somewhere. Maybe you got malware or a spoofing browser extension.
You have a weak password so that regular password crackers were able to find your password fairly easily. Try to avoid passwords consisting of only existing words or only lower case characters f.e.


What does the term "Longest chain" mean?

Bitcoin's block chain system is really two quite separate systems, and they are easily confused. The first one is the block tree and the second is the active chain.

The block tree consists of all valid blocks whose entire ancestry is known, up to the genesis block. The rules for validness include no double spending, valid signatures, no introduction of more currency than allowed, ... These are the network rules, and every full Bitcoin node verifies them.

The active chain is one path from genesis block at the top to some leaf node at the bottom of the block tree. Every such path is a valid choice, but nodes are expected to pick the one with the most "work" in it they know about (where work is loosely defined as the sum of the difficulties). Relativity and technological constraints prevent us from doing instant communication across the globe, so two nodes can not be expected to pick the same chain as the active one. This is no problem: the mining mechanism makes sure that the chance two nodes disagree about blocks in the past decreases exponentially as they are older.

So no, there is not one "right chain", there are many. Nodes choose for themselves, but the system is designed to make sure consensus arises quickly.

The rules in practice are this: when a new block arrives, and it extends the previous active chain, we just append it to the active chain. If not, it depends on whether the branch it extends now has more work than the currently active branch. If not, we store the block and stop. If it does have more work, we do a so called "reorganisation": deactivating blocks from the old branch, and activating blocks from the new branch.


Running bitcoind on VPS, won't speak to my web server

It looks like you are using the wrong port. The RPC server listens on port 8332 by default, so try that. Port 8333 is for bitcoin node traffic.


How to broadcast a transaction anonymously

Here is the solution I found to broadcast transaction on the bitcoin network without revealing your IP: connect bitcoind over the Tor network. Here is my guide.

Edit your torrc file to add .onion bitcoin nodes:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Start Tor

Edit .bitcoin/bitcoin.conf to connect bitcoind over the Tor network. Add:

proxy=127.0.0.1:9050
connect=192.0.2.2
connect=192.0.2.3
connect=192.0.2.4

When Tor is started (green onion) you can launch bitcoind.

More infos
https://en.bitcoin.it/wiki/Fallback_Nodes
https://bitcointalk.org/index.php?topic=50547.0;all


How will internet "take-down" affect bitcoin value?

Of course, assuming you could actually pull it off (which is near impossible at this point, but assume you could) but also keep in mind that bitcoin doesn't actually need the internet to continue working.

In all honesty though, bitcoin's market price would be the least of our worries in the event of a total internet shut-down.


How to get my bitcoin payment confirmed?

Unfortunately there is not much you can do yourself, other than contacting the sending party or simply waiting a bit longer. It is, as you suspect, most likely due to low transaction fees.
For more information you can take a look at this similar question (which is from a senders perspective):
Why is my transaction not getting confirmed and what can I do about it?


This is implementation dependent, but in Bitcoin Core there is not just a single UTXO set:

The UTXO set on disk in the chainstate/ directory in a database. It corresponds to the state as of the last flushed block (and does not include the effects of any mempool transaction, or of any block since the last flush).
The in-memory coins cache is a cache on top of the UTXO set on disk (1), with spends/creations from recent unflushed blocks applied. It only physically stores the changed values; querying it for other UTXOs will cause a read from the disk database (1) instead.
The mempool implicitly defines yet another UTXO set on top of (2). This isn't materialized at all: when querying, we just check if either (2) or the mempool has the transaction output asked for AND whether there is no mempool transaction that spends it. The mempool is always kept consistent with the blockchain (e.g. if a transaction is confirmed that conflicts with a mempool transaction, that mempool transaction is deleted).
During processing of a block, a temporary cache of UTXO changes is maintained, as a patch on top of (2). This allows blocks to spend outputs created by themselves, while if a block is invalid for whatever reason, that temporary cache can just be thrown out without doing extra work. Only if the block is actually completely valid are the changes from this temporary cache merged into (2), and the mempool (3) updated to be consistent with the result.
Wallets conceptually also maintain their own set of UTXOs (that are watched and/or spendable by the owner), though they don't use the same interface in the codebase. This is necessary because a wallet may contain transactions that are unconfirmed and aren't in the mempool (e.g. because they were removed due to eviction, but we still want to retry inserting them).

Finally it's important to note that every node has its own UTXO set(s). Your own wallet/node won't be updating anything when a miner (which one?) starts including your transaction in their candidate blocks - you don't even have any way of knowing they're doing so.


Try

bitcoind -bind=127.0.0.1 -connect=127.0.0.1


What is a midstate? How does using a midstate speed up hashing?

People often talk about SHA256 like it's a single operation, but it isn't. Rather, the input is broken up into 64-byte chunks, and then each chunk is put into a compression function. The state of the hash partway through hashing something does not depend on future parts of the data. Since the nonce is found in the second chunk, changing the nonce doesn't change the the state of the hash function after hashing the first chunk.

This is useful in other applications. For example, if you're hashing a large file, it means that you can hash it without loading the entire file into memory at once or loading it from disk multiple times.

The practical consequence of this for Bitcoin miners is that 99.99999998% of the time, you only need 2 iterations of the SHA256 compression function to check a possible block solution, instead of 3. In other words, you can mine 50% faster. Of course, since everyone else does this, that just means that the difficulty is higher for everyone.

midstate is literally the state midway through hashing.

See also: Did Satoshi intend to allow midstate computation to speed up hashing?


The choice between the UTXO model and the balance model is primarily one between privacy incentives and apparent intuitiveness.

If one follows the standard advice of not reusing addresses/outputs/scripts, as to not gratuitously reveal which coins belong to the sender and which belong to the receiver, the two models are actually equivalent. In this case balances would be single use anyway, and there would be as many balances as there would otherwise be UTXOs, removing both the apparent size advantage and convenience.

However, the balance model effectively incentivizes reuse. As the cost to the system (possibly in fees, but certainly in node operation costs) for a balance update is lower than the creation of a new balance, such a system inherently incentives revelation of transaction sources.

And even though balances are more intuitive, they do complicate reasoning about the security of the system. One issue is the problem of replay attacks. Assume X paid Y, and Y pays Z. Now W pays Y again. In a naive implementation, Z can rebroadcast his earlier transaction from Y, and could take the money from W's payment to Y. One solution is by putting sequence numbers on balances, and requiring transactions to list the sequence number of the transactions they take money of. Unfortunately, this requires maintaining the sequence number even for balances that went to zero, meaning that the balance database needs to maintain some data for every balance that was ever nonzero; a result that's far less scalable than the UTXO model was in the first place (which can forget outputs as soon as they're spent).

In short, my view is that the balance model reduces the fungibility of the currency as a whole for a short term gain that disappears.


what are the dangers of transfering bitcoins between addresses?

The dangers are minimal.

There is no restriction on which addresses can send to which other addresses.

Most common issues arise from wallets failing to support different address encodings (many wallets still do not support bech32), which results in them rejecting valid addresses.

Other, rarer, issues include mixing up address types - a few wallets in the past have interpreted p2sh addresses as p2pkh addresses and sent coins to the correct HASH160 value embedded in an incorrect locking script, effectively burning them.


Why miners need to broadcast blocks that contains full transactions in Bitcoin?

In current versions of Bitcoin Core, most transactions are only relayed once and all transaction are only validated once.

New blocks and transactions in Bitcoin are usually advertised to peers by use of inv (inventory) messages. Blocks are thereby identified with the hash of their header, while transactions are identified by a hash over the complete transaction (also called txid). The peer that receives the inv message will respond by requesting the block header, the full block, a compact block, a Merkle block, or the transaction data if they want it.

Transactions are only relayed twice on older implementations of Bitcoin Core that always request the full block when it is announced by a peer for the first time. Newer implementations use Compact Blocks which transfer only the block header, an encoding of the transactions and up to a handful of transactions that the sending node didn't have when it received the block itself. Nodes don't revalidate transactions that they already had in their mempool, as transactions get validated before a node adds them to their the mempool.

via Compact Blocks FAQ

The full list of transactions must be stored in the blockchain to allow new peers to independently validate the entire transaction history of Bitcoin.


In what year and in which Bitcoin improvement proposal Opcodes such as OP_MODE have been disabled?

It appears many unused opcodes were disabled in 2010 for security reasons (at least OP_CAT) or as a security precaution (many others).
Pseudonymous commented that the first BIPs didn't start until 2011 - a year later.


what does it mean to have >51% hashing power for mining a block?

What does it mean to have > 51% hashing power for mining a block?

Having more than 50% of the hashing power in the total network means that you are likely to produce more that 50% of the blocks at current difficultly. This alone is not bad at first.

  How does this link to the analogy between honest node and attacker ?

However with more than 50% of the blocks produced you could also start mining blocks on another private chain. While mining you could buy something from a merchant with bitcoin. On your private chain you don't include the transaction to the merchant.

Once the merchant has send you the bought goods you could broadcast the private chain. Since you have more blocks (with more hashing work put into) all honest nodes would accept your (previously private) chain as a valid chain. You'd have double spend the coins. The merchant wouldn't have received any coins for the send goods.

  Also can attacker start mining 2 blocks ahead? or 3 or 4 blocks ahead?

It only makes sense to mine a block on top of another valid block. You need block A to mine block B. However you don't have to broadcast A to mine B.


Where can I see the "official" texts of BIP 100 and 102?

BIP 102 was submitted as Pull Request, which you can see here: https://github.com/bitcoin/bitcoin/pull/6451

The latest draft of BIP 100 that I could find was here:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
but it might be out of date.


Transactions are verified by miners. What happens when the last BTC has been mined?

You can still incentivize mining new blocks with transaction fees. So the premise of the question is false.


I can answer some of your questions, I agree with @T9b you are out of luck with BTC and should try some Alt Coins that you can mine with a number of different Algorithms: Litecoin and Dogecoin (Scrypt), or Darkcoin (X11).

For optimal parameters to mine a Scrypt coin I suggest you try this comparison which is pretty detailed and has most of the GPUs out there:

https://litecoin.info/Mining_Hardware_Comparison

Temperatures looks more than fine at 68C, I had a few R9 280 and was struggling to keep them below 80C.

If factory overclocked there is not much else you need to do. I suggest you run the Asus Utilities that came with your card to monitor temps, fan speed, etc. Make sure there is enough air circulating within your PC case.

If you mine with your card 24/7 it will fail rest assured, predicting when it's a bit more difficult as it depends on the card components and build quality. Your card is factory overclocked so it will be even more prone to failure if constantly run for mining purposes. I would say a year max, but then some cards fail after 2 weeks or 3 months, etc...

Test it out and make your own judgement, I personally don't think your card will earn you much with mining. That doesn't mean you can't try it out and have some fun with it, you may learn a few things while doing that. ;)


Is there a way to determine the optimal size of a batched transaction to save on fees?

But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.

The addition of another input does not matter, as it would have to be included in the next transaction too anyway.
In any way, a second stage transaction will always be more costy than a single batching transaction as you would duplicate the (non-witness!) meta bytes (version, n° of input, n° of outputs, locktime, etc..).