How to generate wallet address? And how to get that connected with internet for transactions?

You dont have to be connected to the internet to have your wallet verified or something. People can send bitcoin to you (or a random valid address) even without them knowing it exist. You can create an address on a site like this or create an address in your wallet app (such as Multibit, which is a program I'd advise to use). I would suggest the latter option, because it is safer (just 1 site/app that could possible know your secret key) and it takes away the hassle of importing the wallet in Multibit.

Your second question: yes, the address is the only thing the other person needs to know. Sometimes you also have a QR-code which act as the same thing, but your address alone is enough.

TL;DR. No need to connect to the internet, and create (and control) an address in Multibit. The one who is going to send you coins only needs to know your address. Good luck!


How does Electrum compute seed byte just before BIP-32?

After many hours, I found it! It is exactly what Mnemonic.mnemonic_to_seed() does in mnemonic.py! (link)
The most relevant part is what it returns:
seed_byte = hashlib.pbkdf2_hmac('sha512', mnemonic.encode('utf-8'), b'electrum' + passphrase.encode('utf-8'), iterations = PBKDF2_ROUNDS)

Where PBKDF2_ROUNDS = 2048. Then, I just did...
bip32_node = Bip32.FromSeed(seed_byte)   # Derivation path: "m/"


Got 64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) when submitting segwit transaction

You will receive this error if the value you are signing is not the exact amount of the entire unspent output value.

For example, if your unspent output value is 35,000, and you only want to send 30,000, your output value would be 30,000, and your signing amount would be 35,000. If you sign for only 30,000 (not the full amount of the unspent output) you will receive this error.

Visual Example Using BitcoinJS:

//add input
txb.addInput(txid, outn, null, scriptPubkey);

//add output
txb.addOutput(receivingAddress, 30000); //amount less the mining fee

//signing
txb.sign(0, keypair, null, null, 35000); //NOTE the amount is the FULL amount of the unspent output, NOT the amount being sent


An LTC-BTC Trading pair is the buying of LTC for bitcoins, so the volume of this market will indicate how much LTC has been bought for bitcoins.

The total amount of this trading volume can be shown in different value, if you want you can simply divide this amount by its adjusted price of LTC to know how much LTC has been transacted on this pair.

Usually the volume will be shown in dollar, so if we have a BTC at 10000 dollar, an LTC at 100 and the volume LTC-BTC show 1000 dollar we do:
1000/100 = 10

10 LTC has been exchanged for bitcoins.


Can a Ripple Transaction Sequence have gaps?

For a transaction to be processed it must use the very next available sequence number (as returned by account_info).
If an otherwise valid signed transaction has a sequence number too small (matching a previously used sequence number), then the transaction is guaranteed to never be valid and will produce an error and should be discarded by servers receiving it.
If an otherwise valid signed transaction uses a sequence number (currently) too high, then the transaction is not currently valid and will produce an error but the transaction may become valid (and a server may retain and automatically attempt to apply the transaction at that time). As well anything that has seen the signed transaction could replay it once the "missing" sequence numbers on the account are used. Such transactions are referred to as in-flight and their outcome is undetermined until either the account has a transaction with that sequence number included in a fully validated ledger (possibly a No-OP transaction just to consume/advance the sequence number) or a fully validated ledger with a ledger sequence at least as high as the LastLedgerSequence specified in the signed transaction is seen.
From https://ripple.com/wiki/Transactions#Use_as_a_NOP:

When multiple transactions are yet to be finalized (known to be in-flight), and a local error occurs such that there are following transactions in-flight, the following transactions will temporarily fail until the sequence number used by the local failure is consumed. A transaction is in-flight if it hasn't been included in a fully-validated ledger, but also isn't guaranteed not to be.
…
The in-flight transactions may be later replayed by anyone who has them. It is important for predictability and reliability to consume the sequence number of the bad transaction and replay the in-flight transactions until they are finalized.

And from https://ripple.com/wiki/Transactions#Basic_Transaction_Format:

LastLedgerSequence (optional)
Highest valid ledger number that a transaction can appear in. If this is specified, and the transaction is not included by the time the ledger reaches the specified ledger sequence number, then the transaction is considered to have failed and will no longer be valid.

So specificly,

For example, if I have one Payment Tx with Sequence 123, and then want to create another transaction with a Sequence 200, will it go through?

Not until transactions with sequence 124 through 199 go through. Until then servers will report a "missing sequence number" error on such transactions. Until some transaction with sequence 200 is applied to your account you cannot know that something somewhere won't re-submit your "old" signed payment transaction the moment they see your sequence 199 transaction (i.e. even though you get an error the transaction could be applied later).

Also, I understand that the transaction Sequence numbers cannot be descending, so I couldn't submit a Tx with a Sequence of 100.

Such a transaction will always get a "past sequence number" error and never be valid.


Are high-s ECDSA signatures forbidden in segwit witnesses?


A private key starting with a 6... and being 58 characters long.. sounds to me like you encrypted another private key with BIP38?

Simply decode the private key using a third party tool and then import the decrypted private key into ElectrumSV.

consider the following  private key; L4GPduQvHAhFrpnF5x29N7UV8x5iLqxKRWArfHvJn4PwtZu35Uur and subsequent adress - 1He7vZABE7Um1dZG8b1sRCZLnXD3DX4ebB

which encrypted with password ppg gives the following 58 char bip 38 private key:
6PYKwd9VQNQsmEzy4UqKBDLQ6DhMUxzLGjgzmqzZSAuqm82EPg9HhRM6Qd

To decrypt this without coding, i suggest you use something like Ian coleman's templates, or those of bitaddress.
https://www.bitaddress.org/ download the repository, https://github.com/pointbiz/bitaddress.org , verify it, then run the HTML file.

