text:
How to add handwritten key or code to a wallet
I am actually a newbie who bought twenty (2) bitcoins in 2010 and I have only just found where I copied down the code or key. How do I get this code or key onto a wallet or USB? Please advise.

Can you share the format of what you have written down? Keys can be backed in up several ways, although all the way back in 2010 it's likely a wif or regular hex key. Just describe the length and first character, do not share the actual key.

If you really purchased the Bitcoin in 2010 and wrote down a code you might have own written down an address (a string about 20-27 characters long beginning with a 1). I do not believe any of the above private key formats were available in 2010.
If you did only write down an address, what you'll want to find is a wallet.dat file.
It's also possible that you might have used a service called instawallet or mybitcoin. If so, your Bitcoins are long since gone.
If you did write down a private key, be careful to not give it to anyone else even if they offer to help. Sometimes people offer to help just to steal people's Bitcoins. Honest helpers will almost never ask for your private keys, since they don't want to be accused of stealing them if you somehow get them stolen.
You can safely describe the first digit or two, its length, and/or how many characters it has in it and that could help us determine if you'll be able to recover and what tools you'll need to use.

How do I get this code or key onto a wallet or USB?

Wallet
By USB I guess you mean a hardware-wallet like the Trezor etc.
Choosing a wallet is an important step, I assume you have looked into this and are aware of the dangers of using some types of wallets and are aware of the need to never give any helpers your private-key or the password to a wallet.
There are several ways of writing down a private-key and there are mnemonic-word based systems for saving private-keys (the private-key is derived from the phrase). You should find out which sort of private-key or seed-phrase you have and make sure your chosen wallet supports it.
The general process is to first install the wallet, some wallets are full-nodes and take several days to synchronise with the Bitcoin network.
Private key
Once you have a wallet installed and ready for use, you find the menu option for importing a private key. You can then type the key into the wallet. It should then show the amount of unspent bitcoin for addresses derived from your private key.
A private-key in Wallet Import Format (WIF) might look like 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
A private-key in Hexadecimal format might look like 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
Seed phrase
A seed phrase might look like witch collapse practice feed shame open despair creek road again ice least. They usually have 12, 18 or 24 words chosen from a list defined in BIP39. Not all wallets used BIP39 though.
Wallets such as Electrum support this seed-phrase system which can be used for "wallet recovery".

Useful links:

Wallet Import Format (WIF)
Seed phrase
Wallets
What type of Bitcoin wallet is more secure than others?
Types of Wallet
Why doc says importing private keys is so dangerous?


text:
Is a 51% attack on bitcoin likely?
Given that the majority of bitcoin processing is done in China (source: https://bitcoinmagazine.com/articles/report-links-74-bitcoin-mining-china-sees-threat-network/), is it possible for a single entity to accomplish double spending (or be forced into accomplishing it by the Chinese government) to make profit for themselves or for the country?
How likely is it for all the separate entities doing the mining in China to be forced into complying and compromising the network's validity and has there ever been credible reports of such a thing occurring on bitcoin's front specifically?

No.
Bitcoin is an economical system. To become a pool operator, you must have 1) large amount of bitcoin or 2) large amount of hardware. Both requires you to be an "investor". In contrast to Proof of Stake, it is not easy to sell everything and leave Bitcoin in short time, which means you're informally "contracted" to Bitcoin. To put it another way, the only proper way to profit is long term mining. That requires you to ensure that it won't decrease in value. (1% increase is actually a lot for them) As a consequence, you can't attack Bitcoin even if you have the power to do that, as it'll affect its value.
This was the reason Emin Gün Sirer's Majority is Not Enough: Bitcoin Mining is Vulnerable was controversial.

source: Stack Exchange

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

sort: votes


text:
How To get Address Public Key from Account XPUB?
I am little bit confused or not able to get the right Address Node Public key from Account XPUB.
What I have done :

Get the Account XPUB [78Bytes]

SHA-256

SHA-256 Again

Created Extended XPUB (XPUB + 4 Start Byte of Step 3)

Base 58 ENC

hdnode_deserialize()

Account Node  Change Node

Change Node  Address Node.

But am not able to get the right Public Address.
Please let me know if I have done something wrong.

What you want to achieve (derivation protocol) is precisely described and detailed in BIP32 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#public-parent-key--public-child-key ...

I just want to get the Address Node Public Address by Account XPUB ..

i am writing my own application and somehow not able to get the right result and seek someone help

