Is the "official client" crash-resistant?

Yes, mostly, but there are some things you should know.

Your wallet is stored as a separate file. Your wallet file gets changes written to it as new blocks are received and transactions are made, etc. The chances of a crash occurring during a write to your wallet are probably minimal, but you should have a backup of your (encrypted) wallet anyway. This is by far the most important point. Once your wallet is encrypted with a very strong password (the client provides this function), you can store copies of it in insecure locations, so you always have a copy somewhere - store it in gmail, send it to your family etc. You should only need to make an additional backup every 50 transactions. Bear in mind the receiving address descriptions aren't encrypted though. Running the client with the -rescan option may fix minor issues.

The client will refuse to work if a failed attempt at double-spending is detected, but that's not really what you're asking. Besides, there appears to be a fix for the problem.

The block chain takes a long time to download, so there is a risk that a crash would required you to download it again. If the client is closed (gracefully) while it is downloading the block chain, it resumes where it left off with no issues; I would guess it would probably do the same thing in the event of a crash, but it's only your copy of the block chain that's really at stake.

Realistically, once you've got your wallet encrypted with a strong password and backed up in multiple locations, the biggest remaining risk is from theft through a virus or malware. Quote from Gavin Andresen: "If your computer is infected, then it cannot be trusted, and there is no software in the world that can keep your bitcoins safe if they are stored on it."


At what block height may locktimed transactions get included?

A transaction becomes valid when the chaintip reaches the height specified in the locktime, and may be included in any block with a height greater than nLockTime.

    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
    return true;

  via https://github.com/bitcoin/bitcoin/blob/v0.19.0.1/src/consensus/tx_verify.cpp#L21L22

H/T Pieter Wuille for code section and explanation.


How to use litecoin testnet on fully synced litecoin core on amazon ec2 instance

litecoind --testnet --daemon

Should be all you need to start in testnet and run as a daemon


If you have bitcoins you can buy Ardor fastly and easily in Poloniex.
If not, you can buy Ardor with $ here


Unable to connect to Litecoin Testnet with Litecoin Core on Mac

One possibility is you are using an older version of litecoind which is trying to get testnet3 instead of testnet4.

If this is the case, updating to the latest version should solve it.

See Reset Testnet section at https://blog.litecoin.org/litecoin-core-v0-14-2-release-ab6d2217405f


Why should BIP157 compact filters be processed in-order?

A HD wallet doesn’t know what indexes of a seed to scan for until the ones prior have been used, which can’t be discovered out of order. To allow for out of order scanning the address gap limit would need to be prohibitively large, and might still result in re-scanning filters if the wallet is particularly active.


How many Hashes are in a single Terrahash

Tera is an SI prefix that means 1 trillion.

That means 1 terahash/s means 1,000,000,000,000 hashes per second.


Can a Bitcoin (secp256k1) key be converted to a Ed25519 (Tor v3) key?

The bitcoin key could sign a message containing the onion address. There are several other alternatives but there isn't any way to do this without the key holder producing a message of some kind.


Why does Bitcoin use two hash functions (SHA-256 and RIPEMD-160) to create an address?

RIPEMD was used because it produces the shortest hashes whose uniqueness is still sufficiently assured. This allows Bitcoin addresses to be shorter.

SHA256 is used as well because Bitcoin's use of a hash of a public key might create unique weaknesses due to unexpected interactions between RIPEMD and ECDSA (the public key signature algorithm). Interposing an additional and very different hash operation between RIPEMD and ECDSA makes it almost inconceivable that there might be a way to find address collisions that is significantly easier than brute force trying a large number of secret keys.

Essentially, it was a belt and suspenders approach. Bitcoin had to do something unique and rather than have to hope they got it exactly right, they overdesigned it.


The logic behind the transaction fee in the bitcoin network is that the miners take  in consideration first the txs that have higher fees to be added to the blocks, those txs are taken from the mempool, the place where they should wait until miners decide to add them to a block to be validated.

For example:
If I perform a transaction that has a fee of 300 satoshis it will be first added in the mempool before it goes to a block; and let say, that some minutes later you perform a txs that has a fee of 30000 satoshis it will added  to mempool too, but the miners will consider first your tx because of its higher fee.

Taking that in consideration, when the bitcoin price get up, usually there are a lot of people performing txs and since the size of the blocks is only 1MB, where only can be attached about 2500 txs, much of those people prefer to pay higher fees so their txs could be added to the next block. That cause the mempool get full of transactions waiting to be added to a block.

According that explanation we can say the transaction fees is not directly correlated with the  volatility of bitcoin, it is more correlated with increase or decrease of quantity of transactions waiting in the mempool and the wish of people to get txs done asap. If there are many txs in the mempool people will be more tempted to pay more to get them done.


Here's that source code, annotated. Each annotation refers to the code after it.

This means that this part of the code handles both OP_PICK and OP_ROLL. This is because OP_PICK and OP_ROLL are very similar. The only difference is that PICK copies and ROLL moves.

            case OP_PICK:
            case OP_ROLL:
            {

These are two examples of the stack before and after. This is sometimes called a 'precondition' and a 'postcondition.'

This one documents OP_PICK.

Precondition: xn ... x2 x1 x0 n

Postcondition: xn ... x2 x1 x0 xn

                // (xn ... x2 x1 x0 n - xn ... x2 x1 x0 xn)

This one documents OP_ROLL.

Precondition: xn ... x2 x1 x0 n

Postcondition: ... x2 x1 x0 xn (Note the lack of xn at the beginning.

                // (xn ... x2 x1 x0 n - ... x2 x1 x0 xn)

You need to have at least two elements on the stack, or this operation makes no sense.

                if (stack.size() < 2)
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

Copy (but do not remove) the top element on the stack. Interpret it as a number. Convert it to a 32-bit integer, so it's easier to work with.

                int n = CScriptNum(stacktop(-1), fRequireMinimal).getint();

Now remove the top element on the stack. (Which should be n, remember.)

                popstack(stack);

If n is negative, fail. If n is larger than the stack, fail. (This is where I think your script is having an error.)

                if (n < 0 || n >= (int)stack.size())
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

Copy the value we're after. Remember, 1 2 3 0 OP_PICK should get the element just below n, 3. Also, stacktop(-1) refers to the top. So therefore, we need to invert n and subtract 1.

                valtype vch = stacktop(-n-1);

Remember, OP_ROLL deletes the element from where it was originally. This code is not executed for OP_PICK.

                if (opcode == OP_ROLL)
                    stack.erase(stack.end()-n-1);

Now add the element that we just got back on the top of the stack.

                stack.push_back(vch);

We're done handling this case.

            }
            break;

Does that help?


The "ideal" distribution strategy for OpenCoin, is to give away the 50 billion XRP in such a way that spurs adoption but does not create a surplus which will depress prices. Adoption is spurred by handing out generous helpings of XRP to a small audience. This is what they are doing by handing out 50,000 XRP to every Bitcointalk.org user that has a sufficiently aged forum account. Every week they have been reducing the amount given out.

Very soon they will give out just enough XRP to fund the reserve requirement for an account, plus a couple of trust lines and a couple of order book offers (About 400 XRP at the current requirements).

They want to make sure that each individual can only receive a free serving of XRPs once, or else they will have a surplus of XRP that can be sold, depressing the price. I would expect they would leverage existing identification services such as OpenID, Facebook, Google+ type of systems by creating apps.

They could also leverage the gateways, which already collect personal information on every user as part of "Know Your Customer" and "U.S. PATRIOT Act." By hashing this information according to some standard method, it would be possible to filter duplicates across gateways.


Is there any way to measure relative occurrences of wallet theft over time?

The only way you can measure something like that, is if users would first of all know if their wallets get stolen, and second of all, if they reported that problem. Besides that there is no real way to know if a wallet actually got stolen, nor are there any means of verifying that it did.

On the other hand, if one was to steal a wallet from some big Bitcoin website (say, a pool, an exchange, or an eWallet), one probably could notice a change of pattern of transactions, and we might hear some official statements from website owners about the theft. In this case though, it would probably be more of "quality over quantity" theft, as in we wouldn't see many cases like this appear.


How to combine separately signed inputs from different users?

With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)?

If you are trying to combine two independently signed transactions together it would include a number of constraints on how the amount can be spent and how the transaction is structured. This is because when we sign transaction, we include the serialized transaction as the message (until we have SIGHASH_NOINPUT). The constraints are the following:

The version and nLocktime of both transactions would have to be same.
The individual transaction inputs would need to be signed with ANYONECANPAY|SINGLE SIGHASH flag. The ANYONECANPAY allows adding additional inputs to the transaction. However, if you sign with ANYONECANPAY|NONE, the signer is at a risk of his output being excluded from the transaction as he has not committed to any outputs. Signing with ANYONECANPAY|ALL binds all the outputs and hence no other outputs can be added. All of this means, the signer can only send money to a single address/script and hence cannot include a change output to send remaining money.

The #2 point is true if the signer does not trust any centralized entity in batching the transaction. A signer can however, sign with ANYONECANPAY|NONE flag and assume that when the centralized entity broadcasts the transaction they will sign the transaction with ALL flag in order to bind all the outputs to the transaction.

  Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?

Transaction fees are based on the weight of the transaction. Signatures, outpoints of tx referenced, and locking script occupy the vast majority of that which cannot be done away with batching transactions signed independently. You will only be saving transaction costs on things that are common like 4 byte transaction version, 4 byte nLocktime, 2 bytes for number of tx inputs/outputs.

Batching is generally done to mask who pays to whom (eg. coinjoin) not to save fees. But even in that case the batching server gives the senders a final serialized transaction containing all the inputs and the outputs that all of them sign with sighash_all flag. Each input is not signed independently.