Go to wallet details = > enter your encrypted private key ( in my case ; 6PYKwd9VQNQsmEzy4UqKBDLQ6DhMUxzLGjgzmqzZSAuqm82EPg9HhRM6Qd and tick the "BIP38" encrypt box and fill in the password; which for me is " ppg "
then; you get a couple private keys; compressed || uncompressed in your case.

in my case; i simply see the compressed private key i encrypted, and the uncompressed key; which i wouldn't need in this case, as my balance was on 1He7vZABE7Um1dZG8b1sRCZLnXD3DX4ebB (belonging to the compressed key.)

See which one match the adress holding the balance, and import that private key into electrumSV. You'll have to figure which derivation paths to use yourself i'm afraid.


bitcoin-cli importprivkey to the same user or different users

You can set account like that

bitcoin-cli importprivkey "myPrivKey" "Account" true

if you want to import multi private keys do it like that

bitcoin-cli importprivkey "myPrivKey" "Account" false
bitcoin-cli importprivkey "myPrivKey" "Account" false
bitcoin-cli importprivkey "myPrivKey" "Account" false
bitcoin-cli importprivkey "myPrivKey" "Account" true

So you don't rescan the entire local block database each time, but the last time.

to import it to default account leave it empty

bitcoin-cli importprivkey "myPrivKey" "" true

Also please consider stopping using accounts since it will be removed in 0.16 version.


Why does bitcoin uses INIT_PROTO_VERSION (209) for addrme and addryou in the Version Message

CAddress is serialized differently for different purposes. When serialized to disk, the node version and the time are serialized. This is because this information is relevant to the address manager.
However, when serializing to be sent to another node, both the version and the time are omitted because they aren't necessary. These aren't being sent to other nodes, just the IP address and port themselves. You can see that these are skipped for non-disk operations because it is doing if (s.GetType() & SER_DISK) before the READWRITE (which indicates de/serialization) for both nVersion and nTime.
The output you see is because addrMe and addrFrom are local variables which don't need to have the correct version and time. So the version used is the version for the stream which is the minimum protocol version (this is just a safety thing to ensure compatibility). The time is the default minimum time. Since these values don't matter, using these defaults is okay.


Having problem implementing Electrum's BIP32 Key deriviation path

You're very close.

bip32_ckd returns a BIP-32 extended public key, however pubtoaddr expects as input a "normal" non-extended public key in either raw or hex-encoded form (and it doesn't check if the public key appears valid). Here's what you want:

./pybtctools bip32_ckd $xpub 0
> $xpub0

./pybtctools bip32_ckd $xpub0 0
> $xpub00

./pybtctools bip32_extract_key $xpub00
> $pub00

./pybtctools pubtoaddr $pub00
> $addr


Error: Unknown network starting a bcoin node

bcoin.network.get().toString()

returns main which is not a valid network string, it should be one of mainnet testnet simnet or regtest.


how to get realtime new transaction data in nodejs from bitcore

Either you use some nodejs library which would give you a high level wrapper for the bitcoin core api getrawmempool, or make your script hit your local bitcoin instance in the json-rpc format to get the memorypool data your node has.
The memory pool is basically where the transactions stay before getting confirmed in a block. So your script needs to run in regular intervals of time to keep track of the changes too.

url: http://<username>:<password>@localhost:18332/
post data:{"jsonrpc":1,"id":"curltext", "method":"getrawmempool", "payload":[]}

The username and password is checked from the bitcoin.conf file in the .bitcoin folder. Change the port number to 8332 in case you are running the mainnet daemon.


Is "volume" the quantity of BTC exchanged, or the number of trades completed?

They're both representing the same thing over different time periods. The values on the drop down are always for the past 24 hours, the values on the graph depend on what time range you're viewing.

In your example 75584 is the number of bitcoins traded in the past 24 hours, and 17261 is the number traded between 19:00 and 20:00


How does a share help in the discovery of a new block?

In order to find a Block, one needs to perform A LOT of tries - about 2^32 * the current difficulty. That number is so huge that solo miners rarely would be able to solve a block. A share on the other hand is a block of difficulty 1, which is at the moment a few million times easier to find.

Finding a share does not help in finding a block in any way - each hash is independent of all others. However, a share IS a proof of work done by the miner - they put in the effort to help the pool find the block. Once one miner finds a solution to the block problem, the pool earns money and can pay its miners - logically paying everyone for each share submitted. Those shares did not solve the block, but they were a proof that a miner was trying to solve a block. The more shares, the more work needed to be put.

Without shares, everyone would be essentially solo mining - there would be no way to prove that one put in the work, so there would be no reason to be paying the miners - they might be cheating after all.

A useful analogy would be lottery tickets - it is unlikely you will win, but if you live in a small town and decide to share the potential win with everyone that participates in lottery in proportion to how many tickets they bought, you would essentially have a mining pool. Every ticket, even if it does not win you anything, is worth a slice of the winnings - you had to pay for that ticket, so it's a proof that you put in the effort.


Energy & performance comparison: GPU mining vs playing HD Video

Using a GPU to mine Bitcoins would use a lot more power than watching HD video, since while the video decoder would only use the processing power it needed, a Bitcoin mine would use all of the power available to it.

I don't have any real numbers, but I think mining Bitcoins would be equivalent to, say, playing Far Cry 3 on the maximum settings, while watching HD video would be more like playing Fallout 3 on medium settings.


Is the Bisq API finally "live" now or what?

I tried asking about bisq API on twitter and its a work in progress:
https://twitter.com/bisq_network/status/1324367096524890114
https://github.com/bisq-network/bisq/issues/4257


Verification time: some exchanges take too much time for verification
Verification versus / not verification: some exchanges need verification and others not
Fees. In my opinion, you get the lowest fees on binance -> https://www.binance.com/?ref=16821839
Time: some exchanges take too much time to withdraw etc.
here's a guide to choose the best exchange (made by me) -> https://medium.com/@redqop89/trading-guide-for-bitcoin-ethereum-ripple-and-other-cryptocurrencies-6773ab4b6b2


Is it really necessary to indicate the age of the pieces used?

The "age" is shown only in Blockcypher's API. Transaction itself does not have such field

  Is there a way to reduce the size of the transaction script?

Yes. Use segwit


Would a reduced block generation time make the Finney attack more difficult?

Assuming all else is equal (same network hashrate, etc) then the attacker still represents the same percentage of the overall hashrate and therefore may claim the same percent of the blocks for his/her attack. While it's true that faster block time increases the total number of blocks, reduces the difficulty and makes it so that the attacker has more opportunities to land an attack with the same hashrate it also lowers the detection time for such an attack and narrows the window.

In the standard Bitcoin network, a block is found roughly every 10 minutes, but realistically they are found along normal distributions with their peaks at 10 minute intervals. A block may be found immediately after another block or it may take 20 minutes to find the next block, but these are not typical cases. I don't have data to show what one standard deviation from the 10 minute mark would be, but I can say that if block time were reduced such that the region of +/- 1 standard deviation overlapped slightly, an attacker would face a statistically significant risk of a block being found before he or she could execute the Finney attack. I have no idea what other effects this might have on the network, and it would require significant testing to confirm its feasibility.

Even if the +/- 1 SD region did not overlap, the distance between their boundaries is effectively the period of time an attacker has to execute an attack, so anything which narrows this gap reduces the effectiveness of a Finney attack.

The active question which I've still not found an answer to, is this: Does the value of σ² for the distribution of block finds change along with average block time or is it somewhat static? If σ² remains the same then decreasing the block time will drastically effect the ability of an attacker to utilize this method, but if it decreases proportionally to block time then the only effect block time has on such an attack is the added requirement of greater precision in timing.

Edit: I've received confirmation that block generation isn't a normal distribution but rather a Poisson distribution and that the time window for a Finney attack does scale linearly with block time. To this end, reduced block time provides no statistical advantages over normal block time, but it does still require an increase in precision on the part of the attacker. As I've not heard of anyone executing a Finney attack, even as a proof-of-concept it's questionable how much the precision requirement would help in preventing attacks, though the effectiveness of such is probably more dependent on the merchant/business model than on the network itself.


In this point, if Bob make a fraud transaction with Segwit, legacy
  node will accept, but it is not accepted in terms of fresh node. so,
  some group(legacy nodes) accept, other some groups(fresh nodes)
  doesn't accept. it means that proportion of fresh node should be
  bigger than proportion of legacy node. I think that this is really
  critical issue but current Bitcoin works well. we can say proportion
  of fresh node is bigger than legacy groups, but how it was achieved?
   when Segwit is appeared, at this time proportion of fresh node is
  maybe too small to overtake legacy groups.

Segwit did not just show up out of nowhere with no warning and no software to enforce it. Segwit capable software was released long before its activation, thus allowing for sufficient time for nodes to upgrade.

As with all previous soft forks, the activation time was determined well in advance (kind of). It wasn't scheduled (one soft fork  did have a scheduled activation), but rather required that miners signal readiness to enforce Segwit's rules before they would actually activate and be enforced by nodes on the network. This signalling was done by setting a particular bit in the block version number. 1916 out of a period of 2016 blocks must have the bit set in order for the rules to be activated.

Furthermore, even after the signalling threshold was reached, there would still be another 2016 block grace period where Segwit is "locked in" but not yet active. This is just a grace period for people who haven't upgraded yet to upgrade now that they know that the Segwit rules are going to activate. After the grace period, the rules will activate.

With even the fastest activation (everyone started signalling as soon as possible and the threshold is reached in  the first signalling period), there are ~4 weeks from time of "release" to activation  for people to upgrade. It is likely that there wouldn't be a majority, but at the very least, miners would have upgraded and enforced the rules (in the ideal case, but reality does say otherwise). And once the fork becomes "locked in", it can be expected that many more people will upgrade as they do see the importance of enforcing all rules in effect.

In addition to the time it would take for signalling and lock in, there is also the signalling start time. Miners could only begin signalling for segwit activation after a predetermined time. Any signalling before that time would be ignored. This start time was set to be a few weeks after the release of the first mainnet segwit capable software. Specifically, Bitcoin Core 0.13.1 was released on Oct. 27, 2016. The start time was defined to be Midnight Nov. 15, 2016 UTC. So there was almost 3 weeks between the release of the software and the beginning of the first signalling period. In total, ~7 weeks between the  release of the software and the first possible activation time. This is sufficient time  for many nodes to upgrade, and ideally, enough to protect the network.

Lastly, it is not expected for any soft fork to be deployed at the first possible activation period. They are expected to take a few months as miners are typically slow to upgrade (usually auditing software, upgrading their custom software, etc.). So in practice, by the time a soft fork does activate, many, if not most, nodes have upgraded.

This whole deployment mechanism can be (and is) used for many soft forks. It is described by BIP 9.

And then let's look at what actually happened with Segwit's activation. Segwit took 11 months from the release of 0.13.1 to be fully deployed. By that time, the vast majority of the network had upgraded to segwit capable software.

  Block size is physically 1MB. Regardless of the calculation rule is 'Weight' or 'Bytes', the transaction size is always same physically. Why some guys says that Segwit transaction is compact than traditional transaction? Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.

Blocks are physically larger than 1 MB. The "block size limit" has been removed and replaced with the weight limit. It is true that physically, Segwit transactions are about the same size as non-segwit ones.

The "more compact" stems from a confusion between physical data size, and data size used for computation of the previous block size limit. Under the block size limit byte computation, segwit transactions are more compact. But when computing the actual number of bytes transmitted over the network, they are about the same.


The Chain.com API offers functionality for returning OP_RETURN data by:

Address
TxID
Block height

The JSON return data from the REST API has a text field which is meant to be the decoded hex data sent (ie 6a``hex data) but it's returned in the format \\x``hex data.

In Python you can simply do this:

import __future__
import requests; from binascii import unhexlify
rdata = requests.get("https://api.chain.com/v2/bitcoin/addresses/%s/op-returns?api-key-id=DEMO-4a5e1e4" % "1Bj5UVzWQ84iBCUiy5eQ1NEfWfJ4a3yKG1") # substitute URL here
assert rdata.status_code == 200
jdata = rdata.json()
hexdata = [unhexlify(str(t["text"]).encode("utf-8"))) for t in jdata
print(hexdata)


How Bitcoin mining contributes to confirmations?

he is inputting any arbitrary values, in order to get a value that can be hashed into something with certain preceding zeros. When he got that value, he put that value into the blockchain and generate a new block.

It happens in reverse.
First the miner builds the new block itself. Then builds its header, then hashes that header. Also what the miner looks for is not preceding zeros, but instead is a number (hash result interpreted as integer) that is smaller than the target.

The steps are something like this:

Take 0 to max (to fill the block) number of transaction from mempool
Build the mandatory coinbase transaction
Build the hashMerkleRoot based on 1&2
Fill the block header fields: Version, hashPrevBlock and Bits are unchanging; hashMerkleRoot, Time and Nonce can change
Start a loop and change the variables on its iterations and hash the header.
Convert the result of the hash to an integer and compare it with the target.
Break out of the look and publish the result if hash <= target or if someone else were luckier and found and published the same block.

You can find more information in these links:
https://en.bitcoin.it/wiki/Block_hashing_algorithm
https://en.bitcoin.it/wiki/Proof_of_work

  Then how is this contributing, or say, relating to the confirmations?

Confirmation is when a transaction is included in a block that was found. 1 confirmation means the transaction is inside the last found block, any subsequent number shows the depth of the transaction compared to the block height of that time and is an indication of how hard it would be to perform a double spend.  https://en.bitcoin.it/wiki/Confirmation


The bitcoin client stores, in the wallet, the transactions that affect coins it manages. If it sees a new transaction, it checks to see if that transaction affects any accounts stored in the wallet. If so, the wallet is updated. Similarly, if the chain is reorganized, the wallet is updated.

However, the client doesn't check to make sure the wallet is synchronized to the current block chain. To fix this, the rescan command can be used. This causes the client, on startup, to go through every single block it has downloaded, search for transactions affecting accounts in the wallet, and update the wallet's transaction store and balances to reflect that transaction.

There are a few cases when you definitely need to rescan. For example:

If you restore a backed up wallet, it will be missing any transactions in blocks you downloaded after you backed up the wallet. Since the client won't receive those blocks (since it already has them) the normal wallet update logic won't fix this. You will need to rescan.

If you modify your wallet, say by adding keys to it or removing transactions from it, the wallet update logic won't see the transactions. So if you use a program other than the client to modify your wallet, you will need to rescan.

Theoretically, it shouldn't matter whether you download all the blocks and then rescan or vice-versa. The client won't download blocks while it's rescanning. And newly-downloaded blocks should update the wallet anyway. The logic is basically that this ensures the rescan process sees the blocks containing any missing transactions, rather than the regular block update logic. (They should both work. But if you need to rescan, we know something's wrong anyway.)


How to find what is suitable transaction fee to send 10 mBTC?

Bitcoin Fees is a useful site to see the current network status and pending transaction fees. According to that site as of now, a transaction fee of 4.11 - 4.20 mBTC/KB is required to clear within 1-12 blocks (i.e. within around 2 hours), 4.61+ to clear as soon as possible.


How does bitcoin handle extreme transaction volume?

Basically, transactions just sort of get put in a backlog until there is space enough for them to be processed. That's the usual case anyway.

The more extreme case is when there are too many transactions to even keep in the backlog. To understand what would happen here, you need to know a little bit about the software/people that put transactions into blocks: miners. Miners basically keep a priority queue of transactions, where the transaction priority is determined by the size (in bytes) and the fees it pays. Higher fees and lower size transactions tend to have higher priority. The software that miners run only has so much memory, so if so many transactions are broadcasted to the network that miners can't even keep up, they tend to just 'forget about' the transactions with the least priority.

For users, miners choosing higher priority transactions means that it may be harder for them to get their transaction included in a block. They either have to pay more fees or make smaller transactions to be able to compete.


Fees for Multisig Addreses Twice as High as Standard Address?

A single output is roughly 34 bytes per output regardless of whether the output represents a standard address or multisig address. Is this correct?

Yes, in modern Bitcoin transactions the size of producing an output (ie, paying to an address) is constant and has no relation to the size of the actual script. For native segwit outputs the size is somewhat larger (42 bytes) due to a safer hash function being used, but this is still unrelated to the size of the script.

In other words, the higher price for a MultiSig only matters when it's being used as the input of a transaction, not the output?

Yes, the cost of using a larger multisig transaction is born by the person who owns the keys, which makes sense economically. In the original transaction type of Bitcoin (P2PK) this was not the case, and the additional cost was born by the person sending money, which didn't make a great deal of sense economically.


Why most bitcoin wallet apps don't have Replace-by-fee feature?

Maybe this answer came a bit too late, but lets give it a try.
Let me start by citing A. Narayanan et alter Bitcoin and Cryptocurrency Technologies book:

Since 2013, there has been interest in changing the default policy to
replace-by-fee (RBF) whereby nodes will replace a pending transaction
in their pool if they hear a conflicting transaction which includes a
higher fee. This is the rational behavior for miners, at least in a
short-term sense, as it gives them a better fee.
However, replace-by-fee would make double-spending against zero-confirmation
attacks far easier in practice. Replace-by-fee has therefore attracted
controversy, both in terms of the technical question of whether it is
possible to prevent or deter double-spending in an RBF world, and the
philosophical question of whether Bitcoin should try to support
zero-confirmation as best it can, or abandon it.

So controversy is set between what can be more profitable for miners (i.e accepting transaction with higher fees), versus what may generate more transactions in the mempool and, moreover, could ease double-spending attacks against zero-confirmation transactions. That's probably why Electrum shows such a warning. Merchants could be unwilling to accept transactions that can be replaced if a greater fee is provided before the transaction has been included in a block.
In my humble opinion, it depends on whether your tool will be used for zero-confirmation transactions or not.
Moreover, if you are concerned about what nodes of the network will do when dealing with such a transaction, here you have a question that talks about the relaying policies of RBF.


The blockchain (at least as far as Bitcoin goes) is a series of transactions, collected in blocks.

This data is stored on each and every full node (pruning aside). There is no cloud based storage as part of the bitcoin network, although third parties host various forms of parsed data in the form of explorers and other such products, some of which may use cloud storage (assuming by "cloud" you are referring to AWS/GCP/similar offerings).

The bitcoin network itself is self sufficient and requires no third party resources. When a new node joins the network, it simply downloads the historical data from other, existing nodes. There is no need for any other form of storage.


Millisatoshi's are the unit in which channel balances are accounted for. They are a necessary accounting unit, if the aim is to enable very small lightning payments amounts, which represents a protocol design choice. If I wish to send, let's say, 1 satoshi on lightning, the routing fee should necessarily be denominated in a sub-satoshi unit, or else fees could only be 1 or 0 satoshis.

However, there is a difference between accounting for and actually delivering this balance on the Bitcoin blockchain. Two nodes may negotiate a balance in millisatoshi's, but the signed commitment transactions cannot actually deliver this balance, only to the closest Sat value.

Millisatoshis are not captured in HTLC's of commitment transactions, since these are denominated in sat's. So in the case of a unilateral channel close, the delivered balance will differ from the one negotiated between two lightning peers. A collaborative channel close can also not deliver a balance denominated in fractional Sats.

Therefore, millisatoshi's are a real accounting unit, which enables very small lightning payments (and even smaller fee capture along the way), whilst trading off deliverable balance accuracy during channel closing (The rounding can go both ways).

There is no trust involved, it is clear to each participant independently what the channel balance is (mSat), and how much of the balance is deliverable(Sat) in the Blockchain during any Channel state.


I think your misunderstanding is in the assumption that the genesis block must be a block.

There is no need for that.

For all we care the genesis block is just a specific hash that is used as hashPrevBlock to identify block number 1. It doesn't actually need to correspond to an actual block. Modern Bitcoin software doesn't actually treat the genesis as a block at all. It's just a piece of data - and its hash is special.

So, no, there is no need for a genesis block. But there is a need for a genesis something - just to identify what the first real block is.


Would nine 1MB transactions potentially create havoc on the BitcoinCash network

No, the hard fork also brought new opcodes. Transactions using those new opcodes have already been made, which caused the chains to become separated. If the only change were a block size limit increase, the developers would (?) put a consensus rule that says "The size of the first block after the fork must be bigger than 8 MB.", similar to Bitcoin Cash's first block, after forking the Bitcoin blockchain. "...must be bigger than 1 MB..."

Trivia: Rawpool continued to mine for the old blockchain for one day. More information


In general terms, "hot" wallets store both the wallet address(es) and the private key(s) on a network-connected machine, readily accessible so you can spend your balance any time, with very little effort (and lower security).
Meanwhile, "cold" wallets store your private key(s) in an isolated "hardware wallet," on external storage media (which is a lot less secure, and I would consider a "warm" wallet), or on a piece of paper (search "bitcoin paper wallet"). In this way, the funds are "frozen," because no internet-connected device has the private key. This gives you great security, but is less convenient because you have to transfer the private key to a connected device (or use a connected device to send transaction info to a hardware wallet for off-network signing) before you can spend your balance.
As for "warm" wallets, I've seen descriptions of putting private keys in a separate HDD partition, or an encrypted archive file as "warm" wallets.


How to setup Antminer D3 to solo mine to CANN wallet

Try:(Change IP 192.168.1.147 to your and try same PC wallet and miner)

cannabiscoin.conf

server=1
listen=1
rpcuser=cannabisuser
rpcpassword=cannabispass
rpcport=39347
rpcallowip=192.168.1.147
addnode=seed.cannabiscoin.net
addnode=seed2.cannabiscoin.net
addnode=seed3.cannabiscoin.net
addnode=seed4.cannabiscoin.net
addnode=seed5.cannabiscoin.net
addnode=seed6.cannabiscoin.net
addnode=106.70.242.145
addnode=108.61.10.90
addnode=115.28.42.60
addnode=136.243.217.171
addnode=137.74.104.135
addnode=144.76.237.39
addnode=148.251.8.18
addnode=162.255.117.105
addnode=171.232.8.87
addnode=178.12.190.117
addnode=178.15.70.226
addnode=188.60.110.76
addnode=192.99.200.144
addnode=194.135.90.175
addnode=198.27.68.86
addnode=205.251.171.136
addnode=207.171.249.66
addnode=209.188.18.52
addnode=213.32.6.132
addnode=213.55.176.213
addnode=27.3.20.109
addnode=40.141.98.2
addnode=45.48.182.104
addnode=65.31.179.140
addnode=78.251.112.84
addnode=85.214.23.49
addnode=88.10.240.5
addnode=89.204.137.211
addnode=93.87.143.138

sgminer  https://github.com/sgminer-dev/sgminer

sgminer -o http://192.168.1.147:39347 -u cannabisuser -p cannabispass -I 13 -g 2 -w 256 --lookup-gap 2 --shaders 2048

cpuminer  https://github.com/tpruvot/cpuminer-multi/releases

cpuminer-gw64-core2 -o http://192.168.1.147:39347 -u cannabisuser -p cannabispass
pause


What does "prev_out" and "n" mean in blockchain.info's API data?

A transaction consists of a number of inputs and a number of outputs. Outputs define a script that need to be executed to be able to spend the coins in the output. Inputs provide data to enter into an output script to make it execute successfully and to spend the coins in it.

So, a transaction input must be able to reference the output it is willing to spend. Outputs in a transaction are ordered, so an output can be referred to by specifying the transaction ID of the transaction it has been defined in, and the index it has in the list of specified outputs in that transaction.

The prev_out field is the transaction hash (txid) and the n is the index of the output.

It's not true that every transaction contains exactly one prev_out value. However, many transactions do. This is because many transactions have only one input. You must know, though, that it is possible to have multiple inputs.


Detailed guide on how to Create a Litecoin Fork, With Pre-mine instructions

Off the top of my head:

You need a new genesis block.
You need a different address byte (e.g. bitcoin uses 0).
You need to change the default port and rpc port.
You need a way for clients to find one another. You can run a DNS seed.
You need to change the "backup client list" which is a bunch of 32 bit integers which represent IP addresses.
You need somebody to mine initially, because otherwise transactions won't confirm.
You need to alter the default datadir directory.
You need to change the magic number in the protocol header, otherwise your client might connect to the Litecoin network by accident, wasting bandwidth.
You need to change the alert keys, otherwise the Litecoin devs can send alerts onto your network.
Add a transaction to the UTXDB which is your premine transaction

That's all I can think of, though obviously you'd want to change GUI elements to the actual name of your currency.


Can someone confirm that my GPUs are working correctly?

Right next to HW is the number of hardware errors you are seeing.  This is an indicator that your intensity is set too high. Decrease your intensity until you stop seeing hardware errors. I usually use this link as a starting point for my configurations: https://litecoin.info/Mining_hardware_comparison


What Bitcoin Securities / Stock exchanges are around?

*UNFORTUNATELY THIS IS ALL OUTDATED NOW, SORRY*

BTC Trading Corp. - https://btct.co

Pros: good notifications in email, good analysis of your positions

Cons: always in development, weird UI when new features are added, 24 hour withdrawal limits, but you can request larger amounts but it is delayed a few hours as the admin has to move the bitcoins from cold storage

BitFunder - https://bitfunder.com

Pros: looks more advanced than BTC Trading Corp

Cons: stock prices are typically lower there on cross-listed securities, no email notifications when anything happens, lame we-exchange thing

Havelock Investments - https://havelockinvestments.com

Pros/Cons: Best UI UX, Canada.

MPEx - http://mpex.co

Pros/Cons: Run by a multiple personality lunatic.

Cons: Admission/Listing fees, I forget. Nonexistent UI


state of 'atomic cross-chain trading' in 2016

Interledger's protocol is not atomic swaps. Their model is not entirely trustless either.
There are actionable implementations like MercuryEx but not used because:
a. transaction malleability fix is required
b. discovery problems in a decentralized system


What is the name of the procedure of downloading and checking the ledger for a new node?

The state a full node is in while it is aware it is significantly behind the rest of the network is called initial block download, or IBD. Being in IBD makes the node make different tradeoffs, like preferring bandwidth over latency, and more aggressively batching operations.

While downloading blocks, getting a node closer to the most-work chain tip, block validation happens. This includes sanity checking the received data, verifying its difficulty and proof of work claims, checking that all coins spent by its transaction inputs exist and haven't been spent already, verifying the scripts and ECDSA signatures, and marking the inputs as spent and remembering the outputs created as being available for spending.

The whole process of learning and downloading and validating new blocks to get to the same knowledge other nodes have is called synchronization.


Outputs with 0 value are allowed by the protocol. It is a feature that allows for provably unspendable outputs to not have to have any value that then becomes burned. However 0 value outputs are not limited to just provably unspendable outputs, so transactions like the one that you have found are possible. It is also possible to spend those 0 value outputs, but this ends up just wasting money because there is a non-zero fee cost to spending them.


How to search for an address in last block?

If you have txindex enabled and are using a Linux, debian-based machine, install jq: sudo apt install jq
and save this script somewhere as "any-name.sh":
#!/bin/bash

BLOCK_HASH=$(bitcoin-cli getbestblockhash)
BLOCK_TEMPFILE=bestblock.json
VIN_TXNS_TEMPFILE=vin_txns.temp
VIN_N_TEMPFILE=vin_n.temp

# Check if all temp files and addresses file exists, and delete them if they do before recreating them.
if [ -f "${VIN_TXNS_TEMPFILE}" ]; then
  rm ${VIN_TXNS_TEMPFILE}
fi

if [ -f "${VIN_N_TEMPFILE}" ]; then
  rm ${VIN_N_TEMPFILE}
fi

if [ -f "${BLOCK_TEMPFILE}" ]; then
  rm ${BLOCK_TEMPFILE}
fi

# Get the block information in JSON format
bitcoin-cli getblock ${BLOCK_HASH} 2 > ${BLOCK_TEMPFILE}

# Get the block height for use in address file name
BLOCK_HEIGHT=$(jq ".height" ${BLOCK_TEMPFILE})

# Check if the address file exists. If so, we do not need to run the script again.
ADDRESSES_FILE="Block_${BLOCK_HEIGHT}_Addresses.txt"
if [ -f "${ADDRESSES_FILE}" ]; then
  rm ${BLOCK_TEMPFILE}
  exit 0
fi
touch ${ADDRESSES_FILE}
touch ${VIN_TXNS_TEMPFILE}
touch ${VIN_N_TEMPFILE}
touch ${BLOCK_TEMPFILE}

# Get the block transaction ID's, excluding the first transaction (coinbase)
jq ".tx[].vin[].txid" ${BLOCK_TEMPFILE} > ${VIN_TXNS_TEMPFILE}
tail -n +2 "${VIN_TXNS_TEMPFILE}" > "${VIN_TXNS_TEMPFILE}.temp" && mv "${VIN_TXNS_TEMPFILE}.temp" "${VIN_TXNS_TEMPFILE}"
sed -i 's/"//g' ${VIN_TXNS_TEMPFILE}

# Get the block transaction n's, excluding the first transaction (coinbase)
jq ".tx[].vin[].vout" ${BLOCK_TEMPFILE} > ${VIN_N_TEMPFILE}
tail -n +2 "${VIN_N_TEMPFILE}" > "${VIN_N_TEMPFILE}.temp" && mv "${VIN_N_TEMPFILE}.temp" "${VIN_N_TEMPFILE}"
readarray -t n_vals < ${VIN_N_TEMPFILE}

# Delete the vin n tempfile
rm ${VIN_N_TEMPFILE}

# Get the block txout addresses
jq ".tx[].vout[].scriptPubKey.addresses | .[]?" ${BLOCK_TEMPFILE} > ${ADDRESSES_FILE}

# Delete the block tempfile
rm ${BLOCK_TEMPFILE}

# Get each transaction's vout addresses
i=0
while read line; do
  val=${n_vals[${i}]}
  echo $(bitcoin-cli getrawtransaction "$line" true) | jq ".vout[${val}].scriptPubKey.addresses | .[]?" >> ${ADDRESSES_FILE}
  let "i=i+1"
done < ${VIN_TXNS_TEMPFILE}

# Delete transaction IDs tempfile
rm ${VIN_TXNS_TEMPFILE}

sed -i 's/"//g' ${ADDRESSES_FILE}
awk '!a[$0]++' ${ADDRESSES_FILE} > "${ADDRESSES_FILE}.temp" && mv "${ADDRESSES_FILE}.temp" "${ADDRESSES_FILE}"

Make the script executable: chmod +x any-name.sh
then you can run the script with ./any-name.sh . Keep in mind that this script takes several minutes to complete. I run a node on a raspberry pi 3b, and this script takes ~4 minutes to complete.
Script explanation:
The vins from the most recent block contain a transaction ID as well as the vout index from that transaction that's being spent. We can use the command bitcoin-cli getrawtransaction <transactionhash> true to print JSON information from the transaction as long as we have txindex enabled. This information includes, most importantly for us, the address that is being spent (and "null" if the address being spent is not a standard address type). So for each vin in the block, we find the relevant transaction, and get the address at the specified vout index.


How do cryptocurrency exchanges like Mintpal manage so many?

As there are 100s of crypto coins each with their own QT-client, how do exchanges manage >the transactions?

From what I have seen and what I understand, each exchange running on a website like cryptsy or mintpal is its own process. Each "exchange server" is a program running on the website's server. Because each coin's protocol necessitates its own wallet, they just have to have a lot of servers. The way lots of servers are banded together to handle a lot of requests is a complex science, and a lot of it is proprietary because businesses invest a lot in it.

  QT-Client

Using a qt client in a server is rather inefficient, because there is not much need for a graphical interface. Using such a client is just unnecessary extra overhead. These websites can save a lot of money by optimizing server programs, which in turn allows for less server use, and less necessary investment in hardware.

  Do they use the core client of every altcoin in the servers or will they be programming code to do that?

The most efficient solution for running a crypto transaction would be the barebones command line, as it has minimal overhead. It just takes requests and sends them through the network. This is easiest to do with just the core client, although all bitcoin clients have the core client in them. Next, sending through transactions would require a server side program, that would do the exchange math, and then send the proper funds to the proper wallets. This part would be custom coded. Peatio is not highly prevalent yet, and there isn't other "exchange software," so exchanges do write exchange software themselves.

  If coding is done, which platform or language is secure?

Server side coding does not affect security because it stays on the side of the exchange. Server side security precautions like encrypting important data aren't really affected by platform. As long as the platform can encrypt connections and keep data safe, it's a secure platform. I realize that's kind of a blow off answer, but almost every server platform is made to be secure enough to run these types of things, and so are the coding languages.


I can pay invoices on my mainnet LND node, but others cannot pay my invoices

I did not have any incoming connections with enough liquidity. I got some and it is working now.


I started down the same path as you with my Macbook Pro early-2011 model, and got the same error. My model includes the Intel HD Graphics 3000, and there are no Intel-based OpenCL drivers for it. When I did enable a miner on the Core i7 CPU alone, I got 1.8Mh/s using the CPU, which is poor.

AFAICT, even if you have an OpenCL-compatible Intel GPU, (the Core i5 and i7 are OpenCL compatible on Windows, and Xeon and Xeon Phi on Linux) I've read nowhere that states it's even possible to "GPU mine" with it, either Linux/Windows/Mac... I may be wrong :)

