Why does every HTLC in a commitment transaction require its own signature?

Why isn't the signature for the entire commitment transaction enough?

Because the htlc_signature field contains the signature for the HTLC transactions spending from the htlc output(s) (either received or offered) of the commitment transaction.

To expand a bit, some paths of the HTLCs scripts (timeout for an offered htlc output and success for a received HTLC output) pays to a 2of2, thus you need the right transaction which spends from this output to be signed before comiting to this (otherwise unspendable by using this script path) output.

EDIT: This question originates from this Github issue, to which Olaoluwa Osuntokun (@Roasbeef) gave today a detailed high-level explanation of why second-stage HTLCs are used in Lightning Network.

The following is the copy paste of his answer that might be of interest to anyone passing by.

Here's my attempt at a high level explanation:

We use something called two-stage HTLCs in the system. This allows us to decouple the CLTV (absolute timelock for HTLCs) from the CSV (commitment delay to allow for breach retribution). To see why this is an issue, consider if we had both of these in the top-level HTLC script. From here, one can imagine a scenario where we have an HTLC that can be timed out (absolute block height passed), but we can't spend it (timing it out) until our CSV period has also expired. Therefore, one needs to set their CSV values taking into account the absolute timelock (CLTV) value as well. Critically, before a user can cancel their incoming off-chain HTLC (timing out the outgoing on-chain), they need to wait for this CSV period. However, if the CSV is greater than the time lock delta (diff between incoming and outgoing HTLCs), they've created a race and could possibly lose money.

Without HTLCs, the dependency between the CLTV delta value and the CSV value means that if one wants to have a higher CSV value (more time to punish malicious channel peers), then they also need to have a longer CLTV delta value. As an example, a common set up with lnd is that for super higher value channels we have a CSV value of 2016 blocks (two weeks). Without second-level HTLCs, we would need to also make our CTLV delta value (40 blocks default atm), greater than 2016 blocks. This change would then propagate through the entire network, resulting in very long time lock values. The sender of an HTLC eats the full time lock delay, meaning that know their absolute worst case is much higher, trading off for better multi-hop HTLC security.

Thankfully, we figured out a solution to this: two-stage HTLCs. Note that the HTLC scripts I described above were never actually deployed. Two-stage HTLCs are actually used in the original LN white paper for a similar reason. The defective design described above was created when developers were trying to compress down the scripts and on-chain footprint a bit.

A two-stage HTLC decouples the CSV period from one's CTLV time-lock delta. To do this, we now require the party that forced closed to spend their HTLC with a special transaction. This transaction spends a CLTV clause in the script, and itself includes a nLocktime value as well. The output of this special transaction then pays to the party timing our or redeeming the HTLC, but then enforces a CSV period. We call them two stage as we enforce two states in the claim: wait for absolute timeout value, then wait for CSV value. Note that once the absolute timeout value passes, the party can spend the original HTLC output, transitioning the HTLC claim state machine to the CSV waiting period. At this point, they can safely cancel back any off-chain HTLCs, as the other party isn't able to settle it with a pre-image at this point.

The way we enforce this spend, is that we make any HTLC spends from one's commitment transaction (which you broadcast during a force close) actually be a multi-sig output. We use this output to create what's essentially an "off-chain multi-sig covenant". Since they require our signature to spend this output, we force them into a particular type of spend using pre-signed transactions. As a result, each time we want to give them a new commitment, in addition to the commitment signature (multi-sig spending teh funding output), we also send a series of signatures, one for each HTLC, that blesses their spend of the HTLC output.


BIP38 wallets are significantly more secure and are resistant to brute-force attacks when a decent passphrase is used.

Generally the term "Brain Wallet" refers to one in which the private key is derived from a phrase you make up.  These have been shown to be insecure because humans are bad at entropy and generally anything easy enough to remember is not safe.

Note: modern BIP39 wallets will generate a 12, 18 or 24 word "seed" phrase from which unlimited keys can be derived.  These may look like a brain wallet, but are completely safe as long as they were created securely. Remembering these words can be challenging though, so generally better to write them somewhere and store securely.


how many miners approve a block; before it gets added to the block? Is it 51%?

The rest miners checks whether the puzzle solved by the miner who claimed to solve is correct or not. Then how many miners approve to it; before it gets added to the block? Is it 51%?

No. The miner creates the block himself. There isn't actually a puzzle that the miner solves; he just does a specific mathematical formula (called a hash function) over and over again, slightly changing the inputs to that formula, until he gets a result from that formula (known as the hash) that is less than a specific target value. The target value is a value that is deterministically calculated from all previous blocks; i.e. given the same blockchain, you will always calculate the same target value for a given block.

There is no approval process or anything like that. What happens is that the miner will just broadcast the block to everyone, and everyone individually decides if they want to accept the block or not. This decision is based upon whether the block meets the consensus rules built into the software powering people's nodes. Other miners will also receive the block and decide whether they will accept the block or not. If they accept the block, then they will begin mining another block on top of it.

Blocks get added to the blockchain when nodes accept the block and add it to their local blockchain. There actually isn't anything that is "the blockchain", rather it is just that all nodes who are following the same consensus rules will accept and reject the same blocks so all nodes using those consensus rules will have the same blockchain.

  Suppose a wrong entry gets there in the public ledger. Won't it affect the credibility of bitcoin? How it gets rectified? How a wrong transaction is rectified?

Blocks are not the "final say" of what is valid or not. If a block is invalid in any way (invalid block header, too large, contains an invalid transaction, etc.), everyone who is following the consensus rules that make the block invalid will reject that block and refuse to add it to their local blockchain. Thus those who are following the same consensus rules will still be using the same blockchain. Other miners will be doing the same thing and they will not mine more blocks on top of that invalid block. It isn't possible for a "wrong transaction" to be included in the blockchain because that would make the block that included it invalid to everyone using Bitcoin's consensus rules and thus the block is not part of Bitcoin's blockchain.

  I also read somewhere that each block contains the information about previous block. So after 6 blocks is added to the block-chain; it is surely confirmed that the last 6th block is fully a valid transaction.

No. Blocks do not determine the validity of a transaction. If a block contains an invalid transaction or is invalid in any way, those nodes following the consensus rules that make the block invalid will reject the block under all circumstances. They will never accept the block even if the block has more blocks mined on top of it.

  The miner gets the reward of 12.5 bitcoin. He adds this transaction to himself to the block?

The miner creates a transaction which pays himself 12.5 BTC plus transaction fees. The 12.5 BTC (the block subsidy) is created out of nothing; there is no issuer, there is no treasury.


where is default Bitcoin-Qt data directory?

It depends on your operating system.  Read about it here.

Linux

~/.bitcoin/

Mac

~/Library/Application Support/Bitcoin/

Windows

C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)


What is the purpose of the script like RETURN PUSHDATA(36)(...)

1) How the coinbase could have more than 12.5 BTC?

Because of transaction fees

  2) What is the purpose of the RETURN PUSHDATA(36)(...),

The purpose is to embed data in the blockchain. No bitcoins were burned (and no transaction fee), so that's a free way to embed data in the blockchain.


Is it possible to use the RPC's Label feature in it's current state over the deprecated Accounts feature?

Yes, you can use the current Labels function as it is now.


Proof of burn simply means you have provably destroyed coins. The only way to destroy coins in a proven way is to send them to an address which is improbable to have been generated from a private key, and thus can not be spent.

Chancecoin is the first I've seen to use this way to generate their coins. The announcement for Chancecoin can be found here: https://bitcointalk.org/index.php?topic=528023.0

In here, they instruct people can burn bitcoins for a certain period by sending them to 1ChancecoinXXXXXXXXXXXXXXXXXZELUFD. The reason why we believe that this is a burn address and not a vanity address is that all but 6 characters seem to have been predetermined. The way you would find an address like this which you could send coins to is by running a loop.

Start with 1ChancecoinXXXXXXXXXXXXXXXXXXXXXXX
Ask bitcoin if that's a valid address
If it's not valid, increment the last character by one and try again

After a billion or so tries (not too much in terms of 'mining') address 1ChancecoinXXXXXXXXXXXXXXXXXZELUFD is found which passes the validity check. For more info on address validity see: https://bitcointalk.org/index.php?topic=1026.0

This address is very unlikely to have been generated with a private key, or if so, it would show a big weakness in bitcoin and many other security practices. So we assume that the nobody has access to this private key.


Most exchanges work with an order book. In this method, the two parties involved in the trade are slightly different.

The order book lists prices at which people want to buy and prices at which people want to sell.

You can see btc-e's order book on their homepage. Let's assume the following simple order book:

SELL ORDERS:
    person 1 wants to sell 3 BTC for 101 EUR/BTC
    person 2 wants to sell 1 BTC for 100 EUR/BTC
BUY ORDERS:
    person 3 wants to buy  2 BTC for  95 EUR/BTC
    person 4 wants to buy  5 BTC for  90 EUR/BTC

Note the ordering of the orders, it's on purpose. In all order books, the highers buy price is always lower than the lowest sell price.

Now, these people are passive traders (this is afaik not an official term), meaning that they are waiting for the price to reach a certain value in order to trade. Mostly, they do not need to buy/sell fast, but want to have a good price.

Then, there are active traders, that want to do their trades immediately. So, when I want to buy 1 BTC immediately ("at market price"), I will have to pay 100 EUR for it, as this is the best sell offer I can buy from. If I wanted to fast sell 1 BTC, I would get only 95 EUR for it, meeting the best buy order to sell at.

So in fact, when an active trader wants to buy 1 BTC, he actually creates a buy order for 1 BTC ar 100 EUR/BTC. This order will match the order from person 2, so they will trade. This means that the trade is initiated by the buy order from the active trader. For this reason, this trade will be logged as a buy trade.

Rounding up: Trades are logged according to the type of trade the active trader did.

Some things that are useful to keep in mind:

The bid/ask prices that most exchanges advertise, are the highest buy and lowest sell prices from the order book, respectively.
A buy trade will raise the lowest ask price (or keep it the same), while a sell trade will lower the highest bid price.


Error parsing JSON in bitcoin-cli signrawtransactionwithkey

Try this:

You need to provide the private keys and the utxo as arrays and make sure it is valid json and in quotes.

