Is this true? Do you think only large multisigs care and it will benefit only large multisigs? What is a large multisig? (Main question)

No. I assume large multisig is a term used for multisig with more keys used in quorum or multisig with more users. Taproot is more than just changes to multisigs.
Everyone who cares about secure key management, LN, atomic swaps, privacy, batch validation, etc. should care about Taproot IMO
Even if you ignore all the cool things that are possible after Taproot, it will improve IBD for full nodes which was the biggest reason to avoid increasing blocksize every few months as it will lead to centralization.
Every node on the network must validate every digital signature of every input of every transaction. With currently implemented Schnorr batch verification, verifying all signatures in a block in a batch will become over twice as fast as individually verifying each signature.
Potentially even more exciting, during initial block download (IBD), new nodes must verify every single signature on the entire blockchain. The speedup of using batch verification grows logarithmically with the number of signatures being verified so that one could use batch verification to verify one billion signatures with at least a four-fold speedup! (Though I will note that this may be somewhat infeasible today as it would require a crazy amount of RAM). There are somewhere on the order of a billion signatures on the blockchain right now but sadly this speedup won’t apply to them, since they are all ECDSA signatures. However, future blocks containing Schnorr signatures could benefit from the speedup of batch verification for IBD in decades to come.
https://suredbits.com/schnorr-applications-batch-verification/
I think it's important to note first that BIP341-BIP342 are improvements to the Bitcoin script "framework" more than they are improvements to the smart contracting "functionality".
https://bitcoin.stackexchange.com/a/100051/

If Taproot also involves a new signature algorithm: Schnorr, why would only large multisigs care?

What does signing a transaction mean?
Currently, Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA). With the Taproot upgrade, Bitcoin will integrate Schnorr, a second type of signature.
What are the advantages of Schnorr vs ECDSA?
When Schnorr signatures are part of Bitcoin will it be possible validate each block with only one signature validation?
Schnorr signatures will not replace ECDSA. Only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures. ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs.
https://bitcoin.stackexchange.com/a/90856/
According to P2SH.info 7% of all the BTC value locked belong to native SegWit scripts, we might see increase in this percentage considering the incentives involved in using Schnorr.

Is usage of multisig in bitcoin projects an issue? Which projects already use multisig? Is everything possible without multisig?

No. Multisigs are used and required for lot of things. There are lot of Bitcoin projects that already use multisig. And there are lot of ideas, projects, updates etc. which will be possible after Taproot.
Example: Atomic swaps will make it easier to trade on Bisq without security deposit
Few Taproot related projects: https://en.bitcoin.it/wiki/Taproot_Uses (Do not consider this list as final, anyone can edit the wiki to update list)
One interesting blog post by Andrew Poelstra about use of covenants with Taproot and few opcodes: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
New opcodes could potentially be introduced in a future soft fork: https://bitcoin.stackexchange.com/a/100047/


Who decides what the next, correct Nonce is?

Each node is searching for a different set of Nonces, actually.
This is because each node collects randomly a bunch of transactions that will form a block. So each block that the nodes are mining is different. On top of that, there are many Nonces that could make a correct form of hash.

The only thing here that matters is:

all the data inside the block seem to be correct (correct inputs, with correct and confirmed transactions, with their correct associated hashes, etc.).
Nonce + Block gives you a hash smaller than a predetermined number (known by all the nodes).


You want to download the Bitcoin ABC client, then move your existing bitcoin directory (~/.bitcoin in Linux) or understand that you are going to modify that bitcoin data to go down the Bitcoin Cash fork.

You can use those same CLI coins just want to use the ABC client or any other client on the Bitcoin Cash side of the split.


Can two bitcoin transactions from a Segwit address (p2sh-p2wpkh) have a reused R value?

Segwit does not use a different signature algorithm nor does it change any of the properties of a ECDSA signature. Thus if you find transactions that involve the same public keys and the same R value, then yes, the private key for that public key is revealed.

However, what you are looking at is not the R value. In fact, you are not even looking at the signature. Rather you are looking at part of the redeemScript. 145d3cbed9f338b82667f410340fcb9bf401c7e837e9f4539b915fb8bced is part of the hash of the witnessScript, not part of a signature.

The address 3AQ4kUjQaDjCjmDh2ojKEHjUKTSi52UUqD is a P2SH-P2WSH address. This means that it maps to a Pay to Script Hash (P2SH) output script, which has a redeemScript for a Pay to Witness Script Hash (P2WSH) script. The P2WSH script contains the hash of the witnessScript, which, in this case, is a multisig script.


Arithmetic operations in Bitcoin (OP_ADD, etc)

Short answer: arithmetic on large numbers will cause the script to fail.

Long answer:

Script arithmetic is limited to 32-bit arithmetic.

You can find the code for arithmetic operations in script.cpp, in the function EvalScript, where the opcodes are evaluated using CScriptNum in [script.h](https://github.com/bitcoin/bitcoin/blob/master/src/script.h].

The numeric limit is enforced through the constant nMaxNumSize.

The CScriptNum constructor shows that numbers larger than 32 bits throw an exception, resulting in failure of the script.


Yes, it is a scam. You do not want to give the private key of your wallet to anyone. Do not deal with this person.


Why is the smallest transaction value 5340 satoshis? What is so special about that particular number?

The smallest transaction value is actually 0 as you are allowed to create 0 value outputs. However such transactions are considered non-standard and thus will not be relayed. But they are completely valid if they appear in a block.

The smallest standard output value (also known as the dust limit) changes with the fee rate. The dust limit for a given fee rate is defined as the amount of Bitcoin where spending the output would result in all of the output's value being paid as transaction fees.

Currently, the dust limit fee rate is 3 satoshis per byte which makes the dust limit 546 satoshis, not 5340. The 5340 satoshis dust limit comes from a time when the dust limit was actually defined differently and the dust fee rate was higher.

The previous definition (no longer used, but was the one used when 5340 satoshis was the limit) was the amount at which one third of the amount would be paid in transaction fees. To make calculations easier, this was redefined to the current definition and the default dust fee rate for calculating this was multiplied by 3. Under this definition, the dust fee rate was ~10 satoshis per byte.


A proposal for a genuinely distributed blockchain and pruning

One thing you're missing is that nodes don't actually need access to blocks.

The only time a "scan of the blockchain" occurs is to give historical blocks to another node that is syncing, or to find historical transactions a wallet missed. Solutions for those case are not hard. Sequential bulk storage and bandwidth are cheap and it's not something every node on the internet needs to provide to everyone. You can find movies on the internet for free that take not much less space than the block chain.

Modern full nodes can even run without keeping blocks on disk at all (see the -prune option in Bitcoin Core). In this mode, all blocks are still downloaded and verified one by one, but not kept on disk after verification. The only thing that is kept is the UTXO set - the database of the current state of the ledger, rather than its entire history. This is sufficient for validating future transactions and blocks, participating fully in the P2P network, and provide wallet functionality.

So can't we use your idea for the UTXO set instead then? Maybe, but it's pretty pointless. The reason you run a full node in the first place is to be able to verify that nobody is violating any of the rules. If you're willing to not do that completely anymore and instead start relying on trusting some of your peers, why bother? Bitcoin provides a lightweight mode where you don't need access to either the blockchain or the UTXO set at all.


Is there a way to a get a list of all address tags from Blockchain.com? (either by scrapping or API)

You can try walletexplorer.
Or start compiling this list yourself, there is a ton of false data there. So if you are looking for quantity, I'd suggest walletexplorer, for quality you have to do attribute these services on your own.


CGMiner and 5830's give my the BSOD and GPU hangs, DEAD threads

Try to lower GPU clock a little bit to let's say 900MHZ or stock, and also make sure that the memory clock is not lower than 300MHZ. After that try to keep an eye on the GPU temperatures as this may be the cause of the sudden BSOD. Also there is a intensity parameter, if you keep it as 9 then try to lower it to 7. My config for 5830 looks like this:

{
"pools" : [
    {
        "url" : "mint.bitminter.com:8332",
        "user" : "username_workername",
        "pass" : "worker_password"
    }
],
"intensity" : "9,9,9,9",
"gpu-engine" : "0-950,0-950,0-950,0-870",
"gpu-fan" : "0-85,0-85,0-85,0-85",
"gpu-memclock" : "300,300,300,300",
"gpu-powertune" : "20,20,20,20",
"temp-cutoff" : "95,95,95,95",
"temp-overheat" : "85,85,85,85",
"temp-target" : "80,75,75,80",

"algo" : "4way",
"auto-fan" : true,
"auto-gpu" : true,
"expiry" : "120",
"failover-only" : true,
"gpu-threads" : "2",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"temp-hysteresis" : "3",
"worksize" : "0",

"donation" : "0.00",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

and works for over a year now :)


In MuSig-DN why not use a truly random number for the nonce instead of a pseudorandom function?

This question was answered by Tim Ruffing on Twitter.

The answer is simply that it's not easy to get truly random numbers
right in practice. For example, you need to collect entropy in your
system, and it's hard to write a "test" that checks if your numbers
are really random.
Broken random number generators have led to numerous real-world
failures e.g.
https://www.schneier.com/blog/archives/2008/05/random_number_b.html
and
https://arstechnica.com/information-technology/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/
So it's better to simply avoid real random number generators in
practice, and this is well-established best practice for "normal"
single-singer signatures (Schnorr sigs, ECDSA). MuSig-DN makes this
possible for multisignatures, too.
But your point is correct in theory. If you have a working source of
truly random numbers, this will just do the job.

Pieter Wuille and Jonas Nick added on Twitter:

A working source of random numbers and a place to keep them securely
and tamper-proof between the rounds of the signing process.
Or just a place, to keep a counter securely and tamper-proof between
the signing sessions. Ideally combined with an RNG.

But that is also true for the generation of the private key and we tolerate that there?

Perfectly right, yes.  I think the answer here is two-fold:

We can at least try to avoid real numbers as much as possible. Even for key
generation, we can derive all keys from a single seed, and then we
really rely on randomness only once in the life of a wallet for that
seed

It seems that the randomness is particularly brittle when it comes
to nonces used in signatures. For example, if you fix a single bit in
the nonce, then a few signatures may already be enough to derive the
secret key.

And maybe my second point is not even a valid one. I don't know enough about the concrete attacks to tell if signatures become suddenly insecure when we fix a single bit in the secret key (instead of the nonce)?

Diego Aranha added on Twitter:

Your second point is valid when applied to nonces, but a lot more than a few signatures are needed for 1-bit bias (something like 2^60 for an attack of feasible complexity for secp256k1). Fixing bits of the private key should just reduce the key space

And Akira Takahashi added on Twitter:

Indeed, attacking 1-bit nonce bias of Bitcoin ECDSA is currently out of reach, but 2-bit bias is already exploitable given about one million signatures and 3-bit only requires several thousands (or even less if lattice attack works). Not sure how bad a biased private key can be.
A middle-ground solution would be to include some nonce as PRF input. This way, you retain security even if the nonce is not truly random (proof: https://ia.cr/2016/290) and it should thwart the devastating rewinding attack on Schnorr multisig without ZKP.
But just to be clear, this solution still breaks down once the honest signer reuses the nonce. Dealing with such a stateful scheme is annoying and this is why purely non-stateful solutions like MuSig-DN are preferred in practice.


How to set custom segwit change address in v0.15 Core via config

Is there a way to set custom change address (segwit preferable) in bitcoin core via config or some parameter (not via GUI).

Not in 0.15 I believe, you would have to create a raw transaction manually with the change being sent to the address you wanted. Better support for segwit addresses is coming in 0.16

  Is there a way how to report this to core developers

Yes, you can submit bug reports to the issue tracker on GitHub here: https://github.com/bitcoin/bitcoin/issues


What is the risk of waiting for just one confirmation to validate a transaction, assuming the counterparty is not a miner?

Should I be worried of such blockchain reorganizations when accepting n-confirmation transactions?

Forks do occur quite frequently, and if you're only requiring a single confirmation the counterparty will have the opportunity to double spend each time these orphaned blocks occur.

  Am I right to say that any successful 6-block fork would open the risk of free riding the double spending of ALL transactions not included in the fork, not just those targeted by the rogue miner?

Yes, a successful 6-block fork would allow double spending for all n-confirmation transactions not included in the fork, where n ≤ 6.

  Would most nodes (including the rogue miner) most likely reject the free-riding double spend attempts anyway (even if its transaction fees are set way higher), as the first transaction would by that time be fully disseminated?

Hard to say. The bitcoin protocol doesn't explicitly have a rule for n-confirmations (this is just an accepted number of confirmations after which the receiver of a transaction can be reasonably sure double spending will not occur), so according to the protocol, the transactions would be valid. I doubt there are many miners with logic built in to deal with this scenario since when it becomes anything more than close to impossible (an entity having about half the computing power of the network) the currency probably won't have legitimacy left (therefore no value in them acting as miners).


Transactions can 'claim' from multiple addresses. In fact, the default client will do it if your balance is spread out amongst multiple addresses when you want to make a transaction.


When exactly an entry is removed or added to the UTXO's set in the Bitcoin core?

When exactly an entry is added to the set of unspent transactions outputs?

  When exactly an entry is removed from the set of unspent transactions outputs?

The answer to these questions is that there is no singular set of unspent transaction outputs. There are multiple versions that are maintained and/or implied for different purposes.

1) There is the UTXO set defined by the on-disk LevelDB database. This only changes after a flush (see further).

2) There is the UTXO set defined by the in-memory cache (the pcoinsTip object). It represents the state of the network at the current best block, but does not include the effect of any unconfirmed transactions. Whenever the number of changes in this cache grows too big (see -dbcache) it gets flushed to disk.