If you have an earlier Macbook Pro, a model that includes an NVIDIA GPU, like the GeForce 650M or 9600M GT, you may have some luck getting OpenCL to work. You can try reading the How to Run Bitcoin Miner on Mac OS X guide, but even if it works you'll only get 3.8Mh/s (still not very good).

In short, unless you can get at least 300Mh/s, like from an AMD GPU, it's probably not worth the cost in electricity.


How to put QR Code whenever I generate a unique address? block.io API

The address validation script is actually from RosettaCode https://rosettacode.org/wiki/Bitcoin/address_validation#PHP

All you need to do is create the new address and then put the address in a QR Code. You could use the Google Charts API

<?php
 require_once("block_io.php");

$block_io = new BlockIo($apiKey, $pin, $version);
$createAddress = $block_io->get_new_address();
$address = $createAddress->data->address;
?>

This is your new address:

<img src="http://chart.googleapis.com/chart?chs=125x125&cht=qr&chl=<?php echo $address; ?>">


Is it possible that a virus could be included in the block chain or even spread out to computers as miners are trying to mine?

Ideally it is safe, the data transferred in bitcoin protocol is never meant to be executed. However:

The transactions themself are programs. While they are limited and cannot directly affect your computer, they can be just very computationally expensive, DoSing your PC. This attack is impossible now and in foreseeable future, since any non-standard transaction will not be evaluated.
Not virus, but it is possible to include arbitrary text messages inside blockchain. Therefore, one can include something that is illegal in some jurisdiction, potentially making bitcoin illegal as well, since blockchain can not be retroactively redacted. However, it is dubious whether such trick will actually work (1, 2). But there was some commotion about including catholic prayers in block headers.
There might be some bugs in bitcoin software (be it client or miner), just like in any other software. For example, it is possible to crash a computer by sending specially formed ping or execute code by sending packets to a closed network port. This applies to all software and is not bitcoin-specific.


