When I exit SSH session bitcoind goes down

You could use screen or a similar tool like tmux or byoblu.
Otherwise use the NOHUP command.

nohup is a POSIX command to ignore the HUP (hangup) signal. The HUP signal is, by convention, the way a terminal warns dependent processes of logout.
Output that would normally go to the terminal goes to a file called nohup.out if it has not already been redirected.
nohup is a low-level utility simply configuring a command to ignore a signal. As seen below, nohup is very far from being a full-featured batch system solving all the problems of running programs asynchronously.

  $ nohup abcd &

  $ exit

Alternatives:
The screen or tmux command can also detach a process from the current shell. It allows to reattach to the process later on.
e.g. the following call will run somescript.sh detached from SIGHUP and in the background:

  $ screen -A -m -d -S somename ./somescript.sh &

https://en.wikipedia.org/wiki/Nohup

My advice is to learn to use screen (or tmux) so you can later re-attach the process to the main shell and interact with it.


Bitcoin sent to Bitcoin Cash address, How to Recover?

Unfortunately, once the transaction is confirmed on the blockchain there is no way to retreive the funds and, that I know of, there is no way to zap the pending transaction from the distributed mempool, nor can I imagine a way. The transaction will likely be confirmed in due course.

Even if Blockchain.com zap the tx locally and the Bitcoin show up again in your friends wallet, once the transaction confirms on the blockchain the outputs used to create the transaction will be spent and that Bitcoin will not be spendable. This also protects against double spending.

The one possible solution to this problem is if your friends Blockchain.com wallet allows RBF (replace-by-fee), you could conceivably (and I do not know how granular transaction control is with Blockchain.com) replace the original transaction with a transaction paying instead back to herself and with a higher fee. A few caveats, RBF is opt-in and so would have to be enabled on the original transaction, Blockchain.com needs to have the user functionality necessary to do this and, once the original transaction is confirmed it is game over anyway.


It is important, because it is used to seed the block and chain databases before syncing can occur (you need a block to build on). It's the root of the tree of blocks, forks, and ultimately the chain tips that represent the chains your software is tracking.

It is imported differently to others, as it's coinbase transaction is not included in the UTXO set (it's unavailable to be spent)

Changing the genesis block is a way to definitively fork yourself away from the bitcoin blockchain, ie, start a new network with it's own separate history.

However, some coins do share a common genesis block (Fluttercoin IIRC, shares Litecoins for whatever reason), but the network is forked by the use of checkpoints (genesis might be the same, but block 1 is checkpointed to Fluttercoins, instead of Litecoins).