Another key difference is the rate at which new blocks are generated. Bitcoin blocks are created every 10 minutes or so. Litecoin blocks are produced every 2.5 minutes. This has implications in terms of security of the coins against double spending.


A Satoshi is the smallest unit of account within the Bitcoin network that can be transacted. One BTC equals 100,000,000 Satoshis.

The 0.1 BTC in your example is 10,000,000 Satoshis. 5,000,000 Satoshis are applied the that special person in its own UTXO, and 5,000,000 Satoshis minus mining fees are sent back to yourself to another address, and is recorded as another unspent transaction output (UTXO).

A UTXO is defined by a transaction's ID and the output index of that transaction.  For each successful transaction whose outputs are unspent, each output is a UTXO. An additional point is UTXOs are atomic in the sense all of a UTXO's balance is spent or none of a UTXO gets spent in a transaction.

FYSA - In the future, we might see the term UTXO deprecated with the term called payment.


Is Lightning Offers an improvement over Key Send?

Yes, offers are a carefully constructed rethinking of use cases like donations that used to be serviced by hacks like keysend.
One specific improvement for this use case is that unlike in keysend, you do receive a receipt for the donation you are giving.
But offers are meant to service many more use cases beyond just donations, and do so in a less ad-hoc fashion.


Bitcoin JSON RPC not working on Remote IP

Try to allow RPC calls on particular IP or whitelist all IP's, for example:

rpcallowip=0.0.0.0/0

Plus try to check debug.log if the connection appeared on daemon it should report. If not, probably firewall issues on a system itself.


How to verify a lnurl-auth callback with python

I gave up using the secp256k1 library, but here is a working python solution:
Make sure to install the python-ecdsa package, for instance with pip:
pip install ecdsa
...and then...
import ecdsa

k1 = bytes.fromhex('b29fa5994dc9da9906a36f996e6ac4faa2b0e2601ef13b0fab9d4b4287c57e1f')
key = bytes.fromhex('030f12794ae14407b8e1bfa1cbc297bb68ce6b24455ceab52c02da7a92782b6b14')
sig = bytes.fromhex('3045022100a23fbcaf3f24aff085d8c86a744764be8390e8511eca675ae2af037f33ff1a92022035f00465fbcad73e3175d7dc2e891322fa9dcce7bbd19409866f855e6da1f51e')

vk = ecdsa.VerifyingKey.from_string(key, curve=ecdsa.SECP256k1)
vk.verify_digest(sig, k1, sigdecode=ecdsa.util.sigdecode_der)

With the ecdsa library, make sure to use verify_digest rather than verify.


in python to get transaction data of block you will need to import requests library so first add that "requests" library to your project then run following code

import requests
block_hash = '0000000000000bae09a7a393a8acded75aa67e46cb81f7acaa5ad94f9eacd103'
api_url_base = 'https://blockchain.info/rawblock/'
api_url = api_url_base + block_hash
headers = {'Content-Type': 'application/json'}
response = requests.get(api_url, headers=headers)
jsondata = response.json()
trasactiondata = jsondata['tx']
print(trasactiondata)

if you are using the multiple blocks then run this code in for loop and in each iteration change the block_hash value there you have to put block hash value and this code will give you all transaction data of that block


My solution to the question for an encrypted wallet:

walletpassphrase "......." 600
dumpprivkey ......

I made the mistake of including the brackets [ ] when entering the public key after the call dumpprivkey.


Can a Trezor seed be used in any other HD wallet?

Yes, Trezor uses the BIP0032 standard to derive your keys from the seed. That means you can use any BIP0032-compatible client for recovery, or you can even use them simultaneously (but be aware of the security implications - you don't want it to leak, otherwise it beats the whole Trezor purpose).

For example, Electrum works great with HD wallets, but I'm sure you can find other clients as well.


How is the transaction's nVersion field changed with segregated witness?

Segwit does not use the transaction version field at all.

One reason for this is that it isn't really the right scope. Outputs and inputs are witness-specific, but whole transactions are not.

The transaction version also cannot be used to indicate the presence of the optional witness record. Because the transaction version is part of the "base" transaction data (covered under the txid hash), you'd get compatibility problems when a segwit transaction would be relayed to an old node, and back to a new node. That new node would see the new transaction version number, expect a witness encoding, but the old node cannot give that. Instead, BIP144 introduces a new extensible transaction format with optional records. The encoding used is independent of any data "inside" the base transaction.

It also isn't needed. Specific template transaction outputs are fine to indicate new semantics.

All in all, segregated witness just adds extra records to existing transactions. It does not modify the structure of the existing base part (including the version number).


How many confirmations do I need to ensure a transaction is successful?

It depends on your risk model.

If you can trust the person paying you, you can accept payment on 0/unconfirmed if you want.

As a merchant or trader, you want to use the configuration that is more secure (no incoming connections permitted, explicity connect to well-connected nodes).

With zero confirmations you are vulnerable to the race attack and the Finney attack, as well as the 51% attack.

With one confirmation you are vulnerable to the 51% attack.  There could also be a miner with a lot of hashing power who could get a couple blocks in a row, so three confirmations removes most of them.

With six confirmations it is essentially mathematically impossible for an attacker with less than 51% of all mining capacity to get six blocks in a row. and still surpass the longest block chain.  With 51% or a lot more than 51% the attacker can get six confirmations by creating a parallel blockchain in which only transactions approved by the attacker get included in blocks.

A merchant like a retailer can likely accept even on 0/unconfirmed in most instances (e.g., purchases up to $100 worth).     A merchant that ships e-commerce might hold off until the transaction has three confirmations.

A cash, face-to-face cash trade will probably be best if three confirmations for a large amount, maybe one confirmation for small amounts.

Any recommendation would need to come only after determining which risks are deemed acceptible.


how to view raw json bitcoin transactions

You can do this:

https://blockchain.info/tx/b657e22827039461a9493ede7bdf55b01579254c1630b0bfc9185ec564fc05ab?format=json

or use getrawtransaction and decoderawtransaction RPC's in Bitcoin Core.


Radeon HD 6750 running at 120 Mhash/s table shows 167Mhash/s

If you are using ATI Drivers 11.12 or 12.0 or above you need to set the worksize to 64.

Also the new drivers are a bit slower then pre 11.12 drivers.


Why are the seeds different when going from seed to mnemonic and back using bx?

They adopted bip39 where the seed mnemonic is run through a key derivation function to derive the seed. This is an irreversible step.


Does the miner machine get any other type of reward except confirmation of transaction in bitcoin?

As a result of mining, miners receive income from two sources

The mining reward per block, which halves approximately every 4 years.
The transaction fees for the transactions the miner includes in the block.

Nothing else.
The miner includes as the first transaction in the block (the "coinbase" transaction) a transaction with no inputs and with outputs to one or more addresses of their choice with a total amount which is less than or equal to the sum of other included transactions fees and the current mining reward .


I believe your question is flawed. Consensus isn't about game theory, it's an agreement. While game theory is analysis of strategies dealing with competition. Yes game theory has been applied outside of gaming. It's been used in war, business, even biology. Also it's not far from decision theory. While each individual in a consensus may have opinions facts to validate their positions they're still being judged by people. Game theory attempts to reduce decision making to mathematics, but ultimately we're talking about people here not calculators. Sometimes your best answer is just to eat the grapes & not pick side A or B. Meaning sometimes during a competition there is a winner. In consensus it's not always about a winner as much as it's about reaching an effective agreement which may be a 3rd option not yet revealed. Ultimately people can be irrational & do unexpected things.


Is Bitcoin a developer only currency and community?

Disclaimer: I'm one of those 7 people.

It is true that changes to this one particular code repository, and the releases of the Bitcoin Core software built from it are ultimately controlled by a few people, and many miners run this software.

However:

Bitcoin Core is not the only software interacting with the Bitcoin network. There are other node and wallet implementations.
You can run a modified version, or you can fork the code and maintain a branch yourself if there are features or changes you'd rather see.
Even with Bitcoin Core powering the majority of full nodes on the network, its developers can't directly change the core protocol rules. If a change was controversial, people can (and should) refuse to upgrade. Ultimately, it is the people deciding to run a Bitcoin node that indirectly set the network's requirements.
Miners do not set the rules. This is a common misconception; many people think the longest chain created by miners is the one that gets accepted by the network. This is not correct: it is the longest valid chain that wins. Every full node - including non-miners - verify the transactions in the chain and will simply ignore a chain with faults.


The same problem occured on my Ubuntu 16.04 with Bitcoin v0.15.1.

After some investigation, I found the reason is that the file(init.md) is out of date. Ubuntu has used systemd instread of upstart since 15.10, while the section of ubuntu in that file don't update in time.

It's sure that the lastest modification is 2015-08-04, which is before the release date of Ubuntu 16.04.

$ git blame -L94,97 doc/init.md
234bfbf6 (Adam Weiss   2014-07-31 11:56:17 -0400 94) 4c) Upstart (for Debian/Ubuntu based distributions)
234bfbf6 (Adam Weiss   2014-07-31 11:56:17 -0400 95)
fc25a874 (unsystemizer 2015-08-04 14:10:51 +0800 96) Drop bitcoind.conf in /etc/init.  Test by running `service bitcoind start`
234bfbf6 (Adam Weiss   2014-07-31 11:56:17 -0400 97) it will automatically start on reboot.

The section, "4a) systemd", is valid, which works on me.

Reference

What's New in Ubuntu 16.04 : The systemd Init System
How to identify which init system you are currently booting with


I am Curious about bitcoin testnet. Since there is a massive change in bicoin mainnet i.e. https://bitcoin.org/en/alert/2017-07-12-potential-split