For now you can request a private sale at a good rate by emailing Bitstamp customer service or directly Nejc Kodrič  (nejc dot kodric at bitstamp.net)


How does a client know it is connected to the right P2P network?

There's a list of hardcoded blocks in the bitcoin client: https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp

However, you present an entirely valid attack. If I can control one DNS seed and DDOS the others, I could cause new clients to only connect to my network.


View recovered wallet.dat contents without sync?

1.) no, you need to have at least the transactions up to the point in time, where you stored the wallet.dat file. Without sync there is no blockchain, then there is no data, from which core can read the amount.

2.) no. without blockchain data, there is no "database" to collect the amounts for the address.

There might be a work around for you: try to extract the bitcoin address from the wallet (or the bitcoin app shows you the address), and enter it into blockchain.info. They have a blockchain and the web-api, and can show all amounts, that were collected on a bitcoin address.


How to push a raw transaction using BitcoinJS (and Request)?

Body must be a string.

You can use form instead of body.

Reference:
https://www.npmjs.com/package/request#forms


How many transactions are there in one block

When a transaction is made, miners compete to validate it and create a hash.

Miners will compete to confirm the transaction in a block. 'Validation' of a transaction is completed by each and every full node on the network. Notice the difference between confirmation and validation:
Validation checks to see if the transaction is valid according to the network rules.
Confirmation involves having a valid transaction included in a block that is a part of the longest (most-work) chain.