Currently, there is a lot of demand for bitcoin transactions, you're sort of looking at "surge pricing".
Transaction fees in Bitcoin are paid for the blockspace that a transaction occupies. This means that the fees for a transaction scale with the number of pieces of bitcoin (UTXO you spend and create, irrespective of the amount of value you transfer. Assuming that you have actually taken custody of your funds in your Exodus wallet when you bought them, you would end up having a lot of UTXO in your wallet if you buy in chunks of $50 to $100. This could cause significant transaction fees when you finally want to move your funds.
To mitigate these costs, you could proceed in multiple ways:

Consolidate your funds: before you move your funds out of your Exodus wallet, send all your bitcoins to yourself. This will consolidate all your UTXO to a single piece. Create this transaction at a very low feerate. The transaction will likely take a long time to confirm, but most of your value will be preserved. After that, a more expeditious transaction to transfer your funds to another market or pay someone can be made at a higher feerate without as high of a relative cost.
Buy bigger chunks: bigger chunks means fewer UTXO and less fees.
Use a custodial market to buy: Buy on a custodial service instead, and withdraw at greater intervals whenever you have accumulated more bitcoin or when the blockspace market is less competitive.

If you want to find out more, I've written about the current situation a bit more here: https://bitcoin.stackexchange.com/a/99699/5406


Can somebody explain this privacy concern with Bitcoin once and for all?

As an example, let's say that Alice is an attacker trying to learn Bob's wallet using this method. Alice sends 1 satoshi to some address that Bob owns.
At this point in time, Alice does not know anything about Bob's wallet, except that he has 1 sat that she sent him. But the problem is when Bob wants to send Bitcoin.
Now Bob sends some Bitcoin to a merchant, Carol. When he does this, his wallet will look at what UTXOs it can spend, construct a transaction, sign it, and send it. For this example, let's say that his wallet chooses the UTXO for the 1 sat that Alice sent him. Of course he is paying Carol more than 1 sat and he also has to pay transaction fees. So Bob's wallet chooses several other UTXOs to cover the amount being spent and the transaction fee.
When Bob broadcasts his transaction, Alice can see it too. This is where the privacy comes in. Alice can see the 1 sat she sent Bob in this transaction he made. Since that transaction includes other UTXOs from Bob's wallet, Alice learns that Bob had those UTXOs in his wallet. She can now check the addresses for those UTXOs and learn some addresses in Bob's wallet. If Bob was reusing addresses, she can now learn a lower bound to the amount in Bob's wallet.
Furthermore, because she knows those addresses belong to Bob, she can watch for other transactions that spend those address's UTXOs. With those transactions, she can do the same process of examining the inputs and learning additional addresses in Bob's wallet. Because Alice can see many of the transactions Bob makes, she can see who Bob is paying and who is paying Bob.
Bob can mitigate this part by not reusing addresses. If Bob doesn't reuse addresses, then Alice will learn less information because once she learns about some of Bob's addresses in a transaction, Bob will never use those again so there isn't any additional tracing that can be done.
However, there is still the change outputs that Bob's wallet likely made in his transaction. If Alice is able to identify the change outputs in any of Bob's transactions, she will also be able to do the above.
Now this kind of tracking is not unique to the dust spam attack. Anyone can do this kind of tracing with any amount of Bitcoin. It can be done by someone being malicious after having done a normal Bitcoin transaction.

The 1 satoshi spam attack becomes more interesting when Alice does it en masse. If Alice sends 1 satoshi to millions of addresses, Alice can learn a lot more.
Suppose Alice looks up every address that has ever been used and sends 1 sat to every single one of them. This will include Bob's addresses. She also sends 1 sat to an address ,Bobs_addr, that she knows belongs to Bob.
Bob has never reused an address. But Alice has now forced him to reuse addresses because she has sent 1 sat to all of his addresses. When Bob makes a transaction, his wallet may be unaware of this attack and may choose to include a couple of Alice's 1 sat UTXOs in a transaction, in addition to the 1 sat at Bobs_addr
Now Alice has a transaction that links Bobs_addr with several of Bob's other addresses. Furthermore, because the 1 sat UTXOs belong to addresses that have now been reused, Alice can look up what transactions those addresses were involved in and do the same analysis that I described earlier with the address reuse problem.

There are several mitigations to these privacy revealing attacks. These privacy revealing attacks all rely an assumption that all of the inputs in a transaction belong to the same person. This is known as the common input heuristic. To break this assumption, a sender can join up with other people sending money and they all create a transaction together. This is known as a Coinjoin. A Coinjoin transaction has inputs from multiple people, and outputs which go to multiple people. So this breaks the common input heuristic.
Wallets can also be made aware of such dust spam attacks. If the wallet developers know that this is something that occurs, they can program the wallet such that it will never spend reused addresses unless absolutely necessary. If Bob never reused an address and his wallet avoided address reuse, he could prevent Alice from learning anything more about his wallet with her spam attack because his wallet would choose to ignore Alice's 1 sat UTXOs sent to addresses he already used.
In addition to avoiding reuse, if reuse has occurred, the wallet can also choose to spend all UTXOs to the same address at the same time. This prevents being able to link addresses to additional transactions because all of the reuse is spent at the same time.
To prevent Alice from being able to trace Bob's wallet by trying to figure out his change addresses, Bob's wallet can also choose to not make change outputs. His wallet could be using a coin selection algorithm which searches for an input set which exactly matches the amount that Bob is trying to send. Combined with not reusing addresses, avoiding spending reused addresses, and spending reused addresses all at once, this could effectively prevent Alice from learning anything about Bob because the only lead she has into his wallet is where those coins never lead back to Bob.


Why are compressed private keys typically longer than their uncompressed counterpart?

Because they are not compressed private keys. They are private keys with a marker that indicates that their corresponding public should be compressed. That extra marker takes an extra byte.


I run Bitcoin Core 0.14.1, for Segwit they tell me to "upgrade" to 0.13.1. So confusing

Yes, it means 0.13.1 or later. All versions of Bitcoin Core since enforce the SegWit rules. The upgrade guide was written when only 0.13.1 was available, but since then 0.13.2, 0.14.0, 0.14.1, and 0.14.2 were released. Version 0.15.0 will be released soon.

I've filed an issue to get the page clarified: https://github.com/bitcoin-core/bitcoincore.org/issues/411


Is Bitcoin deflationary and inflationary at the same time?

The keyword is "excessive".

Inflation can be related to the supply of money with the quantity theory of money:

MV = PQ

Where M is the supply of money, V is the velocity of money, P is prices, and Q is production, all taken as the temporal quotient thus geometrically added.

Prices can only go up or down.  Judging by the exchange rate, prices in terms of BTC are deflating as no one would pay 3 BTC for a gallon of gasoline as they would at the beginning of 2012 or so; now, they would pay 0.0003 BTC.

Price are deflating because demand for bitcoin is rising as evidenced by the skyrocketing velocity.

So even though the supply is growing, it is not excessive because velocity is growing so much faster.  Actually, the supply of bitcoin should've grown faster during this period, but it is not programmed to do that.

No cryptocurrency is currently programmed for perfect price stability.


How can "undo" bitcoin transactions be "private"?

The failed transaction won't get stored in a block on the blockchain, so it will be hard for an average person to find them.  I think most of the Bitcoin nodes will delete them from memory eventually.

Also, these sneaky undo transactions are probably not broadcast so publicly in the same way that normal transactions are; they are probably sent to a smaller network of miners who want to participate in this undo system.


Bitcoin privacy - current state of privacy BIPs - is mimblewimble broken?

Community, what is the current state of privacy related BIPs?

CoinJoin related ones:

Adam Gibson's SNICKER draft, which permits a simple unidirectional CoinJoin construction.
BIP 79, Bustapay, a standard for CoinJoined payments.

P2P improvements:

BIP 156, Dandelion: routing newly broadcast transactions a few hops before broadcasting.
Draft for BIP 324: encryption of the P2P layer, making transaction origin harder to find for passive attackers
Draft for Erlay BIP: (less directly privacy focused) introduces a lower-bandwidth, less directed, transaction broadcast mechanism

Consensus rules:

My own draft for BIP-taproot

The first set of these are not consensus or protocol changes to Bitcoin's network. They're merely standards that wallet can choose to implement to improve privacy of their own transactions. There are many more techniques that may or may not be implemented by wallets which aren't written up as formal BIPs, see this great article on the Bitcoin.it wiki by Chris Belcher with an overview: https://en.bitcoin.it/wiki/Privacy

  Anything on the roadmap by core devs to be deployed on main chain within the next year?

Privacy is a complex topic, and while there are some things possible at the protocol level where core developers may be more involved, there is far more to be done at the wallet level. The taproot proposal is an example of a protocol level change: it aims to improve a different type: on-chain policy privacy. This is the problem that the type of scripts your wallet chooses to use on the network reveals what kind of things it is doing (e.g. Multisig, Lightning, 2FA, ...). The goal of Taproot is to make sure that in cooperative cases, all transaction outputs and inputs look indistinguishable. This is completely distinct from the type of privacy leak that CoinJoin-style approaches (which expose linkage between transactions).

As for when it might activate on the network, I doubt anyone can tell you. That is up to the community.

  And regarding mimblewimble: you are aware i assume on the latest researcher claims about broken privacy model of mimble wimble?

I think that's a highly confused statement. Mimblewimble itself does not provide any privacy improvement. It is an improved designed over Confidential Transactions (which is a privacy technique, hiding transaction amounts), making it more scalable and enabling non-interactive CoinJoin.

If you look at the original Mimblewimble paper by Tom Elvis Jedusor, or the more formal paper by Andrew Poelstra, you'll see that privacy is only mentioned in the context of what is provided by CT, or enabled by CoinJoin.

CoinJoin itself is not broken, but how it is used matters a lot. In correct usage, participants interact privately to jointly construct a single transaction, which, when revealed to the public, cannot be disassembled into the individual participants' contributions. What happened in a particular Mimblewimble implementation was they use CoinJoin on the public network. It should be obvious that this does not grant any privacy to anyone observing the network, as they can easily see all individual contributions to transactions. This is not a bad idea either, but it's only a scalability gain. For privacy, CoinJoin needs to happen elsewhere too.

So again: CoinJoin is not broken; it helps when used right. Mimblewimble or its privacy is also not broken - Confidential Transactions and the ability for non-interactive CoinJoin are great. Mimblewimble also enables non-interactive CoinJoin, which happens to be usable as a scalability improvement as well, but when done publicly, does not improve privacy.

  Now, I think the current BIPs have all somehow a mimblewimble-like or CoinJoin-Like approach to solving privacy, right??

You don't "solve" privacy. Privacy is a goal to achieve, but it's multifaceted, and isn't solved by a single piece of technology. Significant parts of privacy are about education and incentives, not a magic bullet technology that suddenly hides everything.

Also, to the best of my knowledge nobody has seriously proposed Mimblewimble in Bitcoin.

  Would above quote from BOgatty also apply to the current privacy BIPs (or to the majority of them)? Without claiming whether it is a flaw or not, just the basic fact: do the currently leading privacy BIPs have this approach of "putting transactions into a single CoinJoin"?

No, because it doesn't apply to CoinJoin. It applies to the use of a scalability improvement inherent to Mimblewimble implementations, which has been misrepresented by some as a privacy gain.

  Would be nice if someone can clarify the state of privacy with Bitcoin, or the future state.

It's hard, but we'll get there.


Is it possible for the transaction to be on hold forever?

There are no rules, miners can pick the transactions they want to include in the block.

Unconfirmed transactions sit in the miners "mempool". And when size of the "mempool" becomes too high, miners may decide to clear out some old transactions.

But there are no hard and fast rules, so you should think twice before sending transactions to the node.


You can technically run appropriately modified Bitcoin on any sort of network of communication, be it LAN, mesh, or otherwise. One could imagine making a mesh network on Zigbee or Bluetooth and allow anyone to connect to those without the Internet, although then the network latency would be way bigger and the Bitcoin network could easily become forked. Preferably there would be at least one proxy server running both on the internet (be it through wires or cellular) and on the distributed network.

If you want to make payments without using the internet, use physical coins, simple as that. It is far safer than making a new internet-less network. The only way you can lose in this way is if the Bitcoin value would plummet.


Possible to run a Lightning node on same computer as Bitcoin Core node?

Yes but some lightning implementations are not running on windows. Lightning needs hardly any hardware but requires to talk to a Bitcoin node (local or remote) anyway.


If 30% of the network are malicious, how many nodes would an SPV need to connect to, to be sure?

Under the assumption that the total node count is large enough that we don't have to care about the reduction of the ratio by only connecting to nodes we haven't connected to, yet:

The chance to connect to five bad nodes in a row is 0.35 = 0.00243 = 0.243%. AFAIK, many SPV nodes only connect to 4 nodes, though. The probability then is 0.81%.


Yes this is expected behavior, it will be handled by applications that register the bitcoin URI, particularly this is prevalent in mobile clients.  Here is a couple links with more information on this topic:

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

http://electrum.org/bitcoin_URIs.html


Missing bitcoin... over 6 confirmations!

Missing bitcoin

Nothing seems to have gone missing.

Therefore I still owe the vendor money

If you sent the money to the correct address, you do not owe the vendor any money.
About 25 minutes later the money was spent in a transaction with about 55 inputs and 15 outputs, maybe the recipient has a custodial wallet whose custodian reorganised some of their holdings or maybe the recipient ran the money through a mixer for privacy.
However, it doesn't matter what they did with their money after they were paid, the blockchain shows they were paid.

leaving the wallet with a balance of zero

You have no way of telling the balance of someone else's wallet. A wallet can hold many addresses. One or more of the output addresses in the second transaction could well be in the vendor's wallet.
If you are referring to your own wallet I don't see how your remaining balance is zero since there seems to be change going to it from the first transaction.


"Bit Coin Investigators" or Consultants for hire - to help locate a Bit Coin account after a person has died?

Do you know where I can obtain a List of "Bit Coin Investigators"

There isn't any established list.

You need to be very careful about trusting strangers on the Internet, there are many crooks looking for people like you. They will ask you for a fee to retrieve the Bitcoins, then ask for additional fees using various technical-sounding reasons until they have bled you dry.

Remember that you are putting an extreme amount of temptation in the hands of any potential helper, it would be so easy for them to take everything away for investigation and later tell you the "bitcoin wallet" was empty - or contained some small amount they thought would satisfy you. Even respectable people working for respectable lawfirms sometimes embezzle their customers money. The temptation is so much greater when the chances of anyone discovering their deceit can be near to zero.

  I have my grandson's computer & iPhone & drive, but don't know how to find his Bitcoin account info.

Unless you know his passwords, it is likely be impossible to ever gain access to any of his Bitcoins.

Unless he was an extraordinarily careless sort of person, he won't have the passwords for his bitcoins stored on his computer or on his iPhone - at least not in a form where you can easily find them.

You could try to find if he had a "paper wallet" - a piece of paper with a string of 36 digits and letters written down or a set of twelve words (sometimes there are eighteen or twenty-four words) which form what is called a "recovery phrase". If you find those, put them aside somewhere very very safe, keep them secret from any helpers, then spend some time learning how to create a bitcoin wallet on your own computer (don't use an online wallet), when you have some experience buying and spending bitcoin, only then, import the key or use the recovery phrase to gain access to your grandson's bitcoins.


With SilkRoad shutting down, and BitCoins being seized, what does this mean for bitcoin?

Bitcoin being seized

The bitcoins on SilkRoad have been seized by gaining access to the private keys of the SilkRoad's wallets. Government agencies have seized bitcoins once before in a similar fashion from a customer of SilkRoad. $3.6m are somewhere around 30k Bitcoin out of the around 11.75m currently existing. For comparison more than 500k BTC have been transmitted in the last 24h according to Blockchain.info. The amount that was seized is economically insignificant and as it probably will be held as evidence for the trial, will not have any influence on the bitcoin market itself.

SilkRoad being shut-down

Bitcoin has plenty of legitimate reasons to be used, so that this one illegal reason should not be all that important.
Bitcoin is useful for/because:

International money transfers (superior speed, reduced cost, however you have the currency risk)
Faster and cheaper for shop owners compared to credit card payments
No exposure of credit-card information when online-shopping
Solves a bunch of problems for services such as porn merchants (no chargeback (buyer's remorse is a big problem for them), pseudonymity, fast, cheap, easy)

Bitcoin has started building a lobby (Bitcoin Foundation, Angle Investors, Investment Trusts, Exchange Traded Funds) and businesses (Exchanges, Webstores, Mining equipment manufacturers, Gambling) have been gathering investments, so that there is funded interest to keep bitcoin going.

I don't think that it was particularly unexpected to see SilkRoad shut down and don't think that it will be a bad thing for the bitcoin project. If anything, it might prove to be an opportunity for the bitcoin project to show that it has evolved beyond just shady use-cases.


Is the change address always at the same position in the vout array of a raw transaction?

No, it picks a random position.

The purpose is to make it hard for people observing the blockchain to know which is change and which is the payment, as that would make tracing easier. This is also the reason why change outputs use new keys to send to.

Note that there has been a bug for a long time that made it always end up in the same position. It was fixed over a year ago, IIRC.


How to change the field of the elliptic curve to the new value N while keeping the default Secp256k1 parameters?

The elliptic curve is secp256k1: y2 = x3 + 7 (mod p)
where the field size is
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F.
The curve order of secp256k1 is:
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
The public key P (point) is calculated by multiplying the private key d (scalar) by the generator point G (point) where
P = d (mod n).G
The n (N) you state is not the field size p, it is the curve order
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
This curve order n is such that nG = point at infinity. This is a property of the curve and cannot be changed.
Thanks to Pieter Wuille for the corrections.


Bitcoin cash with bicore and addressindex

Bitcoin Cash client does not support address index like Bitcoin, so you need a patched client to use this feature. You can use https://github.com/bitprim/bitcoin-abc. I also forked bitcoin-abc with address index feature. This repo is in https://github.com/Sotatek-DucPham/bitcoin-abc. Follow the build guild and get your bitcoind, remember to add usecashaddr=0 in bitcoin.conf before run. Good luck.


On chain cost of Segwit version 1 versus version 0

In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create.

Segwit v1 output scripts as defined by the proposed taproot BIP will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will end up paying a little bit more than for a segwit v0 output. Of course, the recipient can use P2SH wrapped segwit outputs so that cost would actually be pushed to them.

However segwit v1 is cheaper for the recipient when he wants to spend that output. Because segwit v1 is a Pay-to-Pubkey model, the public key does not need to be specified in the input. This saves 34 bytes of witness data (34 weight units, 8.5 vbytes).

Additionally, segwit v0 uses ECDSA signatures which are encoded using the DER encoding. This results in signatures that are typically 71 or 72 bytes (each size has ~50% probability of occurring for any signature unless the software specifically only creates 71 byte signatures like Bitcoin Core does). But segwit v1 uses Schnorr signatures and the encoding specified for that in the BIPs which will typically be 64 bytes in length (can be 65 if something other than SIGHASH_ALL is used but that is rare). For simplicity, we can say that this is a reduction of 8 bytes which is 8 weight units and 2 vbytes.

So for the typical single key case, segwit v1 saves 42 bytes which is 42 weight units or 10.5 vbytes.

Where it gets intereseting is the case of multisigs, the most common type of script used. For multisigs, the MuSig multisignature scheme. MuSig allows a n-of-n multisig or a m-of-n non-accountable multisig (i.e. no one will be able to know who signed) appear to observers as a single key signature. This means that there is only one public key specified in the output and one signature verified in the input. So for all n-of-n multisigs and non-accountable m-of-n multisigs, the cost is exactly the same as for the single key case, but the savings vary depending on the number of signers. The savings for the first signer are the same as the single key case. For every additional signer (i.e. when n > 1), using segwit v1 saves ~107 bytes, which is 107 weight units or 26.75 vbytes.

It gets more complicated for m-of-n signatures where you want accountability.  Such threshold signatures can be achieved by using MuSig and a merkle tree that represents every combination of signing keys. However the size using sewit v1 will ultimately be smaller than segwit v0 because ultimately, the leaves of the merkle tree will always be single pubkeys and the hashes in between will be slightly smaller than public keys in a traditional script. Lastly, the most common of the thresholds can be used as root case in taproot which allows for more savings as then branches of the script don't need to be revealed.


Note that an individual address is not a wallet. A wallet is a collection of addresses.

  Does any wallet address has it's own passphrase in bitcoin daemon? Or it's only 1 passphrase for all wallets in 1 daemon?

A wallet has its own passphrase; passphrases are not per-address (that would be impractical).

You can have multiple wallets in a daemon each with different passphrases (the most recent versions of Bitcoin Core support multiwallet).

  And how can i get the passphrase of the address

Passphrases are not automatically generated. You as the user must have set it. If you do not know the passphrase, then there is nothing that you can do.


Where can I sell domain names and earn in bitcoins?

There are no sites that automatically buy domains at all that I know of. Most of the domain marketplaces don't accept Bitcoin, but the ones that do don't have much traffic.

I use bitcointalk. Just go into their Digital goods section, make a topic called [WTS] INSERT DOMAIN, and in the message, put in the domain registrar, how much you want for it, when it will expire, etc.

If you want, you can host an auction.

Id recommend 100% to use escrow. Here's a list of the best escrows on the forum. https://bitcointalk.org/index.php?topic=855778.0


Where in the world is bitcoin mining the most profitiable?

According to the EIA:
http://www.eia.gov/emeu/international/elecprih.html

The cheapest electricity prices from their available data would be Kazakhstan at .052USD/kWh.

Although electricity cost itself would not be the only determining factor of profitability, it would be a major part.

Currently FPGA's seem to be the answer for best performance/kWh.  Some other factors to think about would be(not 100% inclusive of all the factors):

Difficulty in sourcing equipment to the country of choice.
Governmental taxes
Employee Cost
Weather Conditions(HVAC)
Government stability (Politics in General)
Ability of the power distribution network to handle your load.


How do I Derive Bech32 Address from P2WPKH Output Script?

Okay so I think I've figured it out for anyone else wondering what exactly you have to do to derive an address from this type.

In the case of the already mentioned transaction, (coinbase of block 542748) we first start by looking at the full decoded output script.

0 PUSHDATA(20) 97cfc76442fe717f2a3f0cc9c175f7561b661997

The very first OP_0 in the decoded script is the witness version
We then take the data pushed (in our case 97cfc76442fe717f2a3f0cc9c175f7561b661997) and convert it into binary
Then we divide the binary into 5 bit sections. In our case: 10010 11111 00111 11100 01110 11001 00010 00010 11111 11001 11000 10111 11110 01010 10001 11111 00001 10011 00100 11100 00010 11101 01111 10111 01010 11000 01101 10110 01100 00110 01100 10111
Then we prefix the witness version in 5 bits 00000
Our binary then becomes 00000 10010 11111 00111 11100 01110 11001 00010 00010 11111 11001 11000 10111 11110 01010 10001 11111 00001 10011 00100 11100 00010 11101 01111 10111 01010 11000 01101 10110 01100 00110 01100 10111
The first part of the address is considered the human readable portion.
This is always bc on the mainnet and tb on the testnet
1 is always the seperator between the human readable portion and the rest or data
Now our address starts with bc1 (mainnet is bc + seperator 1)
Now we map each 5 bits into the table here - or this alternative chart I've created
bc1 qjl8uwezzlech723lpnyuza0h2cdkvxvh
The remaining 6 characters is a checksum
Using the provided python code here we can compute the checksum using the bech32_create_checksum function
The first argument is the human readable portion as a STRING without the seperator (1)
The second argument is an array of integers converted from our binary data portion

Our example:

bech32_create_checksum("bc", [0, 18, 31, 7, 28, 14, 25, 2, 2, 31, 25, 24, 23, 30, 10, 17, 31, 1, 19, 4, 28, 2, 29, 15, 23, 10, 24, 13, 22, 12, 6, 12, 23] )

This gives us:

[20, 21, 12, 17, 13, 19]

Which can be mapped with our table to 54v3dn

Finally, we concatenate the human readable, seperator, decoded data, and the checksum for our final address: bc1qjl8uwezzlech723lpnyuza0h2cdkvxvh54v3dn


How is the whitepaper decoded from the blockchain (Tx with ~1000x m of n multisig outputs)

This is a fun little puzzle on the blockchain, basically. First, you need to know a little about pdf's and how they're structured, which you can find here.
Second, you'll note from section 3.4.1 that all pdf's start with this string:
%PDF-

In hex, that is 255044462d. And indeed that is in the very first output in the very first bare multisig pubkey:
<e4cf0200><067daf13>**255044462d**312e340a25c3a4c3bcc3b6c39f0a322030206f626a0a3c3c2f4c656e6774682033203020522f46696c7465722f466c6174654465

I haven't figured out what the first 8 bytes are for (♦edit: e4cf0200067daf13 = 2x 4byte little Endian "checksums", see @WizardOfOzzie comment below), but the rest of the bare multisig keys (everything in between 1 and 3 OP_CHECKMULTISIG in each output -- note the last one is a 1 of 1, so it's 1 OP_CHECKMULTISIG) are pieces of data for the pdf and they are in order. If you can put all the hex digits of the bare multisig keys into a single file (no whitespaces) called "fromblockchain.hex", you can run this very simple program to extract the pdf:
contents = open('fromblockchain.hex').read()
bytes = contents[16:].decode('hex')
f = open("bitcoin.pdf")
f.write(bytes)
f.close()

This should create a bitcoin.pdf which is the actual satoshi whitepaper. I've tested this and indeed it is the whitepaper. Good to know it's literally in the blockchain.
Alternatively, if you have bitcoind running on your machine, you can run this python script to grab the bitcoin whitepaper:
import subprocess

# raw = full hex of raw Tx using Bitcoin-cli
raw = subprocess.check_output(["bitcoin-cli", "getrawtransaction", "54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713"])

outputs = raw.split("0100000000000000")

pdf = ""
for output in outputs[1:-2]:
    # there are 3 65-byte parts in this that we need
    cur = 6
    pdf += output[cur:cur+130].decode('hex')
    cur += 132
    pdf += output[cur:cur+130].decode('hex')
    cur += 132
    pdf += output[cur:cur+130].decode('hex')

pdf += outputs[-2][6:-4].decode("hex")
f = open("bitcoin.pdf", "wb")
f.write(pdf[8:-8])
f.close()

Finally checking checksum
sha256sum bitcoin.pdf
b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553  bitcoin.pdf


What exchanges trade with Unicoin right now?

May be http://newchg.com/unicoin/ can be usefull but I have never used this exchange.


A complex subject with an array of different possibilities results in answers of the same nature. If we provide simple answers, it won't be very helpful. For example:

Q: How do I purchase bitcoins?
A: Depends.

Q: How much do they cost?
A: Depends.

Q: Is there an exchange rate?
A: Yes.

Q: How do I redeem them; turn them back into dollars?
A: Depends.

Complex yet more helpful answers:

Q: How do I purchase bitcoins?
A: Depends on where you live, but I think it's safe to assume you are in the United States based on the details your questions. Coinbase and Circle are US friendly sites that will sell you bitcoins after your sign up and provide them with your personal and financials information. Or you can use a service like localbitcoins to find someone nearby that will meet you at a public place that will sell you bitcoins for your cold-hard cash. Or you can try to find a bitcoin ATM, that will turn your cash into bitcoins. The last two options will require you to have a bitcoin wallet, whereas coinbase and circle can also act as your wallet.

Q: How much do they cost?
A: Depends where you buy them from. Some places are more expensive than others.

Q: Is there an exchange rate?
A: Yes, there are many different exchanges resulting in many different exchange rates. See here http://bitcoincharts.com/markets/currency/USD.html

Q: How do I redeem them; turn them back into dollars?
A: Depends. If you use coinbase or circle they have an option for you to 'sell' your bitcoins back to them and they will ACH deposit the funds back to your bank account in dollars. Or you can find a person on localbitcoins and sell to an individual.


Are nodes that don't accept inbound connections necessarily leechers?

An outbound connection is functionally equivalent to an inbound connection except in the respect that you initiated it.  An outbound only node provides the same resources to the network except that it doesn't provide incoming connection slots.  Outbound-only nodes forward blocks and transactions just like any other node. I think it is generally misleading to describe them as leeches.

You could consider one to be a connection slot leech but not a leech in any other respect.  There have been times in the past when the Bitcoin network has been short of inbound connection slot capacity, and a troubling percentage of listening nodes are concentrated in a few datacenters (and many appear to be run by parties with ill intent for Bitcoin users)... so it is certainly good for you to accept connections if you at all can.

Nodes without open inbound also provide important DOS and privacy protection to the network: It is much more difficult for an attacker to get connected to nodes that don't accept random connections, since the attacker must wait for the victim to come to them. So the presence of outbound-only peers has the advantage of strengthening the network against some kinds of attack. (That said, the network has more than enough out-only peers to achieve those benefits already...)


What's the easiest way to someone to double-spend 0-confirmation transactions?

Peter Todd wrote [Replace-By-Fee Tools](https://github.com/petertodd/replace-by-fee-tools
)

  Basic usage:

  ./double-spend.py <address> <amount>

  Creates two transactions in succession. The first pays the specified
  amount to the specified address. The second double-spends that
  transaction with a transaction with higher fees, paying only the
  change address. In addition you can optionally specify that the first
  transaction additional OP-RETURN, multisig, and "blacklisted" address
  outputs. Some miners won't accept transactions with these output
  types; those miners will accept the second double-spend transaction,
  helping you achieve a succesful double-spend.


This is really asking about basic trading economics: if I have some new product X, what price does it have? I can set a price and see if anyone buys it. If not, I might lower the price or auction it to see what someone might pay for it. That is the starting value, but it doesn't really mean much as it hasn't been field-tested (so to speak). If others think it is worth more, they will buy more; if others think it is worth less, they will not buy at the current price, so those trying to sell will lower their prices until they can agree on a price.

What you describe is a simple pump and dump operation, which could be done on any sort of traded commodity like stocks or cryptocurrencies (especially altcoins). If you can feign interest in something (in this case, an altcoin) so that the trade price goes up, then you might be able to turn a profit. Note, however, that this is a sort of fraud and can open you up to, at minimum, civil lawsuits.

Doing a "pump and dump" will be easier on small markets, like altcoins, than on larger markets, like Bitcoin and Litecoin, because you have to buy up enough of the coin to start an upward trend that people will notice and buy into. If the market is large, you'd need huge resources in order to make an impact in the market.


Could ASICs be used to mine a "BitcoinX4" blockchain?

Any mining device can be used without alteration for mining a specific alt-chain, as long as the chain's proof of work is the same (double-SHA), and the size, encoding and position of the timestamp and nonce fields is the same in a block. The latter ensures that devices that increment those fields internally would not be altering other parts of the block header. As block speed is not a part of the header but an external constraint put on the specific cryptocoin, ASICs and other devices should be able to mine such blocks without a problem.


How to free up the space taken by bitcoind?

The quide you followed is 3 years old. Since then, there was an option added called prune - add it to a line in your bitcoind.conf, like so:

  prune=50000

And restart bitcoind. This would effectively limit your blockchain size to only 50Gb of recent blocks.

In case you need to have a full blockchain available for research & analysis, there is no other way but to buy a bigger HD.

In case you don't need the local blockchain at all, then there is very little reason not to use a lightweight client like Electrum which does not store anything on your HD but instead relies on proprietary servers.


Is it possible for corporate interests to incentivize securing alternate Blockchains instead of Bitcoin's Blockchain?

I am struggling to understand the motivation for this question, but I'll take a guess. From the Reddit post you linked, it seems like you're wondering if alternative ways of securing the blockchain will be adopted by companies who have an interest in keeping costs low? I'm not sure exactly what costs you mean here, maybe costs associated with securing the blockchain?

Short answer:

Who really knows? It's possible, but any answer is really just a best guess.

Long(er) Answer

One thing to be noted is that it's not actually companies who build tech around bitcoin that have an incentive to keep blockchain securing costs low. Companies building technology around Bitcoin (and other coins) work almost exactly the same depending on whether the system is secured with PoW/PoS/other, assuming the system meets some base security level. Rather, it's the miners who have an interest in keeping costs low, and fees high. I don't think that mining companies are being invested in as much as companies that are building tech around the bitcoin blockchain.

    Is it plausible/possible for corporate interests to divert miners/investors from Bitcoin's blockchain to another blockchain with better rates of return (perhaps just initially) on investment?

What kind of rates of return are you looking for here? If you mean rates of return while mining, then see above paragraph. If you mean rates of return for just using the cryptocurrency, then you probably won't be seeing one that is better than bitcoin any time soon, partially because of bitcoins' spreading adoptance and partially because it is a deflationary currency.

If by rate of return, you essentially mean least costly to transact, then you are talking about the fee structure in bitcoin. One of the problems with bitcoin's current fee system (in the long term) is that the people making the transactions are the only ones paying fees. Or rather, those who are just storing bitcoins are still benefitting from the security while not paying for that security. Inflationary currencies differ in that those who store it pay for the security, in a sense, by the money they have losing value over time.

Coding in a slight inflationary factor might make a currency more appealing to transact with. PoS coins have inflationary factors (as do some PoW coins, this one for example), and from this perspective, I could see companies preferring to store value in Bitcoin but transact in a different currency which has some inflation. So, I could possibly see some companies wanting to invest in other currencies that are cheaper to transact in.


Is there an easy way to estimate the number of mining nodes?

While it's possible to estimate the current hashrate from the difficulty, they are two different measures. You can find an estimate for the global hashrate on the same site where you found the difficulty. The current estimate is 162 EH/s (162,000,000 TH/s).
Using a similar approach as proposed by you, we can estimate an upper bound of  162,000,000 TH/s / 110 TH/s = 1.47M mining nodes by comparing the global hashrate to that of the fastest mining equipment.


signing multiple input raw transaction - algorithm and sighash types

Do I understand correctly that both inputs are to be signed
separately?

yes

So first, we sign the first one, then the second one. To sign an input
we replace scriptSig for this input with the scriptPubKey, that locks
this input. ScriptSig for the other one remains blank. It this
correct?

yes

But in both threads in step 13 something is appended at the end of
transaction. It is called hash code type. What is this? Is this has
anything to do with sighash type byte the one that is appended to the
signature?

yes

What is the correct sighash type for the scenario I described above
(signing inputs separately)? Is this: 0x81 (SIGHASH_ALL |
SIGHASH_ANYONECANPAY)? Or should this be 0x01 (SIGHASH_ALL)?

Use 0x01 (SIGHASH_ALL)


Why was the transaction fee more for a 20 mBTC transaction than for a 25 mBTC transaction?

Transaction fees in Bitcoin are not dependent on the amount of value transferred, but on the amount of blockspace purchased.

When you try to send a transaction, your wallet will select a subset of the available unspent transaction outputs in your wallet to fund the transaction. In this particular case, it could have selected a larger number of inputs to fund the 20 mBTC transaction, and a smaller number of inputs to fund the 25 mBTC transaction. It could also be that the transaction fees just changed significantly between the two transactions which happens almost regularly over the course of the day or week.


Hypothetical Scenario - Address collision with address with already confirmed outgoing transaction

Provided the second transaction is spending inputs that have not been spent, yes.

There is no logic or rule that checks to ensure public key uniqueness for an address. As long as you can fulfill the signature and Hash160 checks, the transaction is valid.


Transaction confirmed, bitcoin not received

Your transaction is confirmed. As Rutger said 1 confirmation is enough, more just means more confidence. You should double-check the addresses you used, it's possible the coins were sent to the wrong place.


How does nSequence/Check Sequence Verify work?

In order to use a relative time lock, you need to provide the requirements in the scriptPubKey to which the Bitcoin is sent.

Example

scriptPubKey for escrow with 30 day timeout:

IF
    2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
ELSE
    "30d" CHECKSEQUENCEVERIFY DROP
    <Alice's pubkey> CHECKSIG
ENDIF

Then, in order to spend it before 30 days, the scriptSig that satisfies the first conditional statement (multisig script) must be provided, i.e.:

scriptSig: 0 <signature1> <signature2>

Or after 30 days, alice can provide:

scriptSig: <signature>

See BIP112

Sequence

Note that in order to set a relative locktime: the tx must have the following properties:

version must be 2 or greater
nSequence must not have 32nd bit set
nSequence must have the 23rd bit set (0x400000) if it is a lock-time type, unset for block height type
for relative lock-time type the granularity of each bit is 512 seconds
for relative block height type each bit represents 1 block

For 30 days, I believe it would be as follows:

30 * 24 * 60 * 60 = 2592000 seconds
2592000 / 512 = 5062.5 ~= 5063 or 0x13C7
sequence = 0x13C7 | 0x400000 = 0x4013C7 or 4199367
nSequence = 0xC7134000 (little endian)

The sequence is the very last 4 bytes of the transaction, see https://en.bitcoin.it/wiki/Transaction


Can I open many channels to one connection?

he commands above transfer money the BITCOIN NETWORK to the LIGHTNNG NETWORK - right???

No. It sends money to addresses the c-lightning can use for creating Lightning Network transactions. There is no "transfer money from Bitcoin to Lightning", they are not separate and distinct things.

  If so, which BITCOIN "FROM" address is being used?

There is no such thing as a Bitcoin from address. That is not how Bitcoin works. It may seem like there are from addresses, but that's just a simplification for users.

  Is what I would like to do possible?

No, it is currently not possible to choose what transactions to use to fund your channels with c-lightning.


Why is the 'Estimated BTC Transacted' referring to just one of the multiple outputs?

It's a best effort guess made by blockchain.com, has little relevance, is not particularly accurate, and should not be used for any meaningful analysis. It has no impact on the transaction, and is not part of the Bitcoin protocol.

It is somewhat accurate for very simple transactions, but breaks down for larger ones, and ones that utilize more recent anti-tracking approaches such as randomized outputs, sending change to an address of the same type as the other address being payed, etc.


CPU vs GPU Mining (FTC) - CPU wins? How?

The problem with your math is, that nvidia is far away from being optimal for GPU mining. If you would compare your CPU with an "older" ATI graphic card like my HD 6870  (about 150$) with max TDP 200W you would surely come to the opposite conclusion. I am mining with that card at ~280 to 300 kh/sec on average. Well I did not measure the extra power usage while it is on 100%, but it cannot be more than 150 Watt, since max usage is 200W. Besides: it runs really steady on 100% GPU load (measured with gpu-z) and drops only sometimes to 99% for a second. Not to mention that nowadays cards can get the double amount of kh/s.

I hope I could help you a bit. If you plan to invest into a new/second graphic card then you should go for ATI.


Can I have usd in my MtGox account without transferring it to my bank account, or having it in bitcoins?

Yep.


Can't send the funds - encryption password forgotten. Copay

Simply delete the app, choose "import wallet", and you're fine. This procedure applies to all wallets with seeds. There are no limits, remember that Bitcoin's motto is "Be your own bank"

Or, just look for the "import wallet" button.


Will "Taproot" replace Lightning Network?

With respect to the original wording of the question I believe Taproot will actually make the Lightning Network pointfull instead of pointless.
While Taproot allows us to save some space on the bitcoin base layer, it will not make the Lightning Network obsolete. Remember, the main issue with respect to on-chain scaling is that a protocol in which every transaction is broadcasted to every participant is just too inefficient if those transactions should represent a substantial fraction of monetary payments in the world.
With respect to the Lightning Network there are actually many improvements possible for the Lightning Network if Taproot is activated. Most notably, we can have Point Time Lock Contracts (PTLCs) instead of HTLCs which give us way more flexibility in the payment process as the addition of points and secrets is linear whereas the addition of payment hashes and secrets is not linear. E.g.:
H(r1+r2) != H(r1) + H(r2)

The property of linearity allows us to have applications like

stuckless payments
payment decorrelation
escrow services


How to check ownership of wallet with segwit address

Before segwit one could sign a message and with address given, you could decrypt the message to confirm they actually own the wallet containing that address.

As you discovered, the signmessage and verifymessage RPCs in Bitcoin Core don't currently work with segwit.  There have been discussions about the best way to fix that, but as of this writing, updated code is not yet available.

  Furthermore, i can't take the getrawtransaction  1 command to

The getrawtransaction RPC now takes true instead of 1 for detailed JSON output.  The txid, vout, and vin fields in the JSON output all the same for the way you're using them (they just have a few extra fields now for segwit outputs and inputs).

  How can i verify that someone owns a wallet with segwit addresses?

There is no easy way at the moment using Bitcoin Core or any other software I'm aware of.  If possible, you may want to change your workflow so that you don't need to verify wallet ownership.  For example, if you currently receive all payments to the same address, you can start using separate addresses for each customer, so Alice pays $ADDRESS_1, Bob pays $ADDRESS_2, and you can tell the difference between their payments by which address they paid.

Alternatively, if you need to verify address ownership for refunds, you can have users provide a refund address at checkout.


What are the risks of keeping USD in an exchange account?

Each exchange can be different.  Essentially with every bit of funds held at an exchange, either fiat or bitcoins, the account holder becomes an unsecured creditor of the exchange.

Regulated exchanges of other securities, commodities and currencies and brokers of those exchanges have clear instruction to keep customer funds segregated from the operating funds so that those funds are not at risk if the exchange itself runs into financial issues.

Whether any of these regulations affect a Bitcoin exchange or brokerage may vary based on jurisdiction.  It is possible these exchanges are operating without any regulatory oversight and thus no guarantee that they are holding all customers funds without lending those funds out or using those to fund operations.

An exchange that accepts deposits from an account-to-account (A2A) transfer could help lessen the risk.  For instance, Camp BX and Mt. Gox accept deposits from Dwolla.  So holding dollars at Dwolla until they will be used for trading is one approach to lessening the risk of keeping the funds at the exchange the whole time.   BitFloor accepts CapitalOne 360/ING transfers, as another A2A example.  And multiple exchanges accept transfers from OKPay.

Additionally there are site security concerns.  If the service gets hacked, or an individual account gets hacked, those funds could be used to buy bitcoins and withdrawn -- with the losses assessed to the account holder.  Use of two-factor authentication is essential a core requirement.


How do I accept Bitcoin Cash without using a third-party?

Your Bitcoin cash server may be a target for many since it has all the private keys.

I would suggest you get one private master key and public key.

use your public key to generate addresses and your private key to spend Bitcoins.

You can createrawtransaction and all the other commands using PHP or javascript without the need to have a running server.

these libraries are helpful: bitcoinlib-js for javascript and bitcoin-php for PHP

You may need a server just for broadcast a transaction if you want to send bitcoins. you could use your own server or use public servers like electrum servers or blockchain.info


Which full node implementation(s) supports SegWit2x?

If I can choose between Bitcoin Core, Bitcoin ABC, Bitcoin XT, and Bitcoin Classic

None of these software support Segwit2x. Currently your only choice of Full node software for Segwit2x is btc1.


Can the coin symbol prefix in a cloned NXT blockchain start with a digit?

No, adding a coin symbol prefix is not doable as it will impact other functions that might take it as a parameter. Your better off just doing it on the front end using a css :before class using the content: property.


How DNS Seeds node maintain the list of addresses?

Each normal node should connect to the seeder, this connection is detected by seeder service, that will test the node and add it to the list if some basic verification pass.

Exist other additional features, like for example fetch node list from main know seeder DNS into new seeders services.


Have the early mined coins been moved/transacted?

The earlist blocks have not been spent (except for block 9). You can be alerted by email when new transactions occur here http://bitcoinwhoswho.com/address/12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S/


System requirements for running a Bitcoin Core node on testnet

According to https://tbtc.bitaps.com/ today it's ~20GB. The RAM usage is similar to that of running a Bitcoin node on the main net.


How to generate Segwit address using bitcoind?

Make sure you are using Bitcoin-core v0.16 bitcoin-cli getnetworkinfo then in your bitcoin.conf add

addresstype=bech32

As @Meshcolider comment if you want to get p2sh address you should set:

addresstype=p2sh-segwit

But I would use bech32 since bech32 produces smaller transactions than P2SH segwit transactions.

For Bitcoin-core version 0.15 send

bitcoin-cli addwitnessaddress 1BRo7qrYHMPrzdBDzfjmzteBdYAyTMXW75

to get p2sh address.


Does Bitcoin Unlimited keep ASICBOOST intact vs going with segwit?

How does ASICBoost work

ASICBoost relies on finding multiple block headers that match in the last sixteen bytes. As SHA-256 takes 64 byte chunks of input, this allows to reuse parts of the calculation for the second chunk.

The last sixteen bytes of the block header are composed of the

last four bytes of the Merkle root of the transactions
the time-stamp
the difficulty statement
the nonce.

Thus, the last twelve bytes are arbitrary and the only difficult part is to get four bytes of the Merkle root to match up. This could be done by actually using the same Merkle root, but then (since the hash of the previous block is fixed) the only remaining field in the header to introduce variation is the the version field! Mining blocks with varying version fields is pretty obvious and corresponds to the overt application of ASICBoost.

For a comprehensive explanation of ASICBoost see: Jeremy Rubin's Notes on ASICBoost [PDF]

Covert ASICBoost

On the other hand, the covert application relies on finding multiple Merkle roots that collide in the last four bytes. As we know, the Merkle root derives from forming a Merkle tree on all transactions. A straight forward way of doing this would be to grind the coinbase transaction extra-nonce space. However, each time when you change the coinbase transaction, you have to recalculate the complete left branch of the Merkle tree, which requires an additional 11 to 12 extra hashes for blocks with up to 2048 or 4096 transactions respectively. Obviously, finding a partial collision of the Merkle root would be twelve times faster performed on an empty block.

A more efficient way of finding partial collisions of the Merkle root would be to have a fixed left-side tree, i.e. an unchanging coinbase transaction, and to combine this with various right-sides of the tree. This would then only require a single hash to produce a new Merkle root, and you could immediately check whether you've found the desired collision.

In practice, you could efficiently generate right-side trees by combining several compatible candidate trees a few branches down from the Merkle root in different ways. This is why out-of-order transaction-fees and the absence of dependent transaction pairs could be indicators for the use of covert ASICBoost-usage. This process is highly parallelizable.

How does SegWit influence ASICBoost

This more efficient approach is broken by SegWit and many other BIPs, because it requires in the coinbase transaction a Merkle root commitment which is calculated order-sensitively from all other transactions in the block. This means that whenever any transaction in the block is updated the entire left-branch of the Merkle tree needs to be recalculated due to the updated coinbase transaction.

…and Bitcoin Unlimited?

To come back to your question: AFAIK, Bitcoin Unlimited does not require a commitment in the coinbase, and thus would be compatible with the covert application of ASICBoost.

Many thanks go to David Harding who explained the finer details of the above in chat, from which I've adapted some of the above paragraphs.


How do I consolidate all my BTC into a single address?

Once you have the address you'd like the coins to be in, just make one transaction for the total amount of your balance going to that address.  The inputs from all transactions leading into the sending wallet will be combined into a single output automatically.  Or are you asking how to create the brain wallet in the first place?


How are 'excessive' numbers of inputs and outputs handled in bitcoin transactions?

The number of inputs/outputs is encoded as a "var_int" or "variable length integer".

Start by looking at the first byte. If it's 252 or less, then that's it, that's your number (like you've been using), there are no more bytes to read.

If the first byte is 253, there are 2 more bytes following it, which are a 16 bit little endian integer. 254 means 4 bytes following it (5 in total), which is a 32 bit integer. 255 means 8 bytes follow, i.e. a 64 bit integer.

You can read more here: https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer


Bitcore full node list with Wallet service enabled?

Nodes don't provide wallet services (like Bitpays Bitcore [don't mix that up with Bitcoin Core]). The only service they provide is SPV transaction filtering (which is much "slower").