The change on mainnet does not effect testnet at all. The mainnet change is to activate segwit. However testnet has had segwit for the past year and a couple months.

  Will Testnet4 be there and Testnet3 completely wipe out?

No.

  I just want to perform mining on Testnet. As some people are mining with ASIC even on the testnet and increased the difficulty. If so happens then it would be great to have 0 difficulty again.

There is no such thing as 0 difficulty. The minimum difficulty is 1. Testnet3 has provisions to ensure that it is always mineable by someone. If a block is not found within 20 minutes, the difficulty will drop to 1.


Why are some Bitcoind commands comparatively slow?

For example, running bitcoin-cli getbalance <address> on an arbitrary, watch-only address takes around 6-7 seconds for a response. Is there any way to improve this?

Besides the fact that this is not how getbalance works (you don't call it on an address), getbalance is slow here because it must go through the list of transactions for the addresses in your wallet and sum their outputs to get the balance. If your wallet is very large and has lots of transactions or you are running bitcoind on low powered hardware, this could take a long time.

  How do API services like Blockchain return balance details almost instantaneously? Each API call to Blockchain takes less than half a second for a balance request. Is there a way for me to do that?

Those API services have several large servers hosting their databases. Their databases are massive and index everything in the blockchain. They store information like the balance of each address (which is technically not in the blockchain) so when you ask for the information, it is pulled from the database very quickly. Bitcoin Core does not do this as such databases are a waste of space and most users will not be affected by the slower functionality.


What are the different kinds of Lightning routing nodes?

Alex Bosworth discusses different kinds of routing nodes he has observed on the network in this presentation at a Lightning Hack Day in March 2021. He classifies them as follows:

Ping Pong Routing Node (Bi-Directional Payments)
Liquidity Battery Routing Node (Slow Ping Pong Payments)
Inbound Sourcing Routing Node (Provide Liquidity to Drains)
Liquidity Trader Routing Node (Predict the Future, Provide Reliability)
Last Mile Routing Node (Connect Users to the Network)

A ping pong routing node stays balanced due to routing regular bidirectional payments and only requires operational costs. It avoids the fees required to rebalance channels. In reality, these are rare as there are at least delays between the bidirectional payments and hence periods where channels aren't balanced.
A liquidity battery routing node is more common as it routes bidirectional payments but encounters time delays and periods where channels aren't balanced. It needs sufficient capital to withstand these periods and avoid being drained. Due to the higher capital requirements they potentially have the opportunity to charge higher fees than ping pong routing nodes. These routing nodes also require monitoring of onchain fees to determine when it is affordable to use the chain to rebalance their channels.
An inbound sourcing routing node seeks opportunities to consistently provide liquidity to drains (ie exhausting their inbound capacity with regularity). Capital is only flowing in one direction and this routing node has to manage that and actively rebalance. However, this routing node does get to identify stable routing opportunities with medium fees where there is demand to route to the drains (e.g. merchants) and potentially buy channel capacity to serve periods of increased demand.
A liquidity trader routing node is the most opportunistic of routing nodes as it moves around the network opening channels or buying channel capacity in the short term to take advantage of information that isn't publicly available. It chases high routing fees and hence is information intensive as well as channel management intensive. If its information isn't accurate it risks making higher losses as the costs of channel opening and purchasing liquidity mount up.
A last mile routing node actively tries to connect end users to the Lightning Network rather than being one of the central nodes in the route. These routing nodes need to understand and monitor what the end users' needs are because otherwise they risk their capital being stuck in a channel that isn't being regularly utilized (i.e. no routing fees). It is also critical (even more so than for other routing nodes) that these routing nodes are online 24/7 as they may be the end users' only connection to the rest of the network.
(Being an effective routing node and generating profits from being a routing node is challenging and especially when starting out one should see it as experimentation rather than an investment with reliable returns. Do not experiment with more funds than you can afford to lose.)


Trying to open an old bitcoin core wallet.dat file fails

There are probably other ways, but I tried this a while back with an old wallet.dat from ~2013 and it worked. You can download the Bitcoin Cash release of Bitcoin Unlimited and open that wallet. Bitcoin Unlimited is the reference implementation of the Bitcoin Cash client that is a fork of Bitcoin core so it works with those wallets. To do any transactions you'll have to let it download and verify the blockchain and that takes forever, but it will work.

Once you have it synced, you'll see your balance (assuming you had a Bitcoin/BTC balance before the fork) and you can then transfer your Bitcoin Cash (BCH) to another BCH wallet or exchange (e.g. Coinbase/GDAX is a simple way to exchange now).


Mining behind a proxy and restrictive firewall (only http ports allowed) - possible?

After searching and searching I found these possiblites.

Use bitminter Java client in Version 1.1.2 http://bitminter.com/client/1.1.2/bitminter.jnlp (current version doesn't work)
Make your own miner which supports proxy
Use a tool like Proxifier (I have not tested it personally, because it is commercial)


How to check a signature on an arbitrary message?

No, this is not possible. There are no opcodes that allow you to check a signature on an arbitrary message.


Is BTC inherently much more energy-hungry than other currencies, or just been around longer?

other coins. Do they work fundamentally differently,

To secure the record of transactions, Bitcoin uses a type of mechanism called Proof of Work (PoW). Some other cryptocurrencies use any of several other mechanisms such as Proof of Stake (PoS).

BTC (and many others) rely on solving ever increasingly complex algorithmic problems

The complexity is not increasing. A "difficulty" target is adjusted that affects the number of iterations required. That difficulty target can go down as well as up.

BTC's energy use ...

The energy consumption of Bitcoin's PoW depends on the amount of computing power that miners have invested in. To ensure that new technologies and miners with deep resources do not become able to forge the transaction journal, Bitcoin increases the difficulty of Mining proportionally to the total computing power applied by miners. Mining is competitive so more powerful mining equipment provides a higher proportion of the rewards. So the energy consumption of the Bitcoin network is largely a reflection of the return on investment (ROI) that miners predict in their business plans. It isn't affected directly by number of transactions.
Transactions provide a transaction fee to miners, so the transaction rate and fee-rate has some influence on ROI.  However the transaction rate does not directly drive energy costs in the network.
To put it another way, if all but ten† miners left the Bitcoin network and those ten† only used one† small† PC each for mining, the transaction rate might not be affected and energy costs would be far far smaller. However, in the absence of any other limiting mechanism, the network would be insecure, a miner could step in and use overwhelming computing power to commit fraud.

† These numbers are not real, just illustrative. there is some minimal number that would be adequate to process current transaction rates if all humans were always honest, trusted all other humans in all circumstances, never had disagreements and never made mistakes. However Bitcoin was made for the real world and this requires some energy be expended to keep money secure


https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki

  Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).


Are hardlinks responsible for the bitcoin data directory appearing larger than expected?

The cumulative filesize of the bitcoind/bitcoin-qt directory has been a source of confusion since the introduction of v0.8 because it hardlinks multiple files within the directory. Briefly, two files point to the same data on the disk. So if you sum the size of the files, you don't get the total amount of data actually on the disk. In this manner, you can put 10GB of files on a 1GB USB, for example.

Can I resume a blockchain download?

Yes, absolutely

Is blockchain.info is updated?

Currently, yes.

Is the size of the bitcoin data directory easy to understand

Somewhat, you need to understand hardlinks. Your OS might double count some files, leading to confusion.


Restore Wallet From Jaxx to Coinomi: ETH missing (but BTC and LTC are fine)

Jaxx uses a different derivation path than Coinomi when handling ETH. Coinomi opted for the path as described in the ETH specification. Ledger has the same scheme as Coinomi.

Jaxx: M/44H/60H/0H/0
Coinomi: M/44H/60H/0H

You will have to do the following:

Delete any existing ETH wallets you have added by long pressing them (2 sec) in the Overview tab and clicking on the trash icon that appears.
Add another ETH wallet, but before clicking ADD, click on the gears icon next to the coin name in the coin list and then click on "ADVANCED SETTINGS" link on that popup, and enter this entire text in: M/44H/60H/0H/0 Then click add.

You should now see your ETH balance in Coinomi.


What exactly does the scary option "Allow incoming connections" do in Bitcoin Core?

There are two ways by which bitcoind connects to peers.
The default is purely outbound connections - the node will use DNS seeds, as well as its own database of previously seen peers, and attempt to establish connections to them as needed (upon startup, or when existing connections are closed).
Allow incoming connections allows you to return this favour - it lets other peers initiate the connection to your node, instead of all your connections only being with peers where your node initiates it (of course, on the other side of those connections, is a node with Allow incoming connections enabled).
These peer connections are used for syncing network state, such as blocks, transactions, and information on other peers.
Barring a catastrophic flaw in bitcoind's implementation, this is not a security risk.
Depending on your network setup, you may need to enable port forwarding in your router and/or local machine's firewall before enabling this option has any effect.


Here is what you need to do. Make sure you have the seed from multibit.

Download http://www.electroncash.org/
You create a new wallet, select I already have seed, when you type seed you need to click the "options" button and select BIP39 seed.
It will ask for a derivation path... you need to use: m/0' (note the ' it is important... m/0')
4.Suggest you do research as there are some issues with it not connecting to BCC chain sometimes.

http://reddit.com/r/btc/comments/6qyn18/electroncash_notice_how_to_select_bitcoincash/


How can I migrate from blockchain wallet to Electrum?

These steps are for new Blockchain.info wallets based of BIP39 seeds.
If you have previously imported private keys to blockchain.info they have to be exported separately, as they are not part of the keys derived from the seed.