If one miner creates the hash and more than 51% of miners agree on the validity.

As with transactions, a block is either valid, or invalid, and this fact does not depend on what other miners have decided. Full nodes perform this validity check, while miners just keep adding more blocks to the chain.

)When a block is added it contains one transaction that is validated or more?

Miners can choose whichever valid transactions they would like to include, up to the 'weight limit' of 4,000 kilo-weight-units. In practice, this generally means the block can be anywhere from a few hundred bytes, to 4 MB. These transactions are chosen prior to finding the valid hash, which means that once a valid block has been found, the transactional content of that block is locked in; the miner cannot add or remove transactions without invalidating the block.


Do bitcoin pay accelerators actually work?

Some transaction accelerators work, while others are probably scam .

You can check out Bitcointalk.org->Economy->Marketplace->Sevices.
Some members there offer FREE acceleration services, and have access to a variety of pools.
However, be aware if you decide to go for the PAID services, don't fall for the scammy ones.


what programming languages are used to built bitcoin?

The reference implementation, Bitcoin Core, is written primarily in C++, with various resource files and scripts in other languages.

Another implementation, mainly used in lightweight clients like MultiBit and Bitcoin Wallet (Android), is bitcoinj. It is written in Java.


Signature on transactions with multiple inputs

In short words: yes, if you want to redeem two previous outputs in one transaction - you should sign twice.
The steps for creating such transaction are:

create "template" of transaction for redeeming first output
hash it. this will be digest1.
sign the digest1 with your privkey1. this will be signature1
create "template" of transaction for redeeming second output
hash it. this will be digest2 (not equal to digest1 !)
sign the digest2 with your privkey2. this will be signature2
create the transaction itself with {pubkey1, signature1, pubkey2, signature2}

note: steps 1,2,3 can be made by Alice who has privkey1. steps 4,5,6 can be made by another person, say Bob who holds privkey2. step 7 can be made by everyone


Is there a list of core Bitcoin committers?