3) There is the UTXO set defined by the memory pool. It consists of the UTXO set defined in 2, plus all outputs created by unconfirmed transactions, minus all outputs spent by unconfirmed transactions. This changes every time the mempool changes. Note that this UTXO set is nowhere materialized explicitly - it's just defined by what is in the cache (see 2) and unconfirmed transactions in the mempool.

  Whats' the difference between validating a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).

From the top of my head:

Only consensus rules are validated, not policy/standardness rules
All scripts are validated in parallel (on multiple CPU cores)
The changes are flushed to pcoinsTip (and possibly to disk)


Why is there a need for different exchanges?

Different countries, different laws, different currencies, different banks, different payment systems.

Competition and free market.

No single central point of failure.


Is there a list of charities that accept Bitcoin donations?

The most comprehensive list I can find is here: https://en.bitcoin.it/wiki/Donation-accepting_organizations_and_projects

There is also a website "Bitcoin-Charity" which converts BTC to $ on behalf of charities, promising not to put more than 1% towards admin costs. A neat feature of this site is that no technological knowledge is required by the charity to receive donations, and the total donated to date is listed (though it would be better shown in $ than BTC, or both). They currently have 9 charities listed: www.bitcoin-charity.com/charities/

Edit note: bitcoin-charities.com is no longer active.


bitcoinj uses a date of birth of the wallet. With this you avoid reading the entire blockchain to restore the wallet


Are there any "slow" sidechains? What are the tradeoffs?

Are there any "slow" sidechains?

Softchains fit this definition. Softchains are a type of sidechain that are verified by all mainchain users in a slow but extremely resource-efficient way, by only validating the blocks for which forks occur. It's slow, because you can't assume these forks will occur right away. People who want to actively use the softchain perform full validation, which means consensus will be fast for them.

What are the tradeoffs?

These softchains are not fully decoupled from the mainchain. Creating a new softchain requires a soft fork, and softchain consensus could negatively affect mainchain consensus under some scenarios (software bugs, one-year reorgs). Furthermore, mainchain validation cost goes up by roughly 100MB per softchain per year (which could be compensated for with a mainchain block size decrease).
The above is just a high-level overview.
For a relatively easy-to-follow explanation, I recommend listening to this podcast:
https://youtu.be/4c7cwTts3fo?t=1m45s
And the full details are in this write-up:
https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1


Quadratic hashing problem: Why not just create new OP code "CHECKSIG2" to fix?

Note: As of 2020 this answer is obsolete, as BIP143 / SegWit has been in use for years which fixes this concern.

You can fix it this way, and someone is in the process of doing so.
The problem with hashing the entire transaction is that in order to create a transaction hash, you must know the signature. However, in order to create the signature, you need to know the transaction hash. To make this work, you need to avoid hashing the scriptSig. This is what Bitcoin does, but the way it's implemented prevents you from taking the hash for one output and using it for another.
BIP143 (part of segregated witness) proposes a system where data is (mostly) hashed once.

A new transaction digest algorithm is defined, but only applicable to
sigops in version 0 witness program:
Double SHA256 of the serialization of:

nVersion of the transaction (4-byte little endian)
hashPrevouts (32-byte hash)
hashSequence (32-byte hash)
outpoint (32-byte hash + 4-byte little endian)
scriptCode of the input (serialized as scripts inside CTxOuts)
value of the output spent by this input (8-byte little endian)
nSequence of the input (4-byte little endian)
hashOutputs (32-byte hash)
nLocktime of the transaction (4-byte little endian)
sighash type of the signature (4-byte little endian)

This gets run for each input. Every part of this is fixed length, except for scriptCode, but there's no way to make one scriptCode be hashed by multiple inputs. There are three inputs based on variable-length information, hashPrevouts, hashSequence, and hashOutputs, but there's limited potential for mischief there. All methods of computing them either hash one input/output, or are shared by the entire transaction, or are all zeroes.
Validating very large BIP143 transactions will take linear time, and be dominated by signature verification. However, BIP143 transactions cannot be made right now, as segregated witness has not been accepted by the miners.


Security for bitcoin businesses with Employees

Why would you need to reimburse a customer? They should give you exact change and there's really no reason for them not to. I would recommend creating a daily cold storage wallet to receive bitcoins and then using some kind of online wallet service with a watch-only address so your employees can see the new deposits but they can't actually withdraw any of the coins.