Get your blockchain.info seed. Login to your blockchain.info account, click on 'Security Center' then click on 'Backup Phrase'. Be aware that onced the phrase is backed up, you won't be able to access it again on blockchain.info. So note it down carefully.
Start Electrum, choose to restore a standard wallet, then restore from seed, enter your seed, then click options and check the 'BIP39 seed' box. -> Click Ok/Next.
Blockchain.info follows the BIP 44 standard for derivation paths, so the default account has a derivation path m/44'/0'/0'/0
You should now have migrated to Electrum.


How can you calculate the inverse of S component of signature, while you cannot do it in ECC to calculate private key from public key?

The semantics of multiplication are different in your two equations.

As for the first equation. The s-part of a signature is an element in a group (represented by a number) so the inverse exists and is easy to compute (or even well known)

In the second case you take the numerical value of the private key and compute the multiple of this with a base point. With that notation the "inverse" becomes equivalent to finding the discrete logarithm in this additive group. In ecc it is not known how to compute the discrete log efficiently

I guess this answer is somewhat frustrating. I recommend learning about Groupe theory to understand the differences in notation.


Have you ever thought of looking through your host's Acceptable Use Policy regarding CPU usage? You're breaking their terms so it's no big surprise that your process keeps getting killed. I'm honestly surprised that you haven't been suspended yet for it. To quote:

CPU Usage
Every vps comes with a number of CPU cores that client has access to. The said CPU cores are not dedicated to any vps. Client may not use more than 85% of one CPU core per process thread for more than 10 minutes. Client may not use 100% of one CPU core for more than 2 minutes. When CPU abuse is detected by our automatic programs, process will be killed and/or vps stopped/suspended, and the above Resource Abuse policy will be enforced.

Find a host that allows cryptocurrency mining, or even better- rent a dedicated server.


I'm not able to mine as much Bitcoin as I was able to a couple of months ago

As more people contribute to mining, Bitcoin automatically adjusts the "difficulty" so that the number of new bitcoins created by mining is roughly the same over time. The difficulty has increased rapidly in the last few months, and in fact it has nearly doubled since November 2015. This matches with your performance numbers. Your existing hardware will become less useful over time.


How to make a Hidden Tor Bitcoin Mixing Service?

BitcoinFog is popular and has been around for a few years. If you really want to make your own, you'd need a dedicated server, Tor (for the hidden service), web server software like Apache, and Bitcoin-Qt (or some other bitcoin software which can be interfaced with through PHP). To have it be really safe, you'd need to set in place other precautions like a firewall or a separate server running Bitcoin-Qt.


