There is nothing wrong with it. Just put the order up you want, and wait for it to execute. There are far worse things to do on the internet these days then filling the orderbook. Nobody will care, because most of the time it is outside the visible range (the orderbook pages from Kraken for example).


Do mining pools eliminate the need to store blockchain?

A mining pool does need to store the entire blockchain, however that doesn't mean that every participant of the mining pool needs to store it.  Someone in the pool needs it, but not everyone.

Individuals in a pool can just be sent block headers and perform the proof-of-work without ever verifying the transactions themselves.  This does not require the full blockchain.  However, someone should have already verified the transactions ahead of time, and this node does need the blockchain.


A transaction having a fee is not a consensus rule. Although the vast majority of nodes refuse to relay a 0 fee transaction, it is valid.

Such transactions can be included in a block by directly passing them to a miner, and would tend to belong to the miner themselves, or someone they have some kind of relation with.


How to handle incomplete blocks when reading blk*.dat files?

I'm going to answer my own question. These are my conclusions based on the comments from Nade Eldrege and eponymous.

Assumption 1: This is an 'incomplete block'

Yes, this is an incomplete block. More specifically, it is not part of the blk file format.

Assumption 2: This happens when a block can only be partially downloaded, or written to disk.

Yes, evidence strongly suggests that this happens when the bitcoind is interrupted / killed while writing to disk. If restarted, it just continues to download and write new blocks to the blk file. It doesn't clean up incomplete block.

Assumption 3: Deleting the affected blk files and re-downloading parts of the blockchain doesn't make sense, since this can be expected to happen again.

Yes and no. Yes, because deleting and re-downloading the blk files without interruptions solves the issue. When writing a blk-parser, however, it should be able to handle these incomplete blocks. For example, by skipping to the next valid block.

Assumption 4: The parser should be able to skip these blocks.

Yes. See #3

Assumption 5: The overall blk file is not missing actual data and is not corrupt.

I'm not sure, but since the bitcoind just continues with downloading blocks and works without any issues, one can assume that the incomplete block is just  re-downloaded afterwards.

Assumption 6: The 'incomplete block' will be downloaded and written again further down in the blk file (or to an other blk-file).

It seems so. See #5


The E7-4830v3 has 10 physical cores and 20MB of L3 cache. With two CPUs, you'd only have 20 physical cores and 40MB of L3. Since every thread is doing exactly the same thing, hyper-threading is virtually useless. It wouldn't help you anyway since you only have 2MiB per physical core and that's exactly what cryptonight requires.

So, short answer, with 40MB of L3 cache, you cannot run more than 20 instances of the cryptonight algorithm concurrently without dropping from L3 speed to RAM speed, which is a huge performance loss.

You can probably go higher than 10, but more than 20 is a non-starter.


Previous block hash on first Bitcoin block?

Found the solution, the command for the genesis block should be:

bx fetch-header -t 0


What benefit of Bitcoin (to governments) outweighs the cost of not being able to control the value of a fiat currency?

Using a foreign currency as legal tender can curb inflation and delimit deficit spending. It will also reduce friction for trade with other countries accepting the same currency.

In some cases the stability provided by using a foreign currency outweighs the benefits of controlling your own currency.
 [Wikipedia: Currency Substitution] lists for example
 ten countries that use the USD exclusively, as well as numerous other countries that do not maintain their own legal tender.


only getting 52khs on Litecoin mining with a Nvidia GTX670

You shoud instead use cudaminer for this. I use the same card and I have a mining rate of 150khash.

The reason why you get a low mining rate is because Nvidia cards use CUDA cores to do most of their calculation and most of the miners do not use them since the best graphic cards for mining are AMD cards (and they do not have CUDA cores).

I dont know where you saw that 112 000 Khash/s (mostly because you forgot to give the link) but I doubt that a single card could do that with litecoins (but its possible with Bitcoins).


Need a random seed for vanitygen; where can I obtain one?

It uses RAND_load_file function from OpenSSL, which accepts any binary input - random bytes. Under Linux and OSX the /dev/random file can be used, I don't know  equivalent under Windows. However, OpenSSL uses /dev/random by default, so there is no improvement using it explicitly.

Only scenario might be when you need faster random numbers generator, as /dev/random is quite slow and you start vanitygen very often. Then you can for example use /dev/urandom (but in this case you expose yourself to small but perhaps exploitable possibility that the seeds for generated addresses will be related). Certified hardware random numbers generators would be preferred in this case (some recent Intel and VIA CPUs have one).


The fee is optional; however, including your transaction in the next found Bitcoin block is also optional.

The miner who finds a block gets to decide which, if any, transactions are recorded with the block they found.

Factors that influence whether your transaction is included in that found block include:

The block size limit.  Sometimes the transactions are too large to all fit into the block, so most will prioritize higher fee transactions to be included first.
Local settings for the person finding the block can be set to ignore transactions with fees lower than an amount of their choosing.
Some people will include all the transactions they have seen, as long as they will all fit, but this is not the normal default mode of operating for miners.  If you do not include any fee, then this would be your only chance.


API Bitfinex question: "key amount should be a decimal string"?

You are submitting a float value. Float values are not totaly accurate:

>>> 0.9
0.90000000000000002

Thats why the specification requires a Decimal datatype:

>>> from decimal import Decimal
>>> Decimal("0.001")


Lightning network channel capacities and gambling site jackpot payouts

3 possible ways:

Obviously the house can open a new channel with the user but that takes time.
There is still a lightning network So even if you have a small direct channel with the house you might have some inbound capacity from other nodes and the house has some larger channels to the network. So you might not need a channel at all. The house could route the payment to you through the network even though it has a direct channel with you.
Lightning invoices also have a fallback address. The house can use this address to do an onchain tx if there is no route found.


What will be the price for BCC bitcoin cash on August 1st?

The initial price of BCC will be what the first buyer is willing to pay for it on an exchange. After that, it's simply a matter of demand and supply.

According to coinmarketcap.com, BCC futures are currently trading for $332. This is probably the best indication of what to expect once the market opens.


You did not specify any transaction id so we can't look into the transaction.

You can see however, that this bitcoin address has received bitcoins, and they have been spent again.

You can see the transactions of any bitcoin on a block explorer such as blocktrail:

https://www.blocktrail.com/BTC/address/18MJieFJcDiFbAsvSxe5iCaBAYsikgJta6


What is the signature digest for Segwit outputs

For signatures in P2WPKH and P2WSH spends, the sighash algorithm is described in BIP143.

It is very different from the one used in legacy spends.


Use (or modify to use) the Ledger to perform general key generation and signing?

Yes. The things that the Ledger support are not specific to cryptocurrencies. You can write applications for the Ledger that do other things, so long as the firmware supports the cryptographic operations that are necessary.

  : Buy a general-purpose keygen + signing device that supports crypto-currency signature methods?

Yes. The cryptocurrency stuff happens externally to the cryptography. You can write an application that offloads the cryptography to a general purpose keygen and signing device (usually HSMs) and handles the remaining cryptocurrency stuff (transaction construction, node, etc.) on a general purpose computer.

Hardware wallets are really generic HSMs (although the Trezor does not contain a secure element like Ledger Nano S's do) that have had specific cryptocurrency applications built into them. They can be used for general cryptography things too, you just need to write software for that, and possibly modify firmware.


How do we know that a certain hash below the target is even possible when mining?

For a given block header where the only variable is the nonce, it is trivial to brute force all nonce values and verify if any gives a hash that meets the target.
For the vast majority of block hashes, no nonce value will meet the target in normal difficulty settings (let alone at a target of 3).
Miners get around this by altering other values in the block header, such as the timestamp, block version, merkle root (via altering of the Coinbase transaction and/or set of included transactions).
By the balance of probability, you will eventually find one block header for some combination of the above that meets the target.
The difficulty levels control how likely it is for that block header to be found in ~10 minutes for a given hash rate.
The Bitcoin Wiki elaborates on how the calculation is actually performed to determine this difficulty, along with some example code.


Read only blockchain in bitcoind , patch ideas

I already did working prototype for one bitcoind (with one copy of blockchain) managing multiple wallets: https://bitcointalk.org/index.php?topic=71542.msg96212 It is IMHO easiest thing to to with current codebase and it would fulfill the goal to provide for multiple users' wallets independently while using resources for only one running bitcoind.

But the discussion around it died somehow, looks like nobody tried the prototype and I got only some private inquiries.


How would advancement in ASIC manufacturing process affect mining?

I would beg to disagree - we will see a similar effect when v2, v3, v4....vn rendentions of ASIC come around.  We will see 10X gains in Hashpower and roughly a 40% drop in power consumption.  This is all pure guesswork and speculation based on other responses I've seen and following the developments of KNC, BitFury, BFL, Avalon, and AsicMiner.

It could be said for that matter that we are already seeing the development of v2 hardware with the advancement of the 28 nm class of ASIC Chips.

There will likely be a cascading effect of shifting retired hardware onto other Alt-chains as difficulty increases on the other off color alt-coins such as PPC, FRC, and TRC.

Right now using cyrptocurrency as a medium of exchange is very new...the ecosystem to spend them does not yet exist...if perhaps other services such as internet providers, mobile phone providers, insurance carriers, and other recurring cost structures will willing to adopt btc as a medium of exchange we would see the increases in usage and thus value (price)

Smaller transistors both allow more transistors to be packed on each asic chip and also require less power overall to perform the same level of hashing compared to the larger obsolete transistor size.  I have read that underclocking allows power consumption to be reduced even further - it could be that these devices see between a 30 to 65% increase in GH rates as implied by the jump between Avalon to BFL to Bitfury to KNC.


How to upgrade a Trezor device without wallet.trezor.io?

It is possible to use the trezor command line client trezorctl available here to install a firmware you downloaded from trezor as described in the developer docs here.

BE SURE YOU HAVE A BACKUP OF YOUR SEED

"1) Pick version of firmware binary listed on https://wallet.trezor.io/data/firmware/1/releases.json
2) Download it: wget -O trezor.signed.bin https://wallet.trezor.io/data/firmware/1/trezor-1.6.1.bin
3) Use trezorctl dry-run mode to get the firmware fingerprint:

trezorctl firmware-update -n -f trezor.signed.bin

Step 3 should produce the same fingerprint like your local build (for the same version tag)."

Then it can be installed from the command line:

WARNING: This will erase the recovery seed stored on the device! You should never do this on Trezor that contains coins!

Build with MEMORY_PROTECT=0 or you will get a hard fault on your device.

Switch your device to bootloader mode, then execute:

trezorctl firmware-update -f path/to/firmware.bin


I found that witness didn't include serializied script: that func for some reason just ingnored writing script into buffer, that means algorithm specified here(https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki, specification paragraph) ignored 5th step. So I removed if statement, and instead of (https://github.com/btcsuite/btcd/blob/master/txscript/script.go#L496) pasted writing has160 of pub key and that worked for me


With JSON how do I know the amount that was LAST sent to a given address?

You can also use the filter GET parameter to ensure that the first transaction is one where the address receives bitcoins and not one where the address spent bitcoins and the limit parameter to only fetch one transaction (the latest).

For example https://blockchain.info/address/1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp?filter=2&limit=1&format=json

To get the amount sent, you'll have to filter outputs to get the one sending BTC to the address you're interested in and then get the value field (divide by 100,000,000 to get the amount in BTC).

If you are doing this as a way to get notified of incoming payements, I highly recommend you to use the Receive Payments API as it is dedicated to this use case.


LedgerJS - How to P2SH sign multiple transactions from multiple wallets in 1 function call?