$ /usr/bin/bitcoin-cli -testnet signrawtransactionwithkey "02000000017b0cd6ab6beebace32e00f27aea8092879e178a77d2d0e74d001e10b39f560d10100000000ffffffff0100093d000000000017a9145e235c002eb66a1c33abccfb805043a036baf7798700000000" '["cNoe7mVGEVFwUwQXuCJadosEVPYU5rcCVxzTr46gYWbWMD8gXR7b"]'  '[{"txid":"d160f5390be101d0740e2d7da778e1792809a8ae270fe032cebaee6babd60c7b","vout":1,"scriptPubKey":"a9145c975f4c6d18fa1abd25018e1fa3c18e58c9e93b87","redeemScript":"5221029558bd8bc6e0cac883cac93a420bf8e68e76e8e07944f6034e3c5eadd3f1a4db21038d217a8fa3960a3b3212bc545566c5c48add11003551cb23c0d744a13f9ab8272102fcd0e6ff324c7a3bc9a8e224d61cd9ccd244c54186848ca3035a54736a9780d653ae"}]'


Can multiple transactions transferring the same bitcoin be done in one block?

Yes, this is possible. This is seen happening today in MtGox's green address implementation. The two transactions are not guaranteed to be included in the same block, because the second transaction has a lower priority for miners to include it; but it's possible, and seems to happen in a lot of cases.

Quoting from MagicalTux:

  Actually if you look at : http://blockexplorer.com/address/1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q

  Look at transactions 597d00408b... and 557c87f205....

  597d00408b... is "A to B"
  557c87f205... is "B to C"

  Both happened in the same block, which is the expected behaviour.

  Previous tests did not always end in the same block, so I believe some miners may consider the second transaction lower priority as it involves not yet confirmed coins. In the case of those two transactions it was as fast as a normal transaction, but it cannot be guaranteed in 100% of the cases.

  If we look at the previous transactions we can see it was sometimes coming out with a difference of 1 block, or even more. If pools could put priority on green addresses it'd (mostly) solve this issue.

You can also pay a higher fee on the second transaction in order to compensate for the lower priority.


Why verifying later blockchain is slower?

Earlier blocks had fewer transactions, and so were smaller. Later blocks have many transactions, and so are much larger.


What can blockchain do that normal databases systems won't?

Blockchains are data structures, whose only advantage is that storing data in that structure allows you to achieve decentralization under certain conditions.

So your question reduces to "how is decentralization important"?
Decentralized systems tend to have the following favorable attributes:

Open (anyone can participate; not permissioned)
Borderless (as long as you can reach one other connected node, country/regional borders don't matter)
Neutral (the system doesn't care what you use it for)
Censorship Resistance (transactions/data entry is unstoppable)
Trustless (falsified data is easily detectable by verifying across multiple nodes)
Immutability (data cannot be removed or altered)
Public


How does ENS prevent frontrunning attacks?

The only way to get the domain name on the ENS is to win at the target name auction.
So there is no need to hide the name.
ENS uses the name hash for converting arbitrary length string into bytes32.


First of all, scriptPubKeys are not encrypted and what you are doing is not encryption. This is encoding.

The problem is that you are trying to encode a P2SH address as a P2PKH scriptPubKey. P2SH addresses are different from P2PKH addresses and have different opcodes. You can identify them by looking at the version number of the address which you are not doing. The version number actually has a meaning, it is not ignorable. Your scriptPubKey should actually be

OP_HASH160 01b47e5722f808856a308fa043ccf28323f51711 OP_EQUAL


I solved this, redeemscript wasn't prefixed with pushdata which is necessary as the whole script gets pushed.


How can counterparty tokens be distributed?

1) Yes, as of now (v9.55.1) it's all at once. BUT, you can increase the issuance by issuing more later unless you "lock" the issuance.

2) So yes, there can be a custom distribution schedule. Example: start with 100, run a "stakeholder" vote via Counterparty broadcast or other method or decide by yourself as the issuer, then increase issuance to say 200. But, if you lock issuance, then it's impossible to issue additional quantity of tokens.

Another way of answering your rephrased questions:

1) Counterparty relies on the bitcoin blockchain (and the miners) and it doesn't have its own miners. The native currency (XCP) was created by proof-of-(bitcoin)-burn. Tokens/assets are created by burning a small amount of XCP

2) Coins (tokens/assets) can be distributed in any way you want, it's independent of pretty much anything - for example you could simply ask people to provide their verified address (which they could do in any number of ways that bitcoin supports, for example by signing a message) and send them some tokens. There's a faucet (google it) that works similar to bitcoin testnet faucets and you could use that as well.


why i can't find blk0001.bat and blkindex.bat on my computer

The extension of file names you are looking for is .dat, not .bat.


May it be a risk to use the origin as the change address?

A transaction doesn't just identify a sending address as the source of its funds; it identifies a specific output of a specific previous transaction (by transaction ID and output number), called a txout for short.  Once a txout has been used as an input for a new transaction, nodes mark that txout as "spent" and any future transactions that attempt to spend it will be considered invalid.  (This means that the funds in the txout have to be completely consumed by the transaction; if that is a larger amount than you wanted to spend, you need a change output.  This is the whole reason to have change.)

In particular, this rule will prevent a transaction from being included verbatim in the blockchain a second time.  So any attempt to replay an existing transaction would not result in extra funds being sent.


Is the statement that LN hot wallets will be less secure than non LN hot wallets correct?

Of course this depends a lot on the implementation you are using but generally the answer is yes.

LN wallet vulnerabilites = hot wallet vulnerabilities + LN protocol vulnerabilites

Here are the main additional issues coming with running a LN node:

You could be scammed by somebody releasing an old channel state
You announce to the whole world how much money you have on your node [this is optional and depends on whether you want your node to be routing other peoples payments or not]


Block chain and its uses cases for a non-financial asset market

It's far from obvious that any such system would be usable or secure. But in many places "blockchain" has become a alternative way of saying "cryptography", "digital signatures", or "distributed system" -- all of which might be useful.

Storing patient data "in a blockchain" is one of the more horrifying concepts that I've encountered. I've never seen a good reason for it and in fact there seems to be a perfect mismatch in the technology:  What Bitcoin invented was a way of building a public system of a sort that was previously trivial to build privately.  There are many issues with medical records, making them less private is not generally considered one of them. :)

To me a lot of the blockchain hype feels like "Bitcoin appears to solve a complex problem.  Peace in the middle east is a complex problem, thus the technology from Bitcoin can solve it!".


How does Internal Keychain exactly work?

Bitcoin does not have the concept of account balance. It works on consuming the bitcoins that you have earnt in prior transactions. However, you cannot consume partial amounts. So according to your example, when you are creating a new transaction, in the inputs you will reference the transaction where you earnt the 1 BTC (it may be a single transaction where you got your 1 BTC, or you might reference multiple transactions whose values all add up to 1 BTC) and consume it entirely. Now in the outputs, you will send 0.1 BTC to address A and say 0.895 BTC to your change address. The difference of 0.005 BTC will go as mining fees.


How can I check a public master address balance?

You probably mean extended key. There are extended public keys (xpub) and extended private keys (xpriv).

An example xpub would be:

  xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz

They always start with xpub or xpriv.

You could use  https://blockchain.info/xpub/ or goochain.net or Electrum as a view-only wallet.


Is a bitcoin wallet address the same as your public key?

A public key in Bitcoin is a pair of 256-bit numbers used as part of the ECDSA scheme. A Bitcoin address is a Base58-encoding of the 160-bit hash of the public key (the hash function in question being RIPEMD160 of SHA256).

From the public key you can easily and deterministically compute the address, but from the address alone you cannot deduce the public key.


Hardware wallet - Claiming forked currencies

You can always use backup passphrase which you have to write down on device setup. For the two mentioned devices backup pass phrases are BIP39 compliant. That means that you can always use other wallet/device which is BIP39 compliant and supports the forked coins, enter the backup passphrase on this device and redeem the coins. Note however that it has certain security implications  - you open the possibility that your private keys might be compromised by the new wallet device/software.


Does the mempool size equal roughly the unconfirmed transactions?

Every node owner can set their own policy for the mempool. The mempool is limited two-fold:

With -maxmempool=<n> you can set an explicit limit of MB that it will not exceed. The default is 300MB.
Transactions that don't surpass the minRelayTxFee are not added to your mempool.

As statoshi.info has the mempool at 145MiB and ~11k transactions, it appears likely that different settings on the minRelayTxFee seem to cause your and blockchain.info's divergent mempool size here.


when I looking to a debug.log I don't see anything about blocks. Is it possible?

I expect the net category of log information should contain entries relating to the exchange of blocks with peers but I would not expect the full block data to be logged.
The name of the debug log suggests it is mainly intended as a way to investigate problems, and not intended as a means to routinely extract block data. You should use the RPC API for that.

Related

What are the debug categories?
API reference (JSON-RPC)
getblock


Disable update of blocks locally with bitcoind cmdline option

You can tell bitcoind to have 0 connections using:

bitcoind -maxconnections=0


use bitaddress.org for creating your paper wallet,it gives you the option of encrypting your private key (BIP38) and then print the whole wallet (address,pub key,encrypted private key) plus a QR code.


The coin selection that the client does is performed behind the scenes, the client takes care of the details.

But if you are curious to know what happens behind the scenes:

INPUT:

Address: A  1.0 BTC
Address: B  1.0 BTC

OUTPUT:

Address: C  2.0 BTC

FEE (derived as inputs - outputs): 0.0 BTC

This is assuming you didn't pay a fee.

Let's say instead you only were to pay 1.5 BTC, and a 0.0005 BTC Fee.

INPUT:

Address: A  1.0 BTC
Address: B  1.0 BTC

OUTPUT:

Address: C  1.5 BTC
Address: D  0.4995 BTC

FEE (derived as inputs - outputs): 0.0005 BTC

Address D was an address from your own wallet that the client chose to receive the change transaction.  Your balance in your wallet will then show 0.49995 BTC.

Here's a technical explanation:

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


Any assets can be represented on the blockchain using marked or colored coins. Therefore it's also possible to transfer the ownership of any asset using colored coins. Since the blockchain is public, assets being represented on the blockchain can also be tracked.

Colored or marked coins are basically bitcoins representing -other than their face value- ownership or access right to some other asset assigned to them by the original owner.