Running your own wallet service (like BitPays Bitcore) can be useful if you have your own setup, etc. (It's more a server/client thing).

Bitcore is basically a Bitcoin Core full node with some extra database layers (address index, etc.).
The full node behind Bitcore will connect to some dozens other full nodes (p2p).

You don't want to manually maintain a list of full nodes. There is a built in p2p address manager.


As @Raghav Sood mentioned, you can stop bitcoin for a different datadir (the location of .bitcoin folder) using:

$ bitcoin-cli -datadir=<dir> stop


1)2)
Electrum uses so called "Deterministic wallets". In short this basically means that your entire wallet can be recovered using the seed.

Even if you delete the wallet file/ have no private keys, the seed will give you full access.

3) Either every private key of each adress that you used, or the seed.


Purpose of the LN transaction description

I believe it is to explain the "purpose of the payment" as described in BOLT11:

  Short description of purpose of payment (UTF-8), e.g. '1 cup of
  coffee' or 'ナンセンス 1杯'

This would be the payee letting the payer know what they are paying for, e.g. in case there are multiple outstanding invoices, just like any normal invoice outside of LN. Like you said, it's perfectly reasonable for the payer to suggest a description, and would probably be preferred in some cases, so the payer knows the payee has agreed to the purpose of the payment and is expecting it.