Bitcoin QT - why do I have an undefined reference to `qInitResources_bitcoin() error

The root cause of the error is likely related to the Qt Resource Compiler (rcc), which is generally called earlier as part of the bitcoin compilation process. The rcc generates the src/qt/qrc_bitcoin.cpp file from the src/qt/bitcoin.qrc resource file.
Unfortunately, the compilation process is not halted, if the rcc encounters an error when operating on the resource file. Instead an empty src/qt/qrc_bitcoin.cpp file is created. qInitResources_bitcoin() is never defined and hence will be missing during the linking process.
A common source of errors are missing assets in the qt makefile (ensure listed assets in src/qt/bitcoin.qrc are also included in src/Makefile.qt.include.


Can someone help me understand what these scripts mean?

PUSHDATA(71): Pushes the next 71 bytes onto the top of stack
PUSHDATA(33): Pushes the next 33 bytes onto the top of stack
DUP: Pushes a duplicate of the top stack item onto the top of the stack
HASH160: Pop the top stack item off of the stack, hash it using SHA256 then that hash with RIPEMD160, and push the resulting hash to the top of the stack
PUSHDATA(20): Push the next 20 bytes onto the top of the stack
EQUALVERIFY: Check that the top two stack items are equal. If they are, do nothing. If they are not, immediately fail execution
CHECKSIG:Pop the top stack item and interpret it as a public key. Pop the next stack item and interpret it as a signature. Check that the signature verifies to that public key when the message that is signed is a modified version of the transaction containing the signature. If the signature is valid, push OP_TRUE to the top of the stack. If it is false, push OP_FALSE to the top of the stack.

A full description of all script opcodes and their actual byte values can be found on the Bitcoin wiki.


How to confirm how many peers a node has?

When a node requests one of it's neighbours for a list of it's peers, that node responds with a list of all of it's neighbours.

No it doesn't. It responds with list of nodes that its aware of being claimed exist.  It likely isn't connected to any of the nodes it returns and probably has never connected to many of them. Many of them may not even be real. (though some of them will be, because it does make an effort to include at least some that it has previously connected to)

There is no direct way to get information about a node's peers, and ways to do so are considered a security compromise (if not the most cosmically critical one).


Golang how to derive address from bip32's xpubkey?

Take a look on https://github.com/wemeetagain/go-hdwallet

// Generate a random 256 bit seed
seed, err := hdwallet.GenSeed(256)

// Create a master private key
masterprv := hdwallet.MasterKey(seed)

// Convert a private key to public key
masterpub := masterprv.Pub()

// Generate new child key based on private or public key
childprv, err := masterprv.Child(0)
childpub, err := masterpub.Child(0)

// Create bitcoin address from public key
address := childpub.Address()

// Convenience string -> string Child and ToAddress functions
walletstring := childpub.String()
childstring, err := hdwallet.StringChild(walletstring,0)
childaddress, err := hdwallet.StringAddress(childstring)


When importing the mempool, my debug log mentions failed and expired imports

You can't, and you don't have to.

Since Bitcoin Core 0.14.0, the mempool is saved to disk at shutdown, and read again in the background at startup. This helps in quickly establishing a realistic mempool to help with fee estimation and compact block relay.

However, time likely has passed since the mempool was saved and when the import happens. New blocks may have been created since, which likely contain many of the transactions that are being imported. Those will not be acceptable again to your mempool, and they will be listed as failed. Other reasons may include feerate changes, or conflicting transactions that were mined. Since the mempool import happens in the background, some part of it likely gets imported after processing the blocks with whom those transactions conflict.

Transactions that are older than the mempool expiration setting (default: 14 days) don't get imported either, and get listed as expired.


Tutorial on how to import a paper wallet into blockchain.info and send a transaction with message attached then delete it?

I know it's a few months since you've asked, but just in case someone else is looking for it. If you have a paper wallet, the easiest thing is to import it into a desktop wallet, and from there you can send your BTC to someone or to an exchange or to another wallet, like the one on blockchain. Some online wallets allow importing the private key but the one on blockchain doesn't seem to - at Least I haven't found a way after looking around.


Embedding P2Pool technology in Bitcoin Core

However, as far as I understand, new versions of Bitcoin will soon provide pruning capabilities, therefore allowing miners to only keep unspent outputs (without the entire chain) up to certain blocks, which drastically reduces the amount of space needed to verify transactions.

This has been the case since 0.8.0. The new addition is just to remove the requirement to keep block files around, which were only ever used for serving to other peers and for wallet rescans anyway. Incidentally the pruning function is incompatible with the current wallet, which would make P2Pool operation a bit difficult until it has been patched for operation with its own wallet system.

  With all these new developments, wouldn't it make sense to embed P2Pool sort of technology inside Bitcoin Core itself, or are there bigger limitations that I'm not aware of?

It would have made sense in 2010, less so now. P2Pool has extremely high share difficulty which frustrates small miners, and it has all but lost all of the momentum it might have had a few years ago. Unfortunately it is also written in Python, which makes it a little lethargic and not suited for inclusion without a complete rewrite.

The mining landscape is also a lot different to even a year ago. Home mining is all but non existent, and most of the hashpower is concentrated under the control of as many people as would fit in a small elevator car. Those with miners will often have brands who have released hardware that actively damages P2Pool by discarding valid blocks (a sort of unintentional block withholding attack). Most mining hardware include small single board computers of some description which are underpowered even for stratum mining, which means the person needs to keep another full sized computer around to run a node on, which is apparently undesirable.

The budget for P2Pool development is almost zero as a result of the combination of all these factors. It would have been nice if this was a core part of Bitcoin to begin with, or something similar. Perhaps things would be different now if it had.


Data for time a transaction spent in a pool before it got added to a block

Kind of.

There is no "the pool" or "the mempool" (which is what I assume you are talking about when you say "the pool"). Rather each node maintains its own mempool which may be different from another node's mempool. Because each node receives a given transaction at different times, the amount of time a transaction spends in the mempool will also vary from node to node.

However, you can still run a node and track how long a transaction spends in its mempool before being included in a block. In fact, Bitcoin Core already does this in order to do fee estimation, although the raw data is not exposed to users.


Is the purpose of proof-of-work the immutability of the blockchain?

Immutable transactions are a consequence of blockchain-based systems when the following are true:

There is a cost (in currency and in acquiring materials) of producing a block consistent with the rules of the protocol, and this cost cannot be circumvented
The cost is great enough where incurring this cost to increase the length of the blockchain is more profitable than incurring this cost to fork the blockchain
As part of the rules of the protocol, past transactions cannot be altered by future additional data

Proof of work fits into this because it is provably costly. It requires energy, and it also requires development time and materials to create machines that use this energy efficiently. This cost prevents forks from being supported, as you have limited energy and you can only use that energy once.

This contrasts with Proof of Stake, or an IP based voting system because a lack of energy requirement means that there an incentive to support all forks. This is referred to as the Nothing-at-stake problem.


Relation between bitcoin address/private keys size and number of characters?

There are many types of Bitcoin addresses. Your example specifies (legacy) pay-to-pubkey-hash (P2PKH) address defined by Base58 check encoding and Wallet Import Format (WIF) which is also specified by base58 check
Base58 encoding treats the entire input payload as a big-endian big integer. Consider these alternate examples:
Input value: bc in ASCII: 0x62 0x63 (2 bytes) interpreted as a 2-byte int and encoded without leading zeros...
base 2: 110001001100011 (15 characters)
base 10: 25187 (5 characters)
base 16: 6263 (4 characters)
base 58: 8VG (3 characters)
So going forwards we know that for this example it took 3 base58 characters to encode two bytes. Lets run it backwards and try minimum and maximum values:
base 58, maximum value with 3 characters zzz encodes three byte value: 0x02fa27
base 58, minimum value with 3 characters 211 encodes two byte value: 0x0d24
Conclusion:
From this example alone we discover that we can not determine the length in bytes of the original value based just on the length in characters of the encoded string.
Bonus:
Modern addresses are now encoded with bech32 and represent Segregated Witness programs. The bech32 spec is defined in BIP173 and look like this: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
bech32 encoding does not use interpretation as big integers and instead maps input bytes more directly to output characters:

The data-part values:

1 byte: the witness version
A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:

Start with the bits of the witness program, most significant bit per byte first.
Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
Translate those bits to characters using the table above.

As a result of the previous rules, addresses are always between 14 and
74 characters long, and their length modulo 8 cannot be 0, 3, or 5.
Version 0 witness addresses are always 42 or 62 characters, but
implementations MUST allow the use of any version.

So in summary, with a bech32 address you can determine the length in bytes of the input value based on the length in characters of the encoded string:
In bech32, each character represents 5 bits


Is it possible to spam the bitcoin network with 'dust'?

Such transactions will be subject to fees.  You can read about the fee schedule here.  The fees apply if the transactions send a small amount of coins, or send the same coins over and over (giving the transactions a low priority score).

The fee is set at BTC 0.0001 per 1000 bytes.  Thus someone who wants to spam the block chain with 10 MB will have to pay at least BTC 1 in fees.  That's about US$500 at today's prices, and it causes the block chain to increase in size by about 0.1%, which nobody will probably even notice.  If you're going to spend $500 on mischief, you'll get a lot more bang for the buck by spending it on eggs and toilet paper!


Is bitcoin arbitrage profit varies with BTC market price?

If you want to make money on arbitrage like this, you should have reserves on both exchanges, and at the moment when you are buying in btc-e, you should sell at cryptsy (for example). Otherwise te price can change to "wrong" direction when you are transfering bitcoins from btc-e to cryptsy or vice versa. Also, you should understand how to withdraw/deposit fiat to this exchanges fast with minimal expences, that can be the biggest issue especially for btc-e.


Multibit saving after transaction - what do wallet private key backups look like, if they exist?

In multibit, under the help menu option you can open the help contents. Under Wallet Backups you can read the following:

  MultiBit does this automatically in the background using special files that are described in detail in the File descriptions article. These files can often be used to recover your wallet automatically should a problem occur.

In the File Descriptions article you can read the following:

  For the purpose of illustration, imagine you have created a new wallet called saving.wallet. Please refer to the relevant help section for your version below (use the 'About MultiBit' menu option if required).

  Wallet files for MultiBit version 0.5.13 and later

  Here is a list of the files stored with your wallet:

  saving.wallet  =  This is the main wallet file containing your    private keys and transactions.
  saving.info  =  This file contains the    description of the wallet and the labels you have given to your    addresses.
  saving-data  =  A directory containing your wallet backup    files.
  saving-data/key-backup  =  A directory containing your    automatically generated private key export files.
  saving-data/rolling-backup  =  A directory containing your rolling    wallet backups.
  saving-data/wallet-backup  =  A directory containing    your encrypted wallet backups.
  saving-data/wallet-unenc-backup  =  A    directory containing your unencrypted wallet backups.

  Private key backups. In your private key backup directory you will have files called 'saving-YYYYMMDDHHMMSS.key'. Here the YYYYMMDDHHMMSS
  is a timestamp. With an encrypted wallet every time you add or change
  the password, add a receiving address or import private keys an
  encrypted, timestamped export of your private keys is created. This is
  encrypted with your wallet password. You can use these to recover the
  essentials of your wallet by importing one of these files into a new
  wallet.

This should at least put you in the right direction.


When should I use -reindex-chainstate and when -reindex

-reindex:

wipes the chainstate (the UTXO set)
wipes the block index (the database with information about which block is where on disk)
rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index

-reindex-chainstate:

wipes the chainstate
rebuilds the chainstate using the blocks in the index you had before

The latter should be strictly faster, as it does not need to rebuild the block index first. Perhaps the progress bar during reindex confuses you: that progress is only for the rebuilding of the index. The recreation of the chainstate happens after that rebuild is completed.

You should use -reindex only when you were running in pruning mode, or if you suspect the blocks on disk are actually corrupted. Otherwise, when you only suspect corruption of the chainstate (which is far more likely), use -reindex-chainstate.


Replay attacks: can a coinbase transaction be replayed?

Short answer: No.

Longer answer: depends on the rules of the B chain.

A coinbase transaction creates coins out of thin air, but is typically only valid if the block itself is valid. Typically if the block is valid on chain A it's not valid on chain B: because a block usually points to it's previous block, which should be on the same chain.

On the other hand, the rules of B chain can literally be anything, as crazy as the creators imagination allows. If the B chain is specifically designed to also allow A blocks, then the answer would be yes. But the coins would still belong to the miner, so it's hardly an attack.


Deduct transaction fee always from 1 receiver address if sending some BTC amount to 2 different receiver addresses in single transaction

There is no concept of 'which address is paying the fee' in a Bitcoin transaction.

Instead, transactions are constructed as follows:

One or more UTXOs are specified as inputs. These UTXOs are spent in their entirety
New UTXOs are created as outputs. Each one is of a certain value, and pays to a certain address.
The difference (value of inputs - value of outputs) is the implied miner's fee.

So, it is up to whoever crafts the transaction to allocate Bitcoin to each newly created output in a way which satisfies the socially agreed upon transaction conditions (ie, "decide who is paying the fee, and then deduct the fee from the newly created output they will own").


Is there a way to find the coinbase for a given block using only bitcoind commands?

I think this is best answered by an example. Let's find the coinbase from a block on the Bitcoin testnet.

First we'll get the hash for a block we want to look at. We'll have a look at the (as I write this) latest block:

> bitcoind getblockcount
81626
> bitcoind getblockhash 81626
0000000000834f3933b50577b854692ed246728a17d10006ced1283a3fd8074c

Now we need to find the hash of the generation transaction from that block. It's always the first one listed. In this example there is only 1 transaction.

> bitcoind getblock 0000000000834f3933b50577b854692ed246728a17d10006ced1283a3fd8074c
[...]
    "tx" : [
        "f1fdeb7ced28f697c97b6a3ed7cc1946e1fc5e062ad8c17d05c88b1767b91b2a"
    ],
[...]

And now we can grab the coinbase from the transaction. The getrawtransaction command's second parameter can be set to 1 to give us individual pieces of the transaction so we can easily find the coinbase. Alternatively we could leave that out and it would give us a single binary blob to navigate ourselves.

> bitcoind getrawtransaction f1fdeb7ced28f697c97b6a3ed7cc1946e1fc5e062ad8c17d05c88b1767b91b2a 1
[...]
"coinbase" : "03da3e012cfabe6d6d18c47c97379852a93158528bb709355a0d38d05fedf072b610bb57442aad4e710400000000000000062f503253482f",
[...]

And there's the coinbase. Now we can check whether it contains pieces of ASCII text or whatever else we want to do with it.


Download the bfgminer source code, extract the source, change directory into it.

Then:

$ dpkg-buildpackage -uc -us -rfakeroot

And it'll build a package you can install on Debian Wheezy. You will need to install "dpkg-dev" for dpkg-buildpackage and all the build dependencies, which you'll find out by running the dpkb-buildpackage command.


Are there any altcoins that have tried a contentious hardfork?

Only example that comes to mind is Elacoin. Steve Sokolowski covered the fork in his forum post on the block size increase debate:

Everyone can veto the change
A common misconception about this block size increase is that miners will make a decision about whether the change is accepted or not. Miners only have the power to prevent a hard fork, but they cannot force its acceptance even if they mine new fork blocks.
To see why, consider the story of Elacoins. Elacoins were a proof-of-work altcoin created several years ago. After some initial interest, activity declined until there were no more development updates, and difficulty plummeted. However, after about six months, a new developer came onto the scene and decided to fork Elacoin to be proof-of-stake. He released a new version with great fanfare and many future stakers arrived to use the new coin. He set a date in late 2014, at which the chains would diverge. In anticipation of the upcoming change, volatility increased and trading volume rose dramatically.
Exchange Cryptsy, seeing the trading volume, had no reason to make any change to its market, and CEO Paul Vernon ignored customer support tickets from the new Elacoin developers. As price rose in anticipation of the fork, difficulty also rose. The date of the fork came and went, and price continued to rise - but Cryptsy did not upgrade its daemon. As a result, mining continued on the old fork. Huge buy orders of 5+ bitcoins appeared. A large group of people continued to stake the new fork, but the only people who actually mattered - Crypsty, ignored their tickets. Eventually, the hard fork was declared a failure and Elacoins continued to be traded and mined using the old fork, despite almost every user, developer, and staker wanting to use the new fork.
This story demonstrates that exchanges, not miners, will also decide whether to accept any proposed changes. In fact, almost anyone can veto a hard fork. Just 20% of miners can decide not to mine the new blocks, and the fork fails. Just one massive exchange (Coinbase, or the Bitcoin Investment Trust) can continue trading the old fork, and the fork fails. A few of the richest coin owners, like Tim Draper, can decide that they will continue to make their bitcoin investments on the old fork, and the fork fails. Big merchants like Overstock and Microsoft announce that they will only accept the old fork, and the fork fails.
Miners do not have the final word, or even a significant choice, in whether the fork succeeds. There are several lessons to be taken from the Elacoin story: first, miners like Slush and Luke Jr. do not have the power to cause this fork to happen, only to block it. Second, exchanges are more important than miners in whether the fork succeeds or not. Third, a bare majority of people accepting the fork is not sufficient for it to happen, since the default decision is to fall back if it looks like there is even the slightest chance of failure.


How to verify ASICMiner share ownership through Bitcoin address / blockchain.info?

Go to https://blockchain.info/address/16fuoinLFjBmiCYmCYDXPNfERJtdPB5ASe

Check if the same address as he has signed the message with is on that page. This will only tell you that he had the shares the moment the dividend was paid.

Or you can ask friedcat on bitcointalk.org to confirm the ownership of shares.


The coin shuffling feature is on the product roadmap but I don't know when it will make to the mainnet:
https://bitbucket.org/JeanLucPicard/nxt/issue/135/coin-shuffling-monetary-system


How would a decentralised exchange work?

It is possible, and not conceptually difficult, to extend the way ownership of Bitcoin is determined in a decentralized way using the blockchain to more complicated constructs such as the ownership of other things or the commitment to contracts, including offers to trade at certain prices. Yet there are two nontrivial issues a decentralized exchange, or its underlying protocol has to solve: How to enforce trades (solving the counter-party risk any exchange has), and how to detect if a trade has occurred.

Obviously there are many ways all of this could be settled. For example, exchanges in real finance leave fulfillment and enforcement to the trading parties and the authorities, but that has huge real-world problems even with a limited number of tightly regulated and registered participants that one may hope to avoid in a decentralized approach.

There is a simple solution for exchanging (specially designed) cryptocurrencies where ownership and contract fulfillment is determined by a blockchain. At least typically, protocols enabling a decentralized exchange include at least one such cryptocurrency, such that as a partial solution an automatic escrow can be implemented. But full automation requires that the ownership of the other currency involved in the exchange can also be automatically established, i.e. it must also be some kind of altcoin.

To extend this to cover fiat currency, there must be some form of agreement to honor the obligation to transfer fiat and to reflect its completion in the decentralized exchange. Sadly, this is at the core of all kinds of blockchain-based contracts: How do we get them to be enforceable, ideally by becoming legally binding? I see two possibilities:

Limit trading to participants that sign some kind of real-world contract to honor them in a way that makes them legally enforceable. This has the problem of being difficult to do in a truly decentralized way, unless legal systems start to recognize at least some kind of digital id and digital contracts.
Require some kind of security deposit to be confiscated in case of breach of contract---possibly from both sides of a contract or exchange-brokered trade, to remove profitability for both sides in the event that one party fails to deliver a fiat payment or that the other party fails to admit having received it. Sadly, designing a system where it is ensured that no kind of fraud pays off is not easy and may require a very large security deposit, giving this approach severe disadvantages as well: A cyber-troll willing to suffer a loss could cause someone else to suffer an even larger loss (and potentially blackmail such a victim into letting the troll get away with a profit), and potential users wanting to use the exchange because they need cryptocurrency may find it difficult to cough up a cryptocurrency-based security deposit.


That error likely means that you have not done a git pull or git fetch. Those are required so that you can pull down the latest source code and tags so you can then do git checkout.


How to cash out a Bitcoin wallet into fiat anonymously?

If bitcoin is converted to fiat money on an exchange, the exchange has irrefutable knowledge of your identity because they require the account name and bank account name to match.

Use Bisq and other non-KYC Exchanges. Also follow the best practices mentioned in this comment:

Don't reuse addresses.

Use coinjoin and payjoin when required.

Run and use your own full node (with Tor), open source block explorer etc.

Use an open source bitcoin wallet with active development: https://bitcoinwallet.guide

Do not share information about your transactions on social media


Although certain releases perform database upgrades, the upgrade is handled by the bitcoind binary - updating a node only requires changing the binary, regardless of whether you downloaded a prebuilt one or compiled it from source.

If any additional changes to the bitcoin data are required, the updated bitcoind will perform them when it starts.

If you are downloading a prebuilt binary, make sure you get it from a reliable source (such as bitcoin.org) and verify the signatures to make sure it has not been tampered with.


Buy bitcoins with my regular AMEX (american express card)

You can try virwox.com but it will also depend on the country that you choose for sign up. I know that when you use Germany as the country for sign up, you can pay with AMEX but you will have to covert to SLL first before you can get the bitcoins. I hope this helps eventhough you asked this question long ago!!


Is it possible to make a transaction with no transaction fee?

As Raghav Sood noted in a comment, transactions with no transaction fee are not transmitted by standard Bitcoin nodes - so your zero-fee transaction normally won't reach a miner. In theory you could make some special arrangement with a miner but it's hard to see why they would want to do that.

  Is it possible to pay more fee to prioritize your transaction?

Choosing a higher initial fee tends to result in quicker confirmation. If your wallet supports Replace By Fee (RBF) you can use that subsequently to improve the likelihood of a quicker confirmation.


How do you deploy a Bitcoin-Cash full node on a Cent OS 7 server?

Follow this deployment guide.

https://github.com/CanadianRepublican/BitcoinCash-Daemon-Deployment-CentOS7

it includes a systemd service file, and a logrotate configuration file


Which Bitcoin thin client that can execute on restricted IoT devices?

you could use a SVP  Client/wallet like discussed here : What is an SPV client?

IOT is a wide space, you could specify the technical features of your IOT to get the right help, a raspberry pi for example could be considered as an IOT and it could host a full or a light node.


For example, a blank input could be used to guarantee a particular output was included in a transaction, using SIGHASH_SINGLE | ANYONECANPAY in combination with SIGHASH_NONE.

You cannot use SIGHASH_SINGLE | ANYONECANPAY in combination with SIGHASH_NONE. You cannot have two or more of SINGLE, ALL, NONE on a single input, they can only be combined with ANYONECANPAY.

Moreover, if you are able to create a zero value (or even dust output), that single output alone will be enough to enforce the rule "If you use this output, you must send X BTC to this address". However, if you have a zero value or dust output, no one is really incentivized to include it - after all, you aren't contributing any significant value to the tx. In fact, you are raising the fee due to the extra input/output size. People will just drop your input and output and build a tx without it.


Detailed overview over old exchange rate

One of the best sites I've found is Bitcoincharts.com. The charts allow you to see Bitcoin prices from its entire history or down to the hour. It allows you to view the prices on different exchanges and markets too.


Is there empirical data about a relationship between bitcoin price and difficulty?

If you look at the network hash rate, you'll notice that it fell off after the Bitcoin exchange rate dropped.

This leads to the conclusion that price drives difficulty. A drop in price caused a drop in difficulty. I have noticed this same correlation on another occasion; about two months ago.

Also, the reverse is probably true. When the price soared to $30+; the network hash rate accelerated greatly. The higher prices clearly attracted miners.


Why does Antpool mine so many empty blocks?

This article gives a nice summary of potential causes and solutions to empty blocks mining: https://bitcoinmagazine.com/articles/decline-empty-blocks-has-increased-bitcoins-transaction-capacity/.
AntPools may just be late at implementing the solutions...


Alice has 500$

It is better to suggest "Alice has 500 mBTC" because amounts in the blockchain are not dollar-denominated.

  Miners who got the chance to validate the transaction has to check whether alice have sufficient balance or not.

No they dont.

Miners don't care about balances.

Miners only care whether Alice has provided proof¹ that she holds the private keys required by the scripts in the transaction inputs.

Other nodes validating blocks also don't care about balances.

In accounting terms, the blockchain is a transaction journal, not a ledger. It does not keep track of balances held by people. By processing the journal you can calculate a current amount for each Bitcoin address. Note that not all transactions use Bitcoin addresses. These addresses are merely an artifact of certain commonly used scripts. Scripts don't have to contain data that is conceptually an address.

  where are these alice and bob balances are stored?

Not in the blockchain.

  how balance is retrieved?

It isn't, not by miners and no one other than Alice ever retrieves Alice's total balance.

  Does entire block chain is searched to find their balance and validate and update?

No.

  or block where these balances are stored is kept track any where else?

No.

Alice's wallet might keep a separate record in memory and committed to local disk in some proprietary form. That would probably be sensible for performance reasons but is not required..

Footnotes

Proof

When Alice uses her wallet to pay 500 mBTC to Bob, her wallet checks its list of unspent transaction outputs (UTXOs) for the bitcoin-addresses that Alice has contol of in her wallet. It uses as many of these as are needed to add up to 500 mBTC plus the selected transaction fee. It constructs a transaction which lists these selected UTXOs as inputs and lists outputs including a 500 mBTC output to one of Bob's bitcoin-addresses and an output to one of Alice's bitcoin-addresses for the unused "change". The transaction includes cryptographic "signatures" made using Alice's private key(s) which proves she controls those UTXOs used as inputs and which can be checked (validated) by other people's wallets by using Alice's published public keys. These signatures by ALice's wallet satisfy the Bitcoin-scripts that are part of the UTXOs which Alice's wallet is using to make the payment.

Note that there is no need to calculate a sufficient balance. When Alice pays Bob $17 using a $10 note† and two $5 notes, Bob doesn't need to know haw many other dollar notes Alice has in her purse. He just needs to check the notes she gave him look real. Alice needs to make sure she gets $3 in change.

† US: bill; Rest-of-English-speaking-world: banknote.


Is it secure to put a wallet address on one's business cards as a QR code?

that's not a bad idea in regards of doing business and distributing it to people. however, as far as I know, a single address is fine because the address itself is secured. the security flaw of a single address distributed will be - people can check the addresses on how good your business is doing. hehe. correct me if I'm wrong. Wishing you all the luck with your business.


Can one mine bitcoin without including transactions and get accepted by network?

The answer was yes few years ago. Does it still apply as per 2020?

Yes, changing that would be a consensus change and require a fork of some kind.

If so, why I cannot find any blocks with no transactions recently?

Because it's more profitable to include transactions. Miners want to make money, and with the diminishing block subsidy, they will want to collect as much in transactions fees as possible, so they have to include transactions in their blocks.

Is it not easier to mine blocks with no transactions?

The amount of transactions in a block has no effect on its difficulty. It may be nominally "harder" because a bit more logic needs to be done to collect and choose the transactions to include, but this is negligible and the fees collected far outweigh any benefit to mining empty blocks.

Also, if it still applies, are there any mining software that would allow it? Cgminer and bfgminer are so old, are they still in use and what are you using guys?

AFAIK, both cgminer and bfgminer are still maintained. Old does not mean bad. They can mine empty blocks if whatever node provider they are connected to gives them empty blocks to mine.


How do we know that the algorithm of Bitcoin does not embed bugs since inception?

I'm going to answer your questions directly although I know you've selected another answer. It's for all those who come across this question.

  How do we know that the algorithm cannot be modified to gain control over the expansion of the monetary base?

These are part of the config settings of the Bitcoin protocol. It can be changed but all you would be doing is changing your own node. You would have to convince all the other nodes to change their settings too and additionally you would have to be able to mine coins faster than anyone else to guarantee that you were generating the coins. Without getting too technical, this is the power of a p2p distributed network, the crowd matters, not the individual.

  After all, I don't think that there exists a man-made software that cannot be hacked.

Nobody is saying that one day in the future we won't find a way to hack the security of bitcoin. But if we do then everything is broken, including the internet. The type of security that is used to send your bank details between servers, or when you log in to secure https websites relies on the same type of security. Even the NSA rely on this security. But if it does happen, we just move to the next level, and send our coins to a new address. (It's a little more complex but I summarise).

  Many discussions on this forum flag that suck[sic] a type of attack would be extremely expensive if not impossible. However, how do we know that such type of bug isn't already in the algorithm? See question 3

We know because anyone can look at the code. It's open source. If someone found a bug it would have been exploited already, it is the biggest financial prize in history, you don't think people are trying all the time? They have been trying for 5 years. It may happen if and when a new function is added which is why the core developers need a lot of support from the community.

  How do we know that Satoshi hasn't left a bug in his software (or purposely left out some important protective codelines) that will allow him to artificially steal or claim bitcoins at his/her discretion? After all, Satoshi, the inventor of the software has not revealed himself (or herself).
  Even if Satoshi did not actually steal the money for himself, but simply left an option for himself to increase/decrease the speed of expansion of the monetary base, that would still give him a 'soft', yet enormous power, making him a de facto central bank (and people would not necessarily be aware of this). How do we know that this could not happen?

Just because the developer chose to be anonymous doesn't mean he has anything to hide. Also see my answer above, the code is open source.

The only thing that Satoshi could do that may cause problems is dump his coins on the market. That might spook people and the price might drop considerably, but the whole mechanism is pretty robust and it does what it is supposed to do. So unless there is a real problem, people will just scoop up the cheap coins and we'd all carry on with the mission.

EDIT I just want to add that although Satoshi is revered, his coding style has been criticised for various reasons, and some would say he was not an out and out programming expert. Indeed bugs were discovered early on and corrected, by everyone involved at the time.


On Coinbase Pro does anybody know what criteria are used to decide if a limit order should be rejected due to insufficient funds?

From experimentation it seems like if you're placing a limit order you need enough USD in your account to cover any possible fees regardless if the order will become a maker or a taker. I'm going to mark this as the answer util someone corrects me.


Support sending bitcoins using webpage URL?

The client Electrum seems to support something like that (using a different method): Aliases:

Aliases may be server names (e.g. ecdsa.org) or email-like addresses (e.g. john.doe@ecdsa.org)
The corresponding Bitcoin address is retrieved by the client, using a descriptor located at a canonical url.
Aliases may be entered in the Electrum client, or used in Bitcoin URIs […]


As it was explained on the forum, it is a base58 encoded private key with added 0x80 byte at the front and 4 checksum bytes at the end.

More detailed explanation is not available on the wiki, as well as in a new testing suite.


Sounds like this is what you are looking for

Example usage:

cout << "Script being executed: " << ScriptToAsmStr(script) << std::endl;


senting wrong address from BCH to BTC address PLEASE HELP!

The process would be roughly the same as getting your BCH created at the fork. Here's an answer I wrote on that, but it's for a different wallet.

Let's review what happened:

You sent BTC to shapeshift from a Trezor wallet.
You wanted to trade for BCH.
Shapeshift asks for the receiving address.
You provided a BTC address instead of a BCH address.
Shapeshift sent BCH to an identical address generated with a BTC wallet.

Point 5 is where you might save yourself. BCH and BTC generate addresses identically. You sent Shapeshift an address that you generated, however, you generated it with your BTC wallet, instead of your BCH wallet. Since both coins generate addresses exactly the same way, you can use the private key for that BTC address and import/sweep it into your BCH wallet.

Do this:

Get the private key for the BTC address you generated to receive the BCH. I don't know how to use Trezor, so you'll have to get that info somewhere else; I'm sure it's not difficult.
Find the "import private keys" or "sweep wallet" feature for your BCH wallet software. You didn't say which software you use, but I'm sure it's also easy to find and use.
Take the private key from step 1 and input it into the import/sweep feature from step 2.
Enjoy the fact that you've successfully reclaimed your coin and be more careful next time. Confusing BTC for BCH has been a very common mistake since the fork.


Is it possible to speed up block chain syncing with a miner?

Syncing means:

Downloading the blockchain.
For every transaction, check that its inputs actually reference earlier unspent outputs, and that the signatures match.

Hashing is a completely negligible part of the process and a mining device will not help you. Computationally the major work is verifying ECDSA signatures, and you also need disk access to find the past outputs. Using an SSD will make things faster.


How to make sure that bidders in an auction have sufficient Bitcoin without storing money for them?

The correct way to do this (beware: extremely technical) is to:

Reserve a coin of your own for each auction (the "auction coin"). This shouldn't be too big (you will lose it until the auction is over), but try not to make a dedicated one just for the sake of the auction (use a small one you already have!).
Create an address for the auction's winning bid (the "auction address"). This can be a normal address, escrow address, or whatever.
Bidders should create a raw transaction consuming this coin as an input, and paying to the auction address. They should sign the transaction for all their own coins (added to the auction coin), and send this to you immediately to place their bid.
When the auction is over, you then sign the highest bid's transaction for the input consuming the auction coin, and broadcast it to the network. Note that this will invalidate all the other bid transactions you were sent.
As soon as this winning bid confirms, you deliver the auctioned product. If it is double-spent, you then pick the next highest bid and repeat step 4.


Is it possible to use the same payout address on multiple miners at the same time?

You could use the same address with both miners and there would be no problem. Addresses can be reused, even though this is not recommended due to privacy concerns.

However, you will never manage to mine any bitcoins with home computers. They're too slow and don't contribute enough proof of work to get paid.


The public key becomes known once you try to spend the output as part of the transaction spending that output. Before then only the address is known. This is one reason you should not reuse the same address twice, although a more important reason to not do that is your and others' privacy


How does a hardware wallet interact with the bitcoin network?

No.
The hardware wallet company sometimes runs a node, but you could just as easily use a client like Electrum instead, and use Electrum nodes instead with your hardware wallet. All the node is used for is checking for transactions and publishing transactions.
The wallet software will use the xpub from the hardware wallet to check for payments people have sent to your addresses, using one of these remote full nodes.
Now, let's say you received some Bitcoin and you'd like to spend it. Your wallet software will generate an unsigned transaction on your computer, then it will send that unsigned transaction to your hardware wallet for it to sign, then the wallet software will use the full node to publish this signed transaction.
So like the answer you linked to pointed out, all the full nodes are used for is 1) querying for existing blockchain data, and 2) publishing (NOT creating) an already signed raw transaction.


Does signing message weakens the address' security?

Public / Private key encryption requires that the private key is never revealed - the owner must keep it secret.

Message and transaction signing is done with the private key and verified with the associated public key. So the private key is never revealed to the blockchain. Note that public key here refers to the the full ECC public key, and not a Bitcoin address - which is a hashed and transformed representation of the public key. The public key can only be derived from a Bitcoin address if the SHA256 and ripeMD-160 hashing algorithms are ever broken. This question explores the challenge.

To answer your question: Yes, each new signature produced by a private key may bring an attacker, who already knows the associated public key, closer to discovering the private key.

Comments to this answer have informed an updated position:

Although there is no provable security for ECDSA, it is commonly assumed that, even with knowledge of multiple signatures produced by a particular key, an attacker will not have improved odds at deriving the associated private key or forging its signature.

It is an almost impossible task to discover a Bitcoin private key from its public key. An answer to this question illustrates the challenge mathematically.

Some people advise an attitude of "better safe than sorry" - that public keys should not be revealed, where possible. Yet, caution should not discourage practical utility - as pointed out in the comments below.

Best practice, as you say, is to  frequently change keys and to preferably use a new address for every receive transaction. If you want someone to be able to verify a signature they will, of course, need your public key.

As far as I'm aware, the only Bitcoin transaction type that reveals public keys is Pay-To-Public-Key-Hash (P2PKH) which contains the full public key in its script.


On Blockchain.info, how many addresses can I pass into one API call?

rate limit counts each request you send to the server, so doesn't matter what parameters are you passing.

I'm talking about Nginx and apache rate limits techniques which are used by blockchain.info.

Blockchain has no limits for requests but the limit is coming from Nginx and Apache (default config), unlike blockcypher which counts each address as a request.


Is lightning network censorship resistant?

this is a bit of an old question I assume you've found the answer by now, but I'll answer it so others can benefit.

the short answer is yes the lightning network is censorship resistant.

although naturally some nodes will be more connected and therefor more traffic will go through them, but there is no necessary nodes there will usually be alternate paths between 2 nodes so if a node refuses to let a payment go through the payment will just go through a different path.

more importantly the Lightning network uses onion routing which means each node will only know the node that was before it and the node that came after it, therefore they can't discriminate based on who is the sender or receiver of the transaction.

BOLT #4: Onion Routing Protocol:
https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md


Nodes typically do not rebroadcast transactions. They have no reason to do so, it is not their problem if a transaction is not confirmed.

However if a wallet will likely rebroadcast its transactions, and only its transactions. Rebroadcasting works in the exact same way that broadcasting a transaction works. If nodes still have the transaction in their mempools, then they will ignore the transaction. Of course this means it will not propagate well if all of the nodes that a wallet is connected to already has the transaction but other nodes don't.


What backward compatibility testing is done on Bitcoin Core?

What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the functional tests?

There is a feature_backwards_compatibility.py functional test which spins up functional test nodes from each of the previous releases to do testing between them at the same time.
Once you have built the latest version of Bitcoin Core you can download the previous release binaries using:
test/get_previous_releases.py -b v0.19.1 v0.18.1 v0.17.2 v0.16.3 v0.15.2
You can then run the feature_backwards_compatibility.py test individually or through the test runner.
e.g. test/functional/test_runner.py feature_backwards_compatibility.py
This test is updated with each new release to add a functional test node from the latest release to functional test nodes from previous releases.
At the time of writing (December 2020) there is an open pull request from Sjors Provoost to add v0.20.1 to the backwards compatibility test.

And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?

I don't know at this stage if this in any way a priority (or for that matter whether it should be). It is certainly more resource intensive to build entire previous releases and then test them rather than merely spin up functional test nodes from previous releases. (I will update if I learn more.)


Dealing with 15-minute transaction time limits

It sounds like you are using two different hosted wallet providers.  What you should do is download your own wallet application that you run yourself, and use it as an intermediary between your two hosted providers.  This can be a wallet that runs on a desktop, laptop, or your phone, but doesn't have to be a full node.  You can find a wallet here:  https://bitcoin.org/en/choose-your-wallet

Once you have that, withdraw your bitcoin from the first service to an address from your own wallet.  This may take the usual several hours.  Once you see that the transaction has a confirmation on it, you will be able to then send it to the second hosted wallet easily within the 15 minute timeout.


Transferring many bitcoins without restoring a seed

You would want to use a mixing service. Essentially, you would send your 10 coins from your old wallet to the mixing service and get the same amount out to the new wallet. This effectively anonymizes your coins if the mixing service is doing its job correctly.

A similar effect can be done by sending your coins to an exchange from your old wallet and taking it out to the new wallet. Obviously, the exchange would be able to connect the two addresses, so it wouldn't be as anonymous.


What do I support with Bitcoin Core Version 0.14.2

You can look at the version field of blocks generated by that software, there are websites that show both the client and version.
To my knowledge, core supports bip141, which is SegWit (bit 1 of version)
Core does not support bip91, nor bip148, nor Segwit2x (2mb hardfork)


How would changes to the Bitcoin protocol be decided upon? What constitutes a "majority"?

"...if it benefits a large majority of participants.", nobody proposes anything ever that will not, at least be presented as, 'benefiting a large majority of participants'.  From 'trickle down economics' to 'you might not agree now with me on this proposal, but you'll agree with me later' gives the people that set the agenda and write, defend and prepare these proposals and technical changes a lot of influence.

secondly, normal politics (as this is politics, not engineering primarily, as for instance now BIP16 and BIP17 are evaluated for implementation and the developers do not agree and seem to have valid points.)

Although i don't get the impression that the bitcoin developers have dark motives, or don't want the best, i am worried about what is going to happen when the US government starts to try to exert influence over bitcoin. There are already BIP proposals that for instance make it possible for someone to request a payment from a customer, and this greatly reduces anonymity but increases tracability vs. for instance the implementation of zerocoins which would build in automatic mixing and increase anonimity. the US govt, or any government for that matter will use their influence and also power to try to safeguard its (perceived) interests. (i don't know which BIP's these are - but you get the picture)

Actually, if i am not mistaken there is no bitcoin protocol as such, there is just the bitcoin-qt client, a piece of C++ code that is hard to understand (unless you're a C++ programmer) and by the sound of it not unambiguous. This is the protocol, the protocol is written according to how this program works.

Anybody has any illuminating thoughts or facts on this issue?


Creation of an address is an entirely offline operation; there is no communication with the network.
If you'd (with unfathomable luck) create the same address as someone else, then you'll see incoming payments to it appear in your wallet, and be able to spend them.
There is no provision for dealing with this, because there does not need to be any. The probability of this ever occurring is so mind-blowingly small that it is simply not a consideration.
For typical addresses, there exist 1461501637330902918203684832716283019655932542976 valid distinct ones.


As you can see, only 10.8% of nodes have upgraded to 0.11 and 29.3% of nodes use a pre-0.10 distribution. (Source: https://getaddr.bitnodes.io/dashboard/#user-agents)

Considering that we don't know the hashing power of these nodes and don't know your definition of "swiftly included", there's no way to exactly answer your query.

However, if you assume hashing power to be equally distributed between nodes, There's about a 10% chance that any give block will be mined by someone running 0.11, so about a 47% chance that a 0.11 block will be mined at least once an hour.


Multisignature technology in bitcoin - math and code

Multisig bitcoin transactions have a fairly simple implementation and don't require any advanced cryptography knowledge beyond the regular ECDSA used for P2PKH transactions. There are no "mutltisig address" or "multisig pubkey", but regular public keys and regular signatures are used. A multisig transaction output essentially contains a list of public keys with their count, and a threshold count which is <= to the pubkey count, and finally the OP_CHECKMULTISIG(VERIFY) opcodes, which check the signatures provided against the public keys from the script.

In terms of creating multisig addresses, there are two RPC commands in Bitcoin Core. createmultisig and addmultisigaddress. The code behind the multisig script creation is in standard.cpp#GetScriptForMultisig, which is quite trivial.

Spending the multisig output is not quite as simple. You need to use the createrawtransaction command, followed by a call to signrawtransaction for each signature required to meet the threshold, and finally you can broadcast the signed transaction with sendrawtransaction.

As mentioned above, there is no standard address type for these transactions, but PSBT (Partially Signed Bitcoin Transactions), also known as BIP-174 defines a standard serialization and textual encoding (in Base64) which can be used for sharing the raw transaction at each point in the above process with other parties if the private keys are not owned by the same user.

There are proposals for doing mutlisig schemes in other ways which utilize key or signature aggregation. None of these have a concrete proposal in the form of a BIP yet. I suggest reading the MuSig paper from Maxwell et al. as a starting point, and have a look at BIP-340, which defines the Schnorr Signature scheme which is likely to be made standard into Bitcoin at some point in the near future. Note that the proposal for OP_CHECKSIGADD in BIP-342 does not by itself allow for key or signature aggregation, but it does allow for more efficient batch verification of multiple signatures.


How do I get my bitcoins back if they got sent to an incorrect address?

You appear to have caught some malware that replaces Bitcoin your addresses with their own when copy-pasting one. You'll probably want to look into removing the malware from your computer.

Meanwhile, it is unlikely that you'll be able to recover your bitcoins. The Bitcoin network doesn't have a way of reverting payments. Basically, you're in a similar situation as if you handed cash to a different person than the one who was supposed to get it. Unless you can figure out who it was that got it, there is no way to get it back. There is no central registry of Bitcoin users, and as a general rule you cannot identify users from addresses alone.


Is it possible to create a system for 'shared wallets' on top of bitcoin?

Yes, it's called a Distributed Contract or a Smart Contract.

Projects like Ethereum are aiming to make this much more of a reality. Currently they're a bit of a pain to write.


The Microtransaction API documentation it describes a BlockCypher MicroTX as a normal transaction. BlockCypher just checks that the transaction has reached 98% on their confidence-factor and is therefore included in the next block.

However the documentation (and the whole concept) seems to be outdated.

  The Microtransaction API will accept values between 7,000 satoshis (~$0.04) and 4,000,000 satoshis (~$20). Anything below or above these thresholds will return an error.

At the time of writing (BTC @ ~$7000) the 7000 satoshi would be worth ~$0.49. In the Microtransaction API they alert that MircoTX are not feasible anymore and the API is therefore discontinued on bitcoin.

  Due to congestion on the Bitcoin network and the drastic increase in miner fees, microtransactions have become uneconomical. As a result, our microtransaction API isn’t supported on bitcoin anymore.


Lightning network explaination (bidirectional channel funded by one party)

From what I understand, Lightning does not use absolute timelocks (nLockTime) for single payment channels.

The task of implementing a bi-directional channel is equivalent to the task of invalidating old states (i.e., preventing them from being broadcast to the blockchain). In Lightning, if Alice wants to update the state, she must first sign a "Breach remedy transaction" (BRT). Moreover, the party who initiates closing the channel by broadcasting some channel state must wait before being able to withdraw their funds (implemented with a relative timelock). Putting this all together, if Alice tries to cheat and broadcasts an old state (trying to withdraw more money than she is entitled to), Bob has time to broadcast his BRT and claim all funds in the channel.

Answering your question, none of the transactions inside one channel have nLock. The paper and a wiki page provides more details.