Very simple example: I'm a gold merchant and I'm announcing that I just transferred 0.0001 btc from my address A to address B and that transfer also represents 1kg of gold at my merchant store. Whoever B sends that 0.0001 btc to can transfer it back to me and claim ownership of 1kg of gold.

Now everyone can trade that 1kg of gold using the blockchain. I can track which address owns it. The owner can trade it with other assets as well.

It actually does not need to be the same amount. It works using inputs and outpus of bitcoin transactions.

It's pretty cool stuff but the Bitcoin protocol might not be able to carry the extra load this type of transactions can bring.

Here is a paper discussing the idea: https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit#


What happens with the bitcoin locked in the payment channel if both sides lose the backup?

Tl;dr: also in lightning we have: not your keys, not your coins.

More detailed explanation:

I assume you mean with backup the private keys of the lightning node together with the history of the state data.

Then the same would happen as in the onchain case if you loose your keys. You could not move the coins anymore. Or in a onchain 2-2 multisig wallet (remember payment channels are just such a wallet together with some protocol how to spend from it) the same if you and the other person would loose their keys. None of you could move the btc anymore.

In lightning terminology this would mean that the channel stays open forever but no new states can be negotiated (meaning noone can route through that channel or use it to send / receive payments) and additionally the channel cannot be closed.

While this is a pity for you and your channel partner as in the onchain case it is also a pity for the network as other nodes still think the channel is active and will try to route payments over it.


What does postfic in the wallet transaction id mean

It means this receive is due to output number 0 of the listed transaction.

Transactions can have multiple outputs (and usually do), and it is possible that more than one of them pays you. If that is the case, they will be listed as separate "transactions" in the UI, but their output will be distinct.


Why are there two byte sizes for timestamps in the Bitcoin protocol?

This was discussed in the mailing list a while back:
http://sourceforge.net/mailarchive/message.php?msg_id=30824341

I'm guessing 32-bit timestamp was used by Satoshi in the original client and the 64-bit timestamp was introduced later to avoid timestamp overflow.

We may need to change (hardfork) the old 32-bit timestamp fields to 64-bit at some point. See https://en.bitcoin.it/wiki/Hardfork_Wishlist


Why can't Bitcoin use a very large blocksize such as 1GB?

If you made the block size that large, the rate of network divergence would increase drastically as more and more miners would find blocks while still transferring a block that someone else found. (You have to consider the network latency of propagating 1GB to peers every 10 minutes).

There are other problems. Large blocks make it harder to do full verification of transactions, meaning that it would be done less. That would mean more and more miners who trust others to verify transactions on their behalf. This could threaten Bitcoin's decentralization.

There are lots of other problems, these are just the most severe and obvious.


Where does MultiBit keep its data directory?

Windows
Type %APPDATA%\MultiBit into the address bar of File Explorer.
If that doesn't work, try

Windows XP: C:\Documents and Settings\<your name>\Application Data\Bitcoin
Windows Vista and later: C:\Users\<your name>\Appdata\Roaming\Bitcoin

Mac

Open Finder, then open the Go menu.
Click "Go to Folder..."
Type ~/Library/Application Support/MultiBit

Linux
Open your home directory. Look for the MultiBit folder.
Wallet name
The wallet is always called multibit.wallet. It's the equivalent of wallet.dat in Bitcoin-Qt.


Can I receive BTG to my BTC address after BTG hardfork?

No

Bitcoin Gold has replay protection.  After the fork, all further transactions on the BTC chain will not transfer BTG, nor vice versa.

In your example, when someone sends you 1 BTC after the fork, the corresponding 1 BTG will still belong to the sender, not to you.  You will not gain any BTG from the transaction.  (Of course, they could send it to you separately if they wanted.)

It will also not be possible to spend BTC as BTG or vice versa.  To exchange one for the other, you will have to find someone to make a trade with, and agree on an exchange rate, which will probably not be 1:1. (You can use an organized exchange to make this efficient, but it's the same thing in principle.)


Can dust outputs become an economic problem?

"Dust" refers to UTXOs whose cost of spending is a significant portion of their total value. In Bitcoin Core's source code, "dust" specifically refers to UTXOs that are smaller than three times their fee at minTxRelayFeeRate. For a Pay to Public Key Hash (P2PKH) output, this is 546 satoshi because an output has 34 bytes and an input has 148 bytes. It's a bit smaller for single-sig segwit outputs.
Given that, an increase of the Bitcoin exchange rate would not directly change the definition of dust, but dust amounts would correspond to a larger amount of purchasing power. On the other hand, the cost of spending such a small UTXO would also be significantly higher, making such payments similarly uneconomic as before, just at higher value.
If the price actually goes up by multiple magnitudes (like the 4,000× you suggest), we may see the minRelayTxFee get reduced by one or two magnitudes. Very unlikely we could even see a hardfork that increases the precision of the amounts on the network to a fraction of satoshis. More likely, the transaction fees on the base layer will be prohibitive for all but the largest payments and smaller payments will live on other layers or sidechains.
Transaction fees in Bitcoin are paid per their blockweight and not per value transacted. This means that on-chain transactions generally don't lend themselves to micropayments since smaller payments have a high relative cost. Micropayments will almost inevitably get pushed out of the blockchain layer to either systems like the Lightning Network, where fees scale with the payment's value, or to off-chain payment systems, where they might be essentially free.


Who is the decision body for forking a blockchain ledger?

First of all, it is important to distinguish between multiple things, all of which are often called 'forks'.

The existence of two or more competing versions of history. These happen unintentionally in proof-of-work consensus systems when two miners produce a candidate block around the same time. These get resolved automatically.
Software projects branching off from another one. These are not generally (but could be) associated with a change to the ledger/rules.
A change in the rules about the validity of blocks (which additions to the ledger are accepted).

My view is that in a perfect world, (3) would never be necessary. We would all agree on what properties the system should have, encode those into software, and never touch those rules again. Reality is different of course, and sometimes changes to the system's rules are necessary - due to improve the technology, or to prevent against certain weaknesses or attacks. However, I do feel that cryptocurrencies (in general, as a research topic) intend to approach that goal, and are an experiment in building a system that lacks the need for human control. One of its value propositions is the prospect of creating a monetary system that is beyond control.

So how do we accomplish that? Clearly developers of node software that implements these rules have a strong influence over how it works. However, this influence is not absolute control. When you run a fully validating node, it comes with certain rules programmed in. It won't ever accept a chain of blocks that doesn't satisfy those rules. Only its operator can change that software to another version which has different rules. Developers can of course publish new versions that changes things, but they need to take into account that not everyone may update. Depending on the type of change, if significant (and not necessary large) parts of the ecosystem choose to not adopt an update, this can cause the ledger to split (where the result is 2 separate currencies, with each pre-existing coin spendable once on both sides). This risk is a strong deterrent to adopting changes, unless it is clear that those changes will be universally accepted.

So to answer your question:

  Who are these people and how who holds them accountable?

You are.

Cryptocurrencies have the unique property that all of the system's rules are verifiable by everyone. By running software that implements the rules you want, you know that the system maintains those properties. Anyone who wishes to change these will at least need to convince you to change your software (this is why Bitcoin Core intentionally does not have an auto-update function, for example - it would place far too much power in whomever has control over the auto-update server).


When a fork like this happens, and a new cryptocurrency emerges, the blockchain history from before the fork remains the same.

The amounts you have listed are the coins mined from before the fork + coins mined after the fork. The amount mined will always vary, because of possibly different rules or because the blocks don't always get mined exactly every 10 minutes (BTC block time has jumped up to 15 minutes and will probably slowly decrease over time, while BTG block time is 10min and 26 sec).

BTG supply is lower from BTC simply because from the time BTG forked, more BTC blocks were mined than BTG blocks.

The supply is calculated with the help of total blocks mined and the reward issued for those blocks.

After a fork happens, cryptocurrencies can never merge again. There will forever be separate blockchains.


Is two-phase encryption planned for the standard client?

No, it is not planned.

I'd suggest writing some JSON-RPC proxy code that takes RPC commands, checks to see if they're safe (or checks to see what password was given), and if they are authorized forwards them to bitcoind and passes through the result.  There is a lot of good Python code for json rpc clients and servers, although JSON-RPC is a simple enough protocol it shouldn't be hard to create a proxy in any language.


How do market cap websites obtain their list of coins?

They will usually scrape various exchange APIs/websites for tickers and names.


How to see the entire history of my Ledger Nano S?

The easiest solution would be to use your Ledger via Electrum - it supports hardware wallets, will let you set the derivation path to match your address type, and has no limits on the history displayed.


What software should I use to mine alt coins?

You will need to download some mining software, cgminer was what I used to use, there are others out there to. But find yourself a pool that has the altcoins u want to mine, most pools work on pointing your port at a different values for the different coins. Most good pools have guides for setting up the different miners software for their pool.  Coinotron was always one of my favourite pools and it is still going :) hope this helps


How long does it take to propagate a newly created block to the entire Bitcoin network and why?

According the paper 'Information propagation in the bitcoin network.' by Decker and Wattenhofer. The mean time for a node to see a block is 12.6 seconds, after 40 seconds 95% of the nodes have seen that block. This paper goes into some of the causes of propagation speed.

Block size is a dominating factor:

  "For blocks, whose size is larger than 20kB, each kilobyte costs an
  additional 80ms delay until a majority knows about the block." -'Information propagation in the bitcoin network.'

Network Diameter does not appear to be that important as there are some very long shortest paths in bitcoin, but those paths only represent a tiny faction of the overlay network.
The bitcoin network appears to be extremely well connected for most of the nodes and with a long narrow tail very very poor connections. A block may take a long time, possibly minutes to reach the last 0.0001 percent.

Bitcoin Stats have a nice website that measures block propagation speed, it is based on the research of Decker and Wattenhofer.
It doesn't entirely agree with the Decker and Wattenhofer paper but it is important to understand that the bitcoin network is evolving at a breakneck pace. The bitcoin overlay network like the weather or the stock market, has the property that what was true yesterday might not be true tomorrow.

Bitcoin Stats says that for today, the mean was 5.1 seconds and 90th percentile was 22.4 seconds.


Do I need the bitcoin blockchain for having a simple wallet using the bitcoind (daemon)?