RPC command sendfrom is giving Transaction too large error

Transaction too large

This is referring to the transaction size in bytes, not Bitcoin.

You need to send the Bitcoin in smaller chunks to yourself, or sweep the dust, as they say. This is because a transaction is made up of unspent outputs (UTXO) and since you are sending a large amount, you will likely have many small UTXO from all of the tips you're trying to spend. This increases the size of the transaction in bytes.

Bitcoin core will return that error if the transaction weight is greater than MAX_STANDARD_TX_WEIGHT, which as of v0.16.3 is 400,000, which also happens to be the maximum size of 1 block.

What is tx weight?

  Transaction weight is defined as Base transaction size * 3 + Total
  transaction size (ie. the same method as calculating Block weight from
  Base size and Total size).

  Virtual transaction size is defined as Transaction weight / 4 (rounded
  up to the next integer).

  Base transaction size is the size of the transaction serialised with
  the witness data stripped.

  Total transaction size is the transaction size in bytes serialized as
  described in BIP144, including base data and witness data.  See BIP
  141


An updated forkcoins tree chart (only blockchains)

As far as I'm aware, the newest graph mapping forkcoins which spun off from Bitcoin is Bitcoin Magazine's Map of Bitcoin forks infographic. It was published in April 2019, so it will not include newer forks like the upcoming BCH split. It does include the major project forks, but doesn't list all forks (there have been over 40 mostly irrelevant forkcoins).
I looked up a prior project called Map of Coins which was aiming to collect the full pedigree of altcoins that forked from Bitcoin's codebase (and other original projects) but it appears to not have gotten updated since 2017.