The third parameter is just your outputs script (actually it's the whole outputs part of a transaction) so depending on which address you want to send the funds it will change.

It's using the same format as in bitcoin transactions. The data are serialized like this

TYPE | Description
VARINT   | Number of outputs to create
8 byte   | Amount to send to the first output
VARINT   | Size of the output script
x bytes  | The actual output script

In most case you can consider that VARINT is only 1 byte (special cases if you data is bigger than 255 bytes but if that's the case you probably have an issue somewhere :P)

Regarding the output script depending on which address you want to send you have different type of scripts to use.

btc.serializeTransactionOutputs(???).toString('hex') is just serializing the outputs part of the transaction from a split transaction. If you use it on an existing transaction you're basically sending to the same addresses (the same amounts to the same addresses).


How do I add a miner's fee to a BTC transfer

Depends what you're using to create and broadcast the transaction (txn). If you're using a web/GUI wallet, then there's usually an option somewhere. If you're crafting txns by hand or interested in the protocol, the miner will receive any unspent BTC from the txns (any amount from the input that's not sent to the recipient or back to you as change).

In theory, the lucky and hardworking miner that's solves the block containing your txn will be rewarded handsomely with 25 BTC and the fees from all txns contained in the block. In practice, most miners are in a pool, so the reward will be shared with all miners participating in the same pool as that lucky and hardworking miner


How to see the number of segwit transactions in a block

Look here under "Transactions (Segwit)" tab:

https://oxt.me/charts

And here's a page showing exactly what you're looking for:

http://segwit.5gbfree.com/countsegwit


You can find a list of contributors to the official bitcoin software here: https://github.com/bitcoin/bitcoin/graphs/contributors

Over 160 people have contributed to writing the bitcoin software, not counting the ones like Satoshi him/themselves who wrote the initial version of the program.

But the important part is that many more people have actually read and reviewed the source code. You can review it yourself if you learn how to program, and judge for yourself that the software is doing what it actually claims to do.

So it doesn't matter at all that we don't know who initially wrote it.

If you read or heard about a great idea somewhere, would you discard it simply because you don't know who actually had the idea? If the idea is useful and it makes sense, it should be used regardless of the creator.


Is it actually possible to create a "verifiably unspendable" address?

Every valid ECDSA public key corresponds to some valid ECDSA private key.  Bitcoin addresses are not actually public keys though, they are a 160-bit hash of a particular binary representation of the public key.

You asked:

  Are there valid Bitcoin addresses for which it's possible to mathematically prove that there is no private key?

As far as I know, the answer to that is no.  To construct such a proof, you would have to somehow consider the enormous set of all possible public keys, and prove that none of them have a binary representation whose 160-bit hash would match the Bitcoin address in question.  The point of hash functions is that they cannot be easily inverted, so you can't just get a list of all the valid inputs that would result in the same hash.

The number of ECDSA public keys (approximately 2^256) is vastly greater than the number of Bitcoin addresses (2^160).  So the average Bitcoin address actually corresponds to about 2^(256-160) = 2^(96) different public keys.  So it seems like it would be hard to find an address that corresponds to 0 public keys.


Python source code for issuing a new altcoin?

Try TinyCoin, a small and easy to understand cryptocurrency written in Python. I'm still unsure exactly what you need because you con't create an altcoin from Bitcoin without knowing C++, Bitcoin is not written in python. But if you just need a python altcoin for learning purposes, this one should do the trick :)


Why is mining which seems to be a software activity create bitcoins which is actually equal to currency?

The purpose of mining is not the creation of new bitcoin, this is the incentive system. Mining secures the bitcoin system and enables the emergence of network wide consensus without a central authority. Miners receive two types of rewards in return for the security provided by mining: new coins created with each new block and transaction fees from all the transactions in the block. There is an exchange of value because in exchange for the security they provide and the computing power they expend, miners get bitcoins which is a valid trade. Similarly in the early days of bitcoin Satoshi Nakomoto sent bitcoin to his peers in exchange for them testing or developing bitcoin core, this again is an exchange of value. Once the darknet got involved in bitcoin they used it because of its anonymity and security, it was valuable to them because of these reasons and this is where demand for bitcoin started and because of this the value of it increased. So the fact the people are willing to exchange valuable things like electricity, computing power, software and testing skills for bitcoin gives it value.


Yes. The ASICs themselves only perform the SHA256 calculations, they do not deal with anything protocol related and as such can merged-mine exactly the same as existing GPU and FPGA implementations. In other words, merged mining is part of the protocol, ASICs just do the math.

The standard rules of merged mining still apply, of course. The alternate currency must also be based on the same type of SHA256-based proof of work as Bitcoin and has to have implemented merged mining in their own protocol.


how long does it take to get 6 confirmations with confidence of 99%

The following holds for a generalized case on the required time for having m blocks with a confidence of p 100\%. The time X between consecutive blocks is exponential distributed, i.e. X~Exp[k] with k=1/10.
The sum of m independent and identical exponential random variables follows the Erlang distribution, that means for X_i~Exp[k],  X_1+X_2+...+X_m~Erlang[m,k]. The required time for having m blocks with a confidence of p 100% is given by the p-quantile of the Erlang[m,k] distribution. In your case m=6 and p=0.99. The quantile Q_Erlang[m,k](p) does not have a closed form expression. However, it is given in terms of the inverse regularized gamma function which can be evaluated numerically.

Plugging in the values leads to Q_Erlang[6,1/10](0.99)=131.085, which means that in 99% of all cases 6 blocks will be mined in less than 131 minutes.


Can a Bitcoin server have a .onion ToR address?

Yes, since version 0.7 this is possible with the reference client.

See the documentation about tor: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md

EDIT: also see https://en.bitcoin.it/wiki/Fallback_Nodes#Tor_nodes for a list of published onion nodes. The explanation on that site should be updated to reflected the built-in support for onion addresses since 0.7.0, though.


What is the average bandwidth used by the default client?

100 MB per day, or less.

(i.e., a dial-up modem could handle it.)


Certainly. Bitcoin Core has various utility RPCs which are separate from the wallet. You can use createrawtransaction to create a transaction. Of course, without the wallet, you will need to specify the inputs and outputs for the transaction manually. You can sign that transaction with a private key not in the wallet by using signrawtransactionwithkey. You can then broadcast that transaction using sendrawtransaction.

To get the outputs for an address that you can use in createrawtransaction, you can use scantxoutset to scan the UTXO set for UTXOs pertaining to a particular address.

All of these can be done without the internal wallet and separate from the internal wallet.


How to move Bitcoin data from Application Support on an external drive [Mac]

Assumptions:

Your current folder for your bitcoin data is here:
"~/Library/Application Support/Bitcoin" or here
"/Users//Library/Application Support/Bitcoin"
Your current folder for your bitcoin-qt application is here:
/Applications/Bitcoin-qt.app
You have an external drive named "My Passport" and your Finder,
Preferences setting are set to display Devices.  Select Finder,
Preferences and tick the box to the left of External disks.

To do this on a MAC running OSX 10.9 follow these instructions:

Open Finder.
In Finder, using the Finder menu bar, select: Go, Go To Folder... , and type ~/Library and press the RETURN key.
In Finder, navigate to the "Application Support" folder.  You will see the Bitcoin directory.
In Finder, select, or highlight, this folder, then select: Edit, Copy "Bitcoin" from menu bar.
In Finder, navigate to your external drive "My Passport".
In Finder, create a folder called "Applications" on your "My Passport" external drive (see step "3" above after connecting external drive, if necessary).
In Finder, navigate to the newly created "Applications" directory.
In Finder, select edit and paste item to start copying the "Bitcoin" directory to your external drive's "/Volumes/My Passport/Applications/" folder.
Once this completes and both the "~/Library/Application Support/Bitcoin" and "/Volumes/My Passport/Applications/Bitcoin" folders are identical.  Rename the Bitcoin directory in  "~/Library/Application Support/Bitcoin" to  "~/Library/Application Support/BitcoinOLD".
Launch Terminal from LaunchPad, Utilities or from Applications in Finder.
At the Terminal prompt type: cd ~/Library/Application\ Support Yes, that "\" slash is necessary.
Type: ls -laf, and insure that the Bitcoin directory is now called BitcoinOLD.
Type: ln -s /Volumes/My\ Passport/Applications/Bitcoin/ ./Bitcoin.  this command actually creates a symbolic link to your external drive.   Yes, that slash "\" just after the "My" is necessary to account for the space in "My Passport".
Launch Bitcoin-qt from Applications in Finder and let the "Reindexing blocks on disk.." process complete.  It should not be downloading anything until this completes and then will download only those blocks since your last synchronize to the Bitcoin network.
Once this completes, delete the BitcoinOLD folder using finder. "~/Library/Application Support/BitcoinOLD".


Namecoins are used to register .bit domains:

http://dot-bit.org/HowToRegisterAndConfigureBitDomains

They're also bought and sold by speculators, but DNS registration is their original purpose.


How to hash data from 'getblocktemplate' request

The wiki has an extremely good explanation, with a python run-through that takes you from GBT output to share submission. You could also have a look at some of the implementation in Luke-Jr's "gmp-proxy", which translates GBT reponses into a getwork compatible interface.

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

https://gitlab.com/bitcoin/eloipool/blob/master/gmp-proxy.py


Why does electrum need connection to server when recovering a wallet from a seed?

While the generation of the private keys can be locally, to recalculate the account's balance tied to the private keys needs data from the distributed ledger (blockchain). As the electrum client does not keep a replica of the ledger it will need access to recalculate the balance of the accounts and hence of the wallet as a whole.


It has a Negative Balance of -0.00199614 BTC, but it also has an unconfirmed transaction for the same amount.  The transaction is from 2015.

That report page is showing unconfirmed transactions as well as confirmed.
Presumably, that transaction will never get confirmed, because it would send the balance negative.


Why is data stored in reverse in the blockchain files?

See little-endian and big-endian.
The choice made by Bitcoin authors for data transmitted over the network is somewhat arbitrary. I think the reference implementation (Bitcoin core) chooses to store the data on disk verbatim as received from the network.
The standard for the Internet is called network order and is big-endian. The Intel x86 family of processors are little endian. The early software developers of Bitcoin didn't convert native order to network order when constructing packets. At least, not entirely.


How to unstuck a low-fee transaction with Electrum?

I've just visited #electrum on IRC to get some advice. While restoring from a seed may make your wallet forget a transaction and allow you to resend it with a higher fee, abpa there told me that this sometimes doesn't work because the server will remind the client about the transaction if it's still in the server's mempool.

abpa suggested using child-pays-for-parent to unstuck transactions, i.e. to send a transaction that spends the change output of the previous transaction with a higher fee to pay for both transactions. (Update:) Apparently, the Electrum developers have added GUI-support for CPFP in Electrum 2.8.0 on 2017-03-09.

In general it is recommended to activate replace-by-fee when using Electrum. This allows updating the fee after the transaction was broadcast if it turns out that the first estimate was insufficient. The setting can be found at Tools > Preferences > Fees > Enable Replace-by-Fee.


Is a Bitcoin address guaranteed to be unique?

It is correct: new addresses are not checked against any existing address.
Cryptographically speaking, those addresses look like completely random strings (that is they are indistinguishable from a real random string).
Interestingly, Bitcoin addresses used in transactions are not even bound to be real: you can put whatever random string (of course in that case you would lose your money :).

Now, still cryptographically speaking, that "almost impossible" means that the probability of that event to happen is the same for you to be hit by a lightning 5 times in a row on a sunny day...(or something like that :)
What I mean is that even though the event is mathematically possible, it is impossible in practice.

That said, in case it actually happens,
the person who generated the colliding address would also have the same private key, giving them the ability of spending all the coins associated to the original address.


Is it actually possible to install Bitcoin full node on a Raspberry Pi 3B+?

I have a Bitcoin full node perfectly running on my raspberry pi 3B (of course, without mining).
The biggest constraint in the installation of bitcoin core (though there are also other implementation of Bitcoin protocol) is the initial blockchain download, because your machine need to verify each and every single transaction inside every block from the genesis block up to now. My raspberry with its poor hardware took about 2 and a half months to complete that procedure, but since that it has been running perfectly.
Speaking about the second part of your question, if you run a bitcoin full node on testnet it's probably for self-learning reasons or the will of doing some little tests before turning to mainnet, so it's convenient for you to already get the memory you will need for the real Bitcoin network.


What is the current state of the Hashcash protocol that is cited in the Bitcoin whitepaper?

There is no serious usage, and has never been, of Hashcash.

Most obviously, the disparity between the resources of a spammer (who can rent a botnet of stolen compute resources, or use high powered servers and GPUs) is no match for a user sending an email from their phone with limited power available . This simply means that the difficulty of generating a "stamp" has to be so high that only spammers are able to send messages, which defeats the purpose.


Ripple Labs makes a downloadable client available. You can store wallets in a local file, encrypted with a passphrase. The source code is available on github along with build instructions.


What are we trying to predict in fee estimation and why?

Different Bitcoin projects try to predict fee rates for improving UX because its not easier for every user to understand all the technical things involved, look at different charts and decide a fee rate for the transaction.

Are different estimations misleading and affect the way fees are used in Bitcoin transactions? Will it be better if we just share mempool stats and user can decide the fee rate accordingly?

Some fee estimations maybe misleading but not everything. And they are only estimates which does not guarantee the transaction to be confirmed. Mempool stats can be shared in the wallets and most of the wallets already provide option to enter fee rate manually.

If I compare this with BTCUSD orderbook on any exchange, are we trying to estimate at what price buy order will get filled in certain time? Does that make sense?

There are few differences between BTCUSD market and Bitcoin fee market which are shared below.
Fee rates used for bitcoin transactions increase during the bull market and stay low in bear market.

BTCUSD follows cycles which are mentioned as bull and bear above.

The difference in two charts above is BTCUSD making new highs in every bull market and considered as a store of value in long term following logarithmic regression, whereas fee rates chart looks like sine wave and reset to 1 sat/vByte often.

Fee rates used in bitcoin transaction are lower during weekends because of less demand for block space however there can be exceptions and its not necessary that fee rates will always stay low during weekends. The amount of decrease in fee rates during weekends and fee market post weekend also varies. An example with weekends highlighted in last one month:

Other things that affect the fee rates used are technical:

Segwit usage: https://transactionfee.info/charts/payments-spending-segwit/
Batching: https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb
UTXO Consolidation: https://bitcoinops.org/en/xapo-utxo-consolidation/
Fee estimation used in different wallets: https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72
Coin selection algorithms used in different wallets: https://iohk.io/en/blog/posts/2018/07/03/self-organisation-in-coin-selection/
Layer 2 usage: https://bitcoinkpis.com/layer2
Exchanges: https://b10c.me/mempool-observations/2-bitmex-broadcast-13-utc/

Taproot will be added to this list once its activated and being used by different Bitcoin projects.

Will it be better if the wallets used this approach?

Show mempool stats
Leave the fee rate for user to decide
RBF every transaction and follow different algorithms for automated bidding
A simple algorithm for automated bidding can be: https://i.stack.imgur.com/1SlPv.png

RBF algorithms for automated fee bidding can be tried and users should also manually prefer to use RBF for most of the transactions.
ZmnSCPxj shared few exceptions on bitcoin dev mailing list which should be handled while creating such algorithms:

Again, a race condition can occur --- while the wallet is feebumping a new transaction that includes the new output, a random miner can find a new block that includes the old transaction.
Further, of course it is convenient to be able to spend money even while it is unconfirmed.

But the sender of the unconfirmed input might be using the same software as this wallet as well, meaning that the actual transaction output might change as the original spender keeps fee-bumping it over time.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018886.html
Jeremy Rubin shared few other ideas in response to my question related to fee estimates and RBF:

In the long term, this can be particularly useful since you can use a
separate fee-only wallet to arrange the bumps if your main wallet keys are
offline, and you do not disturb any of the on-chain dependants.

I'd like to share with you a draft proposal for a mechanism to replace
CPFP and RBF for
increasing fees on transactions in the mempool that should be more
robust against attacks. A reference implementation demonstrating these rules is available
here
for those who
prefer to not read specs.
https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018882.html


Is there a lower percentage cost to transfer from Coinbase or Coinbase Pro to my mobile wallet?

So I downloaded Coinbase wallet, and tried to transfer 0.001 bitcoins from my Coinbase or Coinbase Pro to the Coinbase wallet

This fees is decided by Coinbase.

Is there a way to transfer the money to my mobile wallet at a much lower fee? A fee that is lower than 1% is more acceptable.

Use DEX or P2P exchanges like Bisq, HodlHodl, Localcryptos etc. and decide the fees yourself for on-chain bitcoin transactions.

Use open source wallets that support segwit. For mobile: Bluewallet and Samourai are good enough

Use layer 2 solutions like LN and Liquid if you need to make multiple transfers involving small amounts with no time to wait for confirmations.

Wallets for LN: https://link.medium.com/ltyID21izdb
Wallets for assets issued on Liquid including LBTC: Aqua, Green, Jade
Exchanges for LN: Bitfinex, Okex, Fixedfloat, Sideshift, Lnmarkets
Exchanges for Liquid: Bitfinex, BTSE, HodlHodl, Sideshift, Liquiditi
DEX: Bisq (Supports Liquid), OpenDEX (Supports LN), Sovryn (rBTC)


Nbitcoin's BitcoinPubKeyAddress not recognizing native segwit addresses

It runs fine with segwit addresses starting with a 1, but not native segwit.

Prefix 1 is used by legacy addresses. You can check the other prefixes used here: https://en.bitcoin.it/wiki/List_of_address_prefixes

Is there a way to use native segwit with Nbitcoin?

Replace BitcoinPubKeyAddress with BitcoinWitPubKeyAddress in your code for using native segwit addresses


Help a newbie: How to buy Bitcoin without giving bank account info?

Edit: CampBX is shutting down so this is no longer applicable.

CampBX will accept deposits via mailed money order.  A money order from the US Postal Service costs about $1.50, up to an amount of $1000, plus the postage to mail it to the exchange.  You can buy a money order with cash, in which case no bank information is ever needed. The exchange then charges a commission of 0.55% on each trade.

You're unlikely to find lower fees for buying with credit card.  The fees charged to the exchange by the credit card companies are substantial and have to be covered somehow.  Moreover, credit cards present a substantial risk of fraud to the exchange.


What information does a lightning network node hold?

When syncing the bitcoin node (a prerequisite to running Lightning securely), you are downloading the entire blockchain and validating all historical transactions, which takes a while and a over couple hundred GiB of information. Having a full validating node means that you are always receiving valid transaction information yourself, and you are not relying on third-parties who could present false information, or where you may have privacy leaks by requesting information about transactions from others.

The bitcoin node will continue to receive new blocks and transactions as they occur on the network, and each block acts as a synchronization point approximately every 10 minutes.

When initially syncing the Lightning node, you are receiving the most recent information about online nodes, open channels, and the policies by which you can send payments through those channels with Lightning's onion routing. By default, this information is limited to the previous 2 weeks only, so historical information about nodes and channels is not transmitted or stored.

After the initial sync, your node will constantly receive and rebroadcast new information about nodes and channels over Lightning's gossip network. Each node broadcasts information about itself or its channels each 2 weeks if there have been no changes and the channels are still active. Any changes to channel or node states are broadcast immediately, but nodes may limit the frequency of updates they accept to prevent potential DoS which would degrade the network. These broadcasts are also timestamped and signed.


How can I cancel and replace a Transaction that never gets confirmed?

You could import the private keys used into another wallet and spend the funds there.  For instance, on Blockchain.info/wallet you simply do Advanced -> Import and import the private keys (which can be exported from Bitcoin-Qt's debug console).


There are more variables at play than you have listed, so I can't answer with certainty. Calculator for estimated TX-Fees lists some of the considerations as to when a fee is required, and how much the fee is. (but note that some of the info there is out of date due to a change; the Bitcoin wiki has more up to date info, and is also a good resource on this subject) For example, how many inputs are there, and what sizes and ages are they.

That said, I think that most likely, the best thing to do would be to do it all in one large transaction and pay 0.0001 BTC per 1000 bytes. I'd expect you'd have to pay 0.0001 or 0.0002 BTC (~US$0.06-0.12) for the transaction. Including more wouldn't hurt, and might improve how long it'll take to get it confirmed.

Assuming the transaction is valid (you should make sure it is before broadcasting it) and includes a large enough fee to be relayed by most peers and miners, you shouldn't have to worry about anything going wrong with the transaction. E.g. none of your recipients can invalidate the transaction.


Recovering the last few digits of a Litecoin private key

First off: I don't know of any recovery tools (but didn't google for them either). What I'll explain is the difficulty to guess the correct address.

The wallet import format has 4 byte of checksum data. That's 8 characters. So losing the last 4 byte or part of them only loses / diminishes your ability to check for typing errors in the important part of the wallet import format instance.

8 characters in base58 (which is what the wallet import format uses) is log_2(58^8) bit = 46.86 bit. Subtract the 4 byte of redundant data from this and you know that you have to guess 14.86 bit (idealized (won't work out)). So after 2^14.86 = 29'738 guesses you have it for sure and stochastically the expectation is 14'869 guesses. That's entirely feasible (even non-idealized).

Everything you have after guessing is the so-called extended key. That's enough to derive your private key (which is what you need to send money) from it (just drop the first byte).

If you need it in wallet import format, after your guess you have to hash the extended key using sha256, take the first 4 byte (8 characters in hexadecimal notation, again), and add them to the extended key.

But there are classes which give you the public key if you enter the private key. And you almost got it. You probably also got the corresponding public key. So you need the write a script which tries all the possible private keys, calculates the public keys for them, and checks them against the public key you feed into the script. That's probably way faster than figuring out if there are funds in the wallet.


Which address should be used to send the money as target?

I think these is only one answer to this question: ask whomever gave you the xpub.
Xpubs define series of keys, but there isn't any implicit contract or understanding about how that should be converted into addresses. The specific index positions to use is one question, but there are others, like what type of address/script to use (P2PKH, P2WPKH, ...). All of these are things you should ask the receiver, as it is ultimately up to them to determine what kinds of transactions they would consider a valid payment.
To make a analogy: the receiver told you where they live, and you owe them money, but they haven't told you anything else. Do they want you to pay to their bank account? Do they want you to put an envelope with cash in the mail? Do they want you to bury a treasury chest with jewels under their lawn at night? All of these are in some shape or form ways that value can be transferred, but arguably you wouldn't go bury a treasury chest in their lawn without even talking to them, and expect them to treat that as a payment.


How to accept Bitcoin payments using Bitpay and Electrum for a business

Bitpay is easy to use but certainly has many limitations at least on the merchant side.
In my country it has even suspended the bitcoin settlement service altogether.

If your company is interested in investing a bit on the cryptopayment side, maybe can be a more wise approach building your own infrastructure, maintaining a BTCPay server and a Bitcoin full node.
This is the BTCPay description you find on bitcoin wiki:

BTCPay Server is an open source payment processor. It enables online
merchants to accept bitcoins as a form of payment.
The invoice API conforms to that of the centralized payment processor
BitPay. This allows easy migration of a merchant's code base to their
own self-hosted payment processor. This enables all the benefits of
using a full node wallet; such as censorship-resistance, control over
your own funds, trustless validation, uptime and privacy.

BTCPay is used both by small and large companies, it is widely supported by the Bitcoin community, supports lightning network which enables micropayments and seems a perfect fit for your needs.
This is the homepage: https://btcpayserver.org/
and here there is a live demo: https://mainnet.demo.btcpayserver.org/login?

If you don't want run your own BTCpay server, you find here some merchants that sell the service: https://directory.btcpayserver.org/filter/hosts
(although i suggest you reading this first)

If you want to explore other service beyond BTCpay i found this "curated list of awesome Bitcoin payment processors enabling merchants, businesses and nonprofits to accept Bitcoin payments": https://github.com/alexk111/awesome-bitcoin-payment-processors


my coin transferred on 17 Dec and confirmed on 31 Dec still showing unspent on 5 Jan

That transaction is valid and confirmed.

"Unspent" in the right-hand column means that the outputs have not been spent.  The funds are still sitting in the 1965... and 144f... addresses and have not been moved out of those addresses.

If one or both of those addresses belong to you (i.e. you generated them with your own wallet and have the private key(s)), then you can spend those funds any time you like.

If they belong to someone else (e.g. a merchant from whom you are trying to buy something, an exchange where you are trying to make a deposit to your account, etc.) then that person has the funds.  If they haven't acknowledged the funds (delivered your order, credited your account, etc) then that is something you have to take up with them directly.  But the Bitcoin protocol has done its job at this point.


College Economics Student in Support of Crypto Looking for Live Hashrate Data

You can get a current estimate of this info by running the bitcoin-core full node software and calling the command:
bitcoin-cli getnetworkhashps


Based on the source cpuminer has a --coinbase-addr parameter which accepts a bitcoin address (for example: ./cpuminer --coinbase-addr=1abcdef..., I believe you only need to set this.

The program checks if you have provided an address and if not then switches to "getwork" mode, unless you disabled it by adding the --no-gbt command line switch.


What bitcoin core options can be changed without a restart?

Debugging print options can be changed without a restart.


Are there any services hosting Bitcoin-related ads for websites?

There is not anything like adsense yet, but there are smaller ad platform. Here are a few:

http://dailybitcoins.org/ they offer both ads by number of impression and per click.
http://www.bitcoinadvertisers.com/ they claim to be the biggest, I do not know how true that is.
http://anonymousads.com/ They have a significant presence in the Bitcoin community.
http://puppytwist.com/ they are pretty simple to get started with, high payout too


What am I missing about this "guaranteed" money-making scheme that I didn't hear from anyone but just popped up in my head?

What you are describing is called Arbitrage and is done by many traders for a variety of different assets, not just cryptocurrencies. This is only guaranteed to make you money so long as there is a price difference between exchanges. The end result of many people doing arbitrage is that the exchanges all settle onto the same price.
The main difficulty in performing arbitrage is the time it takes to move assets from one exchange to another. Ideally you would buy the asset, immediately transfer it to another exchange, and then sell it. However because of physics and protocol limitations, it is not possible to immediately move Bitcoin (and most cryptocurrencies). In the time that it took to move the Bitcoin, the price may have moved to be unfavorably to you, so you may lose money, or at least, not make any.
There are ways around it such as having balances on multiple exchanges so buying on one exchange triggers a sell on another. It's not strictly the same asset, but your balance of that asset does not change. However this requires upfront capital to setup those balances.
There are efforts to make it easier to perform arbitrage by decreasing the transfer time. Layer 2 protocols such as the Lightning Network or Blockstream's Liquid network allow for fast and nearly instant transfers of Bitcoin, so they can be utilized by traders to transfer Bitcoin between exchanges to perform arbitrage.


Why is POW/POS absolutely necessary to run public distributed ledger?

You can't do this due to the Sybil Problem. There is no way of proving a node is an individual participant in the system, you can't prove that a node existed at any point in time (or didn't), and there's no source of random numbers at all in the system which can't be influenced or altered.

Proof of Work is a side step to having potentially clones participants in a system vote on validity, it replaces this is with a system in which members of the network verifiably destroy real world resources in order to create additions to the ledger. By adding a real world cost to producing alternate histories, it becomes infeasible for people to modify the history of the system and present it as the truth to anybody else. When faced with multiple choices, participants have a tie breaker by simply comparing the relative amount of resources destroyed and picking the most destructive one.

In your described model:

How do you know that the network is really of this size?
How do you prove to a third party joining the network that you are not all the participants in the network pretending to be other people?
What is to prevent any node in the network signing many alternate histories in which people do and do not get paid, and using this to trick people out of money?

The proposed system breaks down as soon as you introduce malice, which is something cryptocurrencies must be design to defend against. Millions of fake nodes, lying, cheating, and denial of service attacks are all things the system must expect to encounter.

  at least from what I understand, that is what some POS coins do

Proof of Stake cryptocurrencies are usually completely centralized, due to the behavior you're describing here. Faced with the knowledge that PoS is not a method of distributed consensus they use centralized control in an attempt to ensure that the chain is coherent.


Looking for a better way of listing all my peers

Use the getpeerinfo RPC command (available since v0.7.0).


Checking for confirmations using getrawtransaction and decoderawtransaction

The decoderawtransaction RPC call oddly omits the confirmations field in the resulting JSON output. Instead of using decoderawtransaction, try this:

$ bitcoin-cli getrawtransaction <tx_id> true

(Notice the "true" at the end, which means "output as json")

This will return JSON that has a "confirmations" field in the top level of the returned object.


Why has Bitcoin Core stopped shutting down when Windows cleanly shuts down?

According to https://github.com/bitcoin/bitcoin/issues/20052#issuecomment-702659790 you can use the PowerShell Stop-Computer cmdlet.


How do I get a full transaction index with Bitcoin Core?

The commands you have used are not for syncing to the bitcoin blockchain but to install a bitcoin, now with this client you can sync if you want, you will need days or weeks depending on your computer bandwidth and performance and 250+ giga of hard drive, you can start syncing by locating your bitcoin directoryand simply running:

  ./bitcoind

You can find more information about using and running properly a bitcoin full node here: https://bitcoin.org/en/full-node


Absolutely not - terrible exhange for any type of (crypto) currency.

DO NOT BUY HERE - you will receive your coins late (I received mine after 3 days of placing my order) AND they used the exchange rate of the day and time of the processing of the order - in other words I lost 60% of my purchase because they were 'having problems with their system' and took 3 days to deliver.


How does Satoshi Dice's 'zero confirmations' transaction system work technically?

A transaction claims some outputs from previous transactions and then creates new outputs whose summed value is equal to (or less than, in the case of fees) the sum of the claimed outputs values.

For a transaction to be valid it must be the only one that claims the outputs (no double spend) and the transaction that created the claimed outputs must be valid. Satoshi Dice can immediately send back a transaction containing the winnings because the transaction claims the output of the incoming transaction, chaining the two transactions together.

The result is that either both transactions are valid, in which case the player gets his winnings, or the first transaction is not valid, immediately invalidating the second one, and Satoshi Dice is not tricked into sending coins back without receiving the wager.


Importing private keys into wallet - does the bitcoin disappear from the original wallet?

Bitcoins are never actually in a wallet. Bitcoins sit in the blockchain. Many copies of that blockchain resides in nodes (computers). Simply put, your wallet merely is a list of addresses on which according to the blockchain are (fractions of) bitcoins stored.

You can have as many of the same wallet s you like. When they all contain the same addresses, they will show the same balance as they are all looking to the same blockchain.


Mining is a random, progress-free process. Miners are essentially attempting to find a partial pre-image of a hash. Each new (valid) block candidate has exactly the same minuscule chance of yielding a new block. This means that finding a block for the next height is just as likely as finding a block that competes with the current chain-tip.
However, finding the next block is a lot more profitable: the current chain-tip has already been relayed to a large part of the network and all other miners are trying to find it's successor. Mining has a real cost, and only blocks that end up being a part of the best chain get paid out. To successfully compete with the current chain-tip, the miner would have to first find that competing block and then another to make it part of the best chain. It doesn't make sense for a single miner to try to find two blocks while all remaining miners together only need to find one more block to thwart him. Rather, the miner will spend a fraction of a second to validate the current chain-tip and try to find the next block.
There are two exception to the above behavior: Firstly, when a miner controls a significant portion of the total hashrate, they can theoretically attempt to increase their revenue disproportionately by starting to mine on new found blocks before publishing them, gambling on finding two blocks before the remaining network does. This attack is referred to asselfish-mining. Secondly, when a miner controls at least half of all mining power, they can maintain a monopoly on creating blocks by ignoring all foreign blocks and outhashing all other mining power in a so-called majority-attack. This is a popularly discussed failure scenario for Bitcoin and would likely undermine trust in Bitcoin altogether.


can i send Bitcoin directly from my coinfloor exchange wallet to my binance exchange wallet?

Mark Lamb from Coinfloor here. Yes you can do this. That text is only relating to third parties wallets that are not owned by you.


Question: Docker alternative to Tails OS for generating Bitcoin addresses securely for cold storage

It would not be equally safe because you are running the container on a machine that is connected to the internet. Even if the guest is not compromised, the host could be, and that would compromise the guest.
Furthermore, docker containers are not even fully fledged virtual machines. They share the host's kernel as well as a lot of other components from the host system.
In the end, the software that you run in a docker container gets executed by something in the host OS, and that has the potential to leak information to an attacker who has compromised the host.

Running Tails on an offline machine removes any existing OS as a factor since Tails is itself a fully fledged OS running on bare metal. You can ensure that the Tails you are running is that which is officially distributed, thereby ensuring that there isn't something else which has compromised it (of course there is the risk that Tails itself is compromised, but that's a different discussion). By physically disconnecting the device from the internet, there is no way for anything to leak to the internet.


Why does the time interval for OP_CSV need to be in the nSequence field when it is already in the script?

They do not serve the same function.
Putting a relative locktime in the nSequence value means "this transaction cannot be mined until its input is at least that old".
Putting a relative locktime with OP_CSV in the script means "Require that the transaction spending this sets an nSequence of at least this value".
The reason why they are split up is to make transaction validation independent of time. If the value passed to OP_CSV would be compared against the time directly, and it failed, there would be no way to distinguish whether the transaction is just outright invalid or it's due to a temporary locktime/nsequence constraint.
In other words: splitting them up allows us to see the spending transaction, verify it once, and know for certain that it's valid. We never need to evaluate it again, as this validity never changes; if it is valid once, it is valid always. The question of when it can be mined remains independent of this, and can easily be checked by just looking at the nSequence value and comparing it with the blockchain's time.


How to specify testnet via curl against json-rpc?

The port 18332 is the specification you speak of.
When the testnet bitcoind is running on your system, port 18332 is open to accept rpc's. In case of mainnet, that port changes to 8332.

Every thing that you can do from the commandline is accessible via curl on that port.


The discontinuation of newly mined bitcoins does not mean that there will be no block rewards. Block rewards come from confirmed transaction fees also.


I want to know how I can express a phenomenon found in Merkle Trees mathematically


How miner deduct Transactions fees from transaction?

The sum of a transaction's inputs must be greater than or equal to the sum of outputs as part of the validation rules.  This difference is the transaction fee.

So to answer your question directly, when a UTXO is spent, it is referenced as part of a transaction input.  A UTXO is always completely consumed (analogous to how if you spend a dollar bill, you have to spend the whole bill and get change), so the fees are not taken from that per se.  It is the difference of the inputs (sum of the UTXO values being spent) and the outputs of a properly formed transaction that becomes the miner's fee.


2 of 3 multisignature transaction vulnerability when one of the private keys is compromised

does multi-signature wallet protect users from this kind of scenario?

Not necessarily. Ultimately it is dependent on the design of the application which is using multisig transactions.

  Does it even have a way to protect in this case?

Assuming that the other 2 key holders will blindly sign once the primary key owner has sign, no. If the primary key is compromised, the transaction will be signed by either/both other parties.

  Is the assumption that wallet owners will be communicating about the transaction request offline?

In principle yes, the assumption is that the application requires signatories to decide to sign the transaction on their own accord. Sharing  partially signed transaction should be done in a secure private channel between signatories.


Will be possible to have the same key on more than one wallet?

The pull request that you refer to is just for simple import/export of private keys and wallets and does not include the feature that you want.

There have been some discussions on multi-signature transactions which sounds similar to what you are looking for. That would allow for cases where two different private keys are required to make a transaction. See this forum thread and the draft proposal here.


Is there any point mixing coins if I were to use an online wallet?

Assuming that you'd like to protect your privacy by mixing coins, then yes, there would be a reason. Using an 'online wallet' (I am assuming you mean an online wallet-service, that has a website you log in through, or something similar to that) does not protect you in any way that using a locally generated wallet wouldn't. In fact, it is probably a poorer security model in most cases, since your private keys will be generated in an online device.

Further, the service running the wallet may have logs of your IP, etc, so it may also be worse for your privacy.

A coinjoin helps obfuscate the traceable history of a bitcoin through time, an online wallet does no such thing.


Why are transaction fees sometimes higher than what I'm transferring?

Transaction fees are not in relation to the amount of value transferred, but in relation to the amount of block space they'll take. Therefore, it is relatively cheap to send large amounts of value in Bitcoin but uneconomical to send micro-payments.


How to send bitcoins from an online wallet to a blockchain.info wallet?

That's all there is to it.  The wallets handle the private keys.

It you have access to the private keys for the online wallets, it is always a good idea to export them and save them in offline storage (not on your computer).  That way, if the online wallet goes away, you can still recover your coins by creating a new wallet and importing the private keys.

If you don't have access to the private keys, a better option would be to create your own wallet (either on your computer or offline on paper).  Send the bitcoins to this wallet instead of an online wallet.  This way you are protected if the online wallet disappears or is hacked.  MultiBit, Electrum and Armory are all good wallets, so pick one that meets your needs.  You can find more information here.


Bither max transaction fee is 1mBTC per kb. I don't want a stalled transaction

As of 12/12/2017, there is no updated version, either Android or Windows that allows Bither to go beyond the 1mBTC transaction fee.  At that transaction fee, it might take forever or never for a transaction to go through.

There is NO direct information on Bither on how to do this, but after nearly a full day of work, i figured out how to derive the Bitcoin private Key from the HDaccount wallet from Windows Bither. It took a bit of reading and trial and error but, i had success.

From Bither, I exported the Seed Phrase.  I then utilized the website at https://coinomi.com/recovery-phrase-tool.html.

Instead of trusting the website, even though it's supposedly java client based, i saved the website to an OFF INTERNET computer, and ran the webpage from my offline computer.  I put in the seed phrase which then spit out derived bitcoin addresses and private keys.

I was then able to use that private key to access my bitcoin from another software that has better up to date support including transaction fees.

I hope this helps others.


How do bitcoin nodes sync with the INV mechanism?

If I understood correctly it goes like this:

I get the announcement from a peer that he found a new tip in his blockchain. (so called INV message)
I send him the block locator message with last 10 hashes from the tip of my blockchain.
Me and him could be on different branches so he has to detect which hash do we have in common (the hash where fork happened). Or we are on the same branch and he just advanced the branch by one hash. NOTE: If he does not find the common hash he will ask me to send hashes further back my chain (fork happened somewhere earlier).
When he detects the common hash, he will send me the headers from this hash up to the newly found hash. I validate each header, stopping if a header in this process is invalid.
If his chain is now longer than mine (edit: and download the transaction part's of his blocks, verify them then) I switch to new chain.


If you convert the difficulty bits to hex you will get:
0x1F00FFFF

Coefficient = 0x00FFFF

Exponent = 1F = 31

Target = Coefficient * 2**( 8 * ( exponent-3 ) )

Target = 0xFFFF with 31 - 3 = 28 trailing NULL (0x00) bytes

Target:
0x0000FFFF00000000000000000000000000000000000000000000000000000000

Your Hash:
0x000055f67563d1c2cb141d06d52d2fca63ef457c553519aeb635a2643a9af0b1

So your POW fulfils the target.
Just to be sure, you might want to check endianness during your conversions between int/literal/hex types.


Send raw transaction (have tx_hex) on litecoin testnet using api or module

Postdata must be String, not Object. ('tx_hex=...')


Is there a way to buy bitcoin immediately?

Coinbase offers instant buys, you need to enter your credit card info and go through the verification process, but it takes less than a minute to update my balance.  The max amount for instant buy/sell is 1000usd/day.


Any plans for Bitcoin Core app to integrate Hardware Wallet support?

There currently are no plans to support hardware wallets in Core. However this does not mean that it will not happen, it just means that no one is currently working on supporting them. Unfortunately there are no full node wallets which support hardware wallets. But I am working on hardware wallet support in Armory so you can look forward to that coming out in a few months (probably).


Import wallet.dat into a new Bitcoin-Qt client

First, close the Bitcoin-Qt client.
Then you have to locate your Bitcoin folder. For Windows, it should be here:
%APPDATA%\Bitcoin
and for Linux:
~/.bitcoin
In that folder, there should be a wallet.dat file.

If you currently have no bitcoins in your wallet, you can just delete that file and replace it with your backup.
If you have some bitcoins in this wallet as well, backup that wallet file as well, or send all the coins to an address from your backed up wallet.

When you placed the other wallet.dat file in place, you should run Bitcoin-Qt with the -rescan option. Here's how to do that in Windows:

Go to C:\Program Files (x86)\Bitcoin using Windows Explorer.

In that folder, hold shift and right-click and select Open command window here (picture).

In the command prompt, type bitcoin-qt.exe -rescan and hit enter (picture).

Now Bitcoin-Qt should start and rescan the blockchain to calculate the balances of the addresses in your wallet.dat file.
(Source for pictures: cant see bitcoin after restore of backup)


Why DARPA wants blockchain based secure messaging system

As I see it, the key part is at the very end: "traceable in a decentralized ledger".  That feature isn't described in the EFF page you cite, and I'm not aware that any of the services listed provide it.

To see why this is important, imagine a scenario like the following:

Major Smith receives a message at 0400 hours from Battalion HQ about impending enemy action.  But he's too busy playing Angry Birds and doesn't bother to pass it along to his units in the field.  The enemy attacks at 1100 hours, the field units are unprepared, and they are defeated with heavy casualties.  Major Smith is afraid he will be court-martialed for failing to share the intelligence with his troops.  So he writes a message, backdated to 0500 hours, addressed to Captain Jones and ordering him to contact the field units and give them the information.  He also secretly orders (or bribes) Corporal Johnson, an IT administrator, to alter the message system's logs to show his forged message as having been sent at the appropriate time.  This way, he can blame Captain Jones for failing to act on the message, or at a minimum, plausibly claim there must have been some sort of communication failure that kept Jones from receiving it.

If there is a secure decentralized ledger of all messages sent, then Smith can't insert his fake backdated message in it, and there's no single person he can bribe in order to get it done.  So he can't dodge responsibility for shirking his duty.

A secure decentralized ledger is precisely what a blockchain provides.


A Satoshi is the smallest fraction of a Bitcoin that can currently be sent: 0.00000001 BTC, that is, a hundredth of a millionth BTC. In the future, however, the protocol may be updated to allow further subdivisions, should they be needed.

Further examples of units

1 BTC = 1,000 mBTC (millibitcoin)
1 BTC = 1,000,000 μBTC (microbitcoin)
1 BTC = 100,000,000 Satoshis
1 mBTC = 100,000 Satoshis
1 μBTC (microbitcoin) = 100 Satoshis

So $amount will be 100000000*0.03 = 3000000

and $fee will be Transaction fee value in satoshi (Must be greater than default fee) (Optional)


What would happen if I publish a modified version of an earlier block? Would it be rejected immediately by peer nodes?

Nodes would reject it immediately.

If you simply alter the data of B2 and send it, the block will be invalid by definition as the proof of work and merkle tree will not be valid anymore.

If you modify the data and rebuild the merkle tree and redo the proof of work to produce an alternative, valid B2' (note that everything else in this new block must also be valid, including transactions), nodes will still reject it as the chain going up to B4 has a greater amount of work.

Nodes will consider the chain with the greatest amount of total work as the valid chain. If you want to rewrite history, you will need to mine a new chain going back to the block you want to start rewriting from, and mine it to a point where its total work exceeds the current best chain. If you then broadcast this new chain of blocks, it will cause nodes to perform a reorganization, and drop the previous chain.

As for transactions returning to the mempool, that does happen in the event of a reorganization. All transactions from the dropped blocks are returned to the mempool. Usually, since miners generally pick similar transactions, the new blocks replacing the old ones will confirm mostly similar transactions, so the mempool will usually only be slightly different at the end of it.


Pros and cons of using Mt. Gox as an e-wallet

Because Mt.Gox has to abide by anti money laundering laws they require at least some form of identification. Although this is a requirement for Fiat to Bitcoin conversion there is no need to link your normal bitcoin transactions to your Bank Account / Identity. Wallet services that deal solely with bitcoin do not need to comply with AML laws and hence require no identification or bank details.
Mt.gox doesn't support many features that My Wallet does: Export private keys - Generate New Address - Unconfirmed transactions - Alerts - Multi Recipient Transactions - Paper Wallets - Labelling Addresses.
Even though Mt.gox is the largest and most trusted exchange you are still using them as a bank and are not in control of your own private keys. One of the key advantages of bitcoin is it allows you to be in control of your money without needing a third party. With the new javascript based wallet services your keys are encrypted and decrypted inside your own browser so you never share your keys with the server. Some trust is still required unless you use a paper wallet, but it is at least a happy medium.
Withdrawal limits.
No way to know if Mt.Gox actually has your funds and is not operating as a fractional reserve.

Disclaimer: I am biased because I operate My Wallet


What is the maximum number of outbound full relay connections a bitcoin core full node can make?

Maximum number of outbound full relay connections is 16(8 automatic and 8 manual)
MAX_OUTBOUND_FULL_RELAY_CONNECTIONS 8 (automatic)
MAX_ADDNODE_CONNECTIONS 8 (manual)
If you add 8 trusted nodes with -connect option, those will be the only nodes used for outbound full relay connections and nothing else.

Also do we have any option to decrease the number of MAX_OUTBOUND_FULL_RELAY_CONNECTIONS below 8?

No. And the developers who reviewed PR: https://github.com/bitcoin/bitcoin/pull/21815  think we don't need such option in Bitcoin Core.


Is it faster to retrieve bitcoins from exchanges than fiat?

Just to give this a direct answer:

Yes, it's possible for coin withdrawals from an exchange to be processed instantly, and as far as I know most exchanges actually do so.


1 MB was the maximum Bitcoin block size until 2017, not the size of each block. In the early years there were few transactions and most blocks were almost empty.
After the august 2017 segwit soft fork, the way how the transactions size are measured and the maximum space available has changed, now blocks can be bigger than 1 MB.
If you are interested, you can find here how the things works now: https://en.bitcoin.it/wiki/Weight_units
This is the historical chart of Bitcoin average block size

currently the average block size is about 1.33 MB

Edit: I have updated my answer to take into account the changes introduced with segwit soft fork.


No path found when connected to the same node

When you open a channel, the complete channel balance starts out on the side of the opening party, you. So, by opening two channels, both channels had the complete balance on your side. This leaves no balance on the side of the counterparty to assign to you.
To explain graphically, think of a channel as a string of beads. I use [U] for you, and [C] for the counterparty:
A new channel has all the balance on one side:
[U] 000------ [C]

When you send funds to your channel partner, part of the balance in the channel is assigned to the partner:
[U] 00------0 [C]

To make a multi-hop payment to [R], you trade balance in your channel for balance in another channel of the counterparty:
[U] 000------ [C] 000------ [R]
               ⇒
[U] 00------0 [C] 00------0 [R]

This leaves the same total balance for the forwarding node, just shifted from one channel to another (plus a fee you might have paid for the forwarding).
In your case your two channels looked like this:
[U] 000------ [C] ------000 [U]

The forwarding party had no balance in either channel, so it could not facilitate the multi-hop payment. You will need to spend some of your balance, find someone to open a channel to you, purchase in-bound liquidity, or loop-out some balance to generate some in-bound liquidity before you can receive a payment.


How are thousands of transactions put into a block?

How exactly are these blocks formed?

First a miner decides which transactions to include in their block (usually they run algorithms that maximize its profit), and collects the transactions fees in the block.

  Also, does each transaction have its own hash?

Yep, transactions are named with their hash. For example the transaction c58523726c33e982a69ff092f56d782790ece31185bd4b824e36002e5f507e1e is called c58523726c33e982a69ff092f56d782790ece31185bd4b824e36002e5f507e1e.

  If so, how are all of the hashes grouped together into one has for the block?

That's a complex process named "Merkle root".


How can I run a light (SPV) node on Linux?

Try Electrum. Exact details on how to install depend on Linux distribution used.

Also Wasabi Wallet could be good choice, easy to setup.


A 51% attack involves just 51% of the hashrate, no nodes are involved.
With a majority of the hashrate, miners can construct a new branch in the chain that overtakes the chain that was previously accepted.
It has to be an otherwise valid chain, as otherwise nodes would reject it. The attack doesn't let the 51% attackers make the network accept any invalid transactions - it can just roll them back.


I want to ask if this is the correct procedure in order to get my money back?

No.

You are being tricked by a criminal. A confidence trickster (con-man). It is a common type of fraud or scam.

  If not what can I do to get them back?

There's no way to get the money back. Bitcoin transactions are not reversible and cannot be undone or cancelled.

You can report this fraud to your local police so that the police crime statistics are more accurate - but they won't be able to recover your money for you.

You will be contacted by people who say they, or someone they know, can get your money back. They are lying to you. They also will eventually ask you to pay release fees, transfer fees, decryption fees or some other kinds of fees they invent. None of these fees are real. I urge you to ignore such offers and accept that your money is gone and move on with your life.

  Today I requested my money back and he took another 275 euros from my account

From what you say, your Bluesave and/or Optima and/or Jubiter accounts are no longer under your control, any money in one or all of  those accounts is now under the control of a criminal. It will be best to not ever use these accounts again. Even after changing passwords, they cannot be guaranteed to be safe.

If I were you, I would make a list of all accounts the criminal might know of, then I would set aside any information given by the criminal (phone numbers and email addresses etc) and independently find out the true contact details for the businesses that provide those accounts (but be aware that some may be fake businesses run by the criminal), then I would ask, in writing, each business to close the account explaining that you are the victim of fraud.


Stealing Bitcoin Private key using Man-in-the-Browser

The idea behind a man-in-the-browser attack is that the attacker has access to everything that your browser does, at least for the site you are on.  This is usually accomplished by tricking your browser into running malicious javascript within the context of the domain you are browsing, but may also be the result of malicious or exploitable plugins.  If your browser runs the code that encrypts a key, or uses it to sign something, that means your browser has the unencrypted version of it.  In the case of a MITB attack, the attacker has the unencrypted version too.  This means it doesn't have to steal the private key after it gets encrypted.  It already had it before any encryption.

If your browser has been compromised, nothing you do with it can be considered safe.  From a web security standpoint, a MITB attack is about as bad as it gets.


Is there any where to get free testnet Bitcoins?

Looks like you can get some here:
https://onchain.io/bitcoin-testnet-faucet
The term "faucet" has been used for quite some time for a site giving away small quantities of coins for free. If the above link ever stops working, a web search for "bitcoin testnet faucet" may find a different site.


They're an obvious scam. I mean, absurdly obvious.

I'm really baffled how anyone could fall for something like this. If someone had a way to reliably invest $10,000 and turn it into $120,000 in a month, what would they want your money for?

At that rate, $10,000 would become over $800 quadrillion dollars in just a year, 2,400 times the amount of money that there is in the entire world! Why would they bother setting up a web site and dealing with customers?

Investing always involves a risk/reward trade-off. If there was some way to get large rewards without taking large risks, everyone would do that and be rich. But that's obviously impossible -- there is no economic engine with that capacity. The planet would be entirely owned by every random person with $10,000 to invest in less than year. Where would all those planets full of yachts and mansions come from?

So such a low risk, high reward system doesn't exist. It can't exist. It is so many orders of magnitude outside of the bounds of what is even conceivable, much less possible.

There are a lot of copy/paste scam websites like this. They all have the same red flags all over them. Untraceable testimonials, bad English, no identifiable people in their management, and paragraphs of meaningless mumbo-jumbo.

But most importantly, there is no way anyone could tell what level of risk they would be taking even if the offer was legitimate. Of course, it can't be legitimate, because it doesn't tell you what risks you are taking. Anyone who understood what investment was should be able to immediately tell this is not a legitimate investment because the risks are not clearly disclosed.

If this were possible, nobody would ever have to live in debt. Just borrow $10,000 and next month you have $120,000. You could pay back the $10,000 loan, pay off $100,000 in debt, and have leftover to live off for the next month. Of course, nobody would be in debt -- why would anyone lend anyone $10,000 if they could invest it and have $120,000 in a month? Why would mortgages exist?

Seriously, I have to slap my forehead that people could think this is legitimate. I don't mean to be mean, but geez.


Yes it's solo mining, and the difficulty is so large that you will never be able to find a block before the mining pools do. You have a better chance at winning a lottery than mining a block before big pools do.

So you will most likely never get any coins.


Found my wallet on my external HDD but it has changed the adress and it was empty after synchronising. I can see in blockchain.info that its not empty

Bitcoin Core does not have "the address". There is no "the address" in a wallet. Wallets have more than one address, and every time you want to receive Bitcoin, it will give you a new address. This does not mean that old addresses are forgotten or deleted. They are still there and the wallet still knows about them.

You will not be able to see your balance without syncing the entire blockchain. If the version of Bitcoin Core you have is old, I highly suggest that you install the latest version of Bitcoin Core and let it sync from scratch. To do this, download and install Bitcoin Core 0.15.1 and then delete everything in the data directory except for the wallet.dat file. Then start Bitcoin Core and let it fully sync.


8333 failed after select(): Connection refused (111)

this happens when you have a running daemon and suddenly for whatever reason the firewall starts blocking it. IT IS A FIREWALL ISSUE.
In my case I installed additional programs on my server which changed the settings of nftables (formerly iptables). I had to open up the relevant ports again (that are required by btc-daemon).
After that you have to restart both nftables as well as btcd.
Keep checking the logs for a few minutes. And you will see it will be running just fine.


What is the source of initial transactions of bitcoin?

What is the total amount of all those transactions

You can see Bitcoin's genesis block here:

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

You can easily examine early blocks by using the block height in any blockchain explorer. For example here

  how they got BTCs for the initial transactions?

Mined blocks can be empty (contain no transactions other than the "coinbase" mining reward). I guess this can be the case when the mempool is empty or when all the pending transactions therein have unattractive fees.


I was able to resolve the issue.

public static String estFee(String amount, String receiver, WalletAppKit kit, NetworkParameters params){
        try {
            String value2 = String.format("%.8f",Double.parseDouble(amount) * MainPage.handleFee);
            //String value1 = String.format("%.8f",Double.parseDouble(amount) - Double.parseDouble(value2));
            String value1 = String.format("%.8f",Double.parseDouble(amount));
            Coin val1 = Coin.parseCoin(value1);
            //Coin val2 = Coin.parseCoin(value2);
            System.out.println(receiver);
            Address target1 = Address.fromBase58(params, receiver);
            //Address target2 = Address.fromBase58(params, MainPage.handleAddress);
            Transaction tx = new Transaction(params);
            tx.addOutput(val1, target1);
            //tx.addOutput(val2, target2);
            SendRequest req = SendRequest.forTx(tx);
            req.feePerKb = Coin.parseCoin("0.0001");
            kit.wallet().completeTx(req);
            String[] temp = req.tx.getFee().toFriendlyString().split(" ");
            return String.format("%.8f",Double.parseDouble(temp[0]));
        }catch(InsufficientMoneyException e){
            Double mis = (double)e.missing.getValue()/100000000;
            System.out.println(BackEnd.strFormat("ERROR","NSF","INFO","Not enough money. You are missing "+mis+". This was to retrieve an estimated fee."));
            return "0";
        }
    }

The library wasnt so forth coming so i had to improvise for the solution.


You can't run Bitcoin on CentOS 5. It's too old.

You can't run the binaries because they are compiled against much newer versions of glibc and other critical libraries.
You can't compile the source code because it requires much newer versions of libraries than are present in CentOS 5.

I ran into these issues when putting together my Bitcoin yum repository for RHEL/Fedora. As you'll note, only EL 6 and 7 (and of course Fedora) are viable targets.

That's not to say that it's impossible; it's merely very difficult and a whole lot of work. And you shouldn't use old operating systems for new projects anyway.


Potential security problem: wallettpassphrase opens up the wallet for everybody!

Yes, any person you give your rpcpass and rpcuser to can control your wallet, that's not what the wallet encryption password designed to protect against. You really don't want to be giving arbitrary users your RPC authentication details under any circumstance, and I can't think of one where you would need to.


How do I switch from MultiBit to Bitcoin-QT?

As far as I can tell, BTC 0.006 is not below any relevant transaction limit. A couple weeks ago I bought a cup of coffee for BTC 0.0033 and it went through without problems.

You would probably pay a fee of BTC 0.0001 - less than 2% of your holdings, and about US $0.05 at today's prices. At US minimum wage that buys roughly 20 seconds of your time. You'll spend more time (= money) than that just reading any other answer, much less implementing it.

Short version - just pay the fee!

(Future generations reading this will no doubt, one way or the other, find it hilarious that someone could/would pay BTC 0.0033 for a cup of coffee!)


How much of the Bitcoin Source code is untouchable? [CVE-2018–17144]

I think that's an incorrect impression. The code involved in CVE-2018-17144 was relatively recent (the UTXO handling logic was written in 0.8 (released feb 2013), and underwent a few small changes after, and a large improvement in 0.15). If by "original code" you refer to the code written by Satoshi, this issue is unrelated, as fairly little of that code is left.

The issue wasn't that the code was not understood. It's that it wasn't clear which piece of code was responsible for what.

For performance reasons, block validation is split up in multiple stages; some run when the block is first received, some run later when it's actually a candidate for becoming part of the best chain ("activation"). The general principle is that you try to make the work wasted on verifying an invalid block proportional to the work an attacker has to do. To accomplish that, you verify the things that are cheap to fake first, and things that are expensive to fake later.

One of those checks was whether there were double spends within a transaction. Initially, this check was done when the block was received directly, and a sanity check during activation. In 0.14, in a performance improvement, the check in the initial block was removed, as it became the critical path for validation of compact blocks. This was wrong; instead of removing the code, it should have been moved to activation time, but it appeared that the activation code was already doing this check. In 0.15, when the UTXO handling code was rewritten, this sanity check at activation time was removed as well, because it didn't appear to be actually part of the validation code.

The mistake in my view was that the split up of responsibility for this type of double-spending check was non-obvious and should have been documented. I was largely responsible for this. Several procedures are in place to help prevent issues of this magnitude, including a sometimes annoyingly slow review process, and functional tests (which do exercise double-spending, ... just not double-spending-within-one-transaction). In this case, those procedures failed.

The rest of my answer is my personal opinion, as I don't think I can speak for anyone else.

  are there parts of the bitcoin source code that are 'untouchable'?

No. Certainly some parts are more dangerous to modify, but everything is a question of cost vs. benefit. The changes in 0.15 were a very justified performance improvement, and got a lot of eyes, but not enough. For the future I think this means the bar for review, and tests, vs the possible gain needs to be revisited for changes touching this UTXO handling code.

  How much magic is there in the source code that contributors need to just figure out exists?

I don't think there is any magic. Certainly not all logic is equally easy to understand, but that is true for any software project.

  If bitcoin broke, would the core team jump at the opportunity to recreate bitcoin

My personal opinion is that rewriting something from scratch is orders of magnitude harder to do correctly than making small incremental changes that are individually-reviewable. Note that the bar for correctness in consensus code is extremely high: not only must it accept all valid blocks, it must also reject all invalid blocks. This sort of consistency between codebases is extremely hard to maintain. Most reimplementations of Bitcoin's consensus rules have had one or a few serious mistakes in their history, and I wouldn't be surprised if most of them still have not exactly the same logic in all cases.

  bitcoin with all the new features (mast, tap, schnorr) etc.

Thankfully, those things are very well-isolated changes with a simple interface to the rest of the system. Script validation is pretty much just a "call a function with the output and input without much of any other context, and return true or false". There are also obvious ways to introduce backward-compatible changes in it: simply add additional "return false" statements in it that don't modify any other variables.

  Is describing the source code as having a cancerous centre a huge overstatement, or is it playfully accurate?

I wouldn't know what that centre would be, so I think it's an overstatement.

  Is the idea of current contributors working around the old code like walking on eggshells accurate?

Touching consensus code is always walking on eggshells, but that doesn't mean it shouldn't or can't be done. I also don't think it would be any different if the code had a different history - consensus correctness is just a hard problem.


When does miner insert the coinbase transaction?

If you add the coinbase transaction later, that will change the merkle root. If merkle root is changed, the block header is changed and hence the header hash you calculated earlier is no longer valid. This is why the coinbase transaction needs to be entered before you start calculating the hash of the header.


Indexing of transactions in the blockchain

Each full node maintains an UTXO set, that contains all the unspent transaction outputs. This UTXO set is built by each full node when it is initialized by going through all the blocks until the genesis block. The UTXO set, unlike the blockchain, is stored in the RAM of the machine to allow faster query (UTXOs are actually stored in $DATADIR/chainstate, but are aggressively cached in memory.) When a new block is received and validated, the nodes will remove data related to the UTXOs that are consumed and add the outputs of the new transactions to the UTXO set.


When does a node mark a transaction as confirmed or unconfirmed?

They don't know about the new block until they receive it over the peer-to-peer network (or some other way, e.g. FIBRE).  But since it was broadcast to the network, and all nodes on the network will be trying to relay it to all their peers, this should happen pretty quickly.
When they receive the block, they know to exclude those transactions in their own blocks.  (In practice, they probably generate a whole new candidate block, including only transactions not already confirmed, and with a new header that lists the just-received block as its parent.)
When the node changes its mind about which branch is active, transactions from the previously active branch (subsequent to the block where they diverged) are returned to the memory pool, except for those which are already in the new active branch, or conflict with a transaction on that branch.  Then, just like all other transactions in the memory pool, they are eligible for inclusion in future blocks created by this node.


How to configure a bitcoind instance solely designed to contribute to the network?

Generally speaking if you want to contribute you have two options:

Become a blockchain peer

The Bitcoin network requires the full chain to be available for download.  If not enough peers allow the full chain to be downloaded, this is a risk to the network.  This isn't CPU intensive but puts a small load on your network IO as a configurable number of peers download the data.

Namely you can run bitcoind  and allow inbound access to port 8333.  This will allow people to download the blockchain.  If you see options to run as a "server"  know this runs something different on port 8332 and is considered "sensitive" and should be secured.

I like to visually check on on the process so here is the command I run:

bitcoind -debug   -logtimestamps   -printtodebugger -printtoconsole

If your computer can handle it, edit the bitcoin.conf file (location is platform specific) to allow more people to simultaneously connect.  Edit maxconnections= to whatever you think is best.

Mine

There isn't much use in mining unless you have a FPGA, or ASIC for Bitcoin.  These rigs are more specialized and competitive.   Take a look at www.butterflylabs.com for an ASIC miner that can plug into your USB port


A macaroon consists of three parts:

The header: Identifies the macaroon and contains three fields.

The version: 1 byte, always set to 0x02 in lnd
The location: variable length string, always set to "lnd" in lnd
The identifier: variable length binary data, contains protobuf serialized data in lnd containing the permissions of the macaroon. More on that later.

The caveats: Restricts the capabilities of the macaroon. This is a variable length list of strings. lnd currently only implements two possible restrictions, the time-before and the ipaddr restriction.

Example with maximum characters:
["time-before 2006-01-02T15:04:05.999999999Z07:00", "ipaddr 255.255.255.255"]

Which is roughly 70 bytes plus some encoding overhead.

The signature: An HMAC-SHA256 hash, so 32 bytes plus encoding overhead.

The permissions
As mentioned above, the macaroon identifier contains a list of permissions. Currently this just contains a protobuf serialized list of {Entity string, Action string} pairs that correspond to permission sets in lnd. For example, the pair {Entity: "info", Action: "read"} would give a user read-only access to informational calls.
These permissions make it a bit tricky to estimate the maximum size of a macaroon in lnd. At the moment, the maximum number of distinct entity/action pairs that exists is 17, which is given to the automatically created admin.macaroon. That admin macaroon currently is around 280 bytes in size.
But soon, you will be able to customize the permissions of a macaroon even further by specifying individual URIs that are allowed to be accessed. A user could could then, for example, add a permission pair of {Entity: "uri", Action: "/lnrpc.Lightning/ExportAllChannelBackups"} to a custom macaroon.
Just for fun, I went ahead and created a maximum-sized macaroon with all currently available URIs which turned out to be 4041 bytes in size.
From that, I would summarize that limiting user input when uploading a macaroon to 4096 or 5120 bytes should cover almost all cases of custom macaroons.


How does difficulty get rebalanced in Digitalcoin's Multialgorithm mining?

I assume this means that the network will accept a block mined with either of the three algorithms, as long as fulfills an algorithm specific difficulty.

Yes, this is true.

  However, how does the difficulty get balanced among the three different mining algorithms?

The difficulty for each algorithm is tracked independently. Essentially, each algo is retargeted to be 2 minutes between block solves of the same algo. Since there are 3 algos, 3 blocks will be solved every two minutes, which means 40 second confirmation times on average.

  For example, if blocks are found too quickly, but mainly with one mining algorithm, which difficulties get adjusted and how?

Only the mining algorithm that has seen an increase in hash rate will be adjusted. In addition, no more than three blocks of the same algorithm may be solved consecutively.

The difficulty retargeting algorithm code is here: https://github.com/DGCDev/digitalcoin/blob/master/src/main.cpp#L1429.

I should also note that Myriadcoin was the first to implement this type of Multi-Algo-Pow.


How to create (many address)/receive/send bitcoin without download blockchain?

mkdir .bitcoin
echo "prune=600" >> .bitcoin/bitcoin.conf
bitcoind --daemon

And blockchain not more 600 MB


How can I use multisig / split keys using My Wallet?

This is the latest info I have seen from Ben who runs blockchain.info.

  Question: The escrow function seems to be gone. Will it return?
  https://blockchain.info/wallet/escrow?

  Ben: The escrow feature was removed because not enough people were using it. I think maybe it was just too confusing/not well documented enough.

I did not see any info on if/when it will return.


No, even in Testnet, there is no legitimate reason for coins to be leaving your address without you initiating it.

It's possible you somehow sent the transaction by mistake, or that someone else (perhaps a virus or Trojan) gained access to your private keys.


ScriptSig field during P2PKH transaction signature

According to the accepted answer from How to redeem a basic Tx?, the field is temporarily set with the ScriptPubKey field from the UTXO we want to redeem (in this case a P2PKH ScriptPubKey with the RIPEMD160 of the previous address). However, according to VButerin's pybitcointools, the field is set with a P2PKH ScriptPubKey with the RIPEMD160 of your own address (the one you are using as a source, and which private key will be used to sign the transaction).

You're saying the same thing twice here.

A transaction T1 existed with an output T1:0 which has a scriptPubKey P2PKH(K1). This is the transaction that credited you. It resulted in the creation of a UTXO with script P2PKH(K1), and your own key is K1.

You're trying to create a transaction T2 with as input T1:0 and an output T2:0 with scriptPubKey P2PKH(K2). This is the spending transaction, which you're signing for with K1. It sends money to K2, but consumes the UTXO T1:0 which has script P2PKH(K1).