There are "lightweight" wallets, such as Electrum and mobile wallets, that do not require the blockchain to run.  In exchange for this convenience however, their users rely on a centralized server (or servers) to host the blockchain, which is a bit of a security compromise.

bitcoind is the "Satoshi client" and is not a lightweight wallet.  It won't work without the blockchain.


Does the Bech32 address format decrease Bitcoin's possible address count?

Keep in mind that both types of addresses, assuming we are comparing P2PKH with P2WPKH addresses, are just encoding the hash of a public key. The hash used in both address types is a RIPEMD-160(SHA-256(public key)), so regardless of the encoding, the number of possible valid addresses remains the same. Each address format is simply encoded with a different checksum system, different version system, and different characters. But neither address format is actually ever used within bitcoin transactions themselves, they both just get "unwrapped" when given to a wallet.


When creating a Bitcoin Farm, how do you evade having 20,000 modems

By using a network switch, like how it's done in the server rooms.

Switches extend the network, allowing more devices to be connected.


Is the timestamp in the genesis block relevant?

The newspaper quote proves that Satoshi did not mine a large number of blocks before the public announcement of Bitcoin on January 10. The block chain creator could for example create a chain of 1000 blocks before publishing just the first one. He now has a head start for mining and can invalidate the public block chain at any time by announcing the blocks he kept secret as long as his chain is longer. The block headers contain timestamps but these can be manipulated if no one else is verifying the blocks.


Online wallet to redeem pre-fork paper wallet for both Bitcoin and Bitcoin Cash

This is copied from  the Electrum website today:

Recommendation on how to redeem Bitcoin Cash

July 31st, 2017.

Electrum is a Bitcoin wallet created by Thomas Voegtlin in 2011.
Electrum is distributed by Electrum Technologies GmbH, a company
registered in Germany, using the website https://electrum.org

Electrum users who are not interested in Bitcoin Cash do not need to
worry nor to take any particular action. The following note is only
for users who want to access their Bitcoin Cash (BCC).

"Electron Cash" is a fork of Electrum for Bitcoin Cash. Electron Cash
is not endorsed by Electrum. It is open source, and binaries
(executables files) are available for Windows, OSX and
Android. However, when you run binaries instead of source code, you
have no guarantee that they match the source code. This is why wallet
binaries are usually signed by developers. A digital signature engages
the responsability of the person who signs.

The person who distributes the Electron Cash binaries has decided to
remain anonymous, and uses the fake name "Jonald Fyookball" in order
to sign Electron Cash binaries. Thus, if these binaries contain code
that is designed to steal your bitcoins, the author of the theft will
be anonymous and walk away safely with your funds.

This danger is exacerbated by the fact that the default behaviour of
Electron Cash is to silently copy all your Electrum wallets into its
own directory. Thus, if you run Electron Cash on a machine where you
previously used Electrum, all your pre-existing wallets will be
available in Electron Cash, and you will only need to enter your
password in order to expose your bitcoins to potential theft.

Therefore, users who want to run the Electron Cash binaries should do
it on a separate machine, that does not have their Bitcoin wallet. We
recommend to proceed as follows:

Install Electron Cash on a machine that does not have your
Electrum wallets.
Wait until the BCC hard fork has taken place, and a few BCC blocks
have been mined.
Move all your Electrum funds to a new Electrum wallet. This will
move only your BTC, and not your BCC, because the BCC blockchain has
replay protection. Wait until the transaction is confirmed.
Enter the seed of your (now empty) old wallet or private keys in
Electron Cash. Since the BTC have been moved to a new wallet,
entering your old seed in Electron Cash will not put your BTC funds
at risk.

Following these 4 easy steps you will be able to access your BCC
without compromising your BTC.


Is it possible to create a wallet service, which doesn't have all the blockchain downloaded?

Without any security trade-off vs. running validating nodes, there is no way to create a wallet-service without downloading and validating the blockchain.

If SPV node security trade-offs are acceptable, you may consider running the wallet service with these.

SPV nodes do not fully-validate the blockchain, and only download the longest header-chain. However, since they only validate POW in the header-chain, and do not index all transactions (only those related to the wallet service addresses), they need to obtain a proof that a tx of interest is confirmed via. another full-node peer. This proof can be delivered a merkle-proof, which represents a specific branch of the merlke-tree beginning with the txid of interest, of which the root is committed to each block header.

The security trade-off for SPV nodes is two-fold:

Privacy: Since the wallet service is interested in tx's pertaining to specific addresses, some information about addresses will necessarily leak to the queried full-nodes.
Potential for omission: Peers can always remain silent about specific confirmed transactions without the SPV client being able to prove this, potentially requiring cross-comparison heuristic across validating peers.
A SPV client does not validate any consensus rules, thereby not knowing whether the chain/branch it is following correctly validates according to the validation rule set the user supports.


No, it is not possible. QBitNinja is too tightly coupled with Azure, that means vendor-locked. See this issue for a recent attempt to decouple it.


Set a standard transaction fee in bitcoind

Already got it I needed to use -mintxfee


Why are transactions not used for signalling?

Such a system could be easily gamed by people who simply spam the network with transactions and by miners who choose what transactions to include in their blocks. The penalty which they incur is still very small as compared to income of major economic players.

It does not take into account the amount of coins and also does not consider the vote of people who are simply holding bitcoins.
Such a metric would only be misleading.

There was a dicussion on this and a way for wallets to implement this on bitcoin-dev mailing list under the title
[bitcoin-dev] Transaction signalling through output address hashing
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013532.html


Difference between a SegWit address and a P2SH address

Until a P2SH-P2WPKH UTXO is spent and the redeemScript is exposed, a P2SH-P2WPKH address is indistinguishable from a non-segwit P2SH address (such as a non-segwit multi-signature address)

Reference: https://bitcoincore.org/en/segwit_wallet_dev/

That's because a P2SH address is still a hash of the script, regardless of whether the script is an embedded P2WPKH script or plain old script script. So you can't 'decode' it back into what the script is, you have to wait until the script itself is made public when redeeming the output.


You should not run Armory as root. If you want to run armory as another user, pick a user other than root. You can use "sux" (which you can apt-get install) to become that new user.


Schildbach Wallet complains: not enough mBTC for transation

An mBTC, or MilliBitcoin, is equivalent to 0.001BTC" is this a fixed "forever" exchange rate (BTC)1:1000(mBTC)?

This is not an exchange rate, it is just a unit prefix. There are 1000 millibitcoin in a bitcoin, in the same way there are 1000 millimetres in a meter. Some wallets will allow the user to change the unit that their balance is displayed in (eg BTC, mBTC, sats, etc). Functionally, there is no difference between BTC and mBTC, it is just a display preference.

and it complains "not enough funds" for transfer.

The bitcoin network has been extremely busy for the last few days, so transaction fees are currently very high compared to the what we've seen for the last year. Your wallet may be attempting to construct a transaction which includes a very high fee (more than the wallet contains - which seems kinda crazy, but I've seen some very poorly designed fee management algorithms in some wallets before), but without additional information, its not really possible to fully diagnose the issue. It is probably worth contacting the developer of the wallet if the problem persists. You can also search for 'mempool visualizer' online to watch how busy the network is, and then make transactions during less busy times.
Keep in mind as well, some scam wallets will ask you to deposit coins in order to 'unlock a deposit', 'pay a transaction fee', or some other similar nonsense. I am not saying that the wallet you are using is indeed a scam, but I have not heard of it before, so I mention this just to make you aware of the possibility. The prudent bitcoin user stays alert for such scams.

Schildbach Wallet (...) this app was shown to me by a friend.

I̶ ̶h̶a̶v̶e̶ ̶n̶e̶v̶e̶r̶ ̶h̶e̶a̶r̶d̶ ̶o̶f̶ ̶t̶h̶e̶ ̶w̶a̶l̶l̶e̶t̶ ̶s̶o̶f̶t̶w̶a̶r̶e̶ ̶y̶o̶u̶ ̶a̶r̶e̶ ̶u̶s̶i̶n̶g̶ (EDIT: this wallet is indeed listed on bitcoin.org, as RedGrittyBrick pointed out in a comment below). To help ensure you are using software which is not malicious, I would suggest starting from this page: https://bitcoin.org/en/choose-your-wallet. There are a lot of malicious wallets out there that will steal/scam you.

how in the world, should this be usable to buy a cappuccino worth 3.10€?

When the network is busy and fees are high, it really isn't. During low fee times it is more reasonable, though it is worth mentioning that a ledger which computes and stores every person's coffee transaction information for all time (on tens of thousands of nodes) is a grossly inefficient way to expect a monetary network to work.
If I had to make a small value purchase using BTC, I would instead use the lightning network, which is quite well suited to the job. Doing so will generally require setting up a lightning node/wallet before transaction fees skyrocket though.


As of today (2015-Nov) how many different anonymous type altcoins are there?

Here are a few I have heard of, some are in development some are already being used.

ZeroCoin:
http://zerocoin.org/

whitepaper:
http://zerocash-project.org/paper

  The road ahead

  The plan is to make an altcoin, powered by the new Zerocash Protocol,
  that provides consumers with the financial privacy they expect from
  debit cards, credit cards, and cash. To do this, we plan on release a
  working, non research code quality client based off the bitcoin 0.9.1
  codebase integrating the new Zerocash protocol.

Monero:
https://getmonero.org/home

  WHAT IS MONERO ? Monero is a secure, private, untraceable currency. It
  is open-source and freely available to all.

  With Monero, you are your own bank. Only you control and are
  responsible for your funds, and your accounts and transactions are
  kept private from prying eyes.

  Want to find out more? An overview of Monero's main features are
  below. If you'd like to try Monero for yourself the Getting Started
  section is an excellent launching point.

ShadowCash:
http://aboutshadow.com/

  SHADOWCORE

  An entire privacy-based platform which aims to establish an anonymous
  economy, with multiple features that give people all the financial
  freedom and privacy they should have.

  Shadow is a decentralized anonymous communication, commerce and
  currency platform through which the virtual currency, ShadowCash, can
  be transferred. One of the significant advantages of Shadow is its
  deep integration with the rest of Shadow's features as well as
  offering native TOR support for IP obfuscation.