Eclair Lightning Node With Core Version 18

No, there is no workaround. According to this github issue, Eclair v0.2-beta9 is completely incompatible with Bitcoin Core 0.18. The next release of Eclair will fix this.


The bitcoin wallet is for receiving and sending bitcoins. When it is synced you are all set. You don't need anything else to receive and send coins.

Note that you can receive coins even if the wallet is not synced, you just won't see them before you are synced.


Can you have a password based cryptocurrency?

In particular, is there a way to make it so that it is impossible to know if a transaction signed with a password is correct unless its part of a mined block? This way, even if your password only requires 1,000,000 tries to crack, the attacker needs to mine 1,000,000 blocks to bruteforce the password?

I'm not aware of any cryptographic constructions that would let you do that. The closest thing I can think of is increasing the number of iterations of the password derivation function so that the amount of work required is similar to the amount of work required for creating a block.

  Although it is tempting to say that blocks with invalid passwords are invalid (so our malicious miner doesn't even get to keep what he mined), this would put honest miners at risk of receiving invalid transactions and losing their mined coins. Therefore, invalid transactions would just have to be ignored.

That doesn't completely fix things, though. If someone on the network is trying to bruteforce a password by submitting lots of transactions, the miner is going to see a thousand invalid transactions for each valid one. This means that the honest miners almost never earn fees for their block, and that legitimate transactions almost never go through.

You've got the right idea in trying to prevent an offline attack against a password, though. You should look at Peer Assisted Key Derivation.


How to get confirmation of transaction using Bitcoin j implementaion

Use Wallet.getTransactions(boolean). This returns a Set<Transaction>:

boolean includeDeadTransactions = true;
Set<Transaction> transactions = wallet.getTransactions(includeDeadTransactions);

for (Transaction t : transactions) {
    //Do something
}

You will get all transactions you can looping over so you get each transaction details.


Difficulty based derivatives and insurance

Unlike a commodity which can limit speculation with a delivery requirement, speculation on the difficulty really is more suited for something like a predictions market like https://www.fairlay.com/event/category/bitcoin/difficulty/.

MPOe at one time had an options contract on future hashing but that is no longer offered.


What libraries should I use for E-Commerce

I developed a solution using bitcoind (bitcoin-qt).

It was very easy with PHP + RPC Class, but bitcoind has some limitations which make it not very suited as a backend/library.


bitcoinTestnet Network returning a mainnet address

The following code fixes the issue. The problem was that the class I was using didn't set the network on the bitwasp bitcoin object. The code came from freedom node.

hd.php

<?php

require_once(__DIR__.'/../autoload.php');

use BitWasp\Bitcoin\Bitcoin;
use BitWasp\Bitcoin\Address\AddressCreator;
use BitWasp\Bitcoin\Key\Deterministic\HdPrefix\GlobalPrefixConfig;
use BitWasp\Bitcoin\Key\Deterministic\HdPrefix\NetworkConfig;
use BitWasp\Bitcoin\Network\Slip132\BitcoinRegistry;
use BitWasp\Bitcoin\Network\Slip132\BitcoinTestnetRegistry;
use BitWasp\Bitcoin\Key\Deterministic\Slip132\Slip132;
use BitWasp\Bitcoin\Key\KeyToScript\KeyToScriptHelper;
use BitWasp\Bitcoin\Key\Deterministic\HierarchicalKeyFactory;
use BitWasp\Bitcoin\Key\Deterministic\HierarchicalKeySequence;
use BitWasp\Bitcoin\Key\Deterministic\MultisigHD;
use BitWasp\Bitcoin\Network\NetworkFactory;
use BitWasp\Bitcoin\Serializer\Key\HierarchicalKey\Base58ExtendedKeySerializer;
use BitWasp\Bitcoin\Serializer\Key\HierarchicalKey\ExtendedKeySerializer;

class HD {
  private $network_name = NULL;
  private $network = NULL;
  private $xpub = NULL;
  private $ypub = NULL;
  private $zpub = NULL;
  private $multisig_xpubs = NULL;

  public function __construct($network = 'bitcoin') {
    $this->network_name = $network;
    if (version_compare(PHP_VERSION, '5.3') >= 0) {
      $this->network = NetworkFactory::$network();
    } elseif (version_compare(PHP_VERSION, '5.2.3') >= 0) {
      $this->network = call_user_func("NetworkFactory::$network");
    } else {
      $this->network = call_user_func('NetworkFactory', $network);
    }
    Bitcoin::setNetwork($this->network);
  }

  public function set_xpub($xpub) {
    $this->xpub = $xpub;
  }

  public function set_ypub($ypub) {
    $this->ypub = $ypub;
  }

  public function set_zpub($zpub) {
    $this->zpub = $zpub;
  }

  public function set_multisig_xpubs($xpubs) {
    $this->multisig_xpubs = $xpubs;
  }

  public function address_from_master_pub($path = '0/0') {
    if ($this->xpub === NULL && $this->ypub === NULL && $this->zpub === NULL) {
      throw new Exception("XPUB, YPUB or ZPUB key is not present!");
    }

    $adapter = Bitcoin::getEcAdapter();
    $slip132 = new Slip132(new KeyToScriptHelper($adapter));
    $registry_classname = 'BitWasp\\Bitcoin\\Network\\Slip132\\'.$this->network_name.'Registry';
    $bitcoin_prefixes = new $registry_classname();

    if ($this->xpub !== NULL) {
      $pubPrefix = $slip132->p2pkh($bitcoin_prefixes);
      $pub = $this->xpub;
    } else if ($this->ypub !== NULL) {
      $pubPrefix = $slip132->p2shP2wpkh($bitcoin_prefixes);
      $pub = $this->ypub;
    } else if ($this->zpub !== NULL) {
      $pubPrefix = $slip132->p2wpkh($bitcoin_prefixes);
      $pub = $this->zpub;
    }

    $config = new GlobalPrefixConfig([
      new NetworkConfig($this->network, [
        $pubPrefix,
      ])
    ]);

    $serializer = new Base58ExtendedKeySerializer(
      new ExtendedKeySerializer($adapter, $config)
    );

    $key = $serializer->parse($this->network, $pub);
    $child_key = $key->derivePath($path);

    return $child_key->getAddress(new AddressCreator())->getAddress();
  }

  public function multisig_address_from_xpub($m, $path = '0/0') {
    if (count($this->multisig_xpubs) < 2) {
      throw new Exception("XPUB keys are not present!");
    }

    $keys = array();

    foreach ($this->multisig_xpubs as $xpub) {
      $keys[] = HierarchicalKeyFactory::fromExtended($xpub, $this->network);
    }

    $sequences = new HierarchicalKeySequence();
    $hd = new MultisigHD($m, 'm', $keys, $sequences, TRUE);

    $child_key = $hd->derivePath($path);

    return $child_key->getAddress()->getAddress($this->network);
  }
}


what questions should i ask when deposing a client about hidden bitcoins

To 'own bitcoin' is to have knowledge of the private keys that allow some unspent transaction output (UTXO) to be spent (though in some cases, knowledge of a key may be delegated to a custodial service). So understand that the 'bitcoins' themselves are not what a user must keep safe, rather it is the keys that allow those coins to be spent.

With this in mind, consider that there are many ways to store bitcoin keys. A savvy user may be able to obfuscate their keys entirely, and there is not necessarily any way to prove that a person has current knowledge of a key.

"How much bitcoin have you mined since 2013" is the obvious question to ask. Consider that some amount of the bitcoin mined may have been sold in order to finance the mining operation, may have been traded into other cryptocurrencies or assets, may have been lost due to user error, etc.

Otherwise, I agree with @RaghavSood's comment, especially considering the legal implications of this question, it is difficult to answer comprehensively in a SE posting. This seems like a situation in which a paid consultant may be appropriate.


Solving Bitcoin core's 'ActivateBestChain failed'

That block is not just orphaned, it is actually invalid. It exploits CVE-2018-17144. The only way to fix this error is to upgrade to Bitcoin Core 0.16.3 and begin a reindex following the upgrade.


GetWork requires you to make a new request every 2**32 nonces, modern miners would be making 50,000+ requests a second. No pools have supported this since 2011.


Naming convention: MilliBit or Millibitcoins (mBTC), microbitcoin or Mikrobitcoins (μBTC)?

"Official" units of bitcoin

To my knowledge, only the bitcoin and the satoshi are "officially" named units of bitcoin.
As of 2014/2015, one also often sees bit as a moniker for one microbitcoin, i.e. 100 satoshis.

BTC has been used as the abbreviation for bitcoin for a long time, yet, in September bitcoin was added to ISO 4217, as XBT, where X means not associated with a country, just as  in XAG (Silver) and XAU (Gold), and opposed to national currencies, e.g. USD (US Dollar). However, it seems to me that XBT has not been adopted by the community, BTC remains prevalent.

Origin of millibitcoin and microbitcoin

Millibitcoin and microbitcoin follow the conventions of the International System of Units, and thus are derived from the main unit bitcoin with a prepended "m" for millibitcoin and a prepended "μ" for microbitcoin.
Following the same conventions and starting from the common abbreviation BTC for bitcoin, one would use mBTC and μBTC.

Millibit and microbit are confusing

While usually people will understand the meaning, using the abbreviations "millibit" or "microbit" gives the impression that they are assiociated with bit as the main unit. This is especially confusing with the advent of bit as a nickname for microbitcoins.

"bit"

Bit is a terrible name for two reasons: Bit, the binary digit, is the basic unit of information. It is used a lot in the context of anything related with computers and therefore shouldn't be doubled as a subunit of bitcoin. Second, due to people using "millibit" and "microbit" it is terribly confusing to anyone that is new to Bitcoin, but familiar with the International System of Units.

Millie and Mike

"Millie" and "Mike" were proposed nicknames for millibitcoin and microbitcoin, but I haven't seen them get much usage. I don't think that they will see adoption.

Units in English

In general currencies are not capitalized in English, unlike the name of the protocol. So, you would write about the Bitcoin protocol, but five bitcoins.

Overview

I would argue for the following usage of units:

Unit       Value in bitcoins  Value in satoshis   Abbreviation
-------------------------------------------------------------------
bitcoin        1.0               100,000,000             BTC
millibitcoin   0.001                 100,000            mBTC
microbitcoin   0.000001                  100            μBTC
bit            0.000001                  100             bit
satoshi        0.00000001                  1         satoshi


Where can i find proof of work in Electrum(light weight bitcoin) source code?

Miners perform the proof-of-work that secures the blockchain. Electrum is not a miner.

Electrum is a light wallet, it does not perform proof-of-work hashing to create blocks, instead it just checks to ensure that relevant transactions are valid. Rather than download the entire blockchain, it will just download the block headers (much less data), and then it can perform cryptographic checks to ensure that everything is legit.

For transactions in particular, the wallet will ensure that the relevant transaction hashes are present in the merkle root of a block (the merkle root is part of the block header). The wallet can request the relevant transactions, and then hash them to verify that the correct merkle root is reached (ie, the same merkle root that is present in the longest valid proof-of-work chain). Due to the one-way nature of hash functions, a node could not serve an invalid transaction hash to a wallet, or else the root would change entirely and the wallet would know it is invalid.

In this way, light wallets allow you to verify the blockchain's history with a low level of trust, and low resource intensity (less data, and less verification computation).


I believe that the use of the term "pointer" in the this sentence is not referring to the low-level data type, such as int *pointer_to_int; would be in C.  I think it's more referring to a "pointer" as a key into a data structure or database table.  In this sense, the hash is a pointer/key used to retrieve the information you are looking for.

For example, in Bitcoin, transaction hashes are used in this way.  The hash of a transaction can both be used to look up the transaction and to verify that the transaction retrieved has not been tampered with since it was stored.


Transaction generator with payment fee optimization for large number of small coins

If the coins are in the same wallet then you should be able to send your "large amount of money" in one transaction.

If your coins are spread across multiple wallets in the same client then you would need to take the 15% loss. Or not pay a transaction fee and hope your coins get validated by a very friendly miner. (I would advise the former.)

In the event that your coins are spread across multiple wallets, you should bite the bullet and send them all to a single wallet so you don't continue losing money in the future.

It also might be a good idea to have slightly larger transactions, so you don't pay as many fees.


Yes surely you can, Check out this website : https://localbitcoins.com/country/CA


If you sent BCH to your Trezor BTC address or vice versa, you can use https://trezor.io/recover-coins/ to recover your coins.  The only exception is if you send BCH to a BTC 3... address (segwit), since these are not supported by Bitcoin Cash.

To convert BCH into BTC or vice versa you need to use an exchange.


Where can I find the technical discussion between Satoshi and other contributors in the sourceforge website?

Try https://satoshi.nakamotoinstitute.org
I believe this group has attempted to consolidate all known messages written by Satoshi Nakamoto on their site.


Can a bitcoin exchange recover coins sent to a previous address used on said exchange?

Yes, it would be possible because they hold the private keys for that address. You will need to contact the exchanges customer support. However while they may be technically able to do so, they may not actually credit your account.


How to Send BTC from my address to another using private key

If you don't want to use any wallet software, you could install bitcoind on your local host and

https://stackoverflow.com/questions/38493893/heres-how-to-send-raw-transaction-btc-using-bitcoin-cli-command

You could use an online version of bitcoind RPC endpoint, but I am not sure you want to submit your private key over the network.


lightning daemon rejects bitcoind RPC variables in lnd.conf

Found out that any bitcoind.XXX options need to be under a [Bitcoind] heading. Working lnd.conf is as follows:

[Application Options]
debuglevel=info
debughtlc=false
maxpendingchannels=5
alias=WittyAlias
color=#000300
maxlogfiles=3

[Bitcoin]
bitcoin.active=1
bitcoin.node=bitcoind
bitcoin.mainnet=1

[autopilot]
autopilot.active=1
autopilot.maxchannels=16
autopilot.allocation=0.1

[Bitcoind]
bitcoind.rpchost=127.0.0.1:8332
bitcoind.rpcuser=wittyusername
bitcoind.rpcpass=VerySecretSuperDuperRPCauthPassword
bitcoind.zmqpubrawblock=127.0.0.1:28332
bitcoind.zmqpubrawtx=127.0.0.1:28333


By the looks of things the transaction never made it to the network from your client. Find the "reset blockchain" button in Multibit and wait for it to recover. You won't lose any funds (the ones you "sent" never left) and then you can give it another shot.


By whom and when can transaction malleability be applied?

The underlying data cannot be changed, only the signature thus id can.  It can be altered by anyone with knowledge of how to alter digital signatures while not invalidating them.

If it's a valid transaction, either the altered or unaltered version can be included in the blockchain.

Once it's cemented into the blockchain, the signature thus id cannot be changed.


RPC call to bitcoin node on local machine respond back with code: 401

You are not properly sending the authentication headers. From a quick reading of the documentation, you need to add auth=BasicAuthorization("rpcuser", "rpcpass") to your post request because the URL http://rpcusr:rpcpass@127.0.0.1:18443" is not sufficient for khttp to send the basic authentication headers.


Why did Bitcoin lose value so fast in early January 2015?

Adding to my answer on What are some of the proposed ideas to why the Bitcoin dropped to sub $400 in the end of summer 2014?, which I think is still mostly accurate:

Bitstamp loot

There are about 19k bitcoins held by the hacker that raided Bitstamp. While, as far as I know, they haven't found their way back into the market, it is an amount that would impact the markets if it were dumped. It is possible that some speculators were expecting a dump, and tried to position themselves to buy low. Such a dump in itself could have scared the already skittish market into further dumps.

Bitstamp has no trading fee until 19th

While Bitstamp seems to have weathered the hack well-enough, they are not taking any trading fee until the 19th. The fee usually being 0.2% – 0.5%, trades on much smaller movements are currently profitable. As Bitstamp is still the most important Western Exchange, this might have spiked a new dynamic.

The loss in value

Markets amplify the current trend. The loss in value is causing fear, leading to further dumps, creating a catch-22.

Russia banning Bitcoin websites

Bitcoin supposedly was a hip way to withdraw money out of Russia for a while. Although Russia had been rattling with their saber a while towards Bitcoin, they are finally starting to take action by blocking Bitcoin services there now. This might induce a trend of Russians moving out of Bitcoin.

Butterfly Labs has to sell their stash to confirm with financial obligations

Apparently, Butterfly labs has been ordered by court to refund their customers. According to rumors on reddit, they have been selling thousands of Bitcoins and are still sitting on more than 90k.

Mining operations sliding into unprofitable ranges

A bunch of mining operations, as for example CEX.IO, have cited that the current price makes their mining unprofitable. To cover financial obligations, they have to liquidate a larger percentage of their bitcoins than before, perhaps even their saved holding they were hoping to carry over to the next bubble. With the dropping price covering their obligations by liquidating bitcoins only gets more bitcoin-expensive.

Bringing oneself in position to buy takes a few days

When the price quickly lost value, few of those that were interested in catching up the cheap coins were already in position to buy. As it takes a few days for money to be transferred to exchanges, the buy reaction is a bit delayed in comparison to a price drop.

Especially on Bitstamp where deposits were closed for a few days during the slump in the aftermath of the hack, people were probably waiting for the dust to settle. In fact, a lot of the deposits from Bitstamp were immediately withdrawn on reopening.

Once the dust settled, and people started to realize that Bitstamp actually appeared to be in good shape, it still took a few days for potential buyers to transfer money to Bitstamp, which would explain why the price was somewhat shifted lower on Bitstamp in comparison to other exchanges for a while.

As usual: I'm a computer scientist, not knowledgeable in economy beyond what I read here and there. Please do not consider this investment advice; I have been wrong before. Please trade responsibly.


How to measure profit and losses in bitcoin investment?

I am no expert in finances, but I look at profit calculation of investment in fungible goods in the way shown below:

Total Profit(between time t1 and time t2) = Total assets at t2 - Total assets at t1

Your total assets at time t would be your fiat in USD at time t + value in USD of your BTC at time t.

Total assets at t1 = $1200 + $1500 = $2700 (When you bought 2 btc)

Total assets at t2 = *$0 + $2000*2 = $4000* (Just before selling 1 btc at $2000)

Total assets at t3 = *$2000 + $2000*1 = $4000* (After selling 1 btc at $2000)

Total Profit = ($2000 + 1btc) - ($1200 + $1500) = (1btc - $700) which depends on bitcoin price.

Instead of talking of profit per transaction, it is better to talk in terms of timestamps. Profit earned between t1 and t2 is $1300 and between t2 and t3 is $0.

If it were 2 distinct houses, which you bought at $1200 and $1500, then it made sense to calculate profit on the house which you sold, but because of fungible(almost) nature of bitcoin it makes sense to look at it as mentioned above.


There is a page on Wikipedia that tracks Bitcoin legality by country or territory.

Another one can be found on Coin.dance.


How to check if the block chain is up to date using bitcoind or json-rpc?

I use a python script that grabs http://blockchain.info/q/getblockcount and compares it to the output of bitcoind getblockcount.

As others have said, there is no absolute way of telling if your blockchain is up to date.

Anyway, here is my script:

    import httplib2
    from bitcoinrpc.authproxy import AuthServiceProxy
    access = AuthServiceProxy('#########')
    try:
            blockCount = access.getblockcount()
    except Exception as e:
            print "Problems connecting to bitcoin wallet:"
    else:
            try:
                    response, trueBlockCount = httplib2.Http().request("http://blockexplorer.com/q/getblockcount/")
            except Exception as e:
                    print "Unable to get true blockcount from blockexplorer:"+str(e)
            else:
                    if (int(trueBlockCount) - 5) > blockCount :
                            print "blockchain not up to date: true block count is: "+str(trueBlockCount)+", while bitcoind is at: "+str(blockCount)


I used edge wallet to send my bitcoin from my wallet to my cash app but i used a low fee soo its been unconfirmed for 10 days what can i do?

ViaBTC's Transaction Accelerator service can be used and you can pay with BTC but it will cost $100 or more.
You can wait for your transaction to be confirmed by Monday or you could have tried to spend unconfirmed UTXO if it was not cash app and some non custodial bitcoin wallet by following the below steps :

Generate a new Bitcoin address in wallet.

Make sure RBF (Replace By Fee) is ON. Send some or all of the unconfirmed balance (from the parent) to that address.

Copy the new transaction ID (TX ID) and paste it in the 'Child TX ID' field here: https://cpfp.djbooth007.com/

Enter the desired sats/vB amount. This can be determined by looking at the range of sat/vB in recently confirmed blocks or mempool stats on https://mempool.space

Click 'Calculate Fee'

Perform RBF (Replace By Fee) with the calculated result highlighted as 'Child to Pay'.

Other things you can use in future is RBF for every transaction and a change address if possible.
Some open source bitcoin wallets that support RBF:
Bitcoin Core
Electrum
Bluewallet
Sparrow
Wasabi
Green


If you only need receiving addresses, then you need only a table for those along with a column that flags to prevent it from from being used a second time.

Keys can be generated in bulk:
 - http://bitcointalk.org/index.php?topic=101708.0

Now just because you aren't saving the private key on the web host doesn't mean security can be lax.  If a host were compromised, the attacker could replace the Bitcoin addresses in the table with addresses under the control of the attacker.

For situations where the Bitcoin client needs to send transactions, a cold wallet / hot wallet method will help lessen the damage should  the system become compromised.

Here's additional information for Securing online services:

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


First of all, did you read the manual?

http://cointerra.com/wp-content/uploads/2014/02/TerraMiner-User-Guide-1.pdf

This is a miner with a mining controller on board, specifically the beaglebone black. This allows the miner to do 'standalone mining', meaning it does not need a computer to control it, it has it's own microcontroller to connect to a pool and get the necessary information to start hashing away.

If you do want to connect the miner to a computer:

Accessing the TerraMiner via Serial Port
You can access the TerraMiner by connecting a USB cable between a computer and the TerraMiner’s
serial port and using a terminal program. The login is root and the password is cointerra.

But the manufacturer does say:

NOTE: Accessing the TerraMiner through the serial port is unsupported by
CoinTerra. The Technical Support team will not be able to answer any inquiries
regarding serial port access. Accessing the TerraMiner via the serial port and
modifying the software will invalidate the product warranty.

Edit after comment:

I do not own this machine myself, so I can't say this out of experience. But from what I can read, the miner has a Beaglebone board inside of it, as the miner controller. A beagle bone has a micro USB connection, so plugging in a USB cable into the Beaglebone would allow you to connect to it.


Is anyone taking advantage of different prices across exchanges?

This is possible and many people do it, but the loop can be significantly delayed by the time it takes to transfer fiat between exchanges. There may be automation software out there, but it is likely closely guarded by those who employ it. There is still the manual step of coordinating fiat movement.


bitcoind error "mempool min fee not met" preventing me from sending btc on blockchain

It seems to be a known issue on Electrum. Try a different server:   https://github.com/spesmilo/electrum/issues/3555#issuecomment-352621941


What are the maximum useful memory limits for a Bitcoind full node?

After a point, there's no reason to increase memory usage further.

dbcache is useful up until the point where you have the entire UTXO in memory (4GB+ in 2021), and then increasing it further does not a lot other than increasing the time to shutdown the node safely (up to many minutes on a slow disk)

maxmempool will increase performance by allowing more transactions (and their validity) to be ready for their inclusion in a block, but only up to the point where you are including all of the possible transactions that miners are likely to include.

blockreconstructionextratxn will allow the node to store more transactions which are not in the mempool, but are still valid. This increases the efficiency of compact block transmission as sometimes transactions will be evicted from your mempool but may be in other people's. This setting notably is in number of transactions, not megabytes.

maxorphantx increases transaction relay efficiency by keeping copies of transactions which could not be connected to a parent (and therefor can't be validated!), but might become valid in the future by the arrival of their parent. This setting is also in number of transactions, not megabytes.

These are about as far as you can go just by tweaking the settings in bitcoin.conf.

A "hot rod", "no cost considered" Bitcoin Core node would look a bit different.
The entire UTXO would be stored in a ramdisk (to prevent a cold dbcache ever occurring), with the obvious cost that unexpected shutdowns would result in a complete loss of synchronization state. As many cores as possible would be in use, the node would make connections to other nodes owned by the operator for maximum efficiency, and those nodes would be tuned to have as many high quality peers as possible.
You can go a long way towards making extremely performant nodes with not an unreasonable financial outlay if there's a reason to do so, it's just a matter of optimizing the right parameters and limiting bottlenecks that are normally caused by the network being optimized for stability and correctness.


How does the network adjust the rate at which the coins are created?

TL;DR: The Bitcoin protocol runs the Bitcoin network and the rate at which coins are created cannot be adjusted manually, but follows a pre-defined reward schedule.

The money supply in Bitcoin is governed by the rules defined in the Bitcoin protocol. The protocol defines a reward schedule, i.e. how many Bitcoins may be created with each block, and the rules by which valid blocks may be created.

Reward schedule

The Bitcoin protocol allows a miner that finds a valid block to create a specific amount of new Bitcoins and sent them to an address of the miner's choosing. To do so, the miner includes the mandatory coinbase transaction in the block which doesn't have an input, but only outputs the newly generated coins.

For Bitcoin, this block reward started out to be 50 BTC per block. It is halved every 210,000 blocks, so that it is currently 25 BTC per block (as we are currently at block 281,535).

Block interval and difficulty

The protocol defines that any block which doesn't fulfill the current difficulty criteria should not be accepted by the network. The difficulty is adjusted every 2016 blocks (approx. every 14 days). By the rules defined in the protocol, the new difficulty is calculated such that there would be approximately one block every ten minutes, if the amount of the work available to the network remained like it was for the previous difficulty period.


Why is a Payment Protocol Acknowledgement message not signed?

This discussion talks about the acknowledgement being used as a receipt. In the event of a dispute, the payer can show the payee this receipt to prove payment.

I don't think it says that. Quote:

  When a payment request is signed it's not just the addresses. The memo is also signed. By keeping around the signed payment request, and the transactions you created to satisfy it, you obtain a mathematical proof of payment. The merchant cannot dispute what was paid for because the memo field contains a description, nor can they dispute that payment was delivered (unless they claim they lost control of their private keys, of course).

So, when going to dispute resolution, the buyer shows the signed PaymentRequest, which includes one or more Outputs, and shows a transaction to those outputs.

  It seems like a signed acknowledgement message would provide strong proof of purchase, and would be very valuable from the perspective of consumer protection. Why wasn't this included in BIP 70?

Well, the server isn't required to provide a signed acknowledgement. It could just terminate the connection after the Payment was received. At that point, you'd be in exactly the same boat.


I think you're not understanding what decentralized exactly means.

Sure, a company with a large stake can control the price ( up to a certain degree), but this does not mean that they control (the protocol) Bitcoin itself.

There's no central power which decides what transaction is good, or which one is bad, or who controls what.

which would still be the case even if company X had 90% of the bitcoin supply.


Work rejected. Server says: Stale or alien proof of work

There will always be some stale work that is rejected by the server.

When there is a new block on the network (from any pool) we need to switch to building on top of this new block, at the new height. The server sends out new work data to all workers. But some of them are sending in work results at that moment, and it gets rejected because it is based on the old work data.

I would consider a reject ratio of 0.5% or lower to be normal and acceptable.


http://bitcoincharts.com/charts/mtgoxUSD has historical charts.

These 3 all have 'live' charts:

http://btccharts.com/
http://mtgoxlive.com/
http://bitcoin.clarkmoody.com/


BIP0016 pay-to-scripthash transaction validation

What does it mean "push data operations"?

Push data operations are when a script pushes a byte vector into the stack. Examples are pushing signatures, public keys, or scripts. It excludes all script opcodes apart from OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA3.

  OP_CHECKMULTISIG seems to be allowed but does not look like "push data" to me.
  OP_CHECKMULTISIG is an opcode, however, since it's actually contained in a byte vector. You are pushing a full script to the stack, instead of just pushing the opcode.

So, if you look at a P2SH scriptSig:

  ...signatures... {scriptLength}{script}

You'll see that OP_CHECKMULTISIG is contained within {script} instead of being directly executed by whatever is parsing the scriptSig.


From he official Developer Guide:

  Null data scripts let you add a small amount of arbitrary data to the
  block chain in exchange for paying a transaction fee, but doing so is
  discouraged. (Null data is a standard script type only because some
  people were adding data to the block chain in more harmful ways.)

    script: OP_RETURN <data> (Null data scripts cannot be spent, so there's no scriptSig)

Another information (which is related to your example):

  This pattern is often used to encode data in the blockchain. After the OP_RETURN you can
  insert arbitrary data. The advantage is that the simple bitcoin nodes can prune the transaction
  saving memory, while full nodes will hold it. This is considered good behavior when
  ‘misusing’ the blockchain for storing data.

As you can see in your example there are data following the OP_RETURN so it was used to encode data into the blockchain.


Can I recover funds where the wrong destination tag was used while transferring ripple to bittrex?

Contact Bittrex immediately. They may be able to return the funds if the destination address doesn't map to a valid customer. But if it does, they probably already credited that customer and there is likely nothing that they can do.