To go from account xpub to address, you must first derive an xpub at the External index (0) or Internal index (1), then derive another xpub from the External/Internal xpub. Take the public key from the resulting xpub and this is the public key used for the address.
For a detailed explanation of extended public keys and how to derive child public keys, take a look at the BIP32 documentation. For a not-as-in-depth breakdown of deriving addresses from an extended public key (which is exactly what you're trying to do), I have written this writeup.

can you explain it further more, see what steps i have followed to derive Address Node Public Key.
is there anything wrong in my implementation or pseudo code ?

@AmishSharma Your implementation/pseudocode is very wrong and not even close to what actually happens. Please read my answer, specifically the second link.

Sorry, but i i have done some mistake due to which i was not able to derive right address ..
My Pseudocode is perfectly fine .. By mistake i called hdnode_private_ckd() instead of hdnode_public_ckd()..

Thanks for your time and feedback..  appreciate it

@AmishSharma Please be careful with whatever you are doing. Your pseudocode does not do what you are asking in your question.

then how i got the desired result..
can you just tell me the your PseudoCode for Get Address Node Public key from Account Node XPUB. that would be appreciated

@AmishSharma See answer please...

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


text:
Does a Bitcoin qr code become invalid after 1 Year?
I have been trying to figure out if there exist a software which preserves a BTC QR code for more than one year.

Note: bitcoin addresses (encoded into QR code or not) may not expire, but if you are sending BTC to someone, you should still ask for a new address each time.

Does a Bitcoin qr code become invalid after 1 Year?

Generally no. A Bitcoin QR code encodes a Bitcoin address. These addresses are valid forever - in the sense that valid Bitcoin transactions can be created which pay to those addresses. So long as someone still knows the original private key (or master private key) for the address, any money sent using that QR code in 5 10 or 100 years time, can still be used.


text:
How do I set up IRC bouncer to receive messages and follow the discussion while I am offline?
I am now set up on IRC and I can attend the Bitcoin Core PR review club sessions. But when I am offline I can't receive messages and I can't follow the discussion which has happened during the time I was offline. How do I set up a IRC bouncer to address these problems?

On some IRC channels such as #bitcoin-core-dev there are third party managed conversation logs so you can follow the conversation from when you were offline without setting up a bouncer. However, I don't think (at the time of writing, September 2020) that there are conversation logs for the #bitcoin-core-pr-reviews channel except for the weekly meeting which is logged on the Bitcoin Core PR review club site. You definitely can't receive messages whilst you are offline.
For more background information on setting up a IRC bouncer see here.
For more information on migrating to libera.chat see here and here.
There are various options to set up a bouncer but in the interests of simplicity I will just outline one assuming you followed the instructions here to install Textual on MacOS.
You will need a virtual private server (VPS) to be running 24/7 to log the discussion and receive messages on your behalf and then you can connect to that server whenever you come back online. This will require a monthly subscription.
So your first step is to choose a VPS provider. One easy to use option is Digital Ocean but there are others that perform the same function and are equivalently priced. (We generally avoid product recommendations on this site so please excuse this counterexample.) You can connect directly to your VPS/Digital Ocean Droplet with SSH using the instructions here. There is a tutorial for setting up SSH keys here.
Once you have set up your VPS you will need to install ZNC on that server. Instructions for doing that are here (deprecated but easier to follow and should still work) or here. The latest ZNC release is available here. You can ssh into your VPS using:
ssh -i /path/to/private/key root@IP_address_of_VPS

Instructions for connecting your Textual client to the ZNC bouncer are here.
The Server Address is the IP address of your VPS.
For the Username make sure you follow the below instructions.

In the field labeled Username is where you will enter your username.
The format of this value is very specific: <username>/<network> — The
first half of the value is your ZNC username. The second half, which
is prefixed with a forward slash, is the Network Name

In this case the Network Name is libera so this should be <username>/libera.
Once you have set up your ZNC server and your ZNC configuration file you can edit znc.conf by following these instructions:

In most cases you should NOT edit znc.conf directly. Use webadmin
instead.
If you really need to edit znc.conf by hand, do the following:
pkill -SIGUSR1 znc to save current runtime configuration to znc.conf
pkill znc to shutdown running ZNC instance Edit znc.conf
znc to start it again with new configuration

To set up SASL on the ZNC server follow these instructions.
For troubleshooting ZNC see this FAQ and help for ZNC commands is here.


text:
I'm digging further into the open Taproot PR. Can you explain the BIP340 test vectors?
I'm digging further into the open Taproot PR. I found these BIP340 test vectors.
They have secret keys, public keys, aux_rand (auxiliary randomness), message, signature and whether the signature verifies or not. Can you explain why the signatures that fail are failing?

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.

"Negating" means taking the complement with the group order n, because "-v = n-v mod n". There are no actual "negative" numbers in the ring of integers mod n.

For index=7 it says "negated message". Why does one of the test cases have the complement of the message? Just to show that the signature won't be correct if the complement of the message is used rather than the actual message?

Indeed. It's just trying to predict things an implementation may do accidentally wrong.


text:
How does nix-bitcoin provide greater security for installing Bitcoin nodes?
nix-bitcoin claims on its GitHub repo to facilitate the installing of Bitcoin nodes and higher layer protocols (e.g. Lightning) with increased security? How does it do this?
[edit: as RedGrittyBrick points out below this project is a work in progress as of time of writing (August 2020)]

As of 2020-08-10 the GitHub page for this project includes the warning "This is a work in progress - don't expect it to be bug-free, secure or stable."

nixbitcoindev explains here that the additional security provided by nix-bitcoin is due to minimalism, code reproducibility, compartmentalization and defense in depth.
nix-bitcoin uses NixOS which is a purely functional operating system which means that it builds the entire operating system from the source code of every application of the Linux kernel resulting in the same system every single time it is deployed.
With a general Linux distribution it is not possible to de-install all the packages you don't need as it would eventually result in a broken system. NixOS has a kind of formula where it goes through and calculates what you need and only builds that. This minimalism significantly reduces the attack surface.
Everything is reproducible with NixOS, not only Bitcoin related software such as Bitcoin Core, c-lightning, lnd etc but the entire stack including the Linux kernel. As a result you know you have exactly the same system that everybody else has. That’s a really strong defense against  the developers inserting malicious code or code upstream getting compromised. Once the developers have verified the software, within the hash it’s going to be the same software that everybody is using.
Every service runs in its own little box under its own user. It can only see its own directory and with network namespaces it can't even scope out your entire network. It can only scope out its own network and its Linux namespace and the ones it is allowed to see. Outside processes outside of that network namespace also can't look inside. That offers a great deal of security because now programs like Spark wallet that connect to your c-lightning, they’ll never see JoinMarket, they’ll never see Electrum, they’ll never see bitcoind. They are maximally compartmentalized.
Defense in depth means putting up multiple walls or multiple lines of defense. nix-bitcoin isolates by users and isolates on the network level with systemd.


text:
Use Stolen Private Key?
If only my private key were stolen, could it be used?
Without knowledge of the corresponding public key or address, can one spend BTC with only the private key?
I know you can derive the public key from a private key, but if an address has never been spent from  and change is never returned to the same public key, the public key will remain unknown, thus how could one exploit knowledge of a private key alone?
EDIT:  yes, i now realize this is a pretty bad question.  i now know that with just a private key, an attacker can calculate the public key and Bitcoin address and thus spend any stored coins.

Welcome to Bitcoin.SE!  To get the right eyes on what you're asking, please phrase the title as a question.

I'm unsure how to improve the title of this question, since it is so much confused. I was able to give an answer, though.

Yes.

The private key is used to send from an address.
The public key is used to send to an address.
The public key is generated from the private key.

So if you have the private key you have full control over an address.

You would also need to know the transaction hash + index of the funding transaction (used as an INPUT in the payment transaction) but technically I don't need to know the Bitcoin address to do that.)

@StephenGornick:  what is an "index"?

@joe: To form a Bitcoin transaction (other than the coinbase tranasction to claim the mining reward) you need to know not just which transaction's output your trying to claim but also which output it is, since a transaction can have more than one output. Each output of a transaction has an index that must match in any transaction that tries to use that output as its input (or one of its inputs). (This is all public information though.)

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


text:
How to get hex string from transaction in bitcoinj
I want to use this tool: http://blockchain.info/pushtx to push transaction. I don't understand the input data. It says it is hex string representation. I've read information about that in the raw transaction of the RPC API, but I am working with bitcoinj, it there a way to get this hex string ?
Thank you
EDIT: I want to do that to compose and broadcast a transaction
For now I did this:
final StringBuilder sb = new StringBuilder();
Formatter formatter = new Formatter(sb);
try {
    ByteArrayOutputStream os = new ByteArrayOutputStream();
    transaction.bitcoinSerialize(os);
    byte[] bytes = os.toByteArray();
    for (byte b : bytes) {
        formatter.format("%02x", b);
    }

    return sb.toString();
}catch (IOException e) {
    return "Couldn't serialize to hex string.";
} finally {
    formatter.close();
}

To compose and broadcast a transaction, or to re-broadcast a transaction that the network has already seen?

To compose and broadcast a transaction.

I am using your code and it works very well, thanks

A shorter version could be:
String hex = DatatypeConverter.printHexBinary(tx.unsafeBitcoinSerialize());

Where the hex converter used is standard at least since Java 7:
http://docs.oracle.com/javase/7/docs/api/javax/xml/bind/DatatypeConverter.html

If you use unsafeBitcoinSerialize, make a note of the warnings in the API.

As for the example, the result is only temporary used to convert it to hex and the discarded, so it's safe to be used this way.
Problems arise only if you decide to modify the returned buffer.

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


text:
What is the Default Rounding for 8 digits in Binance,tradingview,etc
I have a problem. I am struggling to calculate programmatically the number of cryptocurrencies because I sometimes have inaccuracies in the last digit. Does anybody know what the problem is? (Of course, I have calculated the appropriate fees that need). For example, Binance uses accuracy for 8 Digits. What is the Rounding that they used? I would appreciate an answer if someone have the appropriate knowledge on this matter
RoundingMode.CEILING
RoundingMode.DOWN
RoundingMode.FLOOR
RoundingMode.HALF_DOWN
RoundingMode.HALF_EVEN
RoundingMode.HALF_UP
RoundingMode.UNNECESSARY
RoundingMode.UP

I am currently debugging exactly the same behaviour  as you describe in this issue. My balance for ETH does not add up if compared to my own calculations. At the moment, I assume that Binance does not credit the full amount of the deposit (e.g. 14 decimal places) to the account balance, but strips it to the precision they internally use (e.g. 8 decimal places). If I thereby apply RoundingMode.DOWN  as rounding mode, my results become valid.
I am still looking to get any confirmation on that though.

There should not be any rounding because all operations are integer operations. The 8 digits is because they calculate using the base unit of Bitcoin, the satoshi, which is 0.00000001 Bitcoin (8 digits). It is calculated as an integer (i.e. calculation uses satoshis, not Bitcoin) multiplied by an integer for the number of bytes, thus the result will also be an integer. The decimal then comes back as they shift the decimal point to represent the value in Bitcoin. There is no rounding involved, if there is, you are doing something wrong.

Are you totally sure that  Markets like Binance or Gdax.etc do the same calculation like this?

There is no reason not to do the calculation like this. If they do not do integer operations, then they introduce the possibility for floating point precision errors which can cause them to lost money for their customers.

Exchanges do have rounding errors.


text:
I have watched addresses in my wallet..how do i use them?
How do I use the watch only addresses that are in my wallet? I can't find the private keys. Is their any way to use them or should I just delete the wallet with the watch addresses in them?

If you do not have the private keys for those addresses, then they are not yours and you cannot do anything with them. Those addresses and their associated Bitcoin do not belong to you, so you cannot use them.
You can delete the watch only addresses if possible; you will not lose any money if you delete just those addresses because there is no money that belongs to you in the first place with those addresses. However be careful of deleting the wallet entirely, it could have addresses and private keys which do belong to you and those you do not want to delete.


text:
Failed to Build Bitcoin-Qt
The error relate to UPnP as show below.
Please kindly help solve the issue.
Thank you!
C:\Coin>mingw32-make -f Makefile.Release c:\Qt\4.8.6\bin\rcc.exe -name bitcoin src\qt\bitcoin.qrc -o release\qrc_bitcoin.cpp g++ -c -pipe -fno-keep-inline-dllexport -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -O2 -frtti -fexceptions -mthreads -fdiagnostics-show-option -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wstack-protector -DUNICODE -DQT_GUI -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_QRCODE -DUSE_UPNP=1 -DSTATICLIB -DUSE_IPV6=1 -DWIN32 -D_MT -DQT_THREAD_SUPPORT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I"..\Qt\4.8.6\include\QtCore" -I"..\Qt\4.8.6\include\QtNetwork" -I"..\Qt\4.8.6\include\QtGui" -I"..\Qt\4.8.6\include" -I"src" -I"src\json" -I"src\qt" -I"..\deps" -I"src\leveldb\include" -I"src\leveldb\helpers" -I"..\deps\boost_1_55_0" -I"..\deps\db-4.8.30.NC\build_unix" -I"..\deps\openssl-1.0.1j\include" -I"..\deps\qrencode-3.4.4" -I"..\Qt\4.8.6\include\ActiveQt" -I"build" -I"build" -I"..\Qt\4.8.6\mkspecs\default" -o build\qrc_bitcoin.o release\qrc_bitcoin.cpp g++ -Wl,--dynamicbase -Wl,--nxcompat -Wl,--large-address-aware -static -static-libgcc -static-libstdc++ -Wl,-s -mthreads -Wl,-subsystem,windows -o release\coin-qt.exe object_script.coin-qt.Release -L"c:\Qt\4.8.6\lib" -lmingwthrd -lmingw32 -lqtmain build\bitcoin-qt_res.o -lqrencode -LC:/deps/miniupnpc -lminiupnpc -liphlpapi C:/coin/src/leveldb/libleveldb.a C:/coin/src/leveldb/libmemenv.a -lshlwapi -LC:/deps/boost_1_55_0/stage/lib -LC:/deps/db-4.8.30.NC/build_unix -LC:/deps/openssl-1.0.1j -LC:/deps/qrencode-3.4.4/.libs -lssl -lcrypto -ldb_cxx -lshlwapi -lmswsock -lboost_system-mgw49-mt-s-1_55 -lboost_filesystem-mgw49-mt-s-1_55 -lboost_program_options-mgw49-mt-s-1_55 -lboost_thread-mgw49-mt-s-1_55 -lboost_chrono-mgw49-mt-s-1_55 -lQtGui -lQtNetwork -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -lmsimg32 -lQtCore -lole32 -luuid -lws2_32 -ladvapi32 -lshell32 -luser32 -lkernel32 ./build\net.o:net.cpp:(.text+0x88f3): undefined reference to_imp__upnpDiscover'
./build\net.o:net.cpp:(.text+0x892a): undefined reference to _imp__UPNP_GetValidIGD' ./build\net.o:net.cpp:(.text+0x896b): undefined reference to_imp__UPNP_GetExternalIPAddress'
./build\net.o:net.cpp:(.text+0x89e7): undefined reference to _imp__freeUPNPDevlist' ./build\net.o:net.cpp:(.text+0x89fa): undefined reference to_imp__FreeUPNPUrls'
./build\net.o:net.cpp:(.text+0x8ae7): undefined reference to _imp__strupnperror' ./build\net.o:net.cpp:(.text+0x8b73): undefined reference to_imp__UPNP_AddPortMapping'
./build\net.o:net.cpp:(.text+0x8bfb): undefined reference to _imp__UPNP_DeletePortMapping' ./build\net.o:net.cpp:(.text+0x8c1a): undefined reference to_imp__freeUPNPDevlist'
./build\net.o:net.cpp:(.text+0x8c29): undefined reference to _imp__FreeUPNPUrls' C:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/bin/ld.exe: ./build\net.o: bad reloc address 0x960 in section.data'
C:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
Makefile.Release:291: recipe for target 'release\coin-qt.exe' failed
mingw32-make: *** [release\coin-qt.exe] Error 1`

Is miniupnp installed in your environment? The linker cannot find the miniupnp library.


text:
How do I restore a Lightning Node with active channels that has crashed causing data loss? Is it similar to restoring a Bitcoin wallet?
If my lightning node crashes after receiving payments (but before I have closed the channel) can I recover my funds? What happens if I do not have backups of all the channel updates?
Is the restoration process fundamentally different from dealing with on-chain Bitcoin?

Unlike bitcoin stored in an on-chain wallet, funds in the lightning network are stateful. Some channel data cannot be deterministically reconstructed like keys derived from a BIP32 seed. If you do not have backups and your channel counterparty is non-responsive, you will likely experience permanent loss of funds. Make sure to have backups of your channel data made with each additional transaction you send/receive/route to other nodes in the network.
If a node falls down and loses critical state data it is important not to broadcast commitment transactions from old backups. If these commitment transactions have been revoked, the channel counterparty will submit a justice transaction to the network and claim all of the funds in the channel.
This failure scenario can be partially mitigated by nodes that use option_data_loss_protect as specified in BOLT 2. This allows a node to detect that it has fallen behind when reestablishing its connection. This only works when both nodes support this feature and the node that has not fallen behind is honest. If the honest node detects its counterparty has fallen out of sync, it should unilaterally close the channel and the fallen-behind node can then reclaim its funds with data it received on connection reestablishment (my_current_commitment_point).
In the future, state backups can be outsourced to 3rd parties on-the-fly, such that if a node falls down it can call on these 3rd parties to provide the necessary data for channel reconstruction. It has been proposed that Watchtowers - nodes that can be compensated to monitor channels for bad behavior - could also be tasked with storing encrypted state backups.
If you do have a backup you can restore it and reestablish connections with your peers and get back to business!

I believe Selfishminer is referring to Bolt 2, not Bolt 12. Bolt 12 doesn't exist (11 is the last BOLT).

@paulrozehnal: You can suggest an edit!


text:
Why was an insecure merkle tree implementation chosen?
At risk of creating a "lets discuss politics" question, let me clarify that what I want to know is whether there is a known benefit to Satoshi's "duplicate the last hash" merkle tree implementation over the seemingly obvious "append zeros".
For those who don't know, the bitcoin merkle tree algorithm allows blocks to be mutated if a transaction can be duplicated which lead to CSV-2012-2459.

As with many things in Bitcoin, it is likely simply because it worked well enough, and such an attack was not immediately obvious.
Several of the choices made in the early days of Bitcoin don't have a full justification behind them, and were simply made because it worked at the time without any major, obvious shortcomings. This is one such scenario, as far as I'm aware.


text:
Is bitcoin deflation a bad thing?
I have read that bitcoins are relatively immune to inflation and will actually deflate in value:

Once 21 million coins exist, they become deflationary since no new coins are issued and, as naturally occurs, money falls out of circulation as wallets are lost.

Deflationary currency sounds terrible as this would encourage people NOT to spend the bitcoins they have. Which is the opposite of what you want in a capitalist society dependent on transactions. Inflation exist for a reason, it encourages people to spend the money they have because holding on to it would mean losing value in the long run.

Correct. Didn't find that question before. Deleting. Wait..., can't delete because it has an answer, dang it.

Don't worry, I think people will vote to close it as a duplicate timely.

I would suspect that most Bitcoin advocates would disagree with you. The simplest counter-argument is this -- wouldn't that mean inflation discourages people from selling things? And you can't spend if nobody wants to sell to you, can you?
Another way to make the same counter-argument is this: Actually, no, deflation encourages people to spend the bitcoins they have. A deflationary currency should be very desirable to hold. So, if I have a deflationary currency, sellers should go out of the way to encourage me to give that currency to them (with low prices, easy transaction, stronger guarantees, whatever it takes). That will make me more likely to buy things.
Of course, all of these arguments are nonsense. The characteristics of the money affect the buyer and seller equally. So while they may change the price, they won't change the likelihood the transaction will occur.
But it won't even matter. Long-term predictable monetary deflation is impossible (for a low friction, demurrage-free currency) because it entails a direct contraction. If you assume long-term, predictable monetary deflation, you get the following paradox:

One unit of currency today must be worth less than one unit of currency tomorrow. Otherwise, you don't have long-term, predictable deflation.
One unit of currency today must be worth more than one unit of currency tomorrow. This is because one of the things you can do with a unit of currency today is hold it until tomorrow. But you can also spend it today if you want. So it has to be worth at least as much.

These two arguments directly contradict each other.
Yes, you have been lied to by economists who want to convince you that the economy will explode if the government doesn't enrich itself and favored bankers at the expense of everyone else. That's not to say deflation can't cause real problems, just not this kind of deflation and these kinds of problems.

I disagree with point number 2. Just because you hold onto the money doesn't mean it is worth more today. The whole point of holding onto the money is to spend less of it the next day, this supports point number 1, not number 2.

This also seems to fly in the face of economics, as deflation was present during most economic depressions in US history. Historically, deflationary currency equates to massive poverty.

"The simplest counter-argument is this -- wouldn't that mean inflation discourages people from selling things?" - No, people take this money and invest it in real world assets which have a higher rate of return than inflation.

@AaronKlap: I can't follow your first comment. As to your second, I agree that deflation is associated with poverty, but we're talking about monetary deflation specifically. That's why I said "just not this kind of deflation". You can burn all the dollar bills you want and nobody will get any poorer.

As to your third, that affects buyers and sellers equally -- both want to invest to get a higher return than inflation -- so it cancels out. Say you want to sell me a car. That car must be worth more to me than you or we won't trade regardless of currency. All we have to do is agree on an amount of currency that is worth more than the car is worth to you but less than the car is worth to me. Since we both agree on the value of the currency, there should be no problem. (This is not a good place for debate though. Maybe the Bitcoin forums? Or chat?)

@Gracchus I agree. Trust no one. Keep your laser handy.

@AaronKlap Would you rather have me pay you a Bitcoin today or me pay you a Bitcoin tomorrow? Which would you pay more for? Clearly the first, because if you want, you can just hold that Bitcoin until tomorrow. But you can also spend it today if you want. So a Bitcoin today must be worth at least as much as a Bitcoin tomorrow, because a Bitcoin today includes the ability to have a Bitcoin tomorrow if that's what you want most. But predictable deflation would mean that rational actors would, today, consider a Bitcoin tomorrow worth more than Bitcoin today, which makes no sense.

authors: Вячеслав Николаев


text:
obtaining currency exchange rate values for different coins via apis
ive been trying to work out what the best way of obtaining the exchange rate of a bitcoin or any other digital currency is via online resources for a website I want to build.
I've seen this question/answer here; Displaying price in BTC based on USD exchange rate
So sure thats easy but what about other coins against the dollar or against bitcoins.  Am I going to have to obtain all this info from different sources?

If you are not actually trading, you can pull the price from multiple exchanges and show an average, since there is no such thing as fixed price for the exchange, preev.com is a nice converter that shows average of 4 sources which you can modify from the settings menu, it should give you an idea.


text:
Can you mine bitcoins with an intermittent Internet connection?
I've got a very precise question and this is not a dupe of:
Does Bitcoin rely on the internet?
My question boils down to: when you mine bitcoins, how "often" does the computer/hardware doing the mining need to connect to the Internet?
However to better explain what I mean by that question, here are a few sub-questions.
When a computer is mining, when is the result of the mining accepted/confirmed?
For example, after the computer received sufficient information to start mining, when will that information not be sufficient anymore to continue mining?  In other words: when will the computer need to have Internet access so that it can continue mining? 1 picosecond? 1 nanosecond? 1 ms? 1 second? 1 minute? 1 hour? 1 day?
What happens if some computation is done on my mining computer, but then Internet connection is off? Is the result "lost" and if that result is lost, after how much time is it lost? 1 picosecond? 1 nanosecond? 1 ms? 1 minute? 1 hour? 1 day?
It may look like a "stupid" question but it would really help me better understand how BitCoin works...
(as I'm new here [but certainly not new on the SE network] I don't know which tag to use: thanks for retagging accordingly if needed)

Assuming you are mining on a pool, your miner needs to receive and send work (shares) every few seconds, with the exact frequency depending on your hashing speed and the difficulty of the shares.
For example, my ASIC sends and receives shares at least once every 20 seconds or so.
So you need a reliable network connection if you don't want your miner to sit idle. This is the same reason why you normally configure the miner to have fall-back pool servers in case the main pool server goes down.

thanks a lot... Is the network "slowing" your miner? I mean: an ASIC is dedicated hardware and is blazingly fast while the network is very, very slow compared to dedicated hardware. Are there drops in the "CPU" / power usage of your ASIC everytime there's a network connection or is all that queue'd / concurrently happening?  (more questions to try to understand how it works)  : )

Yes, network latency can sometimes slow down the mining process. This is why ideally the pool can adapt the difficulty of the shares to suit your hashing power, so that your miner spends more time hashing away and less waiting due to network overhead.

I see... Thanks a lot. That is very, very interesting!

ktorn has a good answer for all practical purposes, especially at this point where solo-mining is a laughable proposition, but here is a more theoretical answer, which could be practical for alt-coins where there is weak network hashing power and/or the difficulty is not very high (because blocks are targeted to be generated every 30 seconds or so).
All you need to mine a block is the hash of the block before it, and any transactions you want transaction fees from. You could then hash offline.
This would need to be done without a pool: your object is to find a block, not just shares that you must submit often. You'd only have to broadcast a block when you found one, and even then you would have a little time on average to connect to the internet to broadcast your block*
You could connect whenever you wanted to pick up more transaction fees or check if the next block had been discovered yet.
What is important to understand is that work is not accomplished "toward" discovering a block, you are just playing an extremely-low-probability lottery billions of times per second.
Any work you are doing off of a block that is not the most recently discovered block is a complete waste, however, so you would have to connect fairly often just to avoid wasting a lot of hashing.
The expected value of your discovered block is reduced to {block reward} * p(network finds a block in {average time you take to broadcast}), and your hashing itself has an expectation of {your hash rate * p(the network has discovered a block since you last connected)}/{network hash rate}
and p(the network has discovered a block since you last connected) is approximately {time since last connection}/{10 minutes}
...it's actually a Poisson process but we won't get into that...
The bottom line is that
Every moment you are disconnected you are lowering the expected value of your next hash, because there is a chance that someone discovered a block and broadcasted it since you were last connected.


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

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

You should be using something like so to run bitcoind as a daemon
bitcoind -daemon

And then, you can check on it like so:
bitcoind getinfo

All I get is "error: couldn't connect to server"

Scratch that, it is magically working now. I guess it needed time...

@puk yea, I forgot about that. Sometimes it can take a minute or two to warm up

Newer builds use bitcoin-cli to connect to the daemon rather than commands with bitcoind. You can pass -rpcwait to this to stop calls failing when the daemon is still checking it's files and starting up.


text:
Lost Bitcoin from Bitcoin-core after resetting PC
The other day I reset my PC and I have lost all my BTC. Is there any way I can get it back? (using Bitcoin core)

Could you be more specific what you did when you "reset" the computer?

about a week ago

What exactly do you mean by "reset"?

I messed up my gpu overclock which put me on bluescreen upon start-up so I did a windows reset but kept files and when it reloaded I had to re-sync  bitcoin core and the wallet was no longer there

If you lost your wallet.dat file, and have no backup, your coins are gone.

It is extremely simple to get your BTC back. Simply fetch one of your backup disks/USB sticks which you have hidden around your home, containing redundant copies of any important data.


text:
I collected 5 bitcoins. I have the coins Ross Approved MJS 2013-2018. I do not know if I ever registered a Bitcoin account. How can know?
How can I sell my Bitcoin collection? I do not know if the coins have been registered.

Does this answer your question? What physical coins of bitcoin exists? many of these collectibles have no  Bitcoin value associated with them. A few types had Bitcoin value.

Hello, welcome to bitcoin.stackexchange! Your question doesn't really make much sense to me, what is 'Ross Approved MJS 2013-2018'? Are you talking about some physical coins? Maybe https://bitcoin.stackexchange.com/questions/22796/i-am-new-to-bitcoin-how-can-i-get-started can be of help to you?


text:
Why does Bisq not upgrade Tor addresses silently
I started up Bisq today. It had a pop-up  with elaborate instructions on how to "upgrade Tor v2 addresses to v3". This involved shutting down Bisq, deleting a dir and then starting it back up again.
Why not simply do it automatically in Bisq, without the user ever having to know about it?

If you have UX feedback for Bisq I'd open an issue on the Bisq repo or discuss it with the GUI developers on Bisq. Asking whether "Bitcoiners" want Bitcoin to stay obscure is like asking whether Americans want to stay Democratic or Republican. I'm sure there are some people who want Bitcoin to stay obscure but I'm pretty sure Bisq wants to onboard as many users as possible and continuously improve the UX as long as it doesn't negatively impact security, privacy.

I will say that I have been working on making my own seqwit wallet. And there is no official documentation. Ultimately I had to examine the source code and ask questions here. If you contrast that to other crypto's like etherium, then yes it feels like the community wants to stay obscure.

@noone392: We're a bit off-topic here, and it might be better to create another topic for that, but I assume you have seen the corresponding BIPs?

Regarding Bisq the simple answer is developer shortage. No, there is no hidden motive. You are very welcome to help with development and get compensated for it by the Bisq DAO.


text:
Btc bitcin juicy vegas
I won some money on juicy vegas and they told me to create a bitcoin account and send money via bit coin to release the funds, so I did but now they are saying that they didn't receive the funds and I'm out of £56

I am sorry to tell you, but you have almost certainly been scammed. Asking money to release money is a very common scamming technique.

I thought as much when they said that they had not received the funds and that iq barcode had timed out. I had reviewed the website before hand of the transaction and it seemed genuine but I'm guessing not. Any idea on how to claim it back?

If you have sent somebody untrustworthy money using Bitcoin, you don’t have recourse to claw it back unfortunately.


text:
HD wallet parameters clarification
I'm using HD Address Generator to create an HD wallet:
let mnemonic = "voyage blind unit shoulder yellow attitude mule all hire above obvious swap"
let bip84 = HdAddGen.withMnemonic(mnemonic, false, "BTC", true, 84)

The object that I'm getting back contains the fields:

bip32Seed
bip32RootKey
accountXprivKey
accountXpubKey
bip32XprivKey
bip32XpubKey

I went over HD Wallets and Extended Keys, as I understand:

bip32XprivKey is the extended private key
bip32XpubKey is the extended public key
bip32Seed is the seed that is derived from the mnemonic

Does it make sense?
Also, what are bip32RootKey, accountXprivKey and accountXpubKey?

Assuming the 84 parameter means that you want BIP84 addresses then:
bip32RootKey: this would be the root EC private key
accountXprivKey: this would be the extended private key at derivation path m/84’/0’/0’
accountXpubKey: this would be the extended public key at derivation path m/84’/0’/0’


text:
51% attack on a small network of nodes?
Not all the nodes in the bitcoin network are connected. So that means the computational power required to attack a smaller network would be comparatively easier.
So, say we start a 51% attack on a large number of such networks. Then, in theory a single group of attackers would only need to influence networks comprising of 51% of the hashing power.
Due to cascading effect of the networks the group of attackers can take over the blockchain with considerably less computing power.
I know I am missing something....?

Why would not all blocks be connected? What smaller network are you talking about? Are you talking about a network partition attack (where an attacker attempts to isolate some portion of the network)?

When you see this, please edit your question to clarify what you're asking. As you can see, it's causing some confusion among potential answerers.

sorry for all the confusion I meant the nodes.

For practical purposes, all the mining nodes should be connected. Anyone who is running a mining node has an interest in staying connected: Otherwise they don't have access to the most recent chain and are wasting cycles on a chain that will be ignored.

I think your confusion stems from misunderstand of Proof-of-Work and 51% attacks. Bitcoin's Proof-of-Work mechanism dictates that the chain with the most "work" is the valid chain. For practical purposes, this means the chain with the most blocks (the longest) is the most valid.
When a node receives a new block from a peer, it can independently determine whether this block is a valid block to attach to the tip of the chain. If one honest node serves valid blocks to a node, no number of other nodes can convince that node that the valid block is invalid. If a node has 7 malicious peers and 1 good peer, the 7 malicious peers cannot disguise the fact that the block served by the good peer is part of a longer chain than the "fake" blocks served by the malicious peers.
This is because a 51% attack involves controlling 51% of the hash rate, not 51% of nodes connected to a specific node, or even 51% of all nodes on the network. As long as 51% of hash rate (mining compute power), is honest, it will continuously produce a longer chain of blocks than any malicious actors, allowing good nodes to serve honest blocks to one another, which they can independently verify are part of the longest chain.
Eclipse Attacks
If a node is completely surrounded by malicious nodes (100% of its peers are malicious), they can perform a DoS attack on a node by refusing to send new blocks to the victim node. In this case, the victim will never see new blocks, and malicious nodes can serve invalid blocks which are not part of the longest chain, because the victim cannot compare all chains to determine which is the longest.

Thanks.I got it now. No nu,ber of bad peers can alter the network of nodes, as each node by itself can understand wheather if thet node is valid or not...


text:
Why my manually generated mnemonic seed phrase is not recognised by metamask or trust wallet
I created a random entropy using this code
func randomNumGenerator() []byte {

    n := 16
    randomByte := make([]byte, n)
    _, err := rand.Read(randomByte)
    if err != nil {
        panic(err)
    }

    return randomByte
}

And created a checksum
func checkSum(entropy *string) {

    data := *entropy
    checkSumLength := len(*entropy) / 32

    //Sha256 of entropy
    hash := sha256.Sum256([]byte(data))
    // hexFormat := hex.EncodeToString(hash[:])

    bitHash := byteToBit(hash[:])
    *entropy = *entropy + bitHash[0:checkSumLength]

}

And added that to the end of the entropy and divided that entropy into 11 bits equal parts
and matched it with the 2048 word list and I got words
"sustain resemble shift future stone merge antique denial devote century clay chalk"
But when I use this words in trust wallet it's showing invalid seed phrase
Can anyone explain me why? I followed all BIP39 procedures correctly in my code

Perhaps it's an issue with the wallet software you are using, check with them. The words you provided "work" fine and I get the HD Seed: 495fbf2c715222b46553fb8c466c33c59a8775541c1fedfe76ae71013f6431c54e8c8465de2f392b2d449f56efb3784a8195335bdd1017621d84e84c6eb0fa61

I can refer you to this implementation, method mnemonic_from_data() (from wallet-core/trezor):
https://github.com/trustwallet/wallet-core/blob/master/trezor-crypto/crypto/bip39.c#L70
I haven't fully analyzed your code snippet, but most likely the checksum byte is incorrect. It is the first byte of the Sha256 hash, appended to the end.
Note that depending on the mnemonic length, some bits at the end of the mnemonic are unused, as follows:
12-words: 12*11=132 bits used, 17*8=136 bits stored, last 4 bits unused
15-words: 15*11=165     /      21*8=168,                  3 unused
18-words: 18*11=198     /      25*8=200,                  2 unused
21-words: 21*11=231     /      29*8=232,                  1 usused
24-words: 24*11=264     /      33*8=264,                  all used

Since the unused bits don't matter, simplest is to just copy the first byte of the hash, without zeroing the unused bits (note that at checking one has to mask the bits).
The correct checksum for the example you provided is:
'sustain resemble shift future stone merge antique denial devote century clay celery'
entropy: 'daf6eb172f4d6516c279d33cc4aca89280'

original (invalid):
'sustain resemble shift future stone merge antique denial devote century clay chalk'
entropy: 'daf6eb172f4d6516c279d33cc4aca892f0'

(Note: SHA256(daf6eb172f4d6516c279d33cc4aca892) = 8e51c3...71, its first byte is '8e', but only the 4 first (high) bits are needed, hence the '80' in the last byte. '8e' would work as well.)


text:
Why grow the Bitcoin miner network?
Complete Bitcoin noob here. What are the advantages of having a large network of miners on the Bitcoin network? Why not have a limited number of super-peers that comprise the network? Isn't that the direction that things are heading anyway, given that only a select few will have access to the dedicated hardware?
Edit: Edited my question to indicate I'm referring specifically to the number of miners on the network.

If there were fewer miners, Bitcoin would be less reliable and you'd have to wait much longer to get the same level of security against a double-spending attack. We need as much mining as possible because mining secures the blockchain.
If I have 10 Bitcoins, I must be able to send them to Jeff. Otherwise, I don't have 10 Bitcoins. If I have 10 Bitcoins, I must be able to set them to Mary. Otherwise, I don't have 10 Bitcoins. But if I could send them to both Jeff and Mary, the system would break. So somehow, sending them to Jeff must prevent me from sending them to Mary too.
Bitcoin does this by having miners pick one of those transactions and heap a massive amount of computations on top of it. Among valid blockchains, Bitcoin prefers the one that likely took the most calculations to do. Miners pile calculations on top of the legitimate block chain to distinguish it from alternate chains. To "undo" a Bitcoin transaction, you must pile more computations on top of it than the rest of the miners combined piled on top of the legitimate chain that includes that transaction. The more mining, the faster you can accumulate sufficient calculations that undoing a transaction is impractical.

Centralization leads to vulnerability. The fewer nodes active at any given time, the fewer nodes any attacker would need to take over in order to control a majority of the network.
Also see this question.

I think Guillochon was thinking in terms of peers, not mining hardware.

He mentions "dedicated hardware". What else would he be referring to?

Yes, I'm referring to the miners. Is the only benefit preventing takeover?

The point of the distributed transaction verification system (the network of miners) is to prevent (or at least make as difficult as possible) takeover by any singular entity, yes. If there are any other benefits (relative to Bitcoin - obviously, electricity companies benefit), I'm not aware of them.

You might be confusing the roles of the blockchain and miners.
Miners are purchasing specialized hardware (known as ASICs) to mine for blocks more efficiently. This has no effect on the rate of block generation because the network auto adjusts difficulty every 2016 blocks (about 2 weeks).
By contrast, the blockchain can be hosted by any computer without specific hardware and is downloaded when you use a "full" client like bitcoin-qt. Because the blockchain is hosted everywhere, it would be near impossible to wipe it out, which is a good thing for a public ledger.

I guess that's more my question: Is there any positive to having as many miners as possible?

There is an advantage to more miners when it comes to thwarting a 51% attack. Currently, the mining pool BTC Guild is approaching half the network hash rate, which would technically cede them control to fork the blockchain. It's unlikely that they'll do this, but some people are calling  for miners to switch pools in an effort to prevent that threshold from being crossed.


text:
Why is blockchain necessary?
I'm trying really hard to understand how bitcoin works.
I understand that bitcoin miners does proof of work, and creates blocks, and then transactions are sealed inside this block to become "confirmed". And this has something to do with double spending.. somehow..
So, my questions is, why cant we do a similar decentralized network, without proof of work/blockchain? In this network, we just keep a list of all transactions (akin to blockchain) (a copy for each node), and then use majority rule. Ie, if there is a dispute in the new transaction, we just go to every node, check their list of all transactions, and if the new transaction contradicts majority of list of all transactions, then the new transaction will be rejected etc. And nobody need to solve any hard math problems (ie proof of work)
And for new transactions, our protocol can be following: If nobody disputes the transaction over the next 60minutes, then we set confirmed flag of this transaction to be 1, and thus this transaction is now confirmed etc.
In other words, im struggling to understand the value of proof-of-work process in bitcoin.

How do you define majority of nodes? How do you stop an attacker from creating a billion new nodes? And what happens if an attacker sends two contradictory transactions to nodes? Everybody need to agree on a single authoritative order.

Ripple does something like this. https://ripple.com/wiki/Consensus answers @CodesInChaos's questions wrt Ripple.

I think the introduction of block has much more a security-related origin:
Currently, getting transactions confirmed costs a certain amount of work for which computer have to run a long time and cost some time, effort and money. Because of this, it is hard to manipulate the chain of transactions. It is hard to find a correct block with a certain set of transactions and cheating will result in your block being refused by the network.
However, when clients just keep lots of transactions, it would be much easier to f.e. set up thousands of false nodes that manipulate the network. A node that only requires memory is much cheaper than one that requires hashpower. With some resources it's easy to add thousands to hundreds of thousands of clients (these don't have to be separate machines but can be virtual ones) participating and entering bogus transactions or leaving some out.
The fact that creating the blocks is "difficult" add a lot of security to the network, making it extremely hard to falsely manipulate the transaction history.

Thank you for the response, now it makes much more sense to me. But here's my follow up question

Steven's answer is correct. A complementary way of looking at it is optimization.
Background
Let's start by assuming that one understands why consensus by majority doesn't work (too easy for an attacker to create bad nodes and take over). Bitcoin's proposed solution is to use a log that keeps track of all transactions and to maintain consensus by log length, not node count. For this to work, Bitcoin proposes a few conditions:

We assume that anyone can create a log (i.e., we don't trust anyone to maintain a "known good log").
The log with the most entries is always considered authoritative.
Each entry has some kind of intrinsic link to the entry that comes before it and the one that comes after it.
It's really difficult (i.e., it takes a lot of time) to add a log entry.

The last condition is really important. If it's easy to add log entries--for example, if the log is just a text file sitting on your desktop--then any attacker can create really long, fake but authoritative transaction logs with whatever sort of transactions that the attacker wants.
If it takes a lot of time to add each entry, however, then an attacker will need to spend all the time that has already been spent on creating the main log just to catch up and create a fake log that is as long. By the time they catch up, the main log will have already moved on and gotten even longer. It becomes increasingly unlikely that an attacker will ever be able to catch up by creating a fake log that is longer than the main log as the main log gets longer and more popular. That diminishing probability is what makes Bitcoin secure.
So what does this have to do with optimization?
Now, the question is, what exactly goes into the transaction log? This is where optimization comes in.
If each log entry were literally a record of a single transaction and if each log entry took, say, 10 minutes to create, it would take forever to make transactions. So instead, Bitcoin proposes that the log tracks mini-logs of transactions. Each transaction is trivial to create and easy to verify, but each mini-log is difficult to create and tracks all the transactions that occurred during a period of time. The idea is that with each new mini-log, faking transactions continues to become increasingly difficult, but at the same time transactions can occur instantly.
How does this work? When you conduct a new transaction, that transaction is broadcast to all nodes who keep track of it in local copies of the current mini-log. Each node is also working on a difficult calculation (hashing) that takes a relatively long time (for Bitcoin's network as of writing, about 10 minutes on average). All it takes is for one node in the network successfully complete the problem, and then that node's local mini-log copy is considered complete and is sent to every other node. Once every node accepts the winning mini-log copy, that copy is considered the authoritative mini-log for all the transactions that had previously been considered conditional. All the transactions that occurred instantly are now said to have one "confirmation."
Conclusion
Now...replace the word "log" with "chain" and "mini-log" with "block" and now you understand why blockchains are necessary not just from a security standpoint but from an optimization standpoint, as well ;-)


text:
Push notification of incoming transaction
Is there a way to be notified by bitcoind via the CLI that some incoming transaction has been confirmed?

there was a patch for that somewhere out there, but i don't recall where exactly so i'll leave it for someone else to find. :)

A transaction can only be confirmed by a new block being added to the chain. And since that happens on average every ten minutes, it would work just as well to be notified when a block is discovered (and/or the chain is reorganized). You can then check any transactions you care about.
One way to be notified if the chain is changed in any way is with my native long polling patch. This should apply pretty cleanly to any recent version of the client (but is based on 0.4.0):
diff -u orig/init.cpp new/init.cpp
--- orig/init.cpp   2011-09-25 08:29:53.935505617 -0700
+++ new/init.cpp    2011-09-25 08:48:13.667215990 -0700
@@ -199,6 +200,7 @@
             "  -rpcport=<port>  \t\t  " + _("Listen for JSON-RPC connections on <port> (default: 8332)\n") +
             "  -rpcallowip=<ip> \t\t  " + _("Allow JSON-RPC connections from specified IP address\n") +
             "  -rpcconnect=<ip> \t  "   + _("Send commands to node running on <ip> (default: 127.0.0.1)\n") +
+            "  -pollpidfile=<f> \t  "   + _("Support long polling\n") +
             "  -keypool=<n>     \t  "   + _("Set key pool size to <n> (default: 100)\n") +
             "  -rescan          \t  "   + _("Rescan the block chain for missing wallet transactions\n");

diff -u orig/main.cpp new/main.cpp
--- orig/main.cpp   2011-09-25 08:29:53.937505613 -0700
+++ new/main.cpp    2011-09-25 08:48:13.667215990 -0700
@@ -1118,6 +1118,7 @@
 bool CBlock::SetBestChain(CTxDB& txdb, CBlockIndex* pindexNew)
 {
     uint256 hash = GetHash();
+    bool lp = false;

     txdb.TxnBegin();
     if (pindexGenesisBlock == NULL && hash == hashGenesisBlock)
@@ -1160,6 +1161,7 @@
     // Update best block in wallet (so we can detect restored wallets)
     if (!IsInitialBlockDownload())
     {
+        lp = true;
         const CBlockLocator locator(pindexNew);
         ::SetBestChain(locator);
     }
@@ -1173,6 +1175,23 @@
     nTransactionsUpdated++;
     printf("SetBestChain: new best=%s  height=%d  work=%s\n", hashBestChain.ToString().substr(0,20).c_str(), nBest

+    if (lp)
+    {
+        // Support long polling
+        string lp_pid = mapArgs["-pollpidfile"];
+        if(lp_pid != "")
+        {
+            FILE *pidFile = fopen(lp_pid.c_str(), "r");
+            if(pidFile!=NULL)
+            {
+                int pid=0;
+                if ((fscanf(pidFile, "%d", &pid) == 1) && (pid > 1))
+                    kill((pid_t) pid, SIGUSR1);
+                fclose(pidFile);
+            }
+        }
+    }
+
     return true;
 }

To use it, just start bitcoin or bitcoind with a command line argument of-pollpidfile=/path/to/some/file. Then write your monitor process' PID to that file. You will receive a SIGUSR1 on any block chain change.


text:
My Bitcoin Transaction Has Been Stuck For 9 days
What can i do to speed it up more? I have used the accelerators and re-broadcast it myself many times but it has not moved. I sent with a low fee by accident.
Txid: dc0b8a1174b1277bc10b1e80a8715b18ebcab60550dcfa694b041f3acee5c407

You say that you have re-broadcast the transaction.  If so, I assume you re-broadcast with a higher fee (i.e., double spend).  If so, then the newer transaction is the one that you should be looking to confirm.  If not, then try the rebroadcast (i.e., double spend) again.  For further discussion, see this question and its answers

sorry i have not rebroadcast just used accelerators


text:
mining Cryptonote currency on scrypt and sha-256 miner
I have a python miner which is only capable of scrypt and sha-256 mining. Is it possible to mine cryptonote monero on it? Pool link(i use minergate): stratum+tcp://xmr.pool.minergate.com:45560

Not possible.  Monero uses the Cryptonight hash algorithm which is distinct from scrypt and sha-256.  However, you should be able to find other CPU mining implementations for this algorithm.  The place to ask would be https://monero.stackexchange.com.


text:
To generate private key
How can I generate a private key to spend the bitcoin of a watch only addresses that is in the imported addresses of blockchain.info?

One cannot "get" the private key from a watch only address. There is ECDSA logic and several hashing functions, that (as per today's knowledge) prevent this.
The priv key is generated in the wallet, via ECDSA you come to the public key, which is hashed and checksum'd and base58encoded into a bitcoin address. These hashing functions are a one way logic...
The answers here are fairly generic, and deserves probably a whole chapter of a book: Andreas' has it already explained in his book "Mastering Bitcoin". It is an amazing book that'll definitely get you to go. It's freely available online here. Look into chapters 4 and 5, that will explain ECDSA and wallets setup, followed by chapters on keys.


text:
From where does a node download a copy of the ledger
From where does a node download the latest copy of ledger initially? Is this information stored in a 'central server'?
Let's say a node is offline for a while, after coming back how will the node get to know the ledger is up-to-date or not?

Good question, This is a quote from article that i have just read, where its described in a pretty simple way:
Now when you first open up a Full Node client like Bitcoin Core, most people are sitting behind a firewall. In this case, your Full Node is limited in the number of connections it can connect to (around 8) and only looks for Super Nodes a.k.a. Listening Nodes. The reason for this is because your Full Node isn’t publicly connectable yet.

In a distributed network, a Super Node functions as a highly connected redistribution point as well as a relay station. Therefore this would be an appropriate term to describe a publicly connectable Full Bitcoin Node. This means many nodes can connect to it to obtain relayed transactional data and blockchain history.
Original article: https://hackernoon.com/lets-talk-about-bitcoin-nodes-e9502193198c
So basically you get your data from publicly connectable Full Bitcoin Nodes

I disagree there's such thing as a 'full bitcoin node'. If it's not full, it's not a node.

@OsiasJota Any system, such as a server, desktop application, or wallet, that participates in the bitcoin network by “speaking” the bitcoin protocol is called a bitcoin node

It shouldn't be.

But I recognize that's the way the word is used today :(

The very word 'node' means there's no servers and clients, every running software is equivalent. No 'central' anything, Bitcoin was created to be a decentralized system. The initial copy and any future updates can be donwloaded from any other node.

When you say 'other node', in group of a million nodes across the globe, how do my node know from which node to download from? How to trust that node? Where to get nodes address from?

Bitcoin node software have a list of IP adresses of other nodes they can communicate. There's no trust required. See this answer: https://bitcoin.stackexchange.com/questions/3536/how-do-bitcoin-clients-find-each-other


text:
why can't i push this transaction?
Why can't I push this transaction using blockchain.info but a transaction just like mine was broadcasted and mined?
My transaction:
0100000001f15c0393d76d26632f9416040a8205da1ff2e294e3ab793425fc95f51a249d3600000000020151ffffffff01301b0f000000000017a9143dbbda49ccc09591516be148dd966610f254e4bc8700000000

Similar/Same transaction:
01000000017742f03fc00dc2ef74a01b62cf1eabcad12f408497d04f2db256c0a9e4b8a93d00000000020151ffffffff0120402c00000000001976a914d19518b71f7603304c81b69dfb8757bb72d117b788ac00000000

Your transaction input has no signature, and it's spending an output sent to address 1BitcoinEaterAddressDontSendf59kuE. Spending such an output requires an input that contains a signature created with the corresponding private key for that address.
In contrast, the other transaction you're referring to sends to a P2SH address 3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj. This address is a hash of the script "OP_TRUE", which doesn't require any signatures (or anything at all; anyone can spend coins send to that address).


text:
Error: connect ECONNREFUSED 127.0.0.1:8332
I get this error:
{ Error: connect ECONNREFUSED 127.0.0.1:8332
    at Object._errnoException (util.js:1022:11)
    at _exceptionWithHostPort (util.js:1044:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1182:14)
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 8332 }

when I use this code:
var bitcoin = require('bitcoin');
var client = new bitcoin.Client({
    host: 'localhost',
    port: 8332,
    user: 'Rohit',
    pass: '12345'
});

Can you post the contents of your bitcoin.conf file (censoring any passwords as necessary)?

Welcome to Bitcoin.SE! You can help the site by marking answers as accepted if they are correct and address the question so that the question does not remain as "unanswered".

I hadn't started bitcored service ..that's why this error occurs
when I started, the error had gone
i followed these steps that given here
Anyway thanks**

The link is dead. Can you please write steps here so links won't be used.

Bitcoin json rpc requires bitcoin core to actually start for it to work and won't work if it turn off


text:
I'm trying to hash transactions together to find the Merkle Root!
Transaction #59500 has 045c670f1c02c919  as its coinbase. Transaction 1 is 6653ad77d695752cff9fe63bbb5702a53807be534c537251d53de06aac5ca093. Transaction 2 is 72e8781092c01e9eb1c21ba33d52ad6abc42f3807601bcd8b8074d583446346e.
Double SHA256 of Coinbase
import hashlib
header_hex = ("045c670f1c02c919")
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
hash.encode('hex_codec')
'6eafdb5c504ed7e70536d70c666503f4435205f367f21d2960ff2262ca2acf0b'
hash[::-1].encode('hex_codec')
'0bcf2aca6222ff60291df267f3055243f40365660cd73605e7d74e505cdbaf6e'

Double SHA256 of Transaction 1
header_hex = ("6653ad77d695752cff9fe63bbb5702a53807be534c537251d53de06aac5ca093")
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
hash.encode('hex_codec')
'b2e28ac8528477c0c3c7978ee29479ae9ca1aed9cb2e58e6b910f17142f6c53d'
hash[::-1].encode('hex_codec')
'3dc5f64271f110b9e6582ecbd9aea19cae7994e28e97c7c3c0778452c88ae2b2'

Would I then combine the double hash of the coinbase with the double hash of transaction 1? Like so:
("0bcf2aca6222ff60291df267f3055243f40365660cd73605e7d74e505cdbaf6e" + "3dc5f64271f110b9e6582ecbd9aea19cae7994e28e97c7c3c0778452c88ae2b2) and then double hash that?
The double hash of the coinbase and transaction 1 is d77fefa4fd82afdf1780f84dae5dc30be2f3b53bc8db2c40db6d17687324dc48
Double SHA256 of Transaction 2
header_hex = ("72e8781092c01e9eb1c21ba33d52ad6abc42f3807601bcd8b8074d583446346e")
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
hash.encode('hex_codec')
'c9f7032f5df64761e74ad4bc7cb653db8c78aed331926382ca37ec3b8d8625a9'
hash[::-1].encode('hex_codec')
'a925868d3bec37ca82639231d3ae788cdb53b67cbcd44ae76147f65d2f03f7c9'

Would I then hash a925868d3bec37ca82639231d3ae788cdb53b67cbcd44ae76147f65d2f03f7c9 with itself?
header_hex = ("a925868d3bec37ca82639231d3ae788cdb53b67cbcd44ae76147f65d2f03f7c9" + "a925868d3bec37ca82639231d3ae788cdb53b67cbcd44ae76147f65d2f03f7c9")
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
hash.encode('hex_codec')
'4075e4ac60dd8a52ed3eb69520ad71d660c8c2bcbf4073c87fd633a276cb2921'
hash[::-1].encode('hex_codec')
'2129cb76a233d67fc87340bfbcc2c860d671ad2095b63eed528add60ace47540'

Lastly when I try to combine that hash of the coinbase and transaction 1 with the hash of transaction 2 with itself...
''d77fefa4fd82afdf1780f84dae5dc30be2f3b53bc8db2c40db6d17687324dc48' + ''2129cb76a233d67fc87340bfbcc2c860d671ad2095b63eed528add60ace47540"
I got this 012853eb35789c270fc72dc11b4b9e24710f6f02793344860bdcad7f25e771e1 when the merkle root is :
ff682ef66cd1b56213fd4db9462fb138f6d8c16d706d41969a7eacc819528038
What did I do wrong?

There are multiple things that you have done wrong.
First, you hashed just the coinbase part of the coinbase transaction. You are supposed to hash the entire coinbase transaction.
Second, you have hashed the transaction ids of the transactions, not the transactions themselves. Hashing the transaction themselves will result in the txid (ignoring segwit). So instead of hashing the txids again, you just take those as the first hash in the merkle tree and combine them and hash the combination for the second level of hashes.
Third, you reversed the hash hexadecimal representation. You should not be reversing those hashes. However, if you start with the txids instead of the transactions themselves, you need to byteswap the twids first. Byteswapping is different from reversing the hex of the string as two hex characters represent one byte. It is easier to do this when the hex has already been decoded into a byte string.
For combining hashes, you just concatenate them. For the last transaction, if it is by itself, you copy its hash and concatenate the copy to the original. It is just the txid concatenated to itself.

You can get the hexstring for the transaction by using a block explorer with their raw tx API. For example, using blockcypher, you can get the raw coinbase transaction with the link https://api.blockcypher.com/v1/btc/main/txs/72e8781092c01e9eb1c21ba33d52ad6abc42f3807601bcd8b8074d583446346e?limit=50&includeHex=true. The hex field is the raw transaciton. However, you don't need this because you have the txid of the coinbase from the block explorer, so you can just use that.

Thank you Andrew! So if I was given the transaction ID of 72e8781092c01e9eb1c21ba33d52ad6abc42f3807601bcd8b8074d583446346e. How would I go about byteswapping this? When you say byte string is that the same as binary?

Yes, a bytestring is the same as binary. Byteswapping a hex string means that ever two characters (representing one byte) is swapped with the two characters in the same position at the end of the string. So byteswapping that txid gives you 6e344634584d07b8d8bc017680f342bc6aad523da31bc2b19e1ec0921078e872

I'm sorry I keep asking questions I just want to get this right. How would I derive the coinbase transaction from the raw data under hex? If transaction 1 is the coinbase transaction I would byteswap that which would give me 93a05cac6ae03dd55172534c53be0738a50257bb3be69fff3c7595d677ad5366. Transaction 2 is the one that you byteswapped which is 6e344634584d07b8d8bc017680f342bc6aad523da31bc2b19e1ec0921078e872. So then do I just combine them 93a05cac6ae03dd55172534c53be0738a50257bb3be69fff3c7595d677ad53666e344634584d07b8d8bc017680f342bc6aad523da31bc2b19e1ec0921078e872 and double hash them?

Yes, that is correct.

I think I'm somehow concatenating them incorrectly in the terminal. I was trying with a different one. "13a3595f2610c8e4d727130daade66c772fdec4bd2463d773fd0f85c20ced32d"
"f6ae335dc2d2aecb6a255ebd03caaf6820e6c0534531051066810080e0d822c8"
gives
"59545fd8dfdd821ca7accecab0655d77437f5bba5aaa5ea8c042a26bc9ae514b". I get this...
'e4dc2114f6e4b087b4683555ae764e99e3f623e1ed44e1213ba34b96a2fb9cb5'

Actually, you have mistranscribed something. The full thing concatenated that you should be hashing is 93a05cac6ae03dd55172534c53be0738a50257bb3be69fff2c7595d677ad53666e344634584d07b8d8bc017680f342bc6aad523da31bc2b19e1ec0921078e872 which has one character different from what you are hashing. The resulting hash will be the byteswapped version of what block explorers tell you is the merkle root.

Andrew thank you so much I was banging my head against the table.

I messed up many many things. First, transaction 1 is the Coinbase transaction, which means that there are only 2 transactions to be hashed together. Second, I didn't byte-swap the TXID's before hashing them together. After getting the double hashed hex string you have to byte-swap it to get the correct Merkle Root.
Transaction 1 is 6653ad77d695752cff9fe63bbb5702a53807be534c537251d53de06aac5ca093
Byteswapped = 93a05cac6ae03dd55172534c53be0738a50257bb3be69fff2c7595d677ad5366
Transaction 2 is 72e8781092c01e9eb1c21ba33d52ad6abc42f3807601bcd8b8074d583446346e
Byteswapped = 6e344634584d07b8d8bc017680f342bc6aad523da31bc2b19e1ec0921078e872

import hashlib
header_hex = "93a05cac6ae03dd55172534c53be0738a50257bb3be69fff2c7595d677ad53666e344634584d07b8d8bc017680f342bc6aad523da31bc2b19e1ec0921078e872"
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
hash.encode('hex_codec')
      '38805219c8ac7e9a96416d706dc1d8f638b12f46b94dfd1362b5d16cf62e68ff'
hash[::-1].encode('hex_codec')
      'ff682ef66cd1b56213fd4db9462fb138f6d8c16d706d41969a7eacc819528038'


text:
How to determine custom synchronization status?
Context:
I'm working on an application in which we'd like to know if the current node is sufficiently synced to be able to handle RPC requests. The method we would like to use is to see if our node has at least 2-4 peers and if a majority of the peers are reporting the same best height / best block hash.

Previous research:

I know the version network call gets the height of the peer at that time, but it isn't updated. In addition, any further version requests result in an increase of the ban score of a node, so this cannot be used frequently.
Bitcoinj keeps track of the height of the best known peer by using the height given in the version message and then incrementing whenever the peer processes an inv message showing they have a new best-block height. This seems fast, but tricky/error prone.
This question is similar, but it asks about how to do this with RPC calls, and it doesn't seem to want to use the same method for determining whether the node is synced as the one I've proposed.
This question helped provide a temporary solution (calling get work and seeing if it fails), but this method is not accurate enough.

Is there a way to just ask a peer what the height of its best block is without getting banned?
Could I just make multiple getheaders requests and see if the peer returns any headers later than the header I have, or would the peer ban me for requesting the same headers again and again?

Bitcoin Core 0.10.0 may provide the solution you need thanks to its headers-first synchronization.  The getblockchaininfo RPC in 0.10.0 provides both a blocks field (the number of verified blocks) and a headers field (the number of partially-validated headers).
Any time the numbers differ, you don't have all the blocks.  During Initial Block Download (IBD), they'll be hundreds of thousands of blocks apart.  (According to a Wireshark sniff I did during IBD a few weeks ago, it took my node less than two minutes to download a complete headers chain; syncing the blocks then took another three hours.)
Bitcoin Core 0.10.0 has two other new fields you might find useful, both in the getpeerinfo RPC.  The fields are synced_headers and synced_blocks.  The headers field is based on the last P2P headers message the remote node sent you.  The blocks field is based on the last P2P block inv message the peer sent you.  In both cases, they let you know the last header or block you have in common with the remote node (as best as can be determined).
I don't know how useful these getpeerinfo fields will be, as your node can't tell you the height of a block until it has the corresponding block header---at which point the getblockchaininfo RPC will already tell you that you're out of sync.  However, they are kinda fun to look at.

Could I just make multiple getheaders requests and see if the peer returns any headers later than the header I have, or would the peer ban me for requesting the same headers again and again?

As far as I know, there's no ban score there (as long as your packets are valid).  However, the remote peer should send you an inv message as soon as it validates an incoming block---so there's no need to poll it as long as your app handles inv messages with a MSG_BLOCK type.

Is it guaranteed that nodes will send you an inv right after they have a new best block every time? Even if you are the one who sent them the new block data?

If you send them an inv, they shouldn't send you an inv for the same data.  Bitcoin Core also won't send invs while they're in IBD.  For all other cases, Bitcoin Core full nodes will send you an inv for each new block they validate.  Based on my reading of the 0.10.0 code a few weeks ago, there is no built-in delay (like for tx invs) or network partitioning (like for addrs) when it comes to block invs. Of course, nothing is guaranteed on a P2P network.

Doesn't the bitcoin method depend on using headers first synchronization? The fields added to getpeerinfo may be just what I need. False negatives (reporting that the node is not sufficiently caught up to handle requests when they actually are) are fine, it's false positives that would be the real kicker. I think the methods in the new getpeerinfo should meet those requirements. So, thanks!

Yes, headers first is required, which is why only 0.10.0 has that field.  Note that it works the same whether or not the remote node uses headers first (0.10.0 won't connect to nodes that don't support the P2P headers/getheaders messages, which were introduced in December 2010).  I'd think the headers field from getblockchaininfo would be more useful because it has the height of the highest of your peer connections (so you don't need to iterate over each connection).

Yes, it probably would be a faster response time and more useful, but we are working with coins other than just Bitcoin (Lite, Doge, etc), and we need the sync check for all of them. Implementing headers first synchronization in all these coins probably isn't doable in the time frame.


text:
Why can't I withdraw any BTC from MtGox?
I have a balance of just 4 BTC at Mt Gox and when I try to withdraw them I get this message: Your account is currently pending review, please visit https://mtgox.com/forms/verification
What am I supposed to do about this?  Is anyone else having the same problem?
EDIT (cannot comment or answer my own question?): Yes I created the account using Tor, and their response says that's the reason.  @Stephen Gornick you are correct, the restriction is specified when creating the account.

You need to go to that URL and follow the instructions.  Your ID must be verified to conduct any business of any size on Mt Gox.  Try withdrawing 2 BTC

@Steve Rogers, did you by chance try to access your Mt. Gox account using Tor?  When signing up they expressly state conditions in which ID verification will be required.  Access via Tor is on of those conditions.

@makerofthings7 - I don't think this is true. 7 BTC is below the daily withdrawal limit for unverified users.

@ripper234 This may have been the case when BTC was worth less... 4 BTC 9 hours ago would have been worth just over 1K where most AML laws apply

When Mt. Gox initiates the demand for verification your account is essentially frozen for withdrawals until you send in the required identification (color photo ID and whatever else they want) and your account gets verified.
The instructions from the link you provided will clearly state what is needed.
For example, it might state

VALID Photo ID Proof (Identity card, license, passport,...)
Residence Proof (utility bill, tax return, insurance,...)
  ISSUED WITHIN 6 MONTHS

For the color photo ID, even a pic of the ID taken with a phone is usually sufficient.

It's worth noting that we have no real way to know the specific trigger to Mt. Gox verification request. Tor access is indeed one factor that triggers it, I don't know if there are more.


text:
How old should be my bitcoins to send them again without transaction fee?
I'm making some test for a bitcoin merchant webpage. I want to test different actions without paying transaction fees everytime, but I can't since I use the same few bitcoins for everything.
Sooo how long should I wait for my bitcoins to be transfered wihout fee?

As the coins "age" they will have a higher priority.
I don't know the algorithm, but believe it is roughly like a day or so and then the age of the coin no longer is a factor.
So if you are seeing minimum fees for coins more than a day after you've received them, it is because of other reasons, such as having outputs at amounts below 0.01 BTC.

In the Bitcoin protocol, fees are totally optional.  You can have a fee of 0btc or 10btc.
Once there are more transactions then what fits into a block, which isn't now, miners will choose what transactions to include into their block, and they will prefer transactions with a fee attached, because they get that fee.
Right now, fees don't help process a transaction any sooner or better, but in the future it's likely to make a difference.  This totally depends on what happens in the future, and is very much up for debate.

Thanks Liquid5n0w. I think i didn't explain myself well, even if the transaction fees are optional right now, when you just receive bitcoins you can't re-send them inmediately without fee, bitcoind tells me to include a 0.005 fee because "i just received those bitcoins". I went and read about that, it seems to be that i have to wait for my bitcoins to be "old enough" to send them for free again.


text:
How is a block accepted with one invalid transaction among many valid transactions?
When a block is mined, let's say there is only one single invalid transaction out of lets say 2000 transactions in a block.
Will they get rid of that one transaction and accept that remaining block or for that one single invalid transaction will they reject the whole block?

How is that block going to be "mined"?

It's not accepted. In a block, every transaction has to be valid by itself, but the whole block has to be valid as well. If anything is wrong about the block, it's simply invalid—there is no "partially right".
Let's say a miner creates such a block and broadcasts it to their peers. Each full node peer attempts to validate the block and realizes that the block does not follow the rules. They drop the block, do not forward it to their peers, do not add it to their blockchain, and do not update their UTXO set. Depending on how the miner relayed the block to them, they probably even drop the connection and ban the miner for sending invalid data. Nobody else sees the invalid block unless someone posts about it on social media to ridicule the miner…

Will they get rid of that one transaction and accept that remaining block

That is not how Bitcoin (and any other blockchain based system) works. You cannot ever alter a block. Never. You can accept or decline a block, that's it in terms of anyone's options.
But "changing/omitting/rejecting a single transaction"? That would lead to a cascadingly increasing change to that block's Merkle Tree, resulting in a different final hash and therefore (almost certainly) requiring a different nonce. Which is known as a completely different block that just so happens to also contain a lot of the same transactions. It would still be a different block in all other regards, and most importantly: it would have to be mined completely separately (aka trying out different nonces). And anyone trying to mine that similar but different block would most certainly put themselves (or their pool) as the reward-adress, so one more thing different about that block

Remember, every full node constructs and submits their own block and then compete to find the nonce to their own block.
That is to say, full node miners are not competing over the same block. This means even if a block got rejected due to an invalid tx, there will be another peer who finds a nonce to their own block which probably includes the same valid txs and their block gets accepted on the chain. There is no time wasted as a result of a bad actor sending an invalid tx.


text:
Can miners double-spend with two transactions in one block?
Let's say Alice sends 5 BTC to Bob and Alice tries to make double spending by again sending those same 5 BTC inputs to carl and lets say that Alice is also a one of the miner node.

Here Alice tries to take those 2 double spent transactions into a same single block
lets say Alice solved hash puzzle and broadcasted those 2 transactions in the same block

since in first transaction, inputs UTXO and output UTXO are valid and in second transaction which is of same block, even have input UTXO which is unspent, but it is double spent. when block is broadcasted those 2 transactions are broadcasted simultaneously,
Questions:

how other nodes are going to validate those 2 simultaneously broadcasted transaction technically by bitcoin code(Where those 2 transaction in same block)?
How is this double spending is solved technically by bitcoin code, when 2 transactions are included in same block (When block is broadcasted then those 2 transactions are broadcasted simultaneously )?

Having sufficient proof of work is a necessary criteria for a block to be valid, but it is not a sufficient criteria for a block to be valid. The proof of work is used to limit the cadence of updates to the shared global state and as a mechanism to select the author of the next block in a distributed manner. Additionally, the block has to pass all the ~40ish rules for blocks to be valid in the first place.
A block that contains two conflicting transactions is invalid. A full node validating it will mark the UTXO as spent when it validates the first transaction, and when the second transaction refers to the same UTXO as its input, the UTXO is no longer available and the block gets rejected.

If a block contains two conflicting transactions (a double spend) then the block is invalid, despite the proof of work being correct. Thus, the miner has wasted their work, and the block will be rejected by all validating nodes.

Can you elaborate how is block will get rejected by all validating nodes technically? Because I know how it rejects block when 2nd transaction is double spent after 1st transaction is already broadcasted to bitcoin ledger. But How the block will get rejected when 2 transaction which are double spent are included in same block and broadcasted (Which means those 2 transaction are technically broadcasted simultaneously )

The validating node marks the UTXO as spent when validating the first transaction, and when it tries to validate the second transaction, the UTXO referred to in the input is spent already and it throws the invalid block out.

The complete block is transmitted as a whole to the fully validating node.
The validator starts checking the transactions one by one.
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_check.cpp
The relevant code that rejects block with double spends is:
    // Check for duplicate inputs (see CVE-2018-17144)
    // While Consensus::CheckTxInputs does check if all inputs of a tx are available, and UpdateCoins marks all inputs
    // of a tx as spent, it does not check if the tx has duplicate inputs.
    // Failure to run this check will result in either a crash or an inflation bug, depending on the implementation of
    // the underlying coins database.
    std::set<COutPoint> vInOutPoints;
    for (const auto& txin : tx.vin) {
        if (!vInOutPoints.insert(txin.prevout).second)
            return state.Invalid(TxValidationResult::TX_CONSENSUS, "bad-txns-inputs-duplicate");
    }

This code doesn't check for doublespends per se, but rather that a UTXO was not spent twice within a single transaction.


text:
Splitting of data across blkxxxxx.dat files
I am trying to parse out the bitcoin data using Big Data and wanted to know more about the blk files themselves. I was wondering how does bitcoin split the transactions across the files. I know there is a 128 MiB limit on the files. Does that mean it is possible for transaction data to be split across a blk ? For instance the merkle root of the transaction is in one file and the output index is in another ? Or is block data retained in a single file ?

Blocks are never split across files: the whole block, from magic to length, to header, to transaction data, is always stored in a single file, continuously.
However you may need to take into account:

Blocks in the blk*.dat files are stored in the order they are received from the network.l, which may not be the blocks' logical order.
It is possible that a block is in file N, and its descendant block is in file N-1.
The files contain all blocks ever received, including ones that are not part of the main chain but were reorged out.
There can be "gaps" of zeroes or garbage data between blocks in the blk*.dat files.

Thanks for your answer! Just one follow up, is there anyway we can pre-sort the blk files in anyway ? Because I'd like to process them into a CSV on individual nodes on a distributed environment and then find out the input address by looking backwards if that makes sense

Bitcoin Core has a linearize script: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize. This can be used to construct a single file with all blocks in the active chain (no reorged forks), in order, without gaps.

As a kind of addendum to the first bullet-point in Pieter's answer, I had written a program to parse blkxxxxx.dat files and, in my case at least, the blocks are very obviously not in logical order. Just as Pieter asserted.
Notice the day number in the timestamps in the first ten blocks:
C> blockchain -file blk02100.dat -blocks -longstats
Block      1, 2020-06-03 03:48, target 171297F6,   2273 transactions
Block      2, 2020-06-03 04:29, target 171297F6,   2768 transactions
Block      3, 2020-06-04 02:00, target 171297F6,   2177 transactions
Block      4, 2020-06-05 12:37, target 17147F35,   2243 transactions
Block      5, 2020-06-01 07:15, target 171297F6,   3150 transactions
Block      6, 2020-06-02 21:48, target 171297F6,   2911 transactions
Block      7, 2020-06-02 21:49, target 171297F6,   2722 transactions
Block      8, 2020-06-05 16:23, target 17147F35,    182 transactions
Block      9, 2020-06-03 05:34, target 171297F6,   2002 transactions
Block     10, 2020-06-03 04:36, target 171297F6,   1958 transactions
...
Block    111, 2020-06-06 03:39, target 17147F35,    259 transactions

Statistics for blk02100.dat (2020-06-01 to 2020-06-06)

   111 blocks
222519 transactions (2004.7 per block)
109173 Segwit tx    (49.1%)
622026 inputs       (mean 2.8, max 1030 per transaction)
614553 outputs      (mean 2.8, max 3799 per transaction)

Processed file in 322.5756ms

I guess this scattered order is because my node was receiving blocks from multiple peers and concurrently receiving them from fairly disjoint ranges.
I can confirm that every blkxxxxx.dat file I tried, started and ended at a block boundary. There were no partial blocks.

Footnote: My program isn't extensively tested so maybe take the above with a pinch of salt. I believe the timestamps to be parsed correctly.

Yes ! I have found the same to be true and the python parser i am currently using parser also has the option to obtain blocks in an ordered/ unordered form.