DashCoin:
http://dashcoin.net/

  Dashcoin (DSH) is an automatically mutating anonymous cryptocurrency
  Dashcoin is a Next generation anonymous cryptocurrency and the first
  automatically mutating cryptocurrency created with CryptoNote
  technology. What does this really means? Our network code is always up
  to date with minimal developer cost and close to 0% errors. You are no
  longer depending on developers good will. Concentrate less on
  developers and more on your trades and projects.

Here seems to be page that has gathered a few more anonymous altcoins:
http://www.altcoinfever.com/anonymous-cryptocurrency-altcoin/

As for the size of any of these communities, that I am unsure of. I just wanted to present you with options I have found. I cannot guarantee the validity of any of these altcoins and their claims of anonymity.


The Steem blockchain is verified by witnesses.

From the Steemit faq: The Steem blockchain requires a set of people to create blocks and uses a consensus mechanism called delegated proof of stake, or DPOS. The community elects 'witnesses' to act as the network's block producers and governance body. There are 20 full-time witnesses, producing a block every 63-second round. A 21st position is shared by the backup witnesses, who are scheduled proportionally to the amount of stake-weighted community approval they have. Witnesses are compensated with Steem Power for each block they create.

Each Steemit account can vote for up to 30 witnesses.


What is the best way to earn money mining Bitcoin?

If you mine with your RaspPi or your PC, you'll lose money because of electricity fees. The best way to mine is buying a miner (S9 is the best currently), but if you don't want to pay $1500, or don't want a noisy machine at your home, choose cloud mining. It's a bit risky, too.


How to establish connection for mining testnet blocks on newly created altcoin

I am glad to say I found a solution. It is quite trivial:
 The main PC, the main node, should be listening for others, therefore you need to add a command:

listen=1

In addition, I would suggest you to add following commands as well, but for all nodes:

testnet=1
testnet_config=1

Good luck everyone.


Does Bitcoin "confirmations" have nothing to do with fullnodes -- only miners?

If Joe sends Sue a satoshi, it will be at least 9 minutes and 59 seconds until they get 1 confirmation (as I understand it).

This is not true. There is no fixed time interval between two blocks. You might see several blocks in a few minutes or no blocks for an hour. On average if looking at a bigger time frame, the block interval is ~10 minutes because of difficulty adjustments.

Then, subsequent blocks will increase the number of confirmations in perpetuity, with 6 blocks equating to roughly one hour.

Partially correct. Blocks mined after the first confirmation will increase a transaction's number of confirmations.

But up until today, I always thought that "confirmations" were simply fullnodes (such as the non-pruned Bitcoin Core I'm running) "confirming" that the transaction took place

Pruned nodes are also full nodes because they fully validate all blocks and transactions.

Full nodes do not add transactions to blocks. That is done by miners when they mine blocks.

If so, what is the point of my fullnode? Does it have any say/power whatsoever? It seems like the miners are the only ones who matter

Full nodes are used because you cannot trust others (verify all transactions yourself), privacy (not leak information about your transactions) and enforce consensus rules.

Miners are not the only ones who matter. Rather, if miners mine invalid blocks those get rejected by the full nodes.


How does one get money into the Ripple system?

Fiat currencies can only exist as debt. If you have them, and they're not in your physical possession, it can only mean that someone owes them to you. This is the same way it works outside the Ripple system. If you have $1,000, and you don't have physical bills, then someone (most likely your bank) owes you that $1,000.

The Ripple system uses gateways whose primary purpose is to offer debt with "withdraw on demand" agreements with large numbers of people. This allows those people who are willing to trust that gateway to use their debt as a means of exchange. The Ripple system includes automated exchanges between gateways just as it provides exchanges between currencies.

This is analogous to conventional banking. If my bank owes me $100, I can send you a check to make your bank owe you $100 more and my bank owe me $100 less. You consider me to have paid you $100 because I made your bank owe you $100 and you chose to trust your bank.


Just a few thoughts from someone with no experience with lawyers: since very few lawyers will have experience with Bitcoin, I personally would look for a lawyer familiar with (1) tax law, (2) currency trading and/or commodities trading, and (3) technology in general. Familiarity with technology may be the least important, and may actually not matter at all, except that the lawyer needs to understand the analogy between Bitcoin and a commodity/currency.

While it doesn't sound like you will be doing Bitcoin speculation, you will still, presumably, be trading services for Bitcoin, and then Bitcoin for a national currency. This is where the lawyers knowledge of currency/commodities trading comes into play. For example, do you pay taxes on the spot price of the Bitcoin at the point of transaction? At the end of the year? Or only when you trade the Bitcoin for national currency? What if you trade the Bitcoin for something other than national currency? Such as if you pay your web site hosting fees with Bitcoin? I'm assuming that these are the sorts of questions you'll need answered in the end. You might use these questions during a free/initial consultation to get a sense of the lawyers ability to field the sorts of questions you'll have.


I would recommend VirCurEx. You can use it as a wallet or trade between different currencies.


It might contain security vulnerabilities (which could potentially expose your private key), but that's extremely unlikely. Something more plausible (but still unlikely) is corrupting your wallet.dat, so be sure to back it up before upgrading.

As a normal user, the test build ought to be safe for most purposes. The main risk, I guess, is for people operating exchanges, mining pools, etc., where you can't afford to go down in the middle of operation. The test build is more likely to crash (or fail to work in some way) rather than be insecure.


All of the information provided by Bitcoin Core applies only to the chain it currently thinks is the best block chain.  Any blocks which are not part of that chain are not counted towards the confirmation score.

If you're using Bitcoin Core in a merchant application, you should probably test what happens during various-length forks.  You can do this using the regression test (regtest) mode.  For example (I haven't tested this):

nodeA_options="-regtest -rpcpassword=foo"
nodeB_options="-regtest -rpcpassword=foo -datadir=/tmp/regtest -port=9999 -rpcport=10000"

## start node A
bitcoind -daemon $nodeA_options

## Create a block to get its coinbase in your wallet (unspendable for 100 blocks)
bitcoin-cli $nodeA_options setgenerate true 1

## start node B and connect it to node A; it'll sync the block
bitcoind -daemon $nodeB_options -connect=localhost

## stop node A to break the connection
bitcoin-cli $nodeA_options stop

## generate a block on node B
bitcoin-cli $nodeB_options setgenerate true 1

## Restart node A and generate a block
bitcoind -daemon $nodeA_options
bitcoin-cli $nodeA_options setgenerate true 1

## Stop and restart node B with a connection to node A
## At this point, both nodes have a different block #2 so you can see
##   what a fork looks like to the nodes
bitcoin-cli $nodeB_options stop
bitcoind -daemon $nodeB_options -connect=localhost

Of particular use, you will probably want to set the -alertnotify command, which can warn you about longer forks and allow you to automatically shutdown your payment processing system until the fork is resolved or you intervene manually.  You may also want to look at the listsinceblock RPC which can work in conjunction with -blocknotify to tell you what's changed in the most recently-accepted block.


Which country has the highest number of Bricks and Mortal merchants who accept Bitcoin per Capita?

Coinmap is definitely not comprehensive. I imagine most of the listings are in NA and Europe because the site itself is in English. I doubt there will ever be a comprehensive centralized repository of brick-and-mortar stores taking bitcoin just due to the nature of the network itself.


How do I build Bitcoin from source in Linux?

Basically, you do this:

Download the distribution tarball or repository. You can use the link on the project's GitHub page.
If you used the distribution tarball, unpack it.
Obtain any needed prerequisites. Things you may need include the development packages or source builds of: OpenSSL, Boost, libZ, GLib2, and BerkeleyDB. You should be able to use your distribution's development packages for everything with the possible exception of OpenSSL. I don't know offhand if Ubuntu ships a version that will work with the Bitcoin client (including ECDSA support). If not, rebuild OpenSSL from the source with default options.
Make a copy of the supplied UNIX makefile (called makefile.unix) and call it Makefile.
Adjust the Makefile you created as needed. You may need to: Add include/library paths for the prerequisites if they're not in the usual places. Localize the name of the BerkeleyDB distribution, for example 'db_cxx-5.1' instead of 'db_cxx'. Localize the name of some Boost libraries (on some distributions, most will need '-mt' added to the end).
Type 'make' and hope for the best.
If it didn't work, figure out why and fix it.

One caution: If two builds of the Bitcoin client are linked against different versions of the BerkeleyDB package, they may not be able to read each other's database files (including the wallet.dat file). There is a process to convert the files (dump to text on one version, build from text on another) but it's cumbersome and perilous.

Update: To your two specific issues, the fix is to remove (or comment out) lines 476 and 479 in the net.h file, the extern declarations of pnodeLocalHost and hListenSocket. (Be careful, when you remove one, the line number of the other may change. Identify both changes before you make either.)


Can I generate passive income on BitCoin

If you buy 100 bitcoins for $10,000 ($100 per coin), indeed you will always have 100 coins, you will never end up with 101. But if the price increases to $15,000 for your 100 bitcoins, you could sell 33.333 of them for $5,000 fiat profit, and still you would have $10,000 worth of BTC just like you bought at the start - a profit of $5,000.

You can increase the number of bitcoins for free if the price then drops after you sold some, lets say the price goes back down to $100 per coin after you sold the 33.333 coins ($5,000 at the time of sale), then you could purchase back 50 coins at the new price, leaving you with a total of 116.667 BTC


What is stopping a Taproot spend following old Taproot rules (initially treated as anyone-can-spend) pre-activation creating a re-org post activation?

When the soft fork (e.g. Taproot) is activated (assuming it is at some stage) all nodes agree to only verify transactions according to Taproot rules from the point of Taproot activation onwards. No nodes will verify transactions pre-activation according to rules specified at activation. Hence the network will always agree that your transaction following the old Taproot rules was an anyone-can-spend even if a valid or invalid SegWit v1 witness is available.
In contrast, post activation there will be some nodes on the network enforcing the new Taproot rules (running the latest version of Bitcoin Core) and some treating them as anyone-can-spend (running older versions of Bitcoin Core). A transaction broadcast post activation following old Taproot rules (never activated on the network) will be rejected by the nodes enforcing the new Taproot rules. Even though some nodes will treat transactions following the old Taproot rules or the new Taproot rules as anyone-can-spend, only transactions following the new Taproot rules will make it into a mined block accepted by all nodes on the network.


Is there a way to launch bitcoin-core and have it shut down when synchronized?