Here is a list of people who have had commit access to Bitcoin Core. This list can also be found on Bitcointalk and on Reddit (it's the same list just in two different places). All lists are kept up to date and in sync.
This list contains the names and usernames of everyone who I can find evidence for ever having commit access to Bitcoin Core, the dates during which they had commit access, sources for all of this information, and reasoning for the access. Those who currently have commit access are in bold.

Satoshi Nakamoto (satoshi, s_nakamoto): 1/3/09 - 9/13/11^[1] Creator, first Lead Maintainer
Martii Malmi (Sirius, sirius_m): 8/30/09 - 9/13/11^[1][2]    Creator of first SVN repo
Laszlo (laszloh) 8/4/10 - 9/13/11^[1]    Original OSX Builds and support
Gavin Andresen (gavinandresen): 10/11/10 - 5/2/16^[3]    Frequent contributor; later Lead Maintainer
Chris Moore (dooglus): 1/21/11 - 3/31/11    Frequent contributor for some time; Still contributes occasionally
Pieter Wuille (sipa): 5/1/11 - present    Frequent contributor
Jeff Garzik (jgarzik): 5/6/11 - July/Aug 2016^[4]   Frequent Contributor
Wladimir J, van der Laan (laanwj, wumpus): 6/5/11 - present^[5]    Frequent contributor; later Lead Maintainer
Nils Schneider (tcatm): 9/19/11 - 5/31/12    Frequent contributor for some time
Greg Maxwell (gmaxwell): 2/11/12 - 12/17/15    Frequent contributor; Gave up commit access due to toxicity and drama from the community
Jonas Schnelli (jonasschnelli): 11/13/15 - present^[6]    Frequent contributor; given access after becoming GUI Maintainer
Marco Falke (MarcoFalke): 4/13/16 - present^[7]    Frequent Contributor; given access after becoming QA/Testing Maintainer
Samuel Dobson (MeshCollider): 12/6/18 - present^[8]    Frequent Contributor: given access after volunteering to be the Wallet Maintainer
Michael Ford (fanquake): 6/8/19 - present^[9]    Frequent Contributor; given access after being nominated by several other frequent contributors and maintainers to become a maintainer.

Footnotes:

[1] The move to Github occurred before the last SourceForge commit, but the last SourceForge commit declares sourceforge as dead. Presumably those who only committed to SourceForge no longer had commit access after the move
[2] Sirius was the one who created the original SVN repo on SourceForge.
[3] gavinandresen was the Lead Maintainer from 2/23/11 until 4/7/14
[4] I was informed via IRC PM by some of the Core devs that jgarzik was removed around August 2016 after he had been inactive for several months.
[5] laanwj is the current Lead Maintainer. After participating in that role for a long time, he was officially given the position by gavinandresen on 4/7/14
[6] jonasschnelli is currently the GUI Maintainer. After participating in that role for a long time, he was officially given the position by laanwj on 11/13/15
[7] MarcoFalke is currently the QA/Testing Maintainer. After participating in that role for a long time, he was officially given the position by laanwj on 4/13/16
[8] MeshCollider is currently the Wallet Maintainer. He had been contributing for a while, particularly to wallet related things. When laanwj asked if anyone would like to be the role of Wallet Maintainer, MeshCollider volunteered.
[9] fanquake is currently the Build System Maintainer as well as a general maintainer. He had been contributing for a while, particularly with updating dependency versions and build system related things. He also had been doing a lot of janitorial things in the repo such as tagging issues, closing old issues and PRs, nominating things to be merged, etc. At the CoreDev event in Amsterdam which several maintainers and contributors attended, he was nominated to be a maintainer by the entire group.

Other Notes:

Dates are Month/Day/year
There may be people missing and dates may be slightly incorrect. These are all that I can determine by looking at old emails and the commit history. Please let me know if anything is incorrect
The start date is determined by the first merge commit made by that person. The end date is determined by the date of the last merge commit made by that person or other announcements of commit access revocation.

After scrolling through nearly the entire git merges history, I have found a couple of interesting things.
Satoshi did not use a Version Control System originally. The releases and source code were originally in a rar file that was uploaded to bitcoin.org. Sirius had to setup the original SVN repository on SourceForge for him. This was then later migrated to GitHub by gavinandresen. Originally patches were authored by developers and then emailed to Satoshi, Sirius, or gavinandresen who then committed the changes to the source tree with the commit message containing the attribution, but not the actual commit itself.
Another interesting fact is that the giving out of commit access has become more strict. It is now a privilege held by those given maintainer positions and those whose privilege was grandfathered in (i.e. they had it previously and kept it). Previously it was simply given out to those who contributed frequently and revoked after they stopped contributing. This appears to be no longer the case, although there are still multiple people who can commit to the repository so that there is not any reliance on one person. The maintainers are still given to frequent contributors as the maintainers are frequent contributors to the set of functionality for which they are maintainers of. They received the positions because of frequent contributions to those functionalities.
Lastly, I could not find any evidence for Satoshi ever publicly announcing that gavinandresen was to be the Lead Maintainer after him. It seems that Gavin was already a frequent contributor and already had commit access for a while before Satoshi disappeared. After Satoshi disappeared and Sirius stopped contributing as much, gavinandresen simply took over the role as lead maintainer as he was the only frequent contributor with commit access.


Altcoin (Litecoin fork) creation. No synchronisation

remove the chainTxData

chainTxData = ChainTxData{
    0,
    0,
    0
};

and make sure also that your first block is mined soon after the genesis time.


How to confirm that given bitcoin address is generated by given public key?

There is a step-by-step guide here and you can also test it on this site.

You can also use this python library.

import os
os.environ['CRYPTOTOOLS_NETWORK'] = 'test'

from btctools import PublicKey

>>> pub = Publickey.from_hex('yourpubkeyhere')
>>> pub.to_address('P2PKH')
'mp9CpH3h25m7FZqsPBf2UfU9Gm4u41j9Eg'


Why getrawtransaction returns an HTTP STATUS CODE 500 for not found transactions?

It should return HTTP status 500 if the transaction doesn't exist. 404 is just for method-does-not-exist errors. (See here.) Reading the code, I don't see how error 404 could be returned for a transaction not existing. (I checked the current code and 0.13.)

HTTP status codes are pretty non-specific. You should parse the JSON response if you want something more specific than 'an error happened.' (But it doesn't always return JSON. IIRC, 401 Authorization errors aren't JSON.)


How do Schnorr signatures impact coin selection and the utxo growth?

Yes, Schnorr signatures are generally slightly smaller than ECDSA signatures. This is due to their more efficient encoding that takes only 64 bytes instead of 72 bytes.
A comprehensive Coin Selection algorithm should therefore e.g. prefer an input with a Schnorr signature at high feerates and should prioritize using up non-Schnorr inputs at lower feerates to minimize costs.
In combination with the signature aggregation, we may generally see more consolidation and batching transactions, and may additionally see a market for creating multiparty transactions as combining multiple transactions will lowers overall cost.
I would expect the UTXO set to shift from old style UTXO to newer, more efficient formats over time, but whether the growth of the UTXO set would be impacted and how, is difficult to predict.


I have a stuck transaction (2 days already)

Your transaction is using a extremely low fee (0.0001 BTC for 226 bytes).
It might never confirm.

What you should try to do is double-spend your own transaction with a higher fee.
You just need to try to create a transaction with the same input: 61ef08eef99e74f9dd6037c6aff3b8b0703fd86371c259a6c4b6bfd2cd7eacf3/vout:1 and maybe the same output but a higher fee (less change).


How long should it take to synchronize with blockchain?

A half hour to sync two days is almost 100x faster than real-time.  It's slower than I would expect, but without more information it's not really possible to tell if there is anything that could be improved about your system or configuration.


How does one confirm if my dbcache setting has taken effect via the gui for bitcoin core 0.17?

When you run bitcoind you can see it popup on the loading screen. If it shows up here, it will be the same when you run the bitcoin-qt gui wallet too.


Does BTC-E have an API for alternate currencies?

The URL to the api's for other currencies are:

https://btc-e.com/api/2/1/ticker - BTC/USD
https://btc-e.com/api/2/2/ticker - IXC/BTC
https://btc-e.com/api/2/4/ticker - I0C/BTC
https://btc-e.com/api/2/5/ticker - SC/BTC
https://btc-e.com/api/2/6/ticker - SC/USD
https://btc-e.com/api/2/7/ticker - GG/BTC
https://btc-e.com/api/2/8/ticker - TBX/BTC
https://btc-e.com/api/2/9/ticker - FBX/BTC
https://btc-e.com/api/2/10/ticker - LTC/BTC
https://btc-e.com/api/2/11/ticker - RUC/BTC
https://btc-e.com/api/2/12/ticker - RUC/USD
https://btc-e.com/api/2/13/ticker - NMC/BTC
https://btc-e.com/api/2/14/ticker - LTC/USD
https://btc-e.com/api/2/15/ticker - CLC/BTC
https://btc-e.com/api/2/16/ticker - DVC/BTC

In the links below change the 1 to a number anywhere between 1-16 to match the category above.

Api for trades: https://btc-e.com/api/1/trades

Api for depth: https://btc-e.com/api/2/1/depth

Api for ticker: https://btc-e.com/api/2/1/ticker

By: dodoking


Yes for all your questions.

Suppose you don't encrypt wallet, if someone access your computer with unlocked bitcoin directory (such directory must be readable for running bitcoin) he can steal your BTC.

It might be better just to encrypt wallet and leave unencrypted directory. He can steal encrypted wallet.dat, which isn't useful.


By default it takes roughly 1 minute to send a transaction and once that is confirmed, it requires the 2nd party to make an approval transaction so thats another 1 minute. so roughly 2+ minutes which is what you have. Ardor would have the same timing aswell. Your stuck with the roughly 1 minute confirmations.


those block files are your copy of the blockchain. you could stop your new bitcoind daemon and move them into the $HOME/.bitcoin/blocks folder and restart bitcoind, and save yourself and the network the necessity to re-download them.


Recommendations for how or where to buy Bitcoin are generally off-topic here, but long-term storage is a fair question.

First, understand what owning Bitcoin really boils down to: having knowledge of the private key that allows you to spend the Bitcoin stored at that key's address. You aren't storing the bitcoins themselves persay, you just need to store the private key (a 256 bit number).

These days, there is an industry standard that is known as 'hierarchical deterministic (HD) wallets' (BIP32) that allows more efficient wallet backups, and there is also a related standard (BIP39) that allows you to create a mnemonic seed phrase that works as a human-readable master backup of your wallet. So rather than storing a single private key, you can opt to store a seed phrase instead. Since it is a standard, most wallet software is compatible.

Whether you are storing a private key, or a seed phrase, it is probably a good idea to make multiple copies, in case something unexpected happens (fire, theft, etc). By storing them in geographically diverse locations, you can avoid having a single point of failure. The medium of storage can be important too: just writing it down on a piece of paper isn't as permanent as stamping it into a piece of titanium. How involved a solution you choose will depend on your personal situation. Generally, I would recommend a physical storage solution for the length of time you've mentioned (10-20 years), as a digital storage solution may experience data degradation within that time.

One issue with the paragraph above is that if you create multiple copies, and one of them is found, then whoever finds it could spend your coins. So (as Raghav mentioned) BIP38 is a standard that will allow you to encrypt the key with a passphrase (note: BIP38 is less commonly implemented than BIP32/39, but it is still available). Keep in mind that now you will need to store the encrypted private key, and also the decryption passphrase, so this adds additional consideration.

There is also the option of using a multisig address, which can only be spent from if m-of-n keys are used. So you could, for example, create 3 keys, but only require 2 of them in order to spend the funds. If you disperse the keys geographically and one of them is found, the finder will not be able to spend your coins (as they'll still need one more key). You can create all sorts of interesting custody setups using multisig addresses, and there are even Bitcoin storage services that offer solutions using such constructions.

It is up to you as an individual to decide which sort of construction you are comfortable with, there really isn't a 'one-size-fits-all' when it comes to long term storage.

So a related question is: what is the best way to generate a private key (and its related address)?

Generally, you will want to use a device that you are certain is clean (not infected with any sort malware). A 'cold wallet' just refers to a wallet whose private keys have never existed on an internet connected device, thus removing many attack vectors by which someone could steal your private key(s). For high-security storage, it is definitely recommended that you generate keys on a machine that does not connect to the internet. This could just be a special-purpose laptop, or a hardware wallet, etc. Again, there is no 'perfect solution', what you choose will depend on your situation.


Virtual Currency wallets show as 'pending' until enough transactions have happened AFTER that one in the block chain.  It is a feature to prevent false sends and doubble spends of wallet to wallet transactions.  Not all wallets let you know how many more blocks need to come after to ensure the transaction is a valid one.  Time and patience will eventualy show that it is complete.  If it is still ' pending ' after 48 hours, contact the other party to see if there is an issue at their end.


They are files to assist reversing additions to the blockchain, handling reorganisations. They essentially contain the references needed to quickly reverse a block being accepted and it’s changes being made to the nodes UTXO. It does not contain transactions.


What are the February 20 changes to the Bitcoin protocol?

Really old versions of Bitcoin did not use checksums in network messages (Satoshi incorrectly assumed that the TCP checksum was sufficient). When Bitcoin was changed to start using its own checksums in network messages, version and verack messages could not be immediately updated to use checksums because old clients would be unable to understand checksum-protected messages from new clients and the network would split. Satoshi's solution was to keep using non-checksummed version and verack messages for two years and then have clients automatically start checksumming version/verack messages. At midnight UTC on February 20, this change will happen.

Versions of the official client later than 0.2.9 will apply the change automatically. Older versions will stop working. Existing connections will not be broken due to the change, so there should be very little disruption at the time of the change. It will probably only cause problems for alt clients and users with seriously-off clocks.


Build a wallet for Android and iOS for a self-made cryptocurrency

You first should learn how to create an android app if you don't know how to do that already. There are lots of resources available for this and better places to ask questions than the bitcoin stackexchange.

Then once you are comfortable with that most android wallets are built using bitcoinj. I don't know of any nice step-by-step guide. Here is a sample github project for bitcoin that should give you a good starting point. https://github.com/thinkmobiles/BitcoinJ-Wallet-Sample-Android. I don't know anything about your coin but you will obviously need to make some fairly critical changes.


As difficulty adjusts automatically, it is indeed possible to run a mostly functional network with the bare minimum hardware required for storage and networking.

Naturally, this network will have next to no protection against a 51% attack, as anyone with a faster computer (or computers) will easily be able to outdo your bare minimum hardware.

Running it would be as simple as setting up a new node with a miner, and making sure it doesn't connect to the existing network - an easy way for that would be to have a new genesis block. You can then mine on this network, and the difficulty will adjust itself so that you have a 10 minute block time.


Can casual people still mine for bitcoins, now that the difficulty is much higher than it was?

Well, you can TRY mining. To see how much coins you can expect, check your computer's GPU on the Wiki page, get its hash rate, and plug that into a profitability calculator, such as mine. This can give you an idea of how many coins can you expect to mine and whether you would get any profit from that.

Unfortunately, most likely you won't be able to mine at a profit using a PC. Bitcoin's difficulty is quite high, the reward will be dropping by half soon, and with the introduction of ASIC miners, GPU mining will be outclassed. However, if you are willing to invest some money into custom hardware, you can still start your career as a full-time Bitcoin miner. But again, you ought to check if it calculates for you.

However, if you want to try your luck at a newly emerging trend of using your GPUs to "mine" for split-key vanity addresses, you can check out my Vanity Pool, or its topic on BitcoinTalk. The process is quite similar, but the profit margin can be better.


How to get permission to edit in Bitcoin Wiki?

Currently, you can ask for permission at IRC channel #bitcoin-wiki on Freenode


How Bitcoin handles addresses collisions?

Both people would have access to any funds in the address. Whoever is first to spend these funds wins.

Of course, it is extremely unlikely that there will be such a collision.


What would stop some major company from blacklisting specific Bitcoins based on the "inputs" used and their "origins"?

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


Is it possible to get the network to accept a partially signed multisig transaction?

The network will only forward transactions that are valid. That is they only claim so far unclaimed outputs and contain all the necessary signature scripts. Your transaction does not contain valid signature scripts, hence it's not valid and will be dropped by the nodes in the network.


Bitcoin transaction fee is more than balance?

Bitcoin fees aren't set as a percentage of the amount being transferred, but based on the number of bytes needed to encode the transaction.  In principle you can set any fee that you want, but miners will choose the higher-fee transactions to confirm, and others may never be confirmed.  It can be a little tricky to get your money back in that case, depending on the software you are using, so some wallet providers (like blockchain.info) may not let you set a low fee.

According to https://bitcoinfees.earn.com/, the currently recommended fee level is around 0.00000016 BTC/byte.  At the current price of $6,663 USD/BTC, that's about US$0.001 per byte.  So if your transaction would need to be larger than about 2.5 KB, you can't afford to send it.

In particular, if you received your bitcoins in many small transactions, then in order to spend them, your outgoing transaction has to list all the previous transactions you are spending, with a signature for each one.  This requires about 180 bytes each.  So, did you receive more than about 12 transactions previously?  Or are you attempting to "split" your transaction to send coins to many different destination addresses?  That will also increase the transaction size.

There isn't very much you can do about this.  It's possible that transaction fees will be lower in the future, but since it's market-based nobody knows for sure.  Otherwise, you might as well assume those coins are unusable, and make sure in the future to receive coins in larger increments.


Electrum won't send bitcoin: ascii error

It is a bug, it was reported and fixed yesterday:
https://github.com/spesmilo/electrum/issues/1967

I will make a new release later today, that will include that fix.


How can I earn an income from my bitcoins without revealing my identity or relinquishing control of my bitcoins?

Bitcoins are a non-productive asset. Lending services earn revenue, because they lend out the coins they borrowed from you to someone else. They connect lenders and borrowers, take most of the risk and a cut. There is some risk involved, which is why there is revenue to be earned in the first place. Without you handing the coins into the service's custody as collateral, it's unclear how the service would make any money, so they would not have any reason to pay you. More traditional forms of credit usually require you to provide your identity and a list of your assets as collateral.
Unfortunately, there is no such thing as a free lunch. Nobody is going to give you something without you either providing value or taking a risk.


CPFP: Child Pays For Parent Clarification Needed

No, it's not a matter of sending to the same address multiple times, rather, CPFP works by spending the output of a previous transaction in a second transaction with a higher fee.

Example:

An unconfirmed transaction A with 500B size paid 20000 satoshis fee which corresponds to a fee rate of 40 satoshis per byte. The transaction has two outputs:

A:0 is signing over funds to the recipient
A:1 is signing the remainder back over to the sender

Let's say that the transaction is stuck because it would have needed a fee rate of 100 satoshis per byte to get selected into a block.

As the sender, you now create a second transaction B that uses the unconfirmed transaction A's change output A:1 as one of its inputs. Let's say that this second transaction B has 250B. To pay a fee rate of 100 sat/B for the second transaction, you'd specify a fee of 25,000 satoshis. But you also wanted to speed up the unconfirmed parent transaction! To do so, you add another 30000 satoshis, which brings the child transaction's fee up to 55000 satoshis.

This leaves the parent transaction A with a fee rate of 40 satoshis/byte, and the child transaction B with a fee rate of 220 satoshis/byte, but the two transactions in sum with 75,000 satoshis for 750 bytes of transactions, or a fee rate of 100 satoshis per byte. In order to get the juicy fee from the child transaction B, a miner has to also confirm transaction A as B is invalid if A is unconfirmed. They are thusly incentivized to include both A and B by the child paying for the parent.

Note that the recipient has the same option by creating an analogous CPFP transaction via spending A:0. (H/T Thalis K. for pointing this out in the comments)


Sending funds from a Segwit address to a non segwit

what happens if I try to transfer SegWit -> Non-SegWit or Non-SegWit -> SegWit

As long as you are using software that supports doing so, this is perfectly possible and fine to do.

  Will the funds be confirmed and get transfered or will it be lost forever?

Bitcoin can never be lost forever because of an unconfirmed transaction. For an unconfirmed transaction, the bitcoin do not move from their starting address until they are confirmed in a block. Eventually a transaction may be confirmed, or the network's nodes will remove the old unconfirmed transaction from their mempool's, and you will be able to spend the coins again. There are a few of ways to push unconfirmed transactions through, like replace-by-fee (RBF) or child-pays-for-parent (CPFP).


What does the mining difficulty number really mean?

(If I may repeat myself a bit...) Mining is like having a lot of people throwing weighted coins (such that 1 millionth of the time it comes up heads) and telling you when they hit a heads. If one such "heads" is reported every 10 minutes (600 seconds), you can make a very accurate estimation of how many times per second the coins are being flipped. In this example:

(1,000,000 flips/heads) / (600 seconds/heads) ~=
1,667 flips/second

The network difficulty is how you adjust this 1,000,000 figure so that the 600 figure stays consistent as the network's total hash power (1,667) changes.

To see real-world calculations of how the difficulty affects the coins discovered per time spent, see any mining profitability calculator, and change the "difficulty" figure. The Bitcoin wiki has details on difficulty, as well.

  I don't know what a hash is either.

When mining, your computer creates a block of data, which has a list of all of the transactions it knows about, includes a transaction that pays you the mining bonus, and then hashes that. If the hash happens to be a small enough number (as defined by the difficulty), the block is valid. If it's not, you increment a random number called a "nonce" that's in the block, so that the block has the same meaning but different data, and hashes the block again. Lather, rinse, repeat. (the nonce is included from the start, of course, but I didn't mention it to avoid being confusing)

The details of the block hash are explained in more detail at Bitcoin wiki's Block hashing algorithm.

Gigahashes per second, then, are how many billion times your hardware can do this hash per second.

If the pool you're in has 424 Th/s and you have 100 Gh/s, then you are about 1/4000th of your pool's total power. You can expect to be the one to solve about 1/4000th of the blocks (on average) that your pool finds.

(technical details intentionally omitted; those are available at my various links, and your link)


Found old Bitcoin wallet of mine, but has unconfirmed transactions from 2013

If they are outgoing transactions they will always appear regardless of how far behind the synchronization is. Any unconfirmed transactions will have long bounced back to your wallet by now. Try going on the command prompt (.cmd) on your computer and type in:

"C:\Program Files (x86)\Bitcoin\bitcoin-qt" --zapwallettxes=1

Or try:

"C:\Program Files\Bitcoin\bitcoin-qt" --zapwallettxes=1

Your bitcoin core wallet will re-scan and the bitcoins will show up on your wallet.

If they are incoming transactions that you are waiting for you will just have to leave the bitcoin core wallet open until it synchronizes to the date the bitcoins were received. This will probably take a few days.

Hope this helps...

James


In each iteration, you concatenate two subsequent hashes of the previous level, and double-sha256 them. If there is an odd number of hashes, concatenate the last element with itself.
This gives you a new list of hashes. Repeat, and stop when one hash remains. This is the merkle root.

Assume you have tx hashes Ha1,Ha2,Ha3,Ha4,Ha5,Ha6,Ha7

First iteration: Hb1=Hash(Ha1|Ha2), Hb2=Hash(Ha3|Ha4), Hb3=Hash(Ha5|Ha6), Hb4=Hash(Ha7|Ha7)
Second iteration: Hc1=Hash(Hb1|Hb2), Hc2=Hash(Hb3|Hb4)
Third iteration: Hd1=Hash(Hc1|Hc2) => Merkle root


Strongest vs Longest chain and orphaned blocks

The "longest" chain is the one with the most work. A chain's work is equal to the expected number of hashes it would take for someone to replicate a chain of the same number of blocks and the exact same difficulty steps. So currently each block adds about 266 work to the chain because it takes on average ~266 hashes to solve a block with the current difficulty. Blocks with less difficulty add less work. (The current total chain work is around 280.) However, two blocks in the same difficulty period always add the same amount of work to the chain. A block with a lower hash is not considered better than one with a higher hash.

Satoshi didn't initially realize that choosing the correct chain by just counting blocks allows for some extremely easy attacks. Version 0.1 just counted blocks. That's why the paper just says "longest". The idea of "chain work" was added a little later.

Resolving orphans as you suggest might actually make orphans more likely because miners would be incentivized in some cases to try replacing the most recent block rather than extending it, especially right before a big difficulty adjustment or when the most recent block contains a lot of fees.

Orphaned blocks happen every now and then. Eligius reports around 2% orphaned blocks. They would indeed be much more common if the target time was 1 minute since blocks would be generated faster and there would therefore be more opportunity for conflicts between blocks.


Stratum is not HTTP, it's a protocol designed directly on top of TCP.

You could use an existing load balancer that works on the TCP level, directing new TCP connection attempts to backend servers. After a client is connected it keeps talking to the same backend.

All Stratum work is related to one connection. Proofs of work from clients must be sent over the same connection where the work data was previously received. There can be no confusion about jobs, and there is no need to open more than one connection.

There's no need for the load balancer to look at individual stratum requests, or even to understand the stratum protocol. It might be an advantage for the load balancer to be able to tell a client to reconnect to get it over on a different backend, if the backend it is on is overloaded. In this case you'd need to create your own stratum load balancing software - you couldn't use a generic load balancer for this. I'm not sure if such a feature is really important though. Disconnecting a client is probably just as effective if you want it to reconnect to the same IP address anyway (the IP address of the load balancer).

Note that, assuming your mining server software is somewhat efficient, a single server would be able to run even the biggest mining pool today. So a setup like this is probably only useful for failover, not so much for balancing load.


Since all I need in order to send a transaction is the receiver
  address.

You also need a private key. In order to send someone coins from your wallet, you need a signed transaction with your private key.

  What is the mechanism (if any) that stops me to send transactions to
  someone BTC without his approval?

You don't need an approval of someone to send him transaction.


Will mining be viable after the halving?

The block subsidy, i.e. the amount of newly created bitcoins per block, will half. Transaction fees are not affected by the halving. The exchange price of Bitcoin is up to market mechanisms. The halving doesn't change the difficulty. So, yes, probably the value of the mining reward will drop significantly between block 419,999 and 420,000.
Mining already is infeasible at home.
Yes, you're making a mistake getting into Bitcoin mining.
Personally, I doubt that any altcoin will be successful.


how to transfer coin using bitcoin rest API

The list of json RPC commands is located on the wiki: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list

There is a list of json-rpc wrapper libraries on the blockchain wallet API page: https://blockchain.info/api/json_rpc_api

Pick a wrapper library for the environment you develop in and dive in.

To create a transaction, you're going to likely use "sendfrom" or "sendtoaddress".


The scriptSig part is first on stack, so there would be:

0 <Alice's signature> <Bob's signature> 0

and this for the payout into the CLTV branch:

0 <Alice/Bob's signature> <Lenny's signature> 1

After the sig part follows the pubkey script, with the first Opcode "IF". This "IF" verifies the value befor on the stack (which is "0" or "1" from the sciptSig before), and branches accordingly:

IF
   <now + 3 months> CHECKLOCKTIMEVERIFY DROP
   <Lenny's pubkey> CHECKSIGVERIFY
   1
ELSE
   2
ENDIF
<Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG

Assuming the first branch is chosen, then the last item in the if clause is a "1", followed by the line after "ENDIF", so this becomes a 1-of-2 multisig, where only one person needs to sign. But this person has then to wait for the time lock (via CSV parameter). Here in the example: Lenny can spend after timeout is reached.

If there is a "0" on the stack before the IF clause, then the second part is executed, and this becomes a "2-of-2" multisig, which means, Alice and Bob can spend anytime.

Et voilà - smart contracts easy :-)


When I specify wallet in bitcoin.conf for testnet3, it gets ignored

This is answered by Can't specify rpcport for testnet but it comes from an issue in the 0.17.XX change where options need to be specified by network type.


Dumpprivkey or dumpwallet won't show my private key for the address in my wallet

The problem was not a technical problem. More like stupidity.

The address I received the bitcoins to is not one of the addresses in the address book. The address book is like your contacts on your phone. Your actual addresses are under the receive coins tab.

So I saved someone else's address to my address book for whatever reason. Then I was trying to extract the private key of that address from my wallet which of course I could not.


What is the relationship between the Digital Signature and the Public Key

They are very different. If you look at their byte values, you will notice that they are different lengths and have different formats.

In essence, public keys are identifiers and signatures are cryptographic proofs.

A signature is produced by taking a private key and a message and performing a signature algorithm with those two pieces of data as inputs. For Bitcoin, we use the Elliptic Curve Digital Signature Algorithm (ECDSA). In Bitcoin, the message is a modified version of the spending transaction.

A public key is derived from a private key and can be broadcast publicly. It is used in the verification algorithm for ECDSA to verify that the private key for that public key was the one that produced a signature for a given message.

So the signature is a proof that the private key for the specified public key endorses are particular message. In Bitcoin, it means that the owner of the private key approves that spending transaction.

Additionally, signatures are generally one time things. They change with the message. You can also get two different signatures for the same message and private key combination. Those two signatures will still be valid and are valid independently. Conversely, public keys (and private keys) are permanent. They don't change unless you replace them.


How to remove a wallet from Android Bitcoin Wallet

Okay, so I think I misunderstood what this app is showing me.  A bitcoin wallet can (and often does) have multiple addresses (public+private keypairs).  What I was seeing in the app was not multiple wallets, but just multiple addresses.


Does bitcoind ERROR "Disk space is too low!" refer to RAM or actual harddrive?

It refers to actual disk space. RAM is memory, not storage. The term "disk space" is very specific.

  Then a while later this:

[2020-01-20T09:05:59Z Reindexing finished]

  But bitcoind continued grinding on... Well then what is all this? ::

Your node was not fully synced, so after it finished reindexing the blocks on disk, it continued to download blocks from its peers and finish syncing.


Your assessment is correct.

But think of it this way: to get a mortgage, you put up your house as collateral, where value(house)>value(mortgage). Same idea here.

Some response to your concern in their FAQ here

  Why would I borrow when I can just sell?

    There are a variety of reasons you may want to borrow and unlock the liquidity of your tokens rather than selling, some include:

    Borrowing Ether to participate in different ICOs,
     Purchasing other tokens from the exchange for different investment strategies without the need to sell tokens,
    Lending altcoins and tokens for short selling or hedging,
     Financing mining expansions,
     Finance for blockchain startups,
     Buying market dips.

    This list is expanded even further when we include USD Pegged Etheruem loans:

    Holding more ETH in a bullish market,
    Purchasing assets with $ while keeping your crypto portfolio safe,

    Future use-cases could include tokenisation of property, shares, intellectual property, and other physical objects (Cars, boats, power plants, art, etc)


What is criteria of mining priority except for transaction-fee?

The code you're looking for is in CreateNewBlock.

The usual way transactions are added to a block is by sorting by priority. The priority of an input is the value being spent in the input multiplied by the number of confirmations it has. The priority of a transaction is the sum of all the priorities of the inputs. See this line:

dPriority += (double)nValueIn * nConf;

Transactions are added to a vector of transaction priority:

vector<TxPriority> vecPriority;

Then they are sorted according to their priority:

TxPriorityCompare comparer(fSortedByFee);
std::make_heap(vecPriority.begin(), vecPriority.end(), comparer);

And one by one, transactions are verified to be valid and then added to the block, done by order of priority, higher priority first.:

while (!vecPriority.empty())
...
// Added
pblock->vtx.push_back(tx);


As a peer:

You can derive the approximate location (GeoIP for IPv4, latencies and allocations for IPv6) unless the node is operating as a hidden service.
You can query the node for it's version number.
You can query the node for current date and time.
You can query some of the nodes recent connections with the addr host discovery mechanism, giving you the IP address and the time the node last saw the peer.

As someone with universal access to a nodes connection:

You can see which transactions (and addresses) belong to a user.

That's about it really unless you want to start poking around for other services, such as a web server on port 80 which would give you a lot of information about the owner, but only if it exists. bitcoind is designed to leak as little information as possible.


How can I buy Bitcoins with Australian Dollars?

This question answers the more general question "How do you obtain Bitcoins?"  Most commonly, people use a Bitcoin exchange to exchange local currency for Bitcoins.

Here is a list of exchanges split by currency and whether they're currently active or not.


Take a look at Wasabi Wallet https://www.wasabiwallet.io/ it is a privacy focused wallet and comes with a built-in coinjoin feature.


How to properly use the rpc command `listunspent` with `bitcore-lib` to create a transaction and get the transaction hash?

First, you need to serialize the transaction:

let txSerialized = transaction.serialize(true);

Then you can broadcast it:

client.sendRawTransaction(txSerialized, (error, response) => { if (error) console.log(error); console.log(response); });


What stops miners from manipulating "target" difficulty in the block header?

The difficulty target in the block header has to match the currently required difficulty. This value is derived and checked by each node individually from the timestamps and difficulty statements of previous blocks. Then, the block hash of a new block has to adhere to this given difficulty target. If either of the two requirements is not met, other nodes will reject a block as invalid.
So, if a miner ignored either of the rules, they'd of course be able to do that, but then their blocks are simply not accepted by the Bitcoin network.


How much extra disk space does txindex=1 require?

The total extra size is around 7GB as of November 2016. You can check by looking at the size of the $DATADIR/blocks/index directory.
If you copy that directory, you'll copy the index with it.

Updated values from comments:

11GB as of 2017-05-08 – via
ens
21GB as of
2019-07-16 – via Vasil
Toshkov
27GB as of 2020-06-14. – via
Anonymous


Has anyone ported the Bitcoin software to plain C or Objective C?

There is a pure C99 bitcoin implementation called cbitcoin by MatthewLM, forum threads:

cbitcoin - Bitcoin implementation in C. Currently in development.
[ANN] cbitcoin 1.0 Alpha 3 Released.

but it is currently in alpha stage. One of its features is weak library dependency, e.g. it possible to implement cryptography using something other than OpenSSL. As far as I know there is no Objective C Bitcoin implementation.


I sent bitcoins to my wallet before it had synced. is there ANY way i can get my coins back?

As long as your wallet.dat file is uncorrupted/unstolen, your coins are fine. Try backing up the wallet.dat file, uninstalling Bitcoin, then reinstalling.


What is the Bitcoin spot price and how is it calculated?

Just like with other commodities, there can be multiple "spot price" numbers.

With gold, for instance, there can (and usually will) be different price on the Comex exchange versus the price the at the auctions in London for local delivery there.

So when referencing the spot price, that is ambiguous until the specific market whose prices will be used are clearly defined.

Even then there is the issue of the the bid/ask spread at any point in time.  Since there is no regulations defining how spot price is computed, there is ambiguity between whether the highest bid offer should be the spot price, or the lowest ask offer.  Others might consider the value from last trade as being the spot price.  Another approach is to find the value exactly in the middle of the bid and ask and deem that as the spot price.

BitPay uses an algorithm that attempts to be fair in determining "spot price" by using multiple exchanges:

https://bitpay.com/bitcoin-exchange-rates

And Coindesk provides a proprietary spot price service where "spot price" also is computed using data from multiple exchanges:

http://www.coindesk.com/price
http://www.coindesk.com/coindesk-launches-proprietary-bitcoin-price-index/


Where can I find more resources that explain Bitcoin simply?

I would suggest you reading Mastering bitcoin book first and second editions. It's exactly what you are looking for.

https://github.com/bitcoinbook/bitcoinbook

if you like watching more than reading this youtube videos are amazing


Because checking for compiler features, without Automake/CMake/Ninja/Bazel with only Makefile and C++ preprocessor is hard and unelegant.
And C++ preprocessor can't be used to make full-compile feature tests. If the compiler supports AVX256, a relatively new instruction set, that doesn't mean the assembler supports it too. There are "fail if can't compile completely"s in the autoconf file.


transferring bitcoin among friends and taxes

They will most likely see any BTC credit in your account as "income" and you are taxable for it, unless you can prove it otherwise. This is a matter of when the IRS will start cracking down on these exchanges and request them to provide a 1099 for every user. I do not do trading via fiat because of this. The end-game is to acquire more Bitcoins, not fiat.

When its time to sell your Bitcoin for fiat, you won't have to because everyone will be willing to take it. -- See this: http://imgur.com/gE8hDnY


Calculate transaction fee from getrawtransaction

No, there is not. That is how the transaction is set and calculated in the first place.


The solution for anyone else is to change the Ignition registry value for fUseProxy back to false, then relaunch the wallet. Search for it in regedit.


Pictures and non-transaction data in block chain

It is still possible to embed data into the blockchain, and it is actually fairly trivial. But don't do it. It is rude and detrimental to the network as it takes up resources to host your random data on all full nodes in the network. The polite way to do it is to create an OP_RETURN output, but that only allows up to 80 bytes of data. The impolite way is to just put your data into the output script since output scripts are not validated until they are spent. But that is impolite as the output is not provably unspendable (and thus can be pruned from the UTXO set) so it will take up full nodes' disk space and memory.


Is the wallet encrypted or not ?
If encrypted, then you will have some automatically generated exports of your private keys in the $HOME/MultiBit/multibit-data/key-backup directory. They are encrypted with your wallet password.

You can create a new wallet and import this file using Tools | Import private key.

There are also rolling backups (essentially old versions of your wallet) in the directory rolling-backup that you can open using File | Open wallet


How old do you need to be to buy bitcoins in a atm?

I know for age limits when buying alcohol, cigarets.....but for using ATM (normal usage or buying BTC)? Never heard for this....maybe you should first learn, how ic/is not BTC regulated in Spain (is it recognized as a curency, comodity ext...) and start from there?


How can there be multiple outputs with same address in the same transaction?

It definitely seems weird to have two outputs towards the same address, but if it was picked up by your bitcoind node, then miners will probably accept it, because they're also using bitcoind.

It would be interesting to read the raw scripts of the outputs. Most likely, as you say, it was created by someone using the raw commands.

One scenario that I could think for someone doing this is that you'd want the receiver to claim the outputs in separate transactions. If there was a single 0.3 output, the receiver would need to claim all 0.3 to use them.

However, I'm not sure when this would be useful.