One easy way to check if your node is active and running and reachable by nodes is to head over to bitnodes and use the IP address of the machine running bitcoin core (or if you are on a home network, you'll need to find out your public IP address, which can be found by visiting What is My IP) and enter it into the "Join the Network" tool. Remember that your node will only accept incoming connections once it is fully verified, which can take a bit of time.

If you struggle with getting incoming connections to work, give the Networking Configuration section of the Running a Full Node docs a read.


A hard fork is something that happens when some of the nodes on the network follow a new set of rules that are in some way incompatible with the existing set of rules.  It occurs upon mining the first block that is valid under the new rules, but invalid under the old.

The software following new rules is deployed and in place before the fork occurs, but doesn't actually start using those new rules until some triggering event.  In practice, this event is when a certain percentage of the last X blocks have been mined by nodes supporting the new rules.  This event is called activation of the new rules.

The fork, however, doesn't occur until a block is found by the nodes following the new rules, that is invalid to blocks following the old:

[G] [G']
 |   |
[F] [F']
 |   |
[E] [E'] <-- Hard fork occurs when this block is mined
 | /
[D]
 |
[C]
 |
[B] <-- "forking" nodes start following new rules here
 |
[A]

Here we see an example where the nodes following the new rules activate at block B.  However blocks C and D are valid under the new rules, and the old rules, thus they don't cause the fork.  When block E' is mined, it is only valid under the new rules, meaning that it is rejected by clients who follow the old rules.  Those clients that reject the block go on to mine E, and we now have two irreconcilable chains.


The first transaction, Satoshi sending 10 BTC to Hal Finney, was recorded in block 170.


How to verify if a transaction is signed correctly?

Pubkey script alone is not enough to verify a transaction, you'll need:

Pubkey script, to evaluate the scripts
Amount, in order to check if the sum of inputs is bigger than or equal to sum of outputs
Index (in TxOut list) and tx hash of the transaction being spent
Block height so that you can set the consensus rules

After gathering all the above (should be found in the node's UTXO database) you can start evaluating if the provided script is valid which isn't limited to signature verification but running/evaluating the script that includes checking correctness of the script, OP codes, OP count, script size,...
A lot of the verification can be found in validation.cpp file.
This is also how I do it in Bitcoin.Net library.


Probably the most appealing way to do that would be by using Physical Bitcoins - they look nice as coins, and since they can hold Bitcoins, it's another bonus. It's definitely better for casual people than giving them Bitcoins in a normal way - at least coins are something they can physically grasp, rather than trying to understand what a cryptocurrency is.


There are no timeouts, and a valid transaction can be mined at any time.

The only thing that can ensure a particular transaction won't get mined in the current block chain is to make it invalid.  The only practical way to do that is to create a confirmed double spend---another transaction that spends one of the same inputs as the transaction you don't want mined.  Once that double spend is confirmed, your original transaction can't be added to a block in the same block chain as the confirmed double spend.


You can do it like this:

1) getblockcount gives you the most recent block you have [call it n]

2) getblockhash n gives you the hash for that block [call it hash]

3) getblock hash gives you the block. You can compare the time of that block with the current time, and estimate how many blocks behind you are. It should be approximately (now - blocktime) / 600 if the times are in seconds.


Gamblers will pay a premium to play on a trusted, reputable site that has a long history of not defrauding its customers.

As noted by LocalBitcoins, Betcoin is accused of shady behavior, including lying about their trademark, failing to correctly use a provably fair system, playing on their own site to inflate volume, and DDoSing competitors. Source: http://bitcoinmagazine.com/7659/betcoin-tm-allegedly-fraudulent-activity/


Can I do a replay attack to spend my testnet bitcoin on the mainnet?

The answer is no, you can't, because the two chains don't share a common history.

Internally, transactions don't spend "from" an address. Instead, they refer to a specific output created by an earlier transaction which they consume.

In order for a replay attack to work, that same transaction whose outputs are being spent must exist on both chains. This is only possible when the two chains share a common history, and the earlier transaction either occurred before the fork (so it exists on both sides), or it itself was already a replay.

As soon as a transaction's history is not identical - meaning it consists of the same transactions leading up all the same to the same coinbase outputs that created the coins - they cannot be replayed, as the txids of the inputs will not exist in both chains.


0.2% is taken from each trade, so if you sold BTC for $100 USD you'd get $99.80 in your account.

Coin deposits are free, withdrawals are subject to a generous miners fee.

Fiat deposits/withdrawals vary from something like 1% to 6% I can't recall off the top of my head.


What can I do if someone obtained control of my blockchain wallet?

To be completely safe, you should throw away every piece of information and data to do with the old wallets used or accessed by the scammer. user-ids, passwords, recovery phrases, backups, keys, addresses and anything else that is related to anything the scammer had access to.
Those wallets and the keys in them are forever unsafe. Even if you reset passwords, change 2FA or do anything else they are still unsafe forever.
In those circumstances I would assume the scammer also has back-door access to any computers or phones or other devices that you, or anyone else in your house owned at the time of the scam.
I would back up any important data (photos, email, other documents) and wipe those devices clean and reinstall the operating systems then sell them.
I would only create a new wallet using reliable sources on a new computer or phone that has never been used on the same local network as any of the devices owned at the time of the scam.
This may seem extreme and it may be unlikely that all of it is necessary in your case. But you don't know for certain. The only way to be sure is to take extreme measures so far as you are able and/or live with the remaining risk.
If you are 100% certain the scammer never persuaded you to install software and never used remote access to share a screen to help you, then your devices might be OK, but you need to be certain.

Postscript:

Typically, potential investors are prompted to fill in an online contact form and then encouraged over the phone to set up a cryptocurrency wallet - but unknown to them the scammer installs remote access software on their device, granting them access to it as well.

From https://www.bbc.co.uk/news/technology-57267199 2021-05-27


How i get callback notification while BTC received to wallet

you have to use ZeroMQ for that purpose see Bitcoin/zmq once you receive a transaction you can get a notification.

Bitcoin/zmq doesn't tell you if some transaction confirmations changed, so you can check transaction confirmations manually by calling getrawtransaction

You can use walletnotfiy as well

walletnotify=/bin/curl http://127.0.0.1/receive.php?trx=%s


The Blockchain.info Android Wallet app is open-source and has been heavily peer-reviewed by the community. Your private key is stored on the device once scanned, but it is encrypted with a password so even if you lose your phone they won't be able to access the key.

As for the using safe ROMs, Android is a very secure sandboxed virtual machine that has been rarely compromised. The encryption of your keys is based on powerful and heavily tested Java libraries which run on an open-source platform called Dalvik, which is based on the Java Virtual Machine (JVM).

In other words, you really couldn't ask for a more secure environment.


How to get the MPK using bitcoinj and how to generate the addresses using the MPK?

I have found the way to do it:

    DeterministicKey extendedKey = wallet.getWatchingKey();
    String mpk = extendedKey.serializePubB58(wallet.getParams());


How does Blockchain as a Service (BaaS) work?

Who runs the nodes?

It depends on the type of Blockchain network you referring to. Typically it is permissionless or permissioned. For the permissionless; anyone/ any organization can volunteer to run full nodes as long as they ready to allow spare computing and bandwidth resources. No incentive Nor reward for this service. In future respective Blockchain company /developers - they may consider for incentive/s or rewards. This would ensure  more and more nodes running at a given point in time. More nodes means more secure for the block mining and there by your secure transaction/s. In recent past, there has been significant drop in "running full nodes". This is a bit of concern.

In addition, permissionless P2P network no access control is needed. Ex. bitcoin/ ethereum supports X.509 certificates and SSL encryption to verify receivers’ identity and help prevent man-in-the-middle attacks. Besides, Blockchain security validate each new block and follow protocol proof-of-work/stake which guarding against the bad actors.


Fail to sign the Segwit Transaction's input in bitcoinj

In general is should be like:
// input index to sign
int index = 0;
// amount to sign (must equal to actual input value)
Coin value = Coin.valueOf(123456);

TransactionSignature signature = tx.calculateWitnessSignature(
   index,
   prvKey,
   ScriptBuilder()
      .data(ScriptBuilder.createP2PKHOutputScript(prvKey).program)
      .build(),
   coin,
   Transaction.SigHash.ALL,
   false
);

tx.getInput(index).setScriptSig(ScriptBuilder.createEmpty());
tx.getInput(index).setWitness(
  TransactionWitness.redeemP2WPKH(signature, prvKey)
);


Who pays for that, and how much? Do I pay per bit whatever the market value is for block space at that time?

The fee for the commitment transactions is determined at the time of channel creation. It can also be updated. So when you broadcast the commitment transaction, the fee will already be set to whatever you two agreed to at channel creation.

The person who pays the fee is also negotiated at channel creation. The current specification says that the person funding the channel will be paying the transaction fees (currently only one party funds the channel).

  With the claim on my entire bitcoin where do the transaction fees come from?

There is no "claim on your entire bitcoin". The other party cannot claim your money unless you agreed to it by signing a commitment transaction. The merchant can only say "you owe me one Bitcoin" but nothing actually happens to the Bitcoin itself.

  What would prevent somebody from using this "pay to take it to court at auction prices" model as a denial of service or theft? For example, a large actor opens many channels and funds them so they are used as hubs....then when well established he "outright disconnects" some large number of those channels. Now there is very high demand for limited blockspace as everybody tries to dispute before the deadline. What happens next? What if there is so much congestion that disputes can not be made fast enough?

If the most recent commitment transaction is broadcast, there is no "dispute". It is just a normal unilateral channel closing and both parties will get their money eventually (the broadcaster must wait out the relative timelock).

If an old commitment is broadcast (and thus fraud is occuring), then there will be only two transactions for each channel closing ("disconnect") and revocation ("dispute"). The closing transactions need to be confirmed before the delay goes into effect. So if there is a shortage of block space, then not all of those closing transactions will be confirmed. When they do confirm, the other parties can then broadcast their revocation transactions and have those confirmed.

Furthermore, because the transaction fee for the closing transaction must be negotiated by both parties and the amounts can only be changed by both parties signing the transaction, the attacker cannot change the transaction fees. So the people broadcasting their revocation transactions have full control over their transaction fees, so they can increase the fee as necessary to have their transaction confirm faster.


If I have a join shared wallet and my partner lost the backup, can we recover this if i can i see the BTC yet?

Assuming this is a 2-of-2 multisig shared wallet, it is not possible to do anything with the coins without signatures from both wallets.  Bitcoin uses strong crytography, and when signatures are required, they're really, really required.  That's why it's secure.

If your partner has irretrievably lost the wallet and backup phrase, then the two of you have irretrievably lost the coins.  Sure, you can see them, but you'll never be able to spend or transfer them.

Sorry.


bitcoin core command line walletpassphrase incorrect but works for the main system?

If your passphrase contains spaces or special characters, you will need to wrap it with single quotes (') so that the debug console can properly parse your passphrase. For example, if your passphrase were This is my passphrase, then your command should be

walletpassphrase 'This is my passphrase'


Some miners set the nVersion field of the block header to 0x8000004. What were they signalling for? Was this an error?

This block signaled support for BitPay's adaptive Block Size Proposal and was mined by slush pool.
I asked slush this exact question on twitter back in 2016!
https://twitter.com/slush_pool/status/744461234389524480
Note that this answer is not entirely complete, because the BitPay proposal specifies:

Miners express their support for this BIP by setting the
fifth-highest-bit in the block's 32-bit version number (0x08000000 in
hex)

But these blocks as you note also set bit 2 (0x00000004) which was not addressed by slush in his answer.
During this era, several other soft-fork proposals were being floated around that (due to lack of coordination a.k.a. decentralization) collided on their BIP9 signals. One was Extension Blocks. I'm having trouble finding links but I believe also at that time there was Rootstock (RSK) proposal that defined bit 2 as the signal, and an anti-asicboost proposal by Greg Maxwell that also signalled bit 2.


Beginner Setup Bitcoin Full Node without GUI

In the very same guide you linked, follow the instructions for the Bitcoin daemon.

  I tried to start the daemon and hope it will download the data but it seems nothing change on H.D. usage so I am guessing it is not downloading. Am I correct?

No, you are not correct. You should check the status of bitcoind itself by using bitcoin-cli to send commands to it. You can use getblockchaininfo to know whether it is actually syncing by calling it twice. If it is syncing, then it will report a different block height and best block hash on the second call.


10 satoshis/byte would have gotten you a confirmation in five days for big parts of the past three months:

 [via https://core.jochen-hoenicke.de/queue/#3m, filter by 10-20 sats/byte]

Yet, I'm afraid that you cannot rely on getting a confirmation within five days at 10 satoshis/byte.

In the past three months, there were e.g. two weeks in August, where only a few blocks had transactions with <10 sats/byte. It's very likely that you would have gone without confirmations for sixteen days. Earlier this year from early May to mid of June, you would not have gotten any confirmation at all for six weeks.

Also, please think about your users' experience. When they end up with a large number of very small unspents, it will be uneconomic for them to spend them: a big portion would get eaten up by fees, at higher fees they would be unable to make any payments at all.

Unfortunately, since the cost of transactions is in relation to the blockchain space transactions require to get confirmed, the relative cost is significantly higher for micropayments than for larger sums. I would highly recommend looking either at off-chain solutions or other blockchains.


With web wallets you need to be careful. As you stated, if they get hacked and they store your private keys, your Bitcoins are at risk. You really just need to ask yourself:

how risk adverse are you?
can you afford to lose your coins?
does the convenience of a web wallet outweigh the risks?


I run bitcoin core. What should I prepare by August 1st?

According to UASF Working Group

What do users need to do to enforce BIP148?
It is recommended that users do not update unless an economic majority commits to updating and users are aware of the risks and mitigations of a failed UASF deployment.
Users aware of the risks and who want to commit should use clients that enforce BIP148. Users that run full nodes would upgrade to one that enforces BIP148, or run their node behind an upgraded border node. Users of light clients (like mobile wallets) should check with each vendor to see their support for BIP148. We plan on documenting any public responses from wallets regarding BIP148 support.

This web-page describes the mechanism for any User Activated Soft Fork (UASF)


It seems to me that the ports aren't matching:

You've set your first node to port=8333 and your second node to port=8330. However, you've called addnode with …18332. Maybe that's it?


Installed MacOSX over HDD containing wallet

I have no experience and I think you would be mightily lucky if you succeed in recovering your wallet file, but I'd advise you to stop using that HDD (to avoid too much writes) and try googling for the problem and trying all the proposed solutions.


Profitability comparisons for Quarkcoin and Primecoin?

The answer is that XPM(http://primecoin.org/static/primecoin-paper.pdf - see "Introduction", especially 2nd paragraph) and QRK(http://www.quarkcoins.com/bitcoin-vs-quarkcoin.html - see "SECURITY" section) have developed their own algorithms. They are not based on SHA-256 proof-of-work(used for BTC and alike - [SHA-256 CRYPTOCOINS][3]) nor on scrypt proof-of-work(used for LTC and alike - [SCRYPT CRYPTOCOINS][4]) hashing algorithms.

The websites which compare profitability use the hashrate you provide(either in SHA-256 or scrypt), the difficulty of the network and the actual price of the respective cryptocurrency in order to make a prediction on how much you can earn by mining.

The 2 cryptocoins we are discussing here are relatively new in the market, thus there is no existing database containing a list of hardware and their respective hashrates for this algorithms. As time passes, if those new coins will receive the needed attention, the community will create the needed resources in order to be able to make an estimate of earnings based on your hardware for XPM and QRK. Then everyone will be able to compare the profitability of mining.

Until then, you can only make your own calculations as there is no website to help you.

  Due to my low reputation I can only post 2 links here. Please find
  the links for reference [3] and [4] in the comments.


CryptoCompare API gives wrong historical daily OHLC data

CryptoCompare has been known to sometimes present inaccurate data in US dollars when complex conversions happen.

For instance, if during the date you queried the BTC to some other reference coin price oscillated, the Bitcoin to altcoin price may have had a low price in Satoshis but the Dollar quote to one of the coins (BTC or the reference altcoin) could've been higher at that particular moment. So the Satoshi price could've been the daily low but the Dollar price could've been a bit higher. Note that in late 2017 there were wild intraday USD price oscillations.

The 2nd data item, where you spotted the bug, happened on 10/06/2017 @ 12:00am (UTC) when Bitcoin prices were at around U$ 4324, which doesn't match anywhere close to the quote you got there. So there's some conversion going on indicated by ...

"ConversionType":{"type":"multiply" ...

...in the JSON data, which you didn't specify in your question. That applied conversion and its relation to the US dollar are the keys to fixing the bug in your program.


Does any exchange site let me automatically sell Bitcoin to USDT (or USD) right after I receive it?

You can use one of the Bitcoin exchanges and using their API, create something with the following logic:
while True:
    current_balance = get_balance("BTC")
    if  current_balance > 0:
        crypto_exchange.sell_market_order(current_balance)
        print("Sold %s" % current_balance)
        break
    else:
        time.sleep(60)

This would automatically sell your crypto as soon as its confirmed as an active balance on the exchange and it would "hedge" your crypto exposure in the process.


What cryptographic operations are performed on the 3 public keys to produce a multisig (2 of 3) address?

To better understand multisig addresses and transactions, it's useful to read BIP 0013 and create a multisig address using https://coinb.in/multisig/

If I want to create a multisig that requires signatures from 2 of the 3 following pubkeys:

04c96a8b79aff49f36766b7827308bb5d6dc031e4e9112b785201a9a61821d2a336dbb7fa69f44c2dc76dee8fa7ed8fee2958f4a86a3dbb7ebf3eeb790cd464db9
04fd6c4db8841f7370a0cdc464a58b3e2a0da5b6566e0502a9cf583360bcdd16e8453a0a8da0fba0ff26e40c1f8c55f8cd0ad61988b7d4418b504264be8a9cef59
04c41b31403f24ef79e9c7dcfb67ea0341fcb986e9555123b022258a92d2bade3674574bf3de7affe93706399d9eb76d04f05213cda8b8e8bb8541533c39f244a9

The resulting multisig script is this: (broken down by OP code)

52 OP_2, meaning you need two signatures
41 push 65 bytes
04c96a8b79aff49f36766b7827308bb5d6dc031e4e9112b785201a9a61821d2a336dbb7fa69f44c2dc76dee8fa7ed8fee2958f4a86a3dbb7ebf3eeb790cd464db9
41 push 65 bytes
04fd6c4db8841f7370a0cdc464a58b3e2a0da5b6566e0502a9cf583360bcdd16e8453a0a8da0fba0ff26e40c1f8c55f8cd0ad61988b7d4418b504264be8a9cef59
41 push 65 bytes
04c41b31403f24ef79e9c7dcfb67ea0341fcb986e9555123b022258a92d2bade3674574bf3de7affe93706399d9eb76d04f05213cda8b8e8bb8541533c39f244a9
53 OP_3, meaning there are three public keys
ae OP_CHECKMULTISIG described at https://en.bitcoin.it/wiki/Script

And the page tells me the address for it is 3K6sEDqXaSFKjcq8PUKNsGbxXjBR8QmBWr

The hash of this script, along with a version number (to make the starting character 3) and checksum (to ensure that a misentering of data is not likely to go through) is what makes up the multisig address:

base58-encode: [one-byte version][20-byte hash][4-byte checksum]

You can verify this by comparing the hash160 value shown at https://blockchain.info/address/3K6sEDqXaSFKjcq8PUKNsGbxXjBR8QmBWr and the result of the following short C# program: they are both befcdceed8cbf0d74d9d58bf8e30ce027e8a9b56

var data = new byte[] { 0x52, 0x41, 0x04, 0xc9, 0x6a, 0x8b, 0x79, 0xaf, 0xf4, 0x9f, 0x36, 0x76, 0x6b, 0x78, 0x27, 0x30, 0x8b, 0xb5, 0xd6, 0xdc, 0x03, 0x1e, 0x4e, 0x91, 0x12, 0xb7, 0x85, 0x20, 0x1a, 0x9a, 0x61, 0x82, 0x1d, 0x2a, 0x33, 0x6d, 0xbb, 0x7f, 0xa6, 0x9f, 0x44, 0xc2, 0xdc, 0x76, 0xde, 0xe8, 0xfa, 0x7e, 0xd8, 0xfe, 0xe2, 0x95, 0x8f, 0x4a, 0x86, 0xa3, 0xdb, 0xb7, 0xeb, 0xf3, 0xee, 0xb7, 0x90, 0xcd, 0x46, 0x4d, 0xb9, 0x41, 0x04, 0xfd, 0x6c, 0x4d, 0xb8, 0x84, 0x1f, 0x73, 0x70, 0xa0, 0xcd, 0xc4, 0x64, 0xa5, 0x8b, 0x3e, 0x2a, 0x0d, 0xa5, 0xb6, 0x56, 0x6e, 0x05, 0x02, 0xa9, 0xcf, 0x58, 0x33, 0x60, 0xbc, 0xdd, 0x16, 0xe8, 0x45, 0x3a, 0x0a, 0x8d, 0xa0, 0xfb, 0xa0, 0xff, 0x26, 0xe4, 0x0c, 0x1f, 0x8c, 0x55, 0xf8, 0xcd, 0x0a, 0xd6, 0x19, 0x88, 0xb7, 0xd4, 0x41, 0x8b, 0x50, 0x42, 0x64, 0xbe, 0x8a, 0x9c, 0xef, 0x59, 0x41, 0x04, 0xc4, 0x1b, 0x31, 0x40, 0x3f, 0x24, 0xef, 0x79, 0xe9, 0xc7, 0xdc, 0xfb, 0x67, 0xea, 0x03, 0x41, 0xfc, 0xb9, 0x86, 0xe9, 0x55, 0x51, 0x23, 0xb0, 0x22, 0x25, 0x8a, 0x92, 0xd2, 0xba, 0xde, 0x36, 0x74, 0x57, 0x4b, 0xf3, 0xde, 0x7a, 0xff, 0xe9, 0x37, 0x06, 0x39, 0x9d, 0x9e, 0xb7, 0x6d, 0x04, 0xf0, 0x52, 0x13, 0xcd, 0xa8, 0xb8, 0xe8, 0xbb, 0x85, 0x41, 0x53, 0x3c, 0x39, 0xf2, 0x44, 0xa9, 0x53, 0xae, };
var sha256 = System.Security.Cryptography.HashAlgorithm.Create("SHA256");
var ripe = System.Security.Cryptography.HashAlgorithm.Create("RIPEMD160");
Console.WriteLine(string.Join("", ripe.ComputeHash(sha256.ComputeHash(data)).Select(x=>x.ToString("X2"))).ToLower());

Then when you want to pay that address, you use pay-to-script-hash output instead of a pay-to-pubkey-hash.


Can I have a bitcoin pool joining another bitcoin pool

Yes, a pool can mine through another pool. There are pools already doing this as you can see under the "proxy mining pools" heading of the mining pool list at https://bitcointalk.org/index.php?topic=104664.0

You won't control which transactions go into the blocks or be able to vote directly with the hashpower. You'll be providing hashpower to another pool that decides how to use it.

The technical part of proxying

If the upstream pool allows you to mine with a larger extranonce2 size than the regular 4 bytes, then you could use a single connection to the upstream pool and partition up the work you receive for your downstream miners with extranonce2 size of 4 bytes. If the upstream pool does not allow this then you'd need to create one connection to the upstream pool for each downstream miner and just pass the work data through like a plain proxy.

In either case you'll need to observe work submitted by your miners and whether it is accepted or rejected by the upstream pool.

Having one upstream connection per downstream miners means a lot of connections. But it simplifies counting accepted and rejected work for your miners, as upstream and downstream difficulty would be the same. You just pass everything through and watch to see what is accepted or rejected by the upstream pool. If you are mining on a single upstream connection then you'll be mining at a very high difficulty in the upstream pool. You can't have your miners all mining at that high a difficulty. So you'd need to process the lower difficulty work that does not meet upstream difficulty yourself instead of passing it upstream for acceptance/rejection. Whenever work from low difficulty miners do meet the upstream difficulty, then their work must of course be passed upstream.

You'll probably want to contact the upstream pool ahead of time. If you create 1000 connections to their pool from the same IP address there could be problems.

Reward system

If you use the PPS reward system things are pretty simple (but extremely risky). If you use something else then you'll need to think about whether it is safe from pool hopping or not. I'm not sure if anyone has ever analyzed whether you can pool hop a PPLNS pool that proxy mines another PPLNS pool, for example.


My spv node received in a nTx = 2 in headers message

I have found what I was missing.

Dogecoin switch to merged mining so the header has a new structure which I didn't know about. I found this wikipedia page (https://en.bitcoin.it/wiki/Merged_mining_specification#Merkle_Branch) which explain everything.

I should have noticed also that my nonce is 0. When I see this and that the next bit is not null I can extend my structure to a merged mining header.

I hope it will help people.


Best way to anonymize bitcoin transactions?

The idea behind Coinjoin or Sharedcoin is that funds can be pooled and mixed with several other Bitcoin users to fund new transactions that can't be easily traced back to you.

Here is a trivial example: imagine 3 users, that want the funds from 3 addresses the each control A (0.5 BTC), B (0.5 BTC) and C (1 BTC) to be sent to addresses X, Y and Z respectively. Instead of transferring the funds directly a service could do the following, assuming intermediary addresses:

A(0.5) --> L(0.5) --\
B(0.5) --> M(0.5) -- +
C(1)   --> N(1) --\   \-- Z(1)
                   \
                    \--- X(0.5)
                     \--- Y(0.5)

So the money originally from C gets split and sent to X and Y while the money from A and B gets added and sent to Z. Mixing services do the equivalent but across much more transactions.


Where to find the amount that is being sent in a signed transaction?

USDT on the Bitcoin blockchain uses the Omni layer, which encodes data in the OP_RETURN outputs. In your transaction, the amount is 0000000006052340, which is hex for 101000000. Omni has a precision of 8, so you can divide that by 10^8 to get 1.01.


Bip39 tool - BIP32 Extended Private Key vs BIP32 Root Key

If you want to import a wallet, you should import a BIP32 extended private key. It is often derived from mnemonics.

What is the difference if I import the BIP32 Root Key or if I import the BIP32 Extended Private Key ?

The terminology is a bit confusing. The BIP32 derivation is done using a number, called the chaincode, over a private key (called the master private key). This private key has nothing special: it's just the starting point of the derivation.
The concatenation of a private key and the chaincode is called an extended key.
To import your wallet you need to import the master extended private key.
Regarding your question about BIP44, it is not a replacement to BIP32 just a set of recommendations of how to use it.
NB: you might be interested in the description of the key derivation process by the bitcoin.org documentation.


Can the same wallet be run from multiple computers

The same receiving address can be used as many times as you like, though with some loss of anonymity.

However, if you run the client on multiple computers with the same wallet file, you'll run into problems; even if you start with an exact copy of a wallet on both computers, they'll get out of sync eventually if you make transactions from each copy.

The Bitcoin-QT client generates up to 100 addresses in advance and stores them in the wallet, but at some point will generate more. Most "send" transactions use one of those addresses as a change address. If you're sending from 2 clients which started with the same copy of a wallet file, at some point they will start using addresses that did not exist in the original wallet file. At that point, bitcoins in one wallet will not be available to spend from the other wallet.


Money can now be stored in a single file inside your hard drive. This is a natural target for criminals so yes, there are virus that steal bitcoins.

If you trust a third party (like an ewallet) to hold your coins, you will not have to worry about wallet stealing virus nor about wallet security. Instead, you should protect your login credentials and/or use a two-factor authentication mechanism. Treat your e-wallet account the same way you treat your e-banking account.

I don't know of any dangerous websites, but there was a report of a bitcoin trojan by Symantec on June 2011.


bech32 addresses beginning with "bcrt..." on regtest

Regtest and testnet are different networks. They are not compatible with each other.

Regtest is a private local network which is used solely for testing. It is primarily used for the regression tests, hence the name regtest.

Testnet is the public testing network which is very similar to mainnet, the main network. It has a different genesis block and has actual miners, DNS seeds, and nodes that you can connect to.


Does any pool accept higher-fee transactions of a double spend, instead of the earlier one?

It seems as if there is such a pool now, advertising the behavior as a feature to allow "reverting mistaken payments":

BitUndo

They also supply a patch to bitcoind.


As far as I know, this is not possible. lnd and bitcoind are two separate daemons, that interact with the bitcoin network in different ways.

The only way I could think of doing this would be to import keys from one daemon to the other, but exploring the help command of lnd I'm not currently seeing any options to import or export private keys.

In any case, I think sharing keys across the daemons may in fact be dangerous, as bitcoind will not recognize funds as being locked in a LN channel. So if bitcoind tried to spend a LN channel UTXO, it may cause a total loss of that channel's funds (since your published transaction was not the LN channel's most recent state, the counterparty would broadcast the revocation transaction, and all funds would be spent to them). Perhaps someone with a deeper knowledge of these daemons could comment, but by my reasoning I believe this would be true


The BTC shows 10^8 times more than what is received in the account

Apparently the app shows the amount as Satoshi (the smallest unit) instead of BTC. For internal calculations that's ok because it avoids rounding errors, but for input and output you should scale by an appropriate factor (10^8 for BTC, or 10^5 for mBTC).


Use two tables for deposits basically.

insert deposits into one table with a unique hash. store sighash and txid with a unique hash and timestamp in the other. when the txid changes, you update the second table, preventing the duplicate deposit.


What are the trust assumptions in --assumed-valid in bitcoin core 0.14?

Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.

None. If there happens to be a fork that makes the assume valid block to no longer be in the longest chain, then you will continue to validate all signatures in the longest chain. If someone were to give you a "fake" blockchain which does not include the assume valid block, you would be doing the same validation process as without the assume valid block. Assume valid does not change the security assumptions as the assume valid block does not need to be in the blockchain unlike was done with checkpoints.

  Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2. It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

No, Case 3 has completely different security assumptions from assume valid. You are trusting that the Core developers are providing you the correct UTXO set and by doing so, you are trusting that you will be using the correct blockchain on startup. With assume valid, you are not trusting or assuming that you are using the correct blockchain, you are still validating almost everything. With assume valid, even if the assume valid block is wrong, you can and will still be using the correct blockchain and just doing the same amount of signature validation to be on the correct blockchain as software without assume valid.


You can not cancel the transaction, but what you can do is to spend that same UTXO to a different address of yourselves (effectively a double-spend).
The reason it has no confirmations is likely that the fee is not sufficient for miners to prioritise your transaction in their mempool. As long as it has no confirmations, you can still double-spend to an address of your choosing.


Multisignature: what happens if the number of signatures exceeds the "threshold" number of public keys?

Then the interpreter checks to see that the next value on the stack is
  0, which it is not:

I am not sure, but pushing OP_FALSE is not a requirement, but some kind a mumbo-jumbo to fix the bug in the very first (and still current) implementation of OP_CHECKMULTISIG :)

In fact, you can push 3 or even more signatures redeeming 2-of-3 multisignature output. Not all miners will accept this transaction, because it is non-standard. But it will be valid.


From where does a node download a copy of the ledger

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


Is a public message at blockchain.info embedded in the actual block chain?

It did for a few days, before the blockchain.info operator concluded blockchain bloat was not good for Bitcoin.  Now those are only stored on Blockchain.info hosts.

For more details, see:

http://bitcointalk.org/index.php?topic=40264.msg1165261#msg1165261
https://bitcoin.stackexchange.com/a/4709/153


Format of a block key's contents in bitcoind's LevelDB?

This is the Bitcoin Core v0.15.1 source code snippet that defines the serialization of CDiskBlockIndex. The various fields are:

A varint version number of the client who wrote the record (for future extensibility). This is the 87c628 you're seeing.
A varint block height.
A varint status with various flags.
A varint determining the number of transactions in the block.
If the status field has bits 8 or 16 set, a varint determining which file (blk*.dat and rev*.dat) the block is stored in.
If the status field has bit 8 set, a varint determining the offset into the blk*.dat file where the start of the block is.
if the status field has bit 16 set, a varint determining the offset into the rev*.dat file where the start of the block's undo data is.
The block header


(litecoin) High hashrate but low amount of submitted shares in solo

The system of shares on a pool is set by the pool owner. It is not exactly the same as mining litecoin solo, and in fact some pools will have much smaller shares (pool-x.eu) set up to encourage you to continue mining, even though you are not actually mining more litecoin. Other pools have larger shares which take longer to mine (ltc.kattare.com), but are actually less work for the server so (theoretically) you should get a bit more from the longer ones.  While solo mining you are A) getting all the shares yourself with no "pool power" and B)getting the normal share size for litecoin. Hope this helps, 5mil


Private key to mnemonic words, is it safe?

Here are two mechanisms for converting a 256-bit (64 hexadecimal  characters) seed into a Electrum seed word mnemonics, and back again.

#1 JavaScript-based

#2 C++ - based

However, the command line interface example below, using mechanism #2, uses one of the most unsafe private seeds is used for demonstrative reference purposes only.

1% echo -n "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | ./bytes_to_words

rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper

2% echo "rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper" | ./inverse_mnemonics

0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

The results are repeatable using mechanism #1.

BIP 39 doesn't require invertability support (analogous to ./inverse_mnemonics for Electrum words) albeit it can be accomplished. See How to generate a valid hash for a bip39 seed phrase? for an approach for accomplishing this task.

The mapping back to the BIP 39 root seed in hex is guaranteed to be unique. However, due to normalization associated with ed25519 cryptography, not currently used by Bitcoin, it is possible to have multiple two sets of 25 Electrum words that map to the same functional private key.


So is it that a miner who mined an orphan block receives the outputs of coinbase transaction but can never spend them?

Kind of.

  In such a case the number of bitcoins in circulation would reduce overtime due to creation of orphan blocks.

No, that's not how miners are paid.

Miners are essentially paid by themselves; they are allowed to produce coins out of thin air in the coinbase transaction. There is not some central money supply that the coins come from that pays coins to miners for creating a block.

When an orphan block is mined, the coinbase transaction is basically forgotten. The coins it produces never go into circulation and don't actually exist. Instead they are "replaced" by the block that was accepted by the rest of the network. So no coins are lost.

It's not that the transaction exists and the miner can't spend from it. Rather the transaction doesn't exist (it isn't in the main chain, so to the network it doesn't exist) so the miner can't spend from it. Because it is not part of the main chain it has no effect on Bitcoin's money supply.


How do non-standard transactions get created, broadcast and mined?

Normally, non standard transactions would be rejected by P2P nodes (but would still be mineable by miners directly since this is just a policy rule).

P2SH addresses do not disclose the script they hash until they are first spent from. So you can send BTC to any script (valid or not) using P2SH addresses. Standardness rules are not imposed on P2SH input scripts, they just have to respect the protocol rules (size, use enabled opcodes, etc...).

To create your own scripts, you can use this question as a starting point.


You seem to think that the number of transaction outputs must be higher than the number of transaction inputs. That's wrong.

Just have a look at transaction 19e68405b2ac2f96d5127748ff07bbd629cde93a230582317c9ff50d9644b562 (click me) which has been included in the most recent block. It took 28 inputs from 28 different addresses and produced 2 outputs in 2 address.

The transaction you describe (transactions with a lot of inputs) actually mean that there are fewer UTXO because of them. The transaction I linked to above is very big (8.6 kB) but it destroyed 28 UTXO and created only 2 new ones.

When you're fearing to have to pay higher fees as an individual, you should think about how you actually get many UTXO. If we're talking about a transaction which takes only 2 inputs and has 28 outputs, those 28 outputs will most likely to belong to 28 different people (28 people who retrieved money from an exchange at that time bundled together in 1 transaction or 28 employees payed by a single employer). But in those cases, creating many UTXO is totally justified because they belong to different people. When they spend their money, they unify the money, again, into fewer UTXO.


How to get more chain tips from getchaintips?

It returns all branches your node knows about.

Note that your node cannot know anything about branches that occurred while your node was still syncing, as you only get the active best chain from your peers.

Also, if you are connected to a single node only for a while, then you will during that time not hear about any branches, as you only get to see the best chain as it is determined by your peer.


How do I buy something from someone with bitcoin?

If you already have bitcoins you might do following:

The best way (or the most common) is to use wallet in your smartphone and do transaction through mobile.

Scan receivers QR code to your smartphone wallet
Send bitcoins
Wait until your transaction receives enough confirmations - can be cheched at www.blockchain.com just by entering your address and finding up the latest transaction. (don't get scared if the transaction doesn't show up within minutes it might get also hours depending on your transaction fees - the higher the fee is the faster confirmation proccess will be) With 0.001 BTC fee the transaction will show up in the next block.
Obtain bought item

In case that you don't have smartphone, bring your laptop to place, where you can acccess internet connection.

You will need to get receivers public address to send bitcoins to - with smartphone you just scan address.

Hope it helps.

If you dont have bitcoins you will need to buy some through exchange or localbitcoins.com.


You are looking for the dumpwallet command.

While in regtest open the console a/k/a debug window, and type:
dumpwallet "C:\myfolder\dump.txt"

This will create a text file with all your keys. At the top you will see your extended master private key. And if you are looking for your HD seed, do a control+f for hdseed, you should find a key with the label hdseed=1.

https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/sethdseed/


Countrywide Internet isolation, inevitable fork

Your assumptions are perfectly right. Since there is no information exchange between the two partitions while the network is partitioned, and Bitcoin guarantees liveness, the global consistency suffers (see CAP Theorem). This means that each partition will have its own blockchain fork, unaware of each other. The forks are incompatible not just because the chain is defined to be a single path from a single header block to the genesis block, but also because transactions in the partitions will contradict each other (not least the mining generation transaction in the block).
Should the partition be prolonged the forks may even start to diverge in difficulty, as they will only see the computational power in their own network and adjust accordingly.

As for the merge, this is still being discussed and we do not have a good contingency plan. Letting the system merge the forks by itself, i.e., dropping the fork with the least work in it, would roll back the entire transaction history in that partition. A manual intervention by making the fork persistent (the alt-coin scenario you mentioned) is also not desirable, as it results in an immediate doubling of the funds in circulation, Furthermore it is likely that one of the forked alt-coins is going to whither and eventually be abandoned anyway. For now the best we can do is attempt to avoid prolonged chain forks, but the risks you pointed out are real and worth discussing before it's too late.


Bitcoind Node crashes after using -dbcache option

You are allocating far too much dbcache. If you allocate 4000 MB to the dbcache, you will use up all of your RAM and it will crash. Your operating system needs RAM, Bitcoin Core itself needs RAM outside of the dbcache. I would highly recommend that you do not set a dbcache at all as 4 GB is really not enough RAM to handle a larger dbcache, Bitcoin Core's other RAM usage, operating system RAM usage, and whatever else may be running on your machine.

I suggest that you start Bitcoin Core without dbcache and check what your RAM usage is (using top or Ubuntu's system monitor). See how much RAM is being used and how much is free. Then you can set a higher dbcache if you have enough free.

Bitcoin Core has a few other suggestions for reducing memory usage. You can set maxmempool=<n> to a number less than the default 300. You can reduce the maximum number of connections by setting maxconnections=<n> to a number smaller than 125. Note that that only is helpful if you happen to have a lot of incoming connections. Lastly you can reduce the number of threads being used for signature validiation by using par=<n> and setting it to a number smaller than the number of cores your CPU has.


Coins are spendable by a wallet as soon as the transaction is included in a mined block. Some online wallets use their own software to sync, or in other words, to make their application aware that the account has received coins. Applications that use this method could have varying durations for recognizing received coins. Furthermore, different wallet providers may also have additional criteria, such as requiring that at least 4 blocks have been mined after the transaction was included in a block. This is known as Minimum Confirmations. For example, Coinbase will credit your account once there have been 3 network confirmations. In this case, the duration to "receive" coins on a local wallet such as Bitcoin Core, would be much faster than on Coinbase, because you would not have to wait for 3 blocks in order to spend the coins. It's also worth noting that this is not an issue of "online" versus "cold" wallets, it's more of an issue of third-party service based wallets versus personal wallet clients which you control the keys for.

As @JBaczuk pointed out below in the comments, technically coins are spendable even without a confirmation. This is especially useful for child-pays-for-parent (CPFP) transactions, where the first transaction may have a fee that is too low, but it is used as an input in a second transaction with an extra high fee, so miners will include the second transaction, which would also require including the first transaction.


You can use Specter Desktop with the Bitcoin Core wallet and a hardware wallet for the first key and second key respectively in a 2-of-2 multisig.
For a disclaimer it states on the Specter README:

This software might be ready to be used but at your own risk.

Alternatives Michael Flaxman also discussed briefly on the Stephan Livera podcast are Caravan (Unchained Capital) and Sparrow.
These are all efforts to manage multisig for different hardware wallets with Bitcoin Core. I am not aware of any efforts from existing software wallets to expand their offering to multisig with other third party software wallets.


In the QBundle Burstcoin Wallet, why is a fee of 1 BURST required to set the account info?

You are claiming an address on the blockchain. The fee makes sure no one will (try to) claim all addresses on the network.


What part of the code is responsible for coinbase payouts?

You're really asking about two separate but related pieces of code. One piece of code claims the mining reward, and the other piece of code says that it is okay for miners to claim a mining reward.

The first is here: https://github.com/bitcoin/bitcoin/blob/1afc22a7667a7a5c66b4b5d7f50832356dd5ec12/src/miner.cpp#L161

The second is here: https://github.com/bitcoin/bitcoin/blob/470c730e3fa9d1120dda1de2d433304023c8aa78/src/validation.cpp#L1819


How can the number of unique addresses decline?

Most likely, it's the number of unique addresses that hold a balance, not have appeared on the blockchain.


Sending transaction with Python + raw protocol

First, if you want to learn how to construct a raw transaction, you should really go to this question: Redeeming a raw transaction step by step example required

Second, the tx_in needs an outpoint_hash, which is the hash of the previous transaction you're spending from.

Third, you should never, ever encode your private key to any part of the transaction as you did in tx_in["script"]. That should stay on a secure device and you need that in order to generate the signature.

Fourth, tx_in["script"] should be the same script from the oupoint (hash, index). The specifics of the script language which is encoded in hex (76a914...88ac) are OP codes you should study (see link above).

Fifth, this library does the signing elsewhere as script_bytes needs to be the actual public key and signature.

I think you'd find it easier to understand using a slightly more standard python library like pycoin (https://github.com/richardkiss/pycoin) or pybitcoin (https://github.com/blockstack/pybitcoin)


Where is the real money stocked? Are exchanges banks?

The first thing you need to understand is that cryptocurrencies like bitcoin are the real money.  They are not merely a measure of government fiat currency denoted in a different unit.  With that in mind, your question doesn't make a lot of sense.  It's like asking where the real money is stored when you purchase gold.  The gold is the value.  You have simply traded some other currency in exchange for it.

Exchanges, web wallets, and other "cloud banks" (although I've never seen this term) are just services that store your bitcoin for you.  They manage your transactions, and often your private keys, so that you don't have to run software on a computer to do so.  If you have given them US dollars, what you have done is purchased bitcoin with those dollars.  This is just like purchasing a bag of groceries with your USD.  Someone isn't storing the money you spent as a backing for the value of your bag of groceries in your pantry.  You've simply exchanged one thing for another.


How to securely store Bitcoin server-side?

The precautions you can take from an architerual point of view would be as follows:

The database storing the private keys or the seeds in case of HD wallets should be running on a separate instance and only accessible via the application server(AWS allows lots of configuration you can make in the virtual private cloud i.e. VPC to accomplish this).
The keys are encrpyted. As you mentioned some sort of 2 way encryption key needs to be maintained. Also it should be your motive to achieve minimal responsibiltiy in case of breaches. So encrypting private keys with users password is a good start. But storing plain text passwords in obviously stupid and so is getting it from the user over the network. https solves the over the network issue but plain text password itself is a point of failure. So you will have to come up with a different scheme where in you are unable to spend your users funds.
Going by the same minimisation of your risk approach, multisig would be the best  solution in this case. But this will require your users to be more active in the transaction process. Bitgo enforces multisig coupled with HD in a secure way to provide similar services.

In conclusion, HD wallets will reduce the number of keys you have to store, having a separate private key server instance and encrypting the private keys by the users passwords is a good way to start. Multisig would make things complicated for the user but would provide utmost security.


How to setup my own exchange? How does Exchange set Initial price of any cryptocurrency

It isn't.  Exchanges don't set prices at all, they merely provide a place for people to trade with one another at whatever price they can agree on.  If there are no customers, the order book is empty; if you like, you can think of the bid being zero and the ask being infinity.  If the first customer is someone who wants to buy, they can enter a limit buy order at whatever price they want, and that will become the bid.  When someone arrives who wants to sell, either their price matches the existing buy and a trade happens, or it doesn't and that price becomes the ask.
These are not really exchanges, just dealers.  You are not trading with the company's other customers, but with the company directly. Just like an ordinary retail store: they have a product, they offer to sell it at a particular price, and their customers either buy at that price or take their business elsewhere.

And as general advice:

  How to setup my own exchange?

If you have to ask the question, then don't.  This is not a do-it-yourself project; the security and legal and financial considerations are daunting and need to be handled by experts.  At best you will waste a lot of time before realizing that it is impractical.  At worst you will discover it is impractical after you have lost a lot of money belong to yourself and your customers.


Why satoshi client's UPnP part maps to a fixed external port (8333 by default)?

A fixed external port is used so that other clients on the internet can connect to your client by knowing only your IP address. They will use the fixed port number to connect.

If you have multiple clients behind a NAT device, then only one client will be able to negotiate with the NAT device to listen on port 8333 (and have incoming connections translated to its client address).

Note that the above assumes the clients actually are behind a NAT devices (which is very common, especially in home networking setups). If instead the router is really just a router and not a NAT device, then each client behind the router will have its own public IP address, and there won't be any conflict between more than one of them listening at the same time on port 8333.


Neither cgminer nor BFGminer detect my Zeusminer Blizzard. (Ubuntu/Linux/Mint)

There are a few things that might be going wrong.

First, are you sure that your user has rights to read and write the serial port?  (There are plenty of tutorials online about how to do this.)  You can check if that is the problem by running (temporarily) as root.  If it starts to work, then you can go back and sort out how to give your user rights to the serial port.

Second, your command line looks like it may be wrong.   I say "may" because it depends on whose version of bfgminer you are running with.   My recommendation is to get the official one from the Github site and build it.   Assuming that is the one you have, then you need to call the miners zeusminer instead of just zeus.   You should also be using -o to define your pool, not --set.

Third, you need to tell bfgminer to operate in scrypt mode, or it will default to SHA256 mode.  This is done by adding the --scrypt command line option.

Try this command line :

sudo /home/me/crypto/bfgminer/bfgminer --scrypt -S zeusminer:all --set zeusminer:clock=340 -o stratum+tcp://mypool.com:6030 -u myuser -p mypass

I just fired up two Blizzard using a command line very similar to this.  (The only difference is I use the -O option to pass my user name and password together.)


Bitcoin difficulty re targeting in case of catastrophic hashrate drop?

But how is difficulty changes if suddenly 90% of hash rate disappears* ?

It will change as it normally does, after 2016 blocks. There is no provision for adjusting the difficulty if the hashrate suddenly drops.

  *recent BCH fork had difficulty adjusted quicker than 2016 blocks.

As part of their hard fork, they added a provision for cases where blocks are taking too long (i.e. sudden hashrate drop). This extra difficulty changing rule is not present in Bitcoin.


Your key descriptors describe a p2sh-p2wpkh address. The descriptor can be decoded as:

sh # p2sh script
(
wpkh # p2pkh script
([
7de694b7 # BIP32 root key fingerprint
/0' # perform one hardened derivation at index 0 on the root key
/0' # perform one hardened derivation at index 0 on the previous derivation's output
/7' # perform one hardened derivation at index 7 on the previous derivation's output
]
032c27921f2d15e7eca768c0e8a8b1aeb863328c74d6c194d41dde2888d4b0e75b # this should be your resulting public key
))
#6z7uwusp # checksum information for the entire key descriptor

The full key descriptor reference is available here.

To go from the public key to the address, you can perform the steps as outlined here.


It looks like the local electrum wallet is not loading addresses that the server created outside the gap limit with --force. Any ideas on how to make local machine load these

Increase the gap limit. Go to view menu > show console, switch to console tab and enter this command:

wallet.change_gap_limit(100)

Then wait for the balance to update in the bottom left corner. If that doesn't do it try a slightly larger number.

Also note that you have to be using a recent version of electrum. Old versions don't sync anymore so make sure you are using the latest version from electrum.org. A version that doesn't sync will not reflect an accurate view of your wallet.


What happens when the same wallet (private key) is used on several machines?

A wallet is a combination of private keys, and transactions that spend from/to it.
Since somewhere in the 0.3 series, bitcoin will detect transactions from a key of yours that you did not create yourself, and count them as spends.

This means that if you duplicate your wallet on several machines, they will all be able to do spends, and observe spends by others. Probably as much as you would hope for, but there are a few caveats:

The wallet contains 100 pre-generated keys to simplify backups, so the first 100 new keys used by both clients will remain the same, but afterwards they will diverge, i.e. start using different keys. You do not want this to happen, which means you will need to synchronize the wallet files at least once every 100 transactions (i.e., copy from one place to the other).
If one of the clients is not yet aware about a spend done by the other (for example, it was offline at the time of the transaction submit, and hasn't caught up with the block chain yet), it may produce a transaction that uses the same input, in other words: a double spend. The software is not able to deal with this, as it will consider its own transactions unquestionably valid. This will probably result in an unusable wallet.

In short: there are some provisions for detecting spends by copy of a wallet, but it's certainly not an encouraged or supported use case.


How to make paper wallet from Electrum wallet

My question is why are there 27 key pairs in electrum for one wallet? [..] Is the balance split up amongst the keys?

Yes, a wallet is a collection of private keys their corresponding addresses. Best practises for making transactions includes using a new address every time you receive bitcoin, and almost every send will also generate a new 'change address' that your wallet software controls. Any wallet that is used to transact will end up being a collection of keys, unless it is poorly coded. Search for 'bitcoin address reuse' to learn more about why this is the norm.

  Do I choose one and convert that?

By choosing one, you will be storing that specific address' private key, and none of the others.

If you would like to make a physical backup of your entire electrum wallet, then you should make a copy of your mnemonic seed phrase. This seed phrase is used to generate your master private key, and each subsequent private key your wallet generates will be derived from this master key.

I don't know your exact intention, but I think it is worth mentioning: the usefulness of a cold storage paper wallet is that it is preferably generated on a machine which never connects to the internet. This helps protect your keys from 'hacking' attacks, largely reducing the attack surface to physical breaches (ie someone breaks into your house and steals the physical paper wallets). So creating a paper wallet that is just a copy of one of your electrum addresses does not give you any additional security (rather, it would increase your attack surface). In general, this is why there probably isn't a good tutorial for 'creating a paper wallet that matches a software wallet': the best way to back up a software wallet is to store the seed phrase! Using paper wallets to do the same adds unnecessary complications.

Also worth mentioning: do NOT input your private keys into the website you linked that does private key format conversions. If you must use it, you should save the html file and open it in a VM or offline machine.


Bcoin vs Bitcoin Core: query your node to list transactions of any address

bcoin can be run with —index-address or indexAddress: true in bcoin.conf. This will index all transactions by address, a feature I do not think is available in Bitcoin Core.

You can read about the API call here:
https://bcoin.io/api-docs/?shell--cli#get-tx-by-address

Normally switching indexes on or off after a full node is synced would not be allowed. However a recent update to the bcoin indexer module (on GitHub master branch, not yet released or published to npm) allows the user to enable indexing at any time. It will, of course, require a long rescan of all block data to create the indexes.

You can review the indexer update here: https://github.com/bcoin-org/bcoin/pull/758


How do I know if the Bitcoin page has been hijacked

First, there isn't any one bitcoin site, but hijackers often try to setup phishing attacks on cryptocurrency sites to get you to enter information they can use to steal your coin (as happened with EtherDelta this week).

Generally speaking, look for the green lock icon in your browser. If it isn't there, don't open continue. Best to also check the actual certificate by clicking on that green lock to ensure the certificate is from a well known Certificate Authority. Also generally a good idea to watch the twitter account associated with the site. For example, in EtherDelta's case they started tweeting about the issue pretty quickly once they were aware. And if in doubt, don't open it and tweat to the twitter account associated with the site just to make sure all is well.

If you see a "self-signed" certificate Do not open the site!


The original Satoshi client (now called Bitcoin Core) was developed from the whitepaper. Exchanges, online hosted wallets and many other things requiring identification came later. You can still run Bitcoin Core or a similar wallet on your desktop and many people value the anonymity.

You are right that when you use an exchange or another service where you are required to identify yourself, link bank accounts or, other similar activities you can be identified.


I live in viet nam and I want to buy bitcoin. How would I do that?

I would say try https://localbitcoins.com
You can buy from other people in your area/country.


Will more hashes per second increase bitcoins per hash per second?

The short answer is: No. The average number of bitcoins per hash is fixed, and is roughly equal to B / (2^32 * D), where B is the bitcoins per block and D is the difficulty. Every calculated hash is either a block or not; if it's not, it doesn't bring you any closer to finding a block.

However, for completeness it should be noted that there are several sophisticated attacks that allow superlinear gains on hashrate, such as lie-in-wait and hashrate amplification (also known as selfish mining). Superlinearity can also be a side effect of a short block interval. All of these require huge hashrate to be effective, on the order of a quarter of the network hashrate - not something which should be of concern to the average miner.


Regular Expressions for DER signature hex (also req, address, TxIDs)?

For DER sigs, it's possible for R or S to be very small.

DER sigs: re.compile('^30[0-9a-fA-F]{72,136}02[0-9a-fA-F]{0,64}02[0-9a-fA-F]{0,64}[0-9a-fA-F]{8}')

Bitcoin addresses cannot have a 0. Also the {1} is superfluous

Bitcoin addresses: re.compile('^[123mn][a-km-zA-HJ-NP-Z1-9]{26,33}$')

Again, {1} is superfluous for OP_RETURN. Also, the a might be capitalized.

OP Return hex strings: re.compile('^6[aA][a-fA-F0-9]{0,80}$')

TXIDs are fine


What can I do with Bitcoin Core to see my current balance?

Bitcoin Core incrementally shows transactions you received as it processes blocks, so if you received the transactions a while ago they should pop up soon. You will not be able to independently verify the validity of your transactions without fully synchronizing.

If you just want to check the balance of your addresses it might be sufficient to look up the addresses on a public block explorer. The JSON-API gives you various methods for retrieving your addresses from Bitcoin Core. Once you have the addresses simply check their balance using a block explorer.

If however you'd like to move to a different wallet, the backupwallet API should give you a copy of your wallet that other wallet software can import.


Lightning Route Discovery - How to know capacity in each direction?

Even if you did find such a route successfully, what guarantees that B WILL use its payment channel? B can deny at any moment, because decentralization.

Also, from routing recommendations:

  When calculating a route for an HTLC, the cltv_expiry_delta and the
  fee both need to be considered: the cltv_expiry_delta contributes to
  the time that funds will be unavailable on worst-case failure. The
  tradeoff between these two is unclear, as it depends on the
  reliability of nodes.

Goes on to explain that the problem is deeper:

  If a route is computed by simply routing to the intended recipient,
  summing up the cltv_expiry_deltas, then nodes along the route may
  guess their position in the route. Knowing the CLTV of the HTLC and
  the surrounding topology with the cltv_expiry_deltas gives an attacker
  a way to guess the intended recipient. Therefore it is highly
  suggested to add a random offset to the CLTV that the intended
  recipient will receive, bumping all CLTVs along the route. In order to
  create a plausible offset the sender MAY start a limited random walk
  on the graph, starting from the intended recipient, sum the
  cltv_expiry_deltas, and then use the sum as the offset. This
  effectively creates a shadow route extension to the actual route,
  providing better protection against this kind of attack than simply
  picking a random offset.

Importantly for this answer, it ends at:

  Other more advanced considerations involve diversity of routes to
  avoid single points of failure and detection and channel balance of
  local channels.

So the answer would be, that LN just provides discovery, doesn't build a path(because a channel cannot be guaranteed to be online in a decentralized network??) so 'tries' is not a feature of core LN(but of the autopilot feature).

The autopilot can be seen here. This is where the heuristics for finding the path goes.

  The autopilot package has been signed to be as abstract as possible in
  order to allow users, developers, and researchers to plug in various
  heuristics in order to experiment with the possibilities, or attempt
  to optimize the channel sub-graph for their targeted nodes. The
  current default heuristic is a mode called ConstrainedPrefAttachment.

Also,

  This is only one example of the
  possible heuristics which could be hooked into an active
  autopilot.Agent instance. We look forward to the additional heuristics
  that developers/researchers will implement!

In short, the current heuristic implementation first selects a slice in the network, and then greedily allocates funds.

switch {
    // If we have enough available funds to distribute the maximum channel
    // size for each of the selected peers to attach to, then we'll
    // allocate the maximum amount to each peer.
    case int64(fundsAvailable) >= numSelectedNodes*int64(p.maxChanSize):
        for i := 0; i < int(numSelectedNodes); i++ {
            directives[i].ChanAmt = p.maxChanSize
        }

        return directives, nil

    // Otherwise, we'll greedily allocate our funds to the channels
    // successively until we run out of available funds, or can't create a
    // channel above the min channel size.
    case int64(fundsAvailable) < numSelectedNodes*int64(p.maxChanSize):
        i := 0
        for fundsAvailable > p.minChanSize {
            // We'll attempt to allocate the max channel size
            // initially. If we don't have enough funds to do this,
            // then we'll allocate the remainder of the funds
            // available to the channel.
            delta := p.maxChanSize
            if fundsAvailable-delta < 0 {
                delta = fundsAvailable
            }

            directives[i].ChanAmt = delta

            fundsAvailable -= delta
            i++
        }

        // We'll slice the initial set of directives to properly
        // reflect the amount of funds we were able to allocate.
return directives[:i:i], nil

[EDIT:straight answer]

  So the heuristic only uses the channel capacity to find a route?

"based on the current internal state, the state of the channel graph, the set of nodes we should exclude, and the amount of funds available"

  Does the path finding heuristic have the information which side of a channel in the network owns how much, or does it only compute a route based on the capacity of channels?

Looking at the spec example, we only get info of "capacity" of an "edge" in the graph and not how much each party owns; only the amount they are willing to transmit. As explained above, yes, it depends on capacity, but it has more properties and not just amounts.


Get available exchange rates of Ripple's built-in exchange

Did I get this right, that it is possible to exchange a currency within the ripple network? Or is it that you have to convert your currency before you deposit into your wallet? In my example convert USD to EUR then deposit into wallet1 and send EUR to wallet2.

Yes, you got it right. Ripple contains order books for any pair of assets.

  Is there a way I can see the exchange rates the ripple network can offer my for any currency pair? e.g USD / EUR.

The best way is to attempt the conversion in the client. If you try to view the exchange rates, you will see only a small subset of the available liquidity.

  I want to know if there is a way to get the exchange rate at which my USD will be converted to EUR, before I send the USD / EUR to wallet2. Or, do I have to send my money haphazardly?

You can estimate the exchange rate by viewing order books in the client or on Ripple charts. But there are a number of reasons why the rate you actually get may not be the rate you see. For example, the best rate may be by exchanging USD for XRP and then buying the EUR with the XRP. The conversion function uses pathfinding.

Also, note that there's really no such thing as USD or EUR on the Ripple network. There are assets denominated in USD or EUR, and there may be more than one of each. The actual exchange rate you get may depend on the precise asset combination you are trying to exchange, not just which currencies it's denominated in.

You would expect an asset issued by a major exchange to be available for very close to face value and you might expect to get near face value for it. But there can be small variations. Providing assets widely valued near face value is essentially the purpose of a gateway.


Three things to check :

Is there rpcssl=1 in your bitcoin.conf ? If so, set it to 0 or make HTTPS connections only
Have you set rpcallowip=127.0.0.1 ?
Try connect to http: //yourname:yourpassword@127.0.0.1:8332/ directly

And the fourth thing to check (as I saw your answer) :

Check if you have correctly entered your username and password ;)


What kind of attacks do exactly check-points prevent?

You are correct that any client which sees two different forks can easily determine which one is longer.  But consider the following possibilities:

The node might never see the longer fork.  This can happen in case of a Sibyl attack, where the attacker has control over the victim's Internet connection and arranges that the victim only connects to evil nodes.  These evil nodes will only send blocks that are part of the shorter, malicious fork, and the victim will assume that this fork is the "real" chain because there is nothing else to compare it to.   So the victim will believe the attacker's view of the transaction record, at least until they manage to get connected to an honest node.  Checkpoints ensure that such an attacker can only manipulate the victim's view of history as far back as the latest checkpoint, which at least puts some limit on the damage that can be caused.
The longer fork might be the "evil" one.  This could happen in the case of a 51% attack, where an attacker who controls more hashing power than the rest of the network decides to fork the chain and "rewrite history" from some point in the past.  With their hash power majority, they can eventually make their fork longer than the "real" one.  A checkpoint ensures that they can only rewrite as far back as the checkpoint.

In each case, this is a rather minimal restriction on the attack; the ability to rewrite history back to the last checkpoint is still devastating.  But it might help in reducing the chaos until the victim can connect to an honest node (in the Sibyl case) or until other protocol changes are adopted (in the 51% case).

See  also Do checkpoints in the block chain help to avoid a 51% attack that rewrites the entire blockchain?

These apply to both full nodes and thin clients.

Also, as mentioned in the post you linked, if you know you don't need to worry about these attacks, then you can decide not to verify every last detail of the chain before the checkpoint, which will save computation and let you sync the blockchain faster.


Resources for multisignature transactions?

blocktrail has a 2of3 HD Multisig Wallet API, it's setup like:
 - the 1st key being your primary key to use
 - the 2nd key being a backup key you store offline and
 - the 3rd key being a cosign key owned by blocktrail

it only supports bitcoin and bitcoin testnet atm though ...

https://www.blocktrail.com/api/docs#payments_overview


Import bitaddress.org wallet into Bitcoin-Qt client?

Use console. Then "importprivkey yourprivatekey"


What attacks are possible with a malicious bootstrap.dat?

You can fake an entire history of transactions and blocks perfectly, but unless you can get a majority of clients approved it's useless.

I'm not sure majority is defined as 51%, because there crypto is more complicated then that.

But look up how transactions get verified

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

So, basically it depends on the lower level procedures which decide which clients to confirm against and you'd need to get majority of those just to fool your client.

Because when an error is detected they all start communicating it