You could sleep for e.g. 10 minutes after you started bitcoind, and then  do the following:

bitcoin-cli getblockcount, which is the current height of the node
call getpeerinfo, parse the JSON, take the median of startingheight (how far these nodes are)
If difference < 10, stop bitcoind with bitcoin-cli stop and exit
Sleep 1 minute, repeat

Or use something like this to determine if the last known block is less than an hour old.


What kind of bug does bitcoin core possess that have to be replicated

Bitcoin's consensus rules are defined by (economically relevant) running nodes. Right now, those are primarily various versions of Bitcoin Core, but there is no inherent reason why that would always be the case.

What this means is that there cannot be a specification of those rules. Imagine we write a document with as close a description of what the most recent version of Bitcoin Core does as we can muster, and declare it to be "The Bitcoin protocol". Now what happens if we discover that the code actually does something slightly different. Which is now wrong? The code or the document? If it's something that constitutes a serious problem (say, stealing money), people may try to convince the world to migrate to a modified implementation, or a different one. But this approach cannot be guaranteed: node owners are sovereign and nobody can force them to adopt new code. In the end, it would just mean that our document is not a correct description of the rules.

Ultimately, this means that at best we can create a document that describes our best knowledge of the consensus rules, but not one that prescribes it. The code that people actually run has the last word, always.

So why can't we just make an exact description of what the current code does? Because we don't know. Knowing the exact behavior of code is remarkably difficult. In what follows I'm going to use the term "quirk" rather than "bug", because for all intents and purposes, these details constitute the Bitcoin protocol, for better or for worse. Here are some examples:

Initially Bitcoin relied on OpenSSL for ECDSA verification. ECDSA is well specified, and one would expect that what OpenSSL implements is exactly follows that specification. It didn't. It allowed various weird deviations from the DER standard (which specifies how the big numbers in ECDSA signatures are turned into bytes). This doesn't break the security of the signature system (it's still impossible for someone without private key to produce a signature), but it did pose a problem for Bitcoin as it meant we'd have to maintain OpenSSL's quirks forever. This was eventually resolved using a softfork (BIP 66) that restricted the set of valid signatures to a well-defined subset. In fact, the situation was even worse than this: OpenSSL turned out to be inconsistent with itself about exactly which deviations from DER were accepted: it behaved different on 64-bit Linux and Windows, which would have allowed an attacker to fork the network between those two. You can read my disclosure of this issue (after BIP 66 solved it) here.
In March 2013, the network experienced a fork between nodes running Bitcoin 0.7 and those running 0.8. The history is described as a port-mortem in BIP 50. The problem was that every version before 0.8 used a database library called BDB. BDB requires configuring a maximum number of "locks" (limiting the number of simultaneous operations that could be performed). It turned out that this number was by default slightly too low. Bitcoin 0.8 replaced BDB with LevelDB which did not have any such requirement. 0.8 was significantly faster, so miners upgraded quickly - and accidentally constructed a block that exceeded the maximum number of locks 0.7 used. The majority of the ecosystem other than miners was still on 0.7, and they rejected the majority chain. It was resolved by having miners revert to 0.7 temporarily, introducing a temporary softfork that "simulated" the locks limit in 0.8, and eventually having the entire network on 0.8.

As you can see, these things aren't as easy as looking at a function and thinking about what it does. These examples both involved an external dependency out of Bitcoin's control, and not quite exactly specified behavior for those. That doesn't mean they're the only source of quirks, but they certainly complicate things.

  For example the same function written in C++ will not work exactly the same as one in Python.

I hope you see now this has actually nothing to do with programming language. If the exact consensus rules were known it would certainly be possible to replicate them in another language (assuming it were possible to also reason exactly about the behavior in that other language). Conversely, reimplementing the consensus in the same programming language has the same problems. The point is simply not taking unnecessary risks when dealing with consensus code - using the code that's already in use has the lowest risk, and small easily auditable changes to it where necessary for performance reasons or intentional protocol changes.

The problem also isn't the known quirks - it's the unknown ones, and I cannot tell you where those are. There are plenty of gotchas that have been discovered over the years and are still relevant in the current rules - and maybe that's the only thing you were after in your question. In that case, there is an old answer here: Satoshi's bitcoind implementation bugs. I'll try to think if I can come up with more recent examples to add there.


Generating Lightning invoice with an optional parameter

You are doing it the correct way. In case you have doubts, you could check if the invoice generated is according to the way you decided by running the command lightning-cli decodepay <invoice> . Below is the result for the invoice that you generated:

lightning-cli decodepay lntb1n1pwhz5a5pp5jcgyzt4578a9y8rk6sv5aylk8j4wqk2grnwwdggaeumfe722324sdq5fysxzmfqwe5kucm9de6qxqyjw5qcqp2fppjmc3rmhe0wngplqnl3002udz6vj3kzwqsfppjg7ddp2vfds5hgdvsvknhdut0fxpe4z6ndth02e8reukhg4lu39xefwevkknh5r7l2ljugknfutfhhumsfprpxefpqwmjq66nkh5kfsu0esx5a0lnwk7lhhvp8tgvexl9cg8meusqty4ls3
{
   "currency": "tb",
   "created_at": 1567708084,
   "expiry": 604800,
   "payee": "023dfbbc3011303a613645671defa34df29934ac19c507c6d42ec88df54a1532df",
   "msatoshi": 100,
   "amount_msat": "100msat",
   "description": "I am vincent",
   "min_final_cltv_expiry": 10,
   "fallbacks": [
      {
         "type": "P2SH",
         "addr": "2NDVm22NNuosAXFbC27Scsn1smMh1QEFZUk",
         "hex": "a914de223ddf2f74d01f827f8bdeae345a64a361381087"
      },
      {
         "type": "P2SH",
         "addr": "2MymqReM8EaYCQKzv4rhcvafGGcddZacUtV",
         "hex": "a914479ad0a9896c2974359065a776f16f49839a8b5387"
      }
   ],
   "payment_hash": "9610412eb4f1fa521c76d4194e93f63caae059481cdce6a11dcf369cf94a8aab",
   "signature": "304402206aeef564e3cf2d7457fc894d94bb2cb5a77a0fdf57e5c45a69e2d37bf3704846022013652103b7206b53b5e964c38fcc0d4ebff375bdfbdd813ad0cc9be5c20fbcf2"
}

However, as the docs point out, the current c-lightning implementation does not use the addresses from these arrays to fulfill the invoice in case no route to the payee is found.  So, if you show your invoice and the payer is using c-lightning, then it won't be able to make an on-chain transaction to you for that particular invoice, if its bolt11 payment fails. This might be especially pertinent in your case as the node that generated your invoice does not have any open channel that is exposed publicly which has an incoming capacity.

Also as a side-note, using fallbacks doesn't make sense for tiny or time-sensitive payments. Since your invoice amount is only 100 milli-satoshi, the payment to fallback addresses will not be routed/accepted on the Bitcoin network as it does not accept dust payments. In your invoice it is a sub-satoshi amount which is also below the smallest unit of Bitcoin.


What is transaction replay and replay protection?

What is a transaction replay

In the context of forks, transaction replay is when a transaction is valid on both sides of the fork. So a transaction can be played (i.e. broadcast) on both chains after the fork and be a valid transaction and confirm. This means that if you intend on sending coins on one fork, you could accidentally end up sending your coins on the other fork as well since someone else could take your transaction and replay it (i.e. broadcast it) on the other chain's network.

  What does replay protection do?

Replay protection is something that makes it so that transactions on one chain are invalid on the other chain thus preventing transaction replay. This can be anything from having a blacklisted address or output type (e.g. if an output to address X is in the transaction, consider it invalid) to changing the signature scheme to changing the transaction format entirely. All this does it makes replaying some or all transactions impossible.


Is there a particular minimal amount of Bitcoin one is allowed to send?

0.00005460 BTC.
According to Paxful

Before making any transactions or depositing Bitcoin to your Paxful wallet, it is important for you to know the minimum BTC amount allowed by the blockchain network for a transaction.
Currently, the smallest amount of Bitcoin you can send or receive in a transaction is 5460 Satoshis, which is equivalent to 0.0000546 BTC.
One of the reasons behind this limit is to prevent spamming transactions.

Although Paxfull isn't Saint Bitts LLC (owner of Bitcoin.com) they are talking about Bitcoin network limits, not proprietary company limits. So it applies. See also What's the minimum transaction with bitcoin?
To send smaller amounts you'd have to use something like the Lightning Network (LN).
Currently 0.0000546 Bitcoin equals approximately 2.71 EUR
Your 0.001707 BTC is larger than this limit. So this is not the cause of your problem.

I keep on receiving the error at confirm "Insufficient funds for fee"

Take the transaction fee into account
"Insufficient funds" is an entirely different problem. When you send x amount of money, for the recipient to receive x you also have to send a transaction fee y. So the amount needed in your wallet at the start is x+y.
See https://bitcoin.stackexchange.com/search?q=insufficient+funds
The size of y depends on

The complexity of your transaction (especially amount of small change rustled up to make the amount)
How busy the network is
How long you are prepared to wait for the transaction to go through. Minutes? Hours? Days? Weeks?

Many wallet programs help you to choose an appropriate fee. You can also use a search engine to find sites that report on current fee-rates.


How to determine estimated block or transaction time

The target block time is usually hard coded. Block time is a function of the current difficulty and the current network hash rate. In Bitcoin, the target hash rate is ten minutes and the difficulty is regularly adjusted to maintain this block time on average.

Whether or not a particular transaction will be included in a particular block is speculative since it is up to miners to include the transaction, however, it is generally considered that transactions with relatively higher fees are more likely to be included.


This transaction is unlikely to be confirmed for a long time.

It has very low priority because it is spending an output which is unconfirmed. None of the parents of this transaction are confirmed either, going back 5 generations.
Each transaction in the chain pays a very low fee of around 0.00000259 BTC, which is below the recommended amount and below what other people are paying to get into a block.


How To Get a New Bitcoin Payment Address

Most online wallets will create for you a new address each time you indicate that you want to receive a transaction, or give the option of creating a new address. Some enforce this by never showing an address twice and simply handle amalgamation  on the backend.

Creating a new address for each transaction is a fool-proof way of ensuring that someone has paid you, because you've given that address to only that person and no one else. There are also some privacy benefits, as using a new address makes it more difficult to trace the bitcoin trail.


Are there clients that manage several alts?

Ufasoft open source client can manage different alt-coins, most of them with same private keys.

https://bitcointalk.org/index.php?topic=58821.0

PD: be careful, some users have reported malware in Ufasoft mining software.


The short answer is yes. P2pool source code is available at https://github.com/forrestv/p2pool. If you stand up a P2Pool proxy (probably hundreds of them on the Internet actively running) such a server will maintain its own P2Pool sharechain state. As most mining pools, you will also need an active full node of the Bitcoin blockchain to validate the transactions being mined are indeed legitimate. Other miners can connect to your P2Pool proxy (that is part of the distributed P2P network) using either Stratum or GBT protocols that both bfgminer or cgminer support. Those same miners don't have to be sharechain-enabled. The P2pool sharechain is transparent to them. P2Pool supports numerous other alternative coins, and as a P2Pool proxy service you can reap additional merged mining benefits beyond the fixed mining fees established.


It isnt clear what you're doing, and I get the impression that you dont speak english natively, so I doubt we're going to get a better explanation of what you're trying to do. Given your question I can only assume your RaspberryPi's IP is 192.168.178.40, it is running bitcoind, and your trying to access the API on it from a computer somewhere on the internet (because you mention dyn-dns), and that there is a router in front of the RaspberryPi performing NAT. If you want any computer on the internet to be able to access the API

rpcallowip=0.0.0.0/0

or if you only want a single computer on the internet with a static IP to be able to access it, then you'd put in the IP address of that computer rather than the RaspberryPi's IP address.

If I got it wrong, try rephrasing your question, because as I said, we don't know how your network is configured.


How dependent is Bitcoin on the clock?

A lot less than many other applications.

  A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours.

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

AFAIK this means that a block can have a timestamp that is earlier than that of its parent (a block can appear older than its parent). I vaguely recall that there are some such blocks in the Bitcoin blockchain.

So if computers become unable to keep good time to within 2 hours of the correct time, they will start to be problems, blocks will be rejected and the Bitcoin network might, I suppose, fragment.

Note that time synchronisation protocols such as NTP can synchronise times on computers to less than a few tens of milliseconds across the planet, despite significant latency and jitter. There's no good reason for computers to have time drifting apart by seconds, let alone hours.

Compromising clocks might be exploitable but it seems non-obvious.


address format is different from bitcoin core response from btcd

Addresses are hashed and encoded pubKeyScript. There are different types of address you can derive per a single public-key (or say also private-key). Most prominent ones are P2PKH, P2SH-P2WPKH, native P2WPKH (bech32).

I expect that the address type you are deriving from BTCD is different then the one your getting from Core.

Since a Core 0.16 (until now time of writing Aug 2018), the default address derivation format is "p2sh-segwit" (P2SH-P2WPKH, starting with 3). I could imaging that BTCD still derives you P2PKH addresses (starting with 1).

Since 0.16, Core has that addresstype argument where you can pass in "legacy" or "bech32" in order to generate either traditional P2PKH addresses or new Bech32 ("bc1...") addresses


"Deposit with Bitcoin client" does the opposite of what you need to do.

(Though I'd read this before making any transactions on that website.)


If you settle for a relational DB you can try BitcoinDatabaseGenerator.
https://github.com/ladimolnar/BitcoinDatabaseGenerator/releases
Sources and wiki: https://github.com/ladimolnar/BitcoinDatabaseGenerator

It may take you a few hours (it takes me 90 minutes but that will vary depending on your hardware and configuration) to transfer the blockchain files to the DB.

If you do that take a look at the views that are already defined in the DB, some of them may be useful to you.


How to change user permissions on the /blocks/ folder in linux?

You should be able to change the permissions of the block files using the following command:

sudo chmod -R go+r .bitcoin/

(replacing .bitcoin/ with your Bitcoin data directory)

The problem is that bitcoind will create all new files with permissions so that only allow the owner of the files can read from and write to them (600), because of the following line in init.cpp:

umask(077);

I have created a patch and a pull request that should fix this, though: https://github.com/bitcoin/bitcoin/pull/4286


It is a variable name.

It holds the nonces needed to build a test blockchain.


Is there a difference between OP_PUSHBYTES and OP_PUSHDATA

In what documentation ? I believe you are talking about how rust-bitcoin refers to the OPs > OP_FALSE and < OP_PUSHDATA1 and will answer as such.
There are multiple OP codes pushing bytes to the stack, defined as integers.
Special case: pushing small integers
There are dedicating OP codes for pushing integers from -1 to 16 (named OP_1NEGATE, OP_0 and OP_1 to OP_16 and valued 0x4f, Ox00 and 0x51 to 0x60).
They are used for instance for (small-ish) multisigs as it saves you 1 byte per number pushed compared to using a "real" push opcode.
"PUSHBYTES": pushing small byte arrays
The (not named in the reference implementation) OP codes valued from 0x01 to 0x4b allow to push from 1 (0x01) to 75 (0x4b) bytes to the stack.
They are commonly used to push pubkeys and signatures.
PUSHADATA: pushing byte arrays
The PUSHDATA1, PUSHDATA2 and PUSHDATA4 (0x4c, 0x4d and 0x4e) operands are used to push a byte array to the stack which size is defined as a variable-length integer .
Further: too many encodings!
This flexibility of encoding introduced malleability in the scriptSig, which was not protected by the signature (which it carries).
BIP62 proposed to restrict this encoding to avoid possible malleation.


Install boost.

See the instructions if you have additional problems.


Is it possible to restrict Bitcoin's network traffic?

Banning peer to peer networks is very difficult in general.

Assuming a node is starting for the first time, I believe it uses DNS seeds to find peers. If those DNS seeds are blocked, is it possible to prevent bitcoin node discovery ?

This is possible but all you need in order to bypass it is one IP address of one peer and then you can connect to it manually and join the network

Is it possible to block certain ports to avoid bitcoin communication ?

Again that's possible but easily circumvented by changing the default ports

Any other ways ISPs can detect bitcoin traffic ?

Peer traffic is not encrypted so ISPs can flag bitcoin traffic by performing some inspection on the data being sent. But again this is bypassed by using a VPN or TOR.
Another way someone might try to stop you is blocking your internet access completely but this can be circumvented too because bitcoin is accessible via satellite, all you need is a dish and you don't rely on your ISP any more.


It might be a signal your GPU is slowly decaying away, or may have to do with competition.

What coin are you mining, and at what pool? I've noticed that as more miners with more powerful machines enter a pool, they tend to give partial results very quickly so the pool orders a work restart more often - lowering the number of shares I get. If your pool allows you to manually set difficulty then set it to a lower value: better to send some shares for a lower difficulty than no shares at all.


How does cryptsy.com allocate trades for many orders with same price

At Cryptsy the order is First In First Out influenced by the account's trading history. If the server were to receive buy orders at the same time assuming there is enough coins at the specified price to fill the orders, the server looks at each account and the one with the most trading history gets processed first, then in order to the account with the least trading history. I work for Cryptsy, I'm Brad!


You may want to take a look at this GitHub repo, which supports merged mining.


What's the difference between synced_blocks and synced_headers?

Bitcoin clients can have headers without having blocks. (However, Bitcoin Core never has a block without a header.)

A synced_blocks of -1 means that the best block for the other node is unknown.

synced_blocks is set here:

https://github.com/bitcoin/bitcoin/blob/b3e42b6d02e8d19658a9135e427ebceab5367779/src/main.cpp#L557

stats.nCommonHeight = state->pindexLastCommonBlock ? state->pindexLastCommonBlock->nHeight : -1;

A synced_headers of -1 means that the best header for the other node is unknown.

synced_headers is set here:

https://github.com/bitcoin/bitcoin/blob/b3e42b6d02e8d19658a9135e427ebceab5367779/src/main.cpp#L556

stats.nSyncHeight = state->pindexBestKnownBlock ? state->pindexBestKnownBlock->nHeight : -1;


Are all UTXOs locked by an address spent in a transaction?

Transactions explicitly refer to which UTXOs they are spending.

You can construct a transaction which only spends one of the two 5-BTC UTXOs, and sends 2 BTC to the destination and 3 BTC to a (possibly new) address of yourself.

You can also construct a transaction which spends both, and sends 8 BTC back to yourself. Or it could have multiple outputs that send funds back to yourself, summing up to 8 BTC.

In short: there is nothing special about the two UTXOs that share an address, apart from the fact that the same key can sign for both - but it doesn't have to.


Question 1) why is not the omni a new blockchain at all if they forked it from bitcoin ? we can see that on github.

As Murch said, Omni uses Bitcoin as its immutable database. So Omni is like a separate blockchain, since the contents of Omni transactions embedded in the Bitcoin blockchain are not relevant to Bitcoin nodes. If there's an invalid Omni transaction, then BTC nodes would still accept it.
Omni doesn't have a directly-connecting peer-to-peer network. It relies on data pushes on Bitcoin.

Question 2) let's assume, it's not a new blockchain - then this means that my second thought is correct. How does it write data to bitcoin blockchain ? I can think of one way: P2SH Scripts, but wanted to make sure.

They could use P2SH - I have a website that uses P2SH to embed data in the blockchain, and it works perfectly. However, currently Omni uses bare OP_RETURN scripts. Most likely, they never thought about using P2SH when they first designed it so they might not afford a breaking change (for Omni, not for BTC) introducing P2SH data pushes. P2SH pushes - are actually currently more feasible.

Question 3) if the omni is not a new blockchain at all, then how does its explorer work ? I guess, their explorer fetches all their related P2SH Scripts from bitcoin itself . right ?

Omni has its own software - a fork of Bitcoin Core. They listen to the Bitcoin network and update their blockchain. If they pulled data from P2SH every time, that would be a waste of computing resources.
So every time a new Omni update on Bitcoin occurs, they update their blockchain, then use their blockchain as their data source.


Bitcoin Core reports progress only up to 0.999999

This is a rounding issue, and not new.

You are most likely fully synchronized.


My system is syncing headers, what does that mean?

Bitcoin's state gets synchronized by everyone downloading the blockchain and applying all transactions in the correct order. Earlier versions of Bitcoin would just download block for block until they were caught up. Nowadays, Bitcoin first synchronizes only the block headers which are 80 bytes each and allow the node to pre-filter orphaned blocks and dead sidechains, before downloading all the corresponding blockchain data.

When your computer got shut down, likely some of your node's blockchain state got mixed up, so it's rebuilding the chainstate database, first headers, then blocks.


Bitcoin Core - Bought bitcoin to a 'sending address', what can I now do, nothing is showing up in my transactions

If you provided one from your sending instead of receiving consider those coins donated. Your wallet only shows transactions on addresses you own.

What you can do is try to figure out what address you provided them. I've never used the service you mentioned but they probably have the transaction ID available. Once you find out the address try to remember what you used that address for in the past. Your coins might be on an exchange or website you used before.


Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)?

No. If you create one, it won't be relayed or mined by Bitcoin Core. If it gets into a block, it will be rejected. From the source code for Bitcoin Core (tx_verify.cpp:164):

if (tx.vout.empty())
    return state.DoS(10, false, REJECT_INVALID, "bad-txns-vout-empty");

However, you can create a vout with 0 satoshis. That isn't a "standard" transaction, so it will not be mined by the software by default. However, if it gets into a block, it's valid.


.csv file of every block timestamp in btc history

You can use https://blockchair.com/bitcoin/blocks.
It is limited to 1 million cells for free, but as you only need "Time" and "Height", just:

deselect all checkboxes but "Height", and click on "Export" selecting then "csv". Open this file with your spreadsheet app.
deselect "Height" and select only "Time". Export.
Open the file from (2), copy the column, and paste it next to the first column in file from (1).
as the results are both ordered by time, rows coincide and you already have the desired data!


Perhaps, if you want to generate a vanity address, I suggest you use Vanitygen Plus

https://github.com/exploitagency/vanitygen-plus (More up to date and features)

and to compile, run make -f Makefile after u clone the repo and cd into it.


If bitcoin is decentralized then who keeps track of computers in network

Nobody keeps track of all the computers in the network, or at least not as part of core network functionality.  There are sites that attempt to track nodes (such as https://bitnodes.21.co/), but they are not needed in order for Bitcoin to function, and are not utilized by nodes.  Each node only knows about the nodes it is connected to.

Therefore, to broadcast a transaction, a node simply sends it to the nodes to which it is currently connected.  Those nodes, in turn, relay the transaction to all their connections who all do likewise.  This means a transaction can reasonably be seen by all nodes in a very short amount of time (a few seconds or less).

For information on how nodes find other nodes to connect to in the first place, there's already some great answers here:

How do Bitcoin clients find each other?


comment and comment-to are both just stored as text with the transaction. The intent is that comment be used to store what the transaction is for, and comment-to be used to store the name of the person or organization to which you're sending the transaction.

Neither are stored anywhere besides your wallet (they're not sent with transactions), and neither are encrypted in any way.


How do you get a Bitcoin Public Key from a Private Key

I'll try answering this again in a different way,
using small numbers to keep it readable.

convert the private key to binary representation, so decimal number 105, which is 0x69 in hex, becomes  01101001.

calculate this list of points, by repeatedly doubling the Generator point G:
1*G
2*G = G+G
4*G = 2*G + 2*G
8*G = 4*G + 4*G
16*G = 8*G + 8*G
32*G = 16*G + 16*G
64*G = 32*G + 32*G

write the bits of the private key next to this list like this:
privkey    pointlist
   1          1*G
   0          2*G
   0          4*G
   1          8*G
   0         16*G
   1         32*G
   1         64*G

now start adding only those points which hava a 1 written next to them.
    9*G = 1*G + 8*G
   41*G = (9+32)*G = 9*G + 32*G
  105*G = (41+64)*G = 41*G + 64*G

now you have calculated the public key for privatekey 105 by using only point doubling and point adding operations.

The actual value will be:
(0xf219ea5d6b54701c1c14de5b557eb42a8d13f3abbcd08affcc2a5e6b049b8d63,
 0x4cb95957e83d40b0f73af4544cccf6b1f4b08d3c07b27fb8d8c2962a400766d1)

The public key will then be in one of two formats:

full, this is a 65 byte number, starting with a byte 0x04
compressed, this is a shorter form, 33 bytes, starting with either 0x02 or 0x03.

The full public key is 0x04, followed by 32 bytes of the x-coordinate, followed by 32 bytes of the y-coordinate.
The compressed public key is 0x02 or 0x03 depending on whether the y-coordinate is an even or odd number,  followed by 32 bytes of the x-coordinate.
Then some more notes on your question:

Some older texts used to refer to scalar point multiplication, as exponentiation, that is why sometimes the private key is referred to the private exponent.

the parameters of the curve were chosen randomly once. meaning that the designers of the secp256k1 curve tried to unsuccessfully convey that there is no specific structure to this curve. Meaning that the NSA could or could not have put a mathematical backdoor in the curve parameters.

when using this curve and generating your public key, -you- have to choose your private key randomly, in a way that it is impossible for anyone to guess it.

the generateor G is a specific point on the elliptic curve, defined in the secp256k1 curve.


Simply put, it is not possible to revert transactions once they are made because it would allow people to scam others by taking back the money they have paid when they bought something. Your money is lost.


Copay wallet problem: "Could not update Wallet: Network connection error"

After some hours, it started to work again. Apparently bitpay's servers were down for a bit.


Options to automatically invest to Bitcoins each month in EUR?

localbitcoins - cheap - spread cost min 2.5 % + 1 % (transaction fee) but more time and your work. Big market.
Bitpay (used by Airbaltic company) - easy, but more expensive.

Waiting for better decentralized bt systems still. Etc K.im coming.

Code https://money.stackexchange.com/a/20277/1627


Multiple public keys - Total received funds

If you're running Bitcoin Core as your wallet, then the graphical interface is handling your wallet's total balance already, which includes the balance of every address within your wallet.

If you prefer the command line method, use bitcoin-cli getbalance to get the total sum of all transactions in your wallet. That command basically balances your wallet transaction history like a checkbook, so including deposits and debits, and delivers you the final balance.

The balance shown in the Bitcoin Core GUI is the same as the balance displayed with bitcoin-cli getbalance.

To answer your second question, as far as I can tell there is no downside to creating unique addresses for every transaction, and in fact it is highly recommended in order to aid in anonymity. The fact that you own all of the Bitcoin associated with a particular wallet is harder to determine when more than 1 address is used to receive funds.

However, spending the entire balance of multiple addresses in a single transaction could negate any protection you were hoping to have by using multiple addresses in the first place, since an attacker could then determine, using that single transaction ID, that the total balance of the multiple addresses was associated with the same wallet.

Hope this helps

EDIT

One important note when creating many unique addresses is, if using the Bitcoin Core wallet, backups would need to be created more frequently because new private/public keypairs are generated when creating a new address, and previous backups will not contain the new keypairs. Therefore, if you create a backup of your wallet, then create a new address and receive 1BTC at that address, then your wallet backup will not contain the address that received 1BTC.


What is the default relaying policy for RBF double spend transactions?

Nodes will only relay if mempoolreplacement hasn't set to false (most nodes probably do relay because the default is true).
There are serval rules for accepting a replacement after BIP125 (check the BIP for more details). In general: The replacement must pay greater fees than the transactions it replaces - if we did the bandwidth used by those conflicting transactions would not be paid for.


Being offline: when do other nodes close channels?

A Lightning Channel does not have any requirement as to when to close the channel, as specified by BOLT. It is entirely decided by the user, and the implementation. For the case of lnd, whenever the user wants to close the channel, he will call
closechannel trying first to perform a cooperative close, unless specified otherwise:

Name:     "closechannel",
Category: "Channels",
Usage:    "Close an existing channel.",
Description: `
Close an existing channel. The channel can be closed either cooperatively,
or unilaterally (--force).

A unilateral channel closure means that the latest commitment
transaction will be broadcast to the network. As a result, any settled
funds will be time locked for a few blocks before they can be spent.

In the case of a cooperative closure, One can manually set the fee to
be used for the closing transaction via either the --conf_target or
--sat_per_byte arguments. This will be the starting value used during
fee negotiation. This is optional.

To view which funding_txids/output_indexes can be used for a channel close,
see the channel_point values within the listchannels command output.
The format for a channel_point is 'funding_txid:output_index'.`,

Even when calling closeAllChannels , being that counterparty node offline, the shell prompts to the user before unilaterally closing the channel:

        // If the channel is inactive, we'll attempt to
        // unilaterally close the channel, so we should prompt
        // the user for confirmation beforehand.
        if !channel.GetActive() {
            msg := fmt.Sprintf("Unilaterally close channel "+
                "with node %s and channel point %s? "+
                "The closing transaction will need %d "+
                "confirmations before the funds can be "+
                "spent. (yes/no): ", channel.RemotePubkey,
                channel.ChannelPoint, channel.CsvDelay)


Do any pools discriminate against some transactions?

Yes; many pools only include transactions based on fees and/or whether the transactions have standard forms. Most pool operators require that transactions have certain fees based on the size (in bytes, not BTC) of the transaction, and I believe that most require the transactions to be in a standard "Pay to address(es)" or "Pay to IP(s)" form. Eligius, for example, generally includes transactions if they have 40.96 µBTC of fees per 512 bytes of transaction, but it could be more or less if they think the transaction seems like "spam" or you make arrangements with the pool operator.


Creating a Deterministic Keychain from BIP32 master public key

It looks like you're trying to get a key from a seed, rather than deriving a key using a path. This uses the default derivation settings, which attempt to derive a hardened key, which can't be done using an extended public key.

Try an explicit, non-hardened derivation instead:

val xpub = "xpub661MyMwAqRbcGiwzoCu93MuL6H91qANYUoYBwD4xSH8bRKJVNXsP1FUnNYiWUiu4trHbs3tavhbr4ih9bwNeVBmdQAnrA5SwSEVVCFza8dy"
val keyChainSeed : DeterministicKey =  DeterministicKey.deserializeB58(null,xpub, MainNetParams.get)
DeterministicKey key = HDKeyDerivation.deriveChildKey(
         keyChainSeed, new ChildNumber(0, false));
val w = Wallet.fromWatchingKey(MainNetParams.get, key);

P.S. You should read the BIP32 spec if you haven't already.