How to manually sign a transaction with multiple inputs and multiple outputs?

When it comes to transactions, I think that a hex representation can explain more unambigiously than words.
That's why my answer uses hex along every step of the signature.
Given your P2PKH transaction with two inputs, here's the raw transaction that has to be signed with the private key corresponding to the first outpoint:
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
19
76a914<your-first-pkhash(160bit)>88ac
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
00
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
01000000

Here's the raw transaction that has to be signed with the private key corresponding to the second outpoint:
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
00
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
19
76a914<your-second-pkhash(160bit)>88ac
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
01000000

And here is the resulting signed transaction:
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
6a
47
304<...rest-of-signature>
01
21
<your-first-pk(264bit)>
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
6a
47
304<...rest-of-signature>
01
21
<your-second-pk(264bit)>
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000

Assumptions: (1) You're using compressed public keys. (2) type is SIG_ALL
Note: Length of signatures can vary, and as a result the bytes that indicate script length can differ from the example above.

Answering your 3rd question, there is a description here


How do more leading zeroes make it more difficult to find a block?

Adding more zeroes (more precisely as a prefix) to the required block hash (which is the hash of block header) makes it more difficult because you need to keep hashing the block header until you find a hash value that is less than the required maximum numeric hash value (you update the block header everytime by incrementing the nonce in it which changes the block header. Presently because of ASICs this field is too small, so the extra nonce is stored in unused locking script of Coinbase transaction, which as a result changes Merkle root which is part of the block header). Here is a documentation of what goes into block header:

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

Mathematically to make sense of it, think of it this way, if I ask you find a number at random from 0 to 100 less than 90, how many times do you have to try before you get a number for sure less than equal to 90? It is exactly 10 times. This same principle applies to SHA-256 of the block header.


That is DeepBit's payout address. Whenever DeepBit pays its miners, it sends one transaction per miner, and each transaction comes from 1VayNert and sends change back to 1VayNert. The change from these thousands of small transactions adds up to create huge "total BTC received" amounts. 1VayNert has never actually contained anywhere near 10 million BTC -- that's just how much BTC it has sent to itself in change from transactions.


You're right that the elliptic curve multiplication is indeed the most expensive operation in the validation algorithm. And as both single signature validation and batch validation require two EC multiplication per signature, it would seem that no speedup can be gained from batching.

However, several algorithms are known for computing the sum of multiple EC multiplications faster than summing the individual multiplications. Straus's algorithm (also known as Shamir's trick), Bos-Coster's algorithm, and Pippenger's algorithm all provide speedups, and are applicable in different scenarios. In the graph in our BIP draft Straus and Pippenger are used (depending on the size of the batch; Pippenger only wins for batches over ~100 keys). For sufficiently large batches, Bos-Coster and Pippenger are O(log n) times faster than individual multiplications.

To give you an intuition for how this is possible, here is a summary of Bos-Coster's algorithm (while in practice it's not the fastest, it's the easiest to explain):

Start with a list of pairs (a1, P1), (a2, P2), ..., (an, Pn).
Sort this list from large to small ai (and renumber it so that a1 is now the largest number, ...).
While the list has length larger than 1:

Replace the top two elements (a1, P1) and (a2, P2) with the two elements (a1 - a2, P1), (a2, P1 + P2). Note that a1P1 + a2P2 = (a1 - a2)P1 + a2(P1 + P2).
If this results in an element with coefficient 0, remove it (this happens when a1 = a2).
Sort the list again.

When only one element remains, it will be of the form (a, P), where a is the GCD of all inputs. For a sufficiently large n, that GCD will be almost certainly be 1, in which case the solution is just P. Otherwise a will be a small number, and the solution is just aP.

The intuition here is that when you have say 100 multiplications to perform, a1 - a2 will on average be 100 times smaller than the number it replaces (a1), so in every step we're dividing one of the coefficients by 100, while only doing a single EC addition. This is in contrast with naive EC multiplication where you generally need to perform one addition for each bit in the input.


How to convert channel id from c-lightning to lnd?

https://github.com/lightningnetwork/lnd/blob/8379bbaa9b259544c2c8591782a78d7384680b2a/lnwire/short_channel_id.go#L25-L43

// NewShortChanIDFromInt returns a new ShortChannelID which is the decoded
// version of the compact channel ID encoded within the uint64. The format of
// the compact channel ID is as follows: 3 bytes for the block height, 3 bytes
// for the transaction index, and 2 bytes for the output index.
func NewShortChanIDFromInt(chanID uint64) ShortChannelID {
    return ShortChannelID{
        BlockHeight: uint32(chanID >> 40),
        TxIndex:     uint32(chanID>>16) & 0xFFFFFF,
        TxPosition:  uint16(chanID),
    }
}

// ToUint64 converts the ShortChannelID into a compact format encoded within a
// uint64 (8 bytes).
func (c ShortChannelID) ToUint64() uint64 {
    // TODO(roasbeef): explicit error on overflow?
    return ((uint64(c.BlockHeight) << 40) | (uint64(c.TxIndex) << 16) |
        (uint64(c.TxPosition)))
}


Exactly the same way, except instead of putting the compressed public key in the redeeming script, you use the compressed one. Decompressing it won't work, as that would change its hash (the address).


Is there any chance to check the name by bitcoin hash?

No, that's not possible. Bitcoin is pseudonymous. In all likelihood, you will be sent an address which never had any activity on it before. You can't find any relation between that address and the real world (including activity on the blockchain) until a transaction sending money to that address is published. Even if you knew the person who gave you the address, you wouldn't know for sure whether it belongs to them (but you'd of course assume it because why would they give you an address of a different person or one which belongs to no one). They can prove that it belongs to them but they can't prove that it doesn't and you as someone it doesn't belong to can't proof they own it nor that they don't.


Is it possible to get all transactions from a single address with bitcoind?

For an address that is in your wallet, you can use the listreceivedbyaddress command. You would use the command as follows to get the transactions related to an address <address>:

bitcoin-cli listreceivedbyaddress 0 true true <address>

The 0 means list all transactions, including unconfirmed ones. The first true indicates that the address should still appear in the output even if there are no transactions; it just won't have any transactions listed under it. The second true means to include watching only addresses in the output. This only matters if your address is a watch only address.

If the address is not in your wallet, you cannot get all transactions for an address. This is because that would require maintaining an address index which Bitcoin Core does not do. Address indexes require more computing power and are not useful to the functioning of the node.


How do I compose a transaction with OP_RETURN in Python?

I have forked the pybitcointools library to return a properly formatted OP_RETURN hex string, or insert the OP_RETURN into a raw hex transaction.

My fork can be found here. The code is as follows:

from bitcoin.pyspecials import safe_hexlify, from_string_to_bytes, from_int_to_byte, from_string_to_bytes

def mk_opreturn(msg, rawtx=None, json=0):
    def op_push(data):
        import struct
        if len(data) < 0x4c:
            return from_int_to_byte(len(data)) + from_string_to_bytes(data)
        elif len(data) < 0xff:
            return from_int_to_byte(76) + struct.pack('<B', len(data)) + from_string_to_bytes(data)
        elif len(data) < 0xffff:
            return from_int_to_byte(77) + struct.pack('<H', len(data)) + from_string_to_bytes(data)
        elif len(data) < 0xffffffff:
            return from_int_to_byte(78) + struct.pack('<I', len(data)) + from_string_to_bytes(data)
        else: raise Exception("Input data error. Rawtx must be hex chars" \
                            + "0xffffffff > len(data) > 0")

    orhex = safe_hexlify(b'\x6a' + op_push(msg))
    orjson = {'script' : orhex, 'value' : 0}
    if rawtx is not None:
        try:
            txo = deserialize(rawtx)
            if not 'outs' in txo.keys(): raise Exception("OP_Return cannot be the sole output!")
            txo['outs'].append(orjson)
            newrawtx = serialize(txo)
            return newrawtx
        except:
            raise Exception("Raw Tx Error!")
    return orhex if not json else orjson

Note that the module name has been changed to btc (from bitcoin) in my fork.

To run this, you'll use os.chdir("c:/python/pybitcointools") (or whatever directory it's been downloaded to. Then from bitcoin import *. Now, let's use msg = 'The enemy of my enemy is my friend' and rawtx = "01000000016e3cd2b24fcf49259db29888ec5fe6521070041cb8c7bb2017537046f9e00f2b0000000000ffffffff0168d61100000000001976a91469bbbb16301e40b9fb67130e1aa53a2281d60af088ac00000000".

mk_opreturn(msg, rawtx) returns:

01000000016e3cd2b24fcf49259db29888ec5fe6521070041cb8c7bb2017537046f9e00f2b0000000000ffffffff0268d61100000000001976a91469bbbb16301e40b9fb67130e1aa53a2281d60af088ac0000000000000000246a2254686520656e656d79206f66206d7920656e656d79206973206d7920667269656e6400000000

This is the raw Tx with the OP_RETURN properly inserted. Run the function without the rawtx parameter and it returns the string 6a2254686520656e656d79206f66206d7920656e656d79206973206d7920667269656e64


Question regarding stale blocks and the heaviest chain

how the chain containing the "empty" block was heavier than the chain containing the stale block?

"Heaviest" is technically not the correct terminology. Bitcoin uses the valid chain with the most cumulative work. This is unrelated to the size of blocks nor their "weight" (whether that be weight units as defined by segwit, or some other definition of weight). The chain containing the empty block becomes part of the main chain because someone mined a block on top of it so the cumulative work of that branch is greater than the others.

Is the mined block time important in resolving such situations?

The only effect the time has is on propagation. Otherwise the time doesn't matter. What matters is getting the block to someone who will mine a block on top of it, and that is where time matters.


Delegated Proof of Stake (DPOS) vs. Proof of stake?

Important distinction of DPoS from PoS is that in DPoS, there is no minimum stakeholder token requirement to participate and instead of stakeholder tokens proportionately representing their ability to produce blocks, users cast votes proportional to their stake to select block producers.
The process for reaching consensus in a round can be broken down into the following basic steps.

Block producers are elected by the stakeholders in a round of voting.

Once the producers are selected, they are deterministically given a
round-robin rotation for a round of blocks equivalent to the number
of producers selected.

This creates a competitive market within the    round, ensuring
reliability.

Block producers validate and broadcast    blocks to the network.
Consensus is reached and the next round    begins.

For their services, block producers receive a reward. If they do not produce a block, then there is no reward and the reward is transferred to the next block producer if a successful block is produced. Producers do not have the ability to change transaction details, however, they could collude to prevent specific transactions from being included in blocks.
An important feature of DPoS consensus models is that the parameters of the system can be modified by the stakeholders through a voting process. These parameters include everything from transaction fees, block sizes, producer pay, and block intervals. Enabling dynamic changes of the parameters that define the model can facilitate a substantial degree of flexibility for platforms employing the DPoS model to fit the platform’s specific needs.
Advantage over POS
A distinct advantage that the DPoS model has over the traditional PoS model is the removal of the “Nothing at Stake” dilemma. This refers to the case where there is little to no cost for validators to validate on two competing chains. For validators, the strategy is the most profitable, but for the network it can lead to a double spend of a digital asset. DPoS mitigates against this due to the fact that stakeholders are using their stake to vote on block producers, not on blocks themselves. The longest chain is considered the canonical chain, so it is impossible for a subset of malicious producers to produce a fork that overtakes the main chain due to the number and order of producers being fixed before each round.


I used to work at Microsoft - testing code - good luck with that - you will likely NEVER get it stable as to the machine you described - it is just too CPU and swap intensive because the XP platform cannot handle the memory the program will actually need and the hard drive - assuming you are NOT running SSD hardware - will never hold up for long


Calculating the average bid/ask price when placing orders

Yes, when you place market order it works exactly like you described.

In case you want to get a fixed pre-defined return, you need to place limit order


There is no way to reset your wallet's password, as Bitcoin-qt is a local application, not an online service.

In your case, as you have not sent any coins to your wallet, you can delete your wallet and create a new one with a new password.

Your wallet.dat file is located in:

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista/Win7)
C:\Documents and Settings\YourUserName\Application data\Bitcoin (Win XP)
~/.bitcoin/ (Linux)
~/Library/Application Support/Bitcoin/ (OSX)

Be careful, and make sure to use a password you can remember or store offline in a secure location next time.


Why couldn't bitcoin be hosted on the internet?

First of all, bitcoin is on the internet, and the Internet is not decentralized, its managed by several private companies, universities and governmental institutions.

You said "couldn't they have rented a few amazon ec2's or some other servers hosted on xyz host and call it a day"

I don't know who do you mean by "they" whoever you mean, just replace it by bitcoin users and the answer is Yes, I've rented some servers on Amazon and it's connected to other bitcoin nodes.


Will 8 decimal places really be feasible in the future?

You need to consider two separate effects:

Mining starts being funded with tx fees rather than inflation. This will result in higher fees, until tx fees per block are similar to current inflation (maybe 1-2 orders of magnitude less).
The value of every bitcoin increases. The real tx fee per transaction remains more or less the same. The nominal fee decreases. The number of txs per block increases, resulting in an equivalent nominal total fee per block. The real total fee per block will increase, to fund greater security for the bigger network.

The 2nd effect is expected to be bigger in magnitude, and to happen sooner, than the first. So overall, we should see a decrease in the nominal fee per tx, allowing us to use small fractions of a bitcoin (which will then have significant value, in real terms).


Are you checking the transaction on a BTC or BCH explorer ?

You have to sweep the private key (of the paper wallet) in a bitcoin cash wallet.

I used Coinomi on Android (be sure to select Bitcoincash) with success.


A safe alternative would be to pre-generate a large number of public wallet addresses offline in your client, then loop through those when displaying them on your website.

That way your private keys are completely safe.  This is the best option in my opinion.

You could generate a lot of keys locally.

To enforce the goal of no 2 transactions per key, you could write a script to check the public address for usage before delivering it to the user.  If the address has already been used, remove it from your list of addresses that you deliver.


Why do transactions take so long to confirm in testnet?

Decoding your transaction shows an output:

"vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN 68656c6c6f5f776f726c64",
        "hex": "6a0b68656c6c6f5f776f726c64",
        "type": "nulldata"
      }
    }, ...

This might be the reason the miners won't touch it as it may be flagged as non-standard on older nodes. Notice the warning on blockcypher:

Maybe someone can comment on exactly why, as these null_data transactions were made standard on Bitcoin-core 0.9.0, see https://bitcoin.org/en/developer-guide#null-data


Answered by Pieter Wuille in comments:

  That's just ECDSA. The nonce is the randomness for the signature, and has nothing to do with the message being signed. An ECDSA signature is a pair (r,s) where r is the X coordinate of kG, and s = (m+r*x)/k (where k=nonce, m=message hash, x=private key, G=curve generator).


No, new nodes don't support the HTTP transport. You'll need to use TCP.


Get the price of a currency at specific time in the past using binance historical data api

Maybe the klines api will suit your needs: https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#klinecandlestick-data

Kline/Candlestick data

GET /api/v1/klines

Kline/candlestick bars for a symbol. Klines are uniquely identified by their open time.

Weight: 1

Parameters:
Name    Type    Mandatory   Description
symbol  STRING  YES
interval    ENUM    YES
startTime   LONG    NO
endTime     LONG    NO
limit   INT     NO  Default 500; max 1000.

    If startTime and endTime are not sent, the most recent klines are returned.

Response:

[
  [
    1499040000000,      // Open time
    "0.01634790",       // Open
    "0.80000000",       // High
    "0.01575800",       // Low
    "0.01577100",       // Close
    "148976.11427815",  // Volume
    1499644799999,      // Close time
    "2434.19055334",    // Quote asset volume
    308,                // Number of trades
    "1756.87402397",    // Taker buy base asset volume
    "28.46694368",      // Taker buy quote asset volume
    "17928899.62484339" // Ignore.
  ]
]


Why is a minimum transaction fee for 0.01 BTC *sometimes* enforced

This depends on the priority of a transaction. If an input (coins you received from an earlier transaction) was not used for a longer time, its coin-age (equal to confirmations) increases and therefore the priority.

If the priority is equal or above middle-priority (thats what the bitcoin-core client and the blockchain.info side calls it) it does not require fees. So when you send your first bitcoins, those had a high enough priority to get shipped for free. Then you tried to send them back immediately, with a low priority, so you were forced to set a transaction fee.


The requirement for a one time pad to be secure is that it consists of uniformly random data, only known to the participants that should be able to encrypt/decrypt.

The blockchain is not random (it's created by miners and users creating transactions), certainly not uniformly random (blocks and transactions have a very strict syntactic structure), and worst of all it is designed to be known to the entire world (or in the case of private blockchains, to all those who should be able to audit).

Short answer: bad idea.


How does ImportPrivateKey get the Address if I don't explicitly send it?

You ought to ask this question on CryptoSE, as the problem is not Bitcoin-specific. I've even done that for you.

In short:

  The public key is QA=dAG where G is the base point on the curve defined in the publicly agreed upon parameters.

And you can find the Bitcoin curve (secp256k1) parameters in the wiki.


Can I use bitcoin as a means of bypassing Argentine Dollar restrictions?

Put up an ad on LocalBitcoins.com.  You possibly might find a tourist arriving with bitcoins who is looking for Argentine pesos.  Or perhaps you'll find a local Bitcoin miner who is simply looking to cash out some bitcoins for your pesos.

Are there any goods that you could pay for with your pesos and then have the goods shipped to a buyer who pays using bitcoins?

You might laugh, but you might find buyers for Argentine pesos sent via the mail.  If there's a market for the Zimbabwe 100 trillion dollar note, there's probably buyers wanting a set of your paper banknotes (for novelty, or maybe even speculation -- who knows.

Again, travelers are a resource for you.  For instance, even while visiting a foreign country a traveler might have family or friend back home that would be able to deposit cash for the purpose of buying bitcoins.  The typical traveler might not need this, but if for instance, the traveler wants to buy a larger valued item and the seller only accepts cash then the traveler is in a bind.  You are simply helping the traveler convert paper money (e.g., USDs) in one country for a different paper money (ARS) in another.

You might also follow the Spanish board on BitcoinTalk forum to find others who might wish to trade by selling bitcoins to you.  Or find some Argentine merchants who accept bitcoin (like this, this or this) and see if they have coins and are looking to trade.   Or find a merchant that does a lot of export and convince that merchant to begin accepting bitcoins.  When they do, you've found your supply of coins.


How to create a bitcoin transaction without inputs

This is not possible. Only the coinbase transaction is allowed to have a null, or non-existent input, and the only way to create that is to mine a block. Moreover, it must adhere to additional rules, such as the inclusion of the block height in the coinbase section of the vin (the scriptSig) as per BIP 34.

Unless you happen to run a mining pool, or have enough hashpower to solo mine a block, you cannot do this.

Creating a transaction with no inputs whatsoever is not possible without a hard fork.


Besides Bitfinex, which crypto currency exchange(s) have Trailing Stop Loss

Kraken have the real deal, where one can set stop-loss based on %, but their trading platform has been a bit unreliable lately.

Bistamp also have trailing stop-loss, but very low on selection of coins.


That is correct. You create an additional txout with value 0 and script "OP_RETURN data".


If you have had bitcoin in zebpay wallet on August 1st, You should have an equal amount of BCH(bitcoin cash). Zebpay wants to send this amount to you.

If you want a BCH wallet, You can install electron wallet from https://electroncash.org/ get a public address and submit it to zebpay. They will send your BCH to you.

Note that if you did not have Bitcoin in zebpay wallet as of August 1st , you may not receive anything.


Where does Bittrex/Binance (alternative cryptocurrency markets) get their coins?

Pure exchange like Bittrex neither need, or have use for a huge reserves of cryptocurrencies. Their service model is based on providing a platform for peers to sell and buy coins/tokens.
Also, they don't actually buy the coins from the sellers. Sellers/buyers are the one's who deposit coins to Bittrex's wallet, so Bittrex act like an intermediary between the seller and buyer.
There is an exception though, you can actually wire transfer to Bittrex and buy USDT, and they will purchase on your behalf from other sellers on a per-order basis.

Coinbase is different, they are more like a bank-hybrid with their own dedicated exchange(GDAX), and as a bank , they have a huge reserves of cryptocurrencies as they deal with buyers/sellers directly.


Good resource for understanding the peer to peer protocol sequence

Your question is rather vague, what do you really want to know?

Bitcoins peer-to-peer nature comes from the fact that no single entity holds the database (the block chain), but every client in the network does.

You misstate that Bitcoin has two main actors. In fact, miners are just like other clients. Every client in the network has the possibility to broadcast a new block it has found. The difference with miners is that they are actually trying to find such a block to publish.

Since the block chain is peer-to-peer, all updates to it will have to be broadcast to all clients as well. These update consist of blocks and transactions.

Whenever someone built a valid block to append to the current block chain, it broadcasts it so that every other client can verify it. If these clients accept the block, it will be added to their block chain. New blocks always refer to their previous block so that clients that did not receive one, or mistakenly accepted a malicious block, can always get the right blocks from the network.

Transactions, as well, are broadcast to all clients where they are validated. Most clients do not have to do anything with these transaction, only those that mine do. Clients that mine bundle all the valid transactions they received into the next block they are trying to build. When they succeed in building the block, these transactions are stored in the block and broadcast to be included in other clients' block chain.

One essential property of Bitcoins peer-to-peer nature is that you can only stop it from existing if you can stop all the nodes. As long as one node exists, "Bitcoin" exists.


'Replace By Fee' (RBF) is a method of increasing the fee rate for a yet-unconfirmed transaction. As a user, if you send a transaction and then realize the fee-rate was set to low, you can utilize RBF to create a replacement transaction which includes a larger fee, in the hopes of quicker confirmation.

In this case, it looks like there was an RBF-enabled transaction that paid those funds to the 18dC... address mentioned in your screenshot. This transaction would otherwise be a normal bitcoin transaction, that just has the 'RBF flag' enabled so that it can be replaced if the user so desires.

If you did not create this transaction, then you should consider the fact that the machine your bitcoin wallet is running on is infected with some sort of malware. Without more info, its not really possible to say for certain what happened here though.


You may need to upgrade is an indicator that you may be running a client that is no longer viable for use on the network.  Download the current version 0.8.6 at this time.  There was at least one hard fork in the network that caused older versions to be deprecated.


Should i invest in a Antminer L3+ or a Antminer S9

Invest? Run the math first on bitcoinwisdom.com. Unless you have free power (and won't get into trouble drawing a kW of AC 24/7; it won't be profitable for long.

Difficulty rises and will continue to do so; until the correction comes; which- it will.

Now would be a bad time to buy a miner. I would wait for a major price correction-- even if BTC hit 10k before the correction- the money to make would be after it drops back down to 5k and the miners are all worthless; then start them up after the price rebounds.

Bitcoin mining is too hot to touch right now if you are not already heavily invested in the game.


How miner makes sure that a transaction he picked up from mempool is actually valid?

Does that mean that if mempool contains a transaction saying "A" gave "B" 0.1 BTC then miner is supposed to actually make sure that "A" has that much unspent BTC before he can select that transaction into a block to be mined?

This is a misunderstanding of how bitcoin transactions work, which assumes that coins are "spent from a wallet," which is not the case.

All transactions spend one or more previous transaction outputs (TXOs). The outputs are always spent in full, and become the inputs for the new transaction. Each transaction output is locked with a public key hash, such that only the person who knows the private key related to the public key can unlock the output to spend it. This is done by digitally signing the spending transaction with the private key.

A wallet, such as the one belonging to A, is simply a collection of private/public key pairs - one pair for each TXO which belongs to A. (Although the same key can be used for multiple TXOs, this is discouraged). The balance of wallet A is the sum of balances for all of the unspent transaction outputs (UTXO) for which the wallet has the private key to unlock and spend.

So when A wants to pay 0.1BTC to B, he will pick one or more of the UTXOs he is able to spend such that the collective balance of them is at least 0.1BTC. These will become the input of his new transaction. The transaction will contain an output with a public key belonging to B (their bitcoin address) for the amount of 0.1BTC. The transaction may also contain a change output, which spends the difference between the the sum of the TXOs which were spent by A and the 0.1BTC payment to B, minus transaction fees - this change output spends to a new address owned by A. These two outputs become new UTXOs, and the previous ones become spent.

Miners do not have any knowledge of the wallet balances of A or B - they can only see the amount of each UTXO, and they determine whether they are allowed to be spent based on whether the signature in the transaction is the correct one for the public key which locks the UTXO. They determine that the sum of output amounts is less than the sum of input amounts, and the difference between the two becomes the transaction fee which the miner collects. If all the checks pass, the transaction is valid.

Miners therefore, only need to keep a reference about all of the UTXOs on the blockchain to determine that they've not yet been spent. All previous historical transactions which were spent are archived and do not need to be accessed.

In Bitcoin Core, all of the block data is archived, and the software also maintains an index called the UTXO set, which says where each UTXO can be found in the archive. The UTXO set is held in a memory-mapped database, for performance.

The UTXOs are identified by transaction id - which is the double-SHA256 of the full transaction data found in a block somewhere, and the index of the output in that transaction. (Collectively referred to as a transaction out-point).

When new transactions or blocks come in from the network, the miner must validate them all. Each transaction's input contains a transaction out-point which must be looked up in the UTXO set - and the signatures must all be verified to correspond to the public keys which can spend the output (done as part of a script, which must always evaluate successfully). If any checks fail, the transaction or block is invalid. If they all succeed, then the UTXOs which are spent by the transactions are removed from the UTXO index and the new outputs are added to it.


Why is there currently no bitcoin package in Debian?

Your link also says:

  action needed

Problems while searching for a new upstream version                  high
2 security issues in sid                                             high
Depends on packages which need a new maintainer                      normal
The package has not entered testing even though the delay is over    normal
Build log checks report 1 warning                                    low
Standards version of the package is outdated.                        wishlist

  testing migrations

  excuses:

  Migration status for bitcoin (- to 0.18.1~dfsg-1): BLOCKED:  Rejected/violates migration policy/introduces a regression
  Issues preventing migration:
  Updating bitcoin introduces new bugs: #939608
  Additional info:
  Piuparts tested OK - https://piuparts.debian.org/sid/source/b/bitcoin.html
  241 days old (needed 5 days)
  Not considered

If you drill into the details you find security bugs such as CVE-2019-15947

  In Bitcoin Core 0.18.0, bitcoin-qt stores wallet.dat data unencrypted in memory. Upon a crash, it may dump a core file. If a user were to mishandle a core file, an attacker can reconstruct the user's wallet.dat file, including their private keys, via a grep "6231 0500" command.

I guess time needs to be spent resolving all the issues identified with the package.


Is that proved that for each block there is always nonce value which will make block hash to start by n count of 0

Cryptographic hash functions are collision resistant and the digests produced by SHA-256 are approximately uniformly distributed. This suggests that if the input space to the hash function is magnitudes bigger than the projection space of a hash function, we would expect that every value of the projection space can be hit.
The block header is 80 bytes, and the digest space of SHA-256 is 32 byte (256 bit). Out of the 80 bytes of the block header, version is unrestricted on 29 of 32 bits, the nonce is a 4-byte arbitrary value, the Merkle root is a 256-bit digest derived from an enormous combination space, the timestamp is rather flexible—limited to a unix timestamp range of roughly 3h/10,800 seconds (~13 bits), only the previous block hash and difficulty statement are fixed. So, before counting the Merkle root, miners could generate up to 74 bits of entropy in the block header.
The Merkle root is derived from the set of transactions that a miner is choosing to include in their Bitcoin block. Not only can the miner arbitrarily pick content and order of the (valid) transactions, but also each miner is paying themselves in the coinbase transaction of their block candidate. Given that paying to different addresses results in different coinbase transactions, every miner is working on a unique transaction set whose Merkle roots making any overlap between block candidates of different miners astronomically unlikely. Further, parts of the coinbase transaction's input can be picked arbitrarily (the "extranonce" and most of the remaining 2–100 byte input script of the coinbase transaction) giving miners a way to easily add further entropy to the set of block candidates they're evaluating. Additionally, miners update their block candidate's transaction composition whenever more new transactions paying higher fee rates arrive. Even if there were no transactions to add in the block, miners could just generate a different address to pay themselves for use in the Coinbase after exhausting the nonce and extranonce space.
Given the power set of all possible transaction orders, the address space of Bitcoin, and the 100 byte input script in sum by far exceed the 32-byte digest size of SHA-256d, I'd argue that the Merkle root provides a full 32 bytes of entropy.
In sum that gives the miners ~41 bytes of arbitrary input data to produce a 32-byte digest i.e. an input space 272 bigger than the projection space. Meanwhile, a block is only restricted to the current difficulty which is significantly smaller than 2224 (the difficulty of requiring a block hash 000…0).
While this doesn't meet the requirements of a rigorous mathematical proof, I'd surmise that miners do not have to worry about running out of possible block candidates. Therefore, it's just a matter of time until someone happens to succeed at creating a new valid block.
Also see this closely related question here: How can we be sure that a new block will be found?.


BFGMiner + CGMiner solo mining, how to specify payout address

It depends upon the parent's support of the coinbasetxn capability. When your (getwork or getblocktemplate) request includes the coinbasetxn flag, the response may (should) contain an address for the payout to go to. Some blockchain implementations support this flag and some don't. A number of miners allow you to specify the address manually. Some don't. Most pool software uses the username instead of the coinbasetxn return as the coinbase address.

You can see this changeset here were local mining support was added to lbrycrd. (Disclaimer: I work for them). https://github.com/lbryio/lbrycrd/commit/24269e177f002eb6975abe077bd727992381a95d


Find Lightning node for channel creation based on amount and route

The mentioned lightning explorers show information from the gossip protocol which nodes usually have copied locally and provide to users. In clightning you can for example access that information with lightning-cli listchannels If I remember correctly  in lnd the command is lncli describegraph.
Gossip says a few meta data about what channels nodes accept. however in general a node cannot / will not guarantee that you will be able to route a payment of a particular size to node n (though in practisce it will most likely work)


How to create bitcoin wallet for many users?

To manage many users balances, you should generate a new deposit address for each person, and keep track of their balances via your own database or similar, rather than relying on the deprecated account system in bitcoin core.


how to achieve transaction info of all the blocks

That's because you're pasting a block hash into a field that expects a transaction hash.

It looks like btc.com doesn't support listing all transactions for a given block, it will only give a tx count: https://btc.com/api-doc#Block.

Blockchain.info does, however at the api endpoint:

https://blockchain.info/rawblock/$block_hash

So, you can copy the hash of any block from the list of the first link in your answer to the $block_hash field in https://blockchain.info/rawblock/$block_hash.


What a completely-decentralized cryptocurrency might look like

Sounds nice, but may pose some challenges.
HashCash, bit gold, and b-money all tried to use self-mined proof of work as cash directly. Those projects were unable to solve the doublespending problem as they did not feature a global consensus system. DigiCash on the other hand was able to solve doublespending but required a central operator to clear payments and issue new tokens—shutting down the operator meant that the currency stopped existing.
Bitcoin's great breakthrough was that it provided a practical solution to the doublespending problem without a single point of failure. It combines the strengths of the above two approaches into a system where network participants both issue coins and decentrally author the global state. The latter removed the need for a central operator, while still providing the referee function which enabled every participant to locally resolve the doublespending problem.
What you describe as

"some kind of (self-mined?) token that can be proven to be unique and to be "owned" only by the holder"

is essentially a description of the doublespending problem: how do you guarantee that a digital good cannot be transferred multiple times?
So, your proposal boils down to a suggestion that we would "only need to find another, even better way of solving the doublespending problem" and then we'd be able to create an even better cryptocurrency. Sounds about right, but might be a bit optimistic since this solution already took a few decades to emerge, and the requirements you describe sound a lot more challenging.


Am I really understanding how the "Trezor Model T", and hardware wallets in general, work?

Hardware wallets such as the Trezor ones you mentioned are only a secure method of storing and using your private keys.  When you want to send BTC, that transaction will be signed mathematically completely within the confines of the key itself.
One could design a hardware wallet with a full user interface, negating the need for a separate computer all together, but that would be far more expensive; in the realm of the price of a modern mobile phone.  Keeping the code inside a Trezor to the utter minimum reduces the potential for security weaknesses and improves reliability, too.


Do miners mine their own transactions or submit them to the network?

I suspect that miners submit their own transactions to the network like other users, but that they may prioritize them in their own blocks beyond what their feerate would merit.
The blockspace is limited to 4,000,000 weight units. Generally, miners simply fill it with a selection of transactions that optimizes for highest total transaction fees collected. Including their own transactions displaces other transactions from their block. If the displaced transactions paid a higher feerate than their own transactions, the opportunity cost of not collecting those fees should be equal to what would have been enough to get their transaction into another miner's block. Nobody can predict when exactly a block will be found or by whom. By submitting the transactions to the open network at a competitive feerate, the miners can get either quicker confirmation times (because any block will include the transaction, not just their own), or signal lower priority than the transactions they would currently include in an optimal block.
I would not be surprised if some miners included their own transactions in their blocks regardless of the feerate, though. It may even make sense to attach a competitive fee even when miners include their own transactions, because the transaction fee can be accounted for as a business cost, which is a bit harder to do for an opportunity cost.


How do we know that the suprnova worker is producing value?

You are mining so slowly that the mining pool thinks you are not mining.

You can't mine sha-256 coins with CPU. You are several hardware generations too late.

CPUs had to give up bitcoin mining in 2011 when GPUs took over completely. Then came FPGAs which made life hard on GPU miners. Finally in 2013 the ASICs arrived which made GPU and FPGA mining completely pointless. Now in 2017 this is old news and sha-256 mining has been ASIC-only for years.

Just like with BTC, BCH (BCC) is also mined with ASICs.

Why do people give up on old and inefficient ways of mining:

It would take several hundred years before you have earned the minimum amount to cash out from the pool. Not only is this tiny amount not worth 5 minutes of your time - you are not going to live long enough to cash it out.
If you lived for 1000 years and mined the whole time, earning 1 US dollar worth of BTC or BCH/BCC, you would have paid a million dollars in electricity to get there. How would it make sense to do so?

Back in 2009 some people would mine 50 bitcoins per day with the CPU of an old laptop. Unfortunately it is not 2009 anymore. Today you earn zero with CPU.


When does `vin` contain multiple addresses

So a transaction will have multiple vins, if it takes multiple UTXOs to send the value.

So let's say you in the past have received 10BTC from X, and 5BTC from Y.

You now need to send 11BTC to Kate.

What it will do is,

it will send out the 10BTC from X, as this is an Unspent Transaction Output, it will then send out the 5BTC from Y and send you back 4BTC.

In this case, you may see 2 inputs on the input side.

Your logic may not work because the "fromAddress" for the 10BTC might be the fromAddress that you hold, but the fromAddress for the BTC, you may not have.

In order to find out all transactions from personA to personB, you must know all of their public addresses in their wallet.

You also cannot assume that all inputs, are from personA because with BTC you can pool transactions, so each input can be from another person.

If you had all of the addresses, your code would look something like this:

if fromAddresses.contains(row['addr']):

Hope that helps.


You can reference the test cases in my Go implementation of this
that I linked to in an answer to a similar question.

For the case given on the wiki page the values should be:

secret: shHM53KPZ87Gwdqarm1bAmPeXg8Tn ==
0x71ED064155FFADFA38782C5E0158CB26
private generator: 0x7CFBA64F771E93E817E15039215430B53F7401C34931D111EAB3510B22DBB0D8
public generator: fht5yrLWh3P8DrJgQuVNDPQVXGTMyPpgRHFKGQzFQ66o3ssesk3o
first private key: pwMPbuE25rnajigDPBEh9Pwv8bMV2ebN9gVPTWTh4c3DtB14iGL
first public key: aBRoQibi2jpDofohooFuzZi9nEzKw9Zdfc4ExVNmuXHaJpSPh8uJ
first Ripple address: rhcfR9Cg98qCxHpCcPBmMonbDBXo84wyTn

Many of those are in Ripple's base58 encoding. I can provide the hex equivalent if required but it's probably easier for people to get the above linked Go package and run the test cases themselves. It should be trivial for any programer (whether they know Go or not) to tweak the test code to show them whatever details they need.

Edit:
With the private/public generators you specify (0x7CFBA64F… and 0x0388E5BA…) you should be hashing 0x0388e5ba87a000cb807240df8c848eb0b5ffa5c8e5a521bc8e105c0f0a442178280000000000000000 into 0x28f3e125edb203022c7d22c486284706058c209dbf4a98c3923705a4e5347c7a which is good and doesn't requre incrementing the sub-sequence.
That is added to the private generator mod N to result in a private key of 0xa5ef877564d096ea445e72fda77c77bb45002261087c69d57cea56b008102d52.


Bitcoin is taxed as capital property (see IRS Notice 2014-21), and a tax event occurs any time it is converted into fiat (e.g. USD) or other assets. You would have to record each transaction and include it in 1040 Schedule D.

This is the difference between how much USD you received less the value of those BTC when bought/acquired them. If you had owned those coins for more than a year, you can report it as "long-term" gains, which has a reduced tax rate. Otherwise, it "short-term", which is just taxed as normal income.

You can use https://bitcoin.tax to help work it out.


How do import a paper private key into MultiBit?

Tools -> Import Private Keys

Create a file with the private key inside it. If you do not add the time of creation of this address, you get this message:

  "There were missing dates. Have to go back to genesis block."

I think this date should be the first transaction date registered in the block chain.

  Key createdAt is in UTC format as specified by ISO 8601
  e.g: 2011-12-31T16:42:00Z . The century, 'T' and 'Z' are mandatory

To be safe, turn the date back a few days.


BIP70 who issues the transactions, wallet or payment_url server?

You're right, it is confusing in the specification. Particularly:

  When the merchant's server receives the Payment message, it must determine whether or not the transactions satisfy conditions of payment. If and only if they do, if [sic] should broadcast the transaction(s) on the Bitcoin p2p network.

and

  Customer authorizes payment to the merchant's address and broadcasts the transaction through the Bitcoin p2p network.

The image particularly shows the Wallet broadcasting the transaction.

What is established, however, is that the transaction in the Payment message sent to the merchant is the same transaction the wallet app broadcasts. IMHO, I think it's safe to assume that both the customer's wallet and the merchant attempt to broadcast the transaction. When both parties hold the transaction, they can both ensure that it was broadcast to the network..


There term originated as a forum post in December 2013 as - what I can only assume to be a drunk day trader. That is holding his coins as the price is crashing.

I don't think it was intended to mean "Hold On for Dear Life" but it has definitely grown to mean that as OP explains that there are three people, the losers (inexperienced traders) and winners(experienced traders) and the group in the middle that buy and hold on for dear life. The forum post itself is an interesting read and I defz recommend that you check it out yourself: https://bitcointalk.org/index.php?topic=375643.0


What are some ways for virtual currency like Bitcoin to have price stability?

There is no straightforward approach that a currency can take to achieve price stability.

There are things that can contribute to a more stable exchange rate, however.  These things are not specific for virtual currencies, though, but also apply to commodities or stock markets.

Mainly, trading liquidity and market availability are key to achieve price stability.  The more an asset is traded, the more stable it will become over time.  Especially when it is traded in different ways.  F.e. the presence of arbitrage and margin trading have an effect on the stability of the price.

Bitcoin has a long way to go on those fronts.  Even though there a numerous Bitcoin exchange websites of which several already support margin trading, the liquidity is still very low compared to traditional FX and commodity markets.  Many people think that the creation of a Bitcoin ETF will benefit price stability, as it enables a new range of traders to enter the market.


How easy is it to solo-mine new altcoins?

Exactly how does one go about solo mining altcoins? Is the process the same as mining bitcoin, litecoin, dogecoin, ethereum etc?

The process is generally the same for most Proof of Work coins. You download a mining software such as cgminer or bfgminer, and configure it to get its work information from a coin daemon that you run. Most modern coin daemons are forked from a version of Bitcoin Core that has the getblocktemplate protocol implemented. Most mining software also support the getblocktemplate protocol. Thus they can use the getblocktemplate protocol for getting their block information in order to mine a block.

  but instead I've had to muck around with mining pools and heaps of complicated settings and I can never get it working

When solo mining, you don't need to mess around with mining pools. You will need to handle complicated settings as these mining software are largely command line software. You can check their help pages (by using the --help option) and look for the options that you want. These are generally ones for setting a username, password, server url, and address. Those are the basic options necessary.


If Bitcoin mining is becoming more and more impractical, what then?

I think you misunderstand the problem. The reason mining is becoming impractical is because there's too much of it. It's like a restaurant that's too crowded. It means you can't get a table, but the restaurant is not going to go out of business.


How does 1ML measure the availability ranking of nodes?

Looks like the problem is found.
I didn`t forwarded 9735 port on router, as LND and my router support UPnP.
But looks like UPnP works not as intended, so sometimes host was accessible on 9735 port, and most of the time not :(.

Now I forwarded 9735 port to my Raspberry Node local address , so  Availability on 1ML not dropping down.


Signing transaction with SSL - private key to PEM

when I verify your self created privkey, I get this error:

  error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long

I couldn't see how you created your privkey, but the way to go is through the ASN.1 structure, and then base64 it.
When using OpenSSL to sign, you must also make sure you are signing hex data, and not strings (this is explained in the answer of the link I provided in my comment).

The ASN1 structure for a privkey looks like this:

# ASN.1 STRUCTURE FOR PRIVATE KEY:
#   30  <-- declares the start of an ASN.1 sequence
#   74  <-- length of following sequence
#   02  <-- declares the start of an integer
#   01  <-- length of integer in bytes (1 byte)
#   01  <-- value of integer (1)
#   04  <-- declares the start of an "octet string"
#   20  <-- length of string to follow (32 bytes)
#           3cd0560f5b27591916c643 ... a738d2e912990dcc573715d2c
#           \--------------------------------------------------/
#            this is the private key
#   a0   <-- declares the start of context-specific tag 0
#   07   <-- length of context-specific tag
#   06   <-- declares the start of an object ID
#   05   <-- length of object ID to follow
#   2b 81 04 00 0a <-- the object ID of the curve secp256k1
#   a1   <-- declares the start of context-specific tag 1
#   44   <-- declares the length of context-sepcifc tag (68 bytes)
#   03   <-- declares the start of a bit string
#   42   <-- length of bit string to follow (66 bytes)
#   00   <-- ??
#            04 f1 44 f0 dc 00 80 af d2 b7 3f 13 37 6c ... 05 49 cd 83 f4 58 56 1e
#            \-------------------------------------------------------------------/
#             this is the public key

Using your privkey, I derived the pukey, and get this pem format:

### use pre defined ASN.1 strings to concatenate PEM privkey
  a pre_string : 30740201010420
  the privkey  : 3cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2c
  a mid_string : a00706052b8104000aa144034200
  the pubkey   : 04BF350D2821375158A608B51E3E898E507FE47F2D2E8C774DE4A9A7EDECF74ED
                 A24243CB992C5673A07FA5B3A66CD8E3ACEF2809D0E380A0C7929DAB1E5D5438B

### base64 privkey file and put some nice surroundings
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIDzQVg9bJ1kZFsZDoLeqadA4OTgKc40ukSmQ3MVzcV0soAcGBSuBBAAK
oUQDQgAEvzUNKCE3UVimCLUePomOUH/kfy0ujHdN5Kmn7ez3TtokJDy5ksVnOgf6
WzpmzY46zvKAnQ44Cgx5Kdqx5dVDiw==
-----END EC PRIVATE KEY-----

using asn1parse, the result looks like this:

openssl asn1parse -in privkey.pem
    0:d=0  hl=2 l= 116 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:3CD0560F5B27591916C643A0B7AA69D03839380A738D2E912990DCC573715D2C
   39:d=1  hl=2 l=   7 cons: cont [ 0 ]
   41:d=2  hl=2 l=   5 prim: OBJECT            :secp256k1
   48:d=1  hl=2 l=  68 cons: cont [ 1 ]
   50:d=2  hl=2 l=  66 prim: BIT STRING

putting all together:

#!/bin/sh
###############################################
# convert from chars to hex
printf $( echo 456f9e1b6184d770f1a240da9a3c4458e55b6b4ba2244dd21404db30b3131b94 | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx.hex

echo "The private key in HEX format: "
echo 3cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2c
# The private key in PEM format:
echo "-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIDzQVg9bJ1kZFsZDoLeqadA4OTgKc40ukSmQ3MVzcV0soAcGBSuBBAAK
oUQDQgAEvzUNKCE3UVimCLUePomOUH/kfy0ujHdN5Kmn7ez3TtokJDy5ksVnOgf6
WzpmzY46zvKAnQ44Cgx5Kdqx5dVDiw==
-----END EC PRIVATE KEY-----" > privkey.pem

# the signing process
#  prepare pubkey:
    openssl ec -in privkey.pem -pubout -out pubkey.pem
#  sign:
    openssl dgst -sign privkey.pem  -sha256 -hex tmp_utx.hex
    openssl dgst -sign privkey.pem  -sha256 tmp_utx.hex > tmp_sig.hex
#  verify:
    openssl dgst -verify pubkey.pem -sha256 -signature tmp_sig.hex tmp_utx.hex

echo " "

returns:

  Verified OK


getrawtransaction doesn't work for every transaction with -txindex=1?

It would appear that when you asked the question the transaction had not been confirmed. They have since been confirmed and they will show up now.


How do you export or save your wallet information for litecoin-qt on ubuntu linux?

File -> Backup wallet

Save your wallet file securely in at least two locations.

Settings -> Encrypt wallet

Ensure that you use a secure password, backup after you encrypt your wallet file if there are no coins in it to ensure its security.


A conflicting transaction has been detected in our memory pool. The transaction hash displayed below may change

There has been some malleability attacks recently - third party duplicating the transactions.

See https://en.bitcoin.it/wiki/Transaction_Malleability for details on the attack technique.

The attack is merely an annoyance as far as I've understood, and there is a BIP in the making (BIP 62) to deal with this attack vector.

Perhaps this explains your problems.


What is the most lightweight proof-of-work algorithm?

Contrary to the name the proof of work used in Litecoin is significantly more difficult than SHA256 to verify (it slows sync times noticeably), while simultaneously not achieving it's goals of being only able to be mined on a CPU, or a GPU depending when you read the pitch on their website. It offers very little resistance to being mined on a GPU or ASIC, in fact its design is extremely well tailored to linear time-memory tradeoffs, which make the hardware cost even cheaper. Being harder to make an ASIC for isn't an asset either, it just means that they become less commodity hardware and more likely a monopoly of one or two players.

SHA256 is about as lightweight and as simple as you can get, avoiding hardware acceleration is not an achievable goal and probably not even desirable even if it were.


How and why increasing and decreasing block size will affect transaction fees?

What any particular change will do to fees is mostly speculation.

A larger block size will not necessarily reduce fees, however, given the current fee model is an auction for limited bandwidth model, it is likely that selling pressure in the auction would be reduced if block sizes were increased. The inverse would be expected initially if blocksize was smaller although, if transaction bandwidth is stifled significantly it also seems likely that consumers may then seek an alternative to Bitcoin since their demand cannot be satisfied. Block size is a delicate balancing act.

Larger block size and a corresponding reduction in fees, if attained, may also harm the mining effort and force miners to seek an alternative as block rewards further reduce in the future. Mining may then no longer be viable even with ASIC hardware.

As I say, much is to speculation.


Why did my Coinbase transaction take 4.5 hours to get in a block?

Brian from Coinbase here.  Sorry you experienced delays!  There have been some issues in the past that we are working to improve.  Coinbase sends a high volume of bitcoin transactions (often in parallel across many machines), and as a result we sometimes encounters issues that are uncommon elsewhere.  In this case, I believe the root of the issue was around spending coins where the inputs were not in a block yet.  We broadcast a large number of transactions, and sometimes other nodes receive them out of order (the transaction that spends the change could arrive before the transaction that generated the change).  The official client, bitcoind, had an issue (unclear whether it was a bug, or intended) where a transaction in the orphan pool that got connected up (it's input transaction finally arrived) did not subsequently get relayed to the rest of the network like a regular transaction.  We've been chatting with Gavin about this to see what solutions could make it into a near term release.

An issue like this could cause it to not be relayed to most/many miners, which is why it would take a long time to make it into a block.

As a short term fix we manually push transactions to well connected nodes like blockchain.info to ensure they are well propagated.  Thanks for bearing with us as we continue improving things. Experiences like this are definitely not what we strive for.  Hope the explanation helps!


This seems to be a variation of Shamir's 3-pass protocol.

I guess that the card trick requires commutative encryption to work, meaning that encrypting with a key K_1 and then with another key K_2 will produce the same result as encrypting with K_2 and then K_1.

Most public-key encryption algorithms do NOT have this feature (at least, RSA and Elgamal do not).


Is there a way to not pay the transaction fees when using the standard Bitcoin client?

Yes, however the answer is a bit more advanced than for your everyday consumer:

It is recommended to have some knowledge of JSON if using this method

WORD OF WARNING: Using this method can cause large amounts of inputs being set as miners fees. I suggest you continue with caution and start by using small inputs.

That being said...

A transaction must be compiled and submitted via the bitcoin-qt console using the commands listunspent, createrawtransaction, signrawtransaction and submitrawtransaction.

To access the Bitcoin-qt console:

launch your bitcoin client as usual and wait for it to load the blockchain and start up
click on 'help' in the menu bar (top right)
click on 'debug window'
select the 'console' tab

Use listunspent to get an array of you spendable inputs in your wallet
This is where you set you transaction fee: Use createrawtransaction to generate a transaction in the form createrawtransaction [{\"txid\":\"[txid of the input transaction]\",\"vout\":[vout that relates to the txid of the input transaction]},...] {\"[address to send your bitcoins to]\":[amount of bitcoins to send to this address],...} If you want a no fee transaction you must make sure all inputs equal the output. All inputs that are not spent in a transaction are used as miners fees.
Use signrawtransaction [the output of createrawtransaction] to sign your generated transaction Note: Your wallet must be unlocked to perform this command. If not type walletpassphrase [your passphrase] 21600
Use submitrawtransaction [the output of signrawtransaction] to send your signed transaction to the network to be included into a block

You can see your transaction by going to http://blockchain.info/tx/[txid output from submitrawtrasaction]


You don't entirely have to trust the owner of the site. The site is client side Javascript based, which means you can probably save a copy of the code, then review it, and run it offline.

If you continue to use the website though, you're trusting the owner of the site to:

Not change the code in any way that compromises the security of the private key
Maintain adequate security so that no hacker can change the code in any way that compromises the security of the private key


No, not to my knowledge. Also, it doesn’t make sense to me to want to incorporate all these different aspects into one device.

Mining devices need to run continuously and produce a lot of noise and heat. They also need to be replaced eventually, as they get obsoleted by better technology. As such, they are most cost efficient if they just focus on the mining algorithm.

While full nodes also run continuously, they can run on fairly small machines more suited to quieter environments. They run more complicated software than the miners and need to have software updates frequently, while the hardware can last.

You don’t want wallets that store large amounts to run all the time, as that increases the exposure to potential theft. Wallets for daily spending tend to be thin wallets which will catch up with the network quickly whenever you need them to, which also is beneficial for running them on small devices that you can carry around.

Decentralized exchanges are even harder. In a way, these are covered by mobile wallets in that they allow users to meet up and trade directly. The challenge with decentralized exchange systems is the interfacing with fiat currencies. I don’t think there is a widely popular solution yet, and it doesn’t appear likely that a majority should be running any such solution.


How to make sure, Bitcoin private key and bitcoin address generator tools are generating valid key pair?

you need to make sure that the private is lower than 1.158 * 10^77 (115792089237316195423570985008687907852837564279074904382605163141518161494337) and

In your case you could do

 import random, keyUtils
 private_key = ''.join(['%x' %random.randrange(16) for x in range(0, 64)])
 print keyUtils.privateKeyToWif(private_key)
 print keyUtils.keyToAddr(private_key)

 from ecdsa.curves import SECP256k1
 decoded_private_key = int(private_key,16)
 if decoded_private_key > 0 and  decoded_private_key < SECP256k1.generator.order():
     print 'valid'
 else:
     print 'invalid'


BOLT 11 - Why is the description field limited to 639 bytes?

Why is the description field limited to 639 bytes?

Every field in lightning invoice is of the form:

type (5 bits)
data_length (10 bits, big-endian)
data (data_length x 5 bits)

The data_length indicates the size of the data that is to be followed. Since data_length itself has a size of 10 bits, it can represent a number up to 1023 (210 -1). Thus the size of data can be at most 1023*5 bits or 639.375 bytes. This puts the upper limit of 639 bytes on the description field.


How can I make this PHP merkle root script recursive?

Your script was a good attempt at this! I modified made it recursive with some very small changes.

Typically when designing a recursive function, it checks whether the state represents a complete computation, otherwise it runs some code and calls itself again. Your function was missing this part.

It also seemed to be computing the hashes incorrectly - the hashing operation is SHA256(SHA256($pair)). I refactored out the function binFlipByteOrder(), which only works on binary, so we can flip the hash before rendering it as hex.

<?php

function binFlipByteOrder($string) {
    return implode('', array_reverse(str_split($string, 1)));
}

function merkleroot($txids) {

    // Check for when the result is ready, otherwise recursion
    if (count($txids) === 1) {
        return $txids[0];
    }

    // Calculate the next row of hashes
    $pairhashes = [];
    while (count($txids) > 0) {
        if (count($txids) >= 2) {
            // Get first two
            $pair_first = $txids[0];
            $pair_second = $txids[1];

            // Hash them
            $pair = $pair_first.$pair_second;
            $pairhashes[] = hash('sha256', hash('sha256', $pair, true), true);

            // Remove those two from the array
            unset($txids[0]);
            unset($txids[1]);

            // Re-set the indexes (the above just nullifies the values) and make a new array without the original first two slots.
            $txids = array_values($txids);
        }

        if (count($txids) == 1) {
            // Get the first one twice
            $pair_first = $txids[0];
            $pair_second = $txids[0];

            // Hash it with itself
            $pair = $pair_first.$pair_second;
            $pairhashes[] = hash('sha256', hash('sha256', $pair, true), true);

            // Remove it from the array
            unset($txids[0]);

            // Re-set the indexes (the above just nullifies the values) and make a new array without the original first two slots.
            $txids = array_values($txids);
        }
    }

    return merkleroot($pairhashes);
}

$txids = array(
    'AB7ED423933FE5413DC51B1041A58FD8AF0CD70491B1CE607CB41DDDCE74A92B',
    'C763E59A79C9F1E626DDF1C3E9F20F234959C457FF82918F7B24E9D18A12DB99',
    '80EA3E647AEEF92973F5414E0CAA1721C7B42345B99ED161DD505ACC41F5516B',
    '1B72EEFD70CE0A362EC0CB48E2213274DF3C55F9DABD5806CDC087A335498CD3',
    '23E13370F6D59E2D7C7A9CA604B872312DE34A387BD7DECA2C8F4486F7E66173',
    '149A098D6261B7F9359A572D797C4A41B62378836A14093912618B15644BA402',
);

$txidsBEbinary = [];
foreach ($txids as $txidBE) {
    // covert to binary, then flip
    $txidsBEbinary[] = binFlipByteOrder(hex2bin($txidBE));
}
$root = merkleroot($txidsBEbinary);

echo bin2hex(binFlipByteOrder($root)) . PHP_EOL;


(Actually that's a deep, political question, but I'll answer it neutrally)

  Why is this? Why don't we remove the size limit?

As Nate Elredge said, miners can create free transactions. RIP Blockchain.
The limit also protects the blockchain from spam attacks - the dust transactions stay in the mempool.

  It sounds like a simple problem that has a easy solution

Hard forks. It may take until forever to wait for people upgrading their nodes compatible with the HF. Also SegWit is a clever trick: "block size increase as a soft fork". In the future, the witness blocks' size can be increased so that Bitcoin won't need a block size increase anymore. (Actually this needs another complex trick, like SegWit)

  Wouldn't miners make more coins from the extra fees from the extra transactions in each block?

Nope. If blocks were bigger, the users would set lower fees and the miners would earn the same.

  What our are other solutions?

Schnorr. A signature system that is much more size (bytes) efficient. This would require a hard fork (or another soft-fork trick), but would work. Or as I said above, a newer version of SegWit that increases witness block size. Or maybe FlexTrans, a compressed transaction format (It looks like Bitcoin won't have it.) Or the most likely one: Layer two solutions: Lightning network, Liquid... They'll allow low fee instant payments, while keeping blockchain size low.


how to get block information using node js

The function client.getBlockchainInformation and the other methods exposed by the bitcoin-core npm module use bitcoin-core's REST interface. In order to use it, however, it must be enabled when you start bitcoind with the -rest flag.

  The REST API can be enabled with the -rest option.

  The interface runs on the same port as the JSON-RPC interface, by
  default port 8332 for mainnet, port 18332 for testnet, and port 18443
  for regtest.

e.g.:

$ bitcoind -rest

or in bitcoin.conf

rest=1


Can a clever hacker still steal everyone's money from the blockchain.info wallet?

They anticipated this type of attack and they are monitoring their JavaScript files, check this website of theirs http://blockchain-status.com/javascript_verifier

Also, CloudFlare (the reverse proxy they use) can modify the Javascript on the fly (CloudFlare is at the other end of the encryption for your browser, so SSL here only secures the connection between you and the CloudFlare machines, and optionally CloudFlare to Blockchain.info, you're not directly connecting to Blockchain)

It is true that the client-side script does not send the password to the server but you actually need to send your wallet password to use their old wallet API (it's being deprecated) and if a hacker can somehow control their servers, it is possible that the hackers can read the unencrypted wallet from the memory without having to inject malicious client scripts, even if we assume they are not saving them to the disk.


Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA).  Your private key is used to create the signature and your public key is used to verify the signature.  This allows anybody to verify your signature as long as they have your public key.

For more detailed information: Digital Signature Algorithm and Elliptic Curve DSA


Ubuntu. (blockchain of version 0.9.3 compatible with 0.10.1?)

In the official release announcement here:
https://bitcointalk.org/index.php?topic=1039713.msg11211433#msg11211433

Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software*

So upgrading works fine, but if you later decide to downgrade the block and database files won't be compatible.


What are the mining spec differences between Bitcoin and Litecoin?

Primarily the differences between Litecoin and Bitcoin are reduced block generation time and use of scrypt in place of SHA256.

It's not the Litecoin requires less power as much as the difficulty rate is much lower due to less mining power. Bitcoins used to be mined on CPUs, but the introduction of GPU mining essentially put that to an end.


How to get BIP34Hash and nMinimumChainWork?

The BIP 34 hash is the block hash at which BIP 34 was fully activated and all blocks less than version 2 were rejected as invalid.

nMinimumChainWork is a value that is updated at every release. It is retrieved from the getblockchaininfo RPC of a node that is up at the time of release. nMinimumChainWork is updated at the same time as assumevalid. It is calculated by summing the work done in each block which is calculated by doing 2^256/(target+1)


Bitcoind (linux) CPU usage through the roof

From the description you are giving it sounds like you haven't yet synchronized with the network. Before you can start doing anything useful, e.g., see your current balance, the bitcoind client downloads the entire blockchain and verifies it. This may take quite some time and will likely keep your CPU busy until its done. You can check the progress of the synchronization by issuing a bitcoind getinfo and checking the blockchain height with blockchain.info or similar site.


Taproot, potential quantum bug, and general clarification

See Pieter's responses.
(1) seems ok
(2) Mark's concern is real, but worry about exposing the tweaked pubkey doesn't seem to be of a high concern to people supporting Taproot. In ref to Taproot exposing pubkey, "numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier)."
"TL;DR: public keys should be public."
Quotes from:
What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?


given a json of a block, how do I calculate its hash?

As described on the wiki page about block hashing, the 2xSHA256 hash is taken of the block's header only (not the transactions in it): 80 bytes, consisting of the version, previous block hash, tx merkle root, time, bits and nonce.

Direct quote from that page :

>>> import hashlib
>>> header_hex = ("01000000" +
  "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
  "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
  "c7f5d74d" +
  "f2b9441a" +
   "42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'


Blockr.io - how to decode a transaction via API

Hex is request body param not query param.


How can I get the whole info for a transaction whose outputs are spent?

If I understand the question correctly, what you’re looking for is a “txindex=1” in your ‘bitcoin.conf’. It allows you to run ‘getrawtransaction’ to recall transactions that don’t spend from your wallet/don’t pay to your wallet/are not in the mempool. Furthermore, it’s named “Index transactions by TXID”.


Create a 2-of-3 multisig raw transaction

You almost have it, you just need to make sure you are creating a transaction with an output that your wallet can sign.

Example (on regtest)

bitcoin-cli -regtest addmultisigaddress 2 '["02983a79d2de8e504d00ddd2343b582acef7e17ed91b308ade8dff027a92e7716d","03548ca1916957bc06dd1c6e3639ebf7b2c3c8b1715915433c1d37cab56fb26ef0","0218a240a599ba437cb1458966eb456d9f848e5bdef45ea0ee4ec31fc40aa4ffa8"]'
￼
{
  "address": "2NA1HC31wqFexbpp8bGB6rsMR5Lz9SrUKkt",
  "redeemScript": "522102983a79d2de8e504d00ddd2343b582acef7e17ed91b308ade8dff027a92e7716d2103548ca1916957bc06dd1c6e3639ebf7b2c3c8b1715915433c1d37cab56fb26ef0210218a240a599ba437cb1458966eb456d9f848e5bdef45ea0ee4ec31fc40aa4ffa853ae"
}
￼
bitcoin-cli -regtest getnewaddress
￼
2NAsEawSCjsjJjtAZcpP9jhXojqNUevjo63
￼
bitcoin-cli -regtest generatetoaddress 110 2NAsEawSCjsjJjtAZcpP9jhXojqNUevjo63
￼
[
  "7e974615714bdcee6f4c69ea158b92fe2c0b728742110737e7ff13d9e8eb49ad",
  ...
]
￼
bitcoin-cli -regtest listunspent
￼
[
  ...
  {
    "txid": "9c9298a5d7ceca73f657110c0222ee606324263694d59722a2194b22ccc8b0ff",
    "vout": 0,
    "address": "2NAsEawSCjsjJjtAZcpP9jhXojqNUevjo63",
    "label": "",
    "redeemScript": "0014821824c23b9c82fa639789bc3314194d1e44ec4a",
    "scriptPubKey": "a914c1499c99d26f5bb7101f1213747bf730c4b9346287",
    "amount": 50.00000000,
    "confirmations": 102,
    "spendable": true,
    "solvable": true,
    "desc": "sh(wpkh([29b8db74/0'/0'/0']03557ff8751b55175307c0550460694dfe3c84598672fe5b9c53dca71bcb9122ee))#25k8n2ql",
    "safe": true
  }
]
￼
bitcoin-cli -regtest createrawtransaction '[{"txid" : "9c9298a5d7ceca73f657110c0222ee606324263694d59722a2194b22ccc8b0ff","vout":0}]' '{"2NA1HC31wqFexbpp8bGB6rsMR5Lz9SrUKkt":49.999}'
￼
0200000001ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000000ffffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d48700000000
￼
bitcoin-cli -regtest signrawtransactionwithwallet 0200000001ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000000ffffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d48700000000
￼
{
  "hex": "02000000000101ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000017160014821824c23b9c82fa639789bc3314194d1e44ec4affffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d487024730440220249224a99d24a0ae1d91328ea2e8da0936916ea31a28e35013de003af72f658d02201c48618283ac00a8c5b362e8ade530f4cfacd396a99ab78081cea2d18ad8d165012103557ff8751b55175307c0550460694dfe3c84598672fe5b9c53dca71bcb9122ee00000000",
  "complete": true
}

bitcoin-cli -regtest sendrawtransaction 02000000000101ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000017160014821824c23b9c82fa639789bc3314194d1e44ec4affffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d487024730440220249224a99d24a0ae1d91328ea2e8da0936916ea31a28e35013de003af72f658d02201c48618283ac00a8c5b362e8ade530f4cfacd396a99ab78081cea2d18ad8d165012103557ff8751b55175307c0550460694dfe3c84598672fe5b9c53dca71bcb9122ee00000000

8b0cd4413dad3e1f02f7344236ba4b3d1994c3cd3bbdda1acc9b2d2c0e184453


Satoshi Nakamoto's Transaction Chain Diagram Hash Value

Can anyone confirm exactly how the Hash value shown is computed

By taking the raw data for the transaction (as in the bytes that are sent over the wire for the transaction) and passing it through a hash function. For Bitcoin, that is SHA-256 double (SHA-256 done twice).

  and whether or not it contains the previous owner's signature?

It depends. For simplicity's sake, you could say that it contains the previous owner's signature.

However, due to the activation of segwit, it does not always contain the signature. For segwit, the hash is not actually the hash of the entire transaction but rather parts of it that are non-segwit. Transactions that are non-segwit will have the signatures as part of the hashed data.


With existing standards and wallets, no, that is not possible.

Existing standards such as BIP 39 do not directly use the value encoded by the words to produce a BIP 32 HD seed for use in a wallet. Instead they hash the words.

Furthermore, wallets that import that mnemonic do not just use the BIP 32 HD seed from it directly. Instead they use it with derivation paths and derive child keys from it.

If you produced a mnemonic from an individual private key, importing it into any existing wallet would not result in your private key being imported. You would end up with things derived from that private key, but that is not useful to you.

Instead of a mnemonic sentence, what you really want are the Wallet Import Format (WIF) private keys that most wallets can export. WIF is a standard way to encode individual private keys so just use that instead.


If anyone with your seed phrase can generate your wallet private keys, what is the advantage of a hardware wallet?

Well, in both cases, your seed words are ultimately the key to the wallet.

If you use a regular wallet, you open yourself up to a number of other attacks

Malware on the device that runs the software wallet
Keyloggers
People shoulder surfing
Backdoored wallet software

Moreover, larger OSes like Windows, Linux, and Mac OS have considerably larger attack vectors than a hardware wallet. Someone may gain access to your machine through some completely unrelated.

A hardware wallet not only minimizes the attack surface, it also makes use of secure elements (the good ones, anyways), which are specifically designed to prevent exfiltration of things like keys. Most computers do not have similar hardware.

Moreover, since the seed generation happens on the hardware wallet, the seed does not pass through a potentially compromised computer. Of course, one must trust that the hardware wallet is honest, which is why it is better to stick with reputable ones, such as Trezor and Ledger.


How to get Coinbase Text for newly found block

Certainly. Use bitcoin-cli getblock <hash> 2 to get the full details of a block (you may want to pipe the output to less as there will be a lot of output). The first transaction in the block (the first transaction in the array tx) is the coinbase transaction. In there, there is a field labeled coinbase. That contains the hex of the bytes of whatever data miners are putting there in the transaction. Drop the hex into whatever Hex to Ascii converter you want and you will get text. Note that some miners may not include readable text in their coinbases.


get the private key for change addresses

I think you can do this by using the bitcoind JSON-RPC interface.

The following links should be helpful:

https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list

Identify the change address by looking at the transaction in question and then use "dumpprivkey ".

My understanding is that bitcoind is creating the change address every time you do a transaction where the change is greater than 0.0.


How does a difficulty increase affect a miner's income?

Your profit relates to the amount of hashing power you contribute to the network. Since your mining power is constant, your share of the total hashing power decreases relatively when the network's hashing power increases. I.e. we can deduce the following formula:

newProfit = currentProfit * currentDiff/newDiff.

At a currentProfit of 1BTC/d and a 30% increase in difficulty, you get:

(1BTC/d)*100/(100+30)= (1BTC/d)/1.3 = 0.76923077 BTC/d

i.e. your profit decreases by ~23%.


Most secure way of sending bitcoins from bitcoin-qt offline wallet

I don't think that is really a problem, but first of all why do you want to use a Linux Live boot? Is that to disable possibly installed malware? When you send your transaction make sure that you install your temporary bitcoin client on a persistent drive, e.g. not on the computers RAM (this will take a lot of time, so better clear out your computer instead of this approach). Your private key will be generated before you send your transaction, so you can't lose it when power shuts of.

This won't save you of course when power shuts down and your hard-drive crashes at the same moment, but when you are dealing with large amounts of bitcoins you could probably use some RAID configuration (e.g. RAID-1) for your hard-drives and still be fine. Or you could buy an external power source as backup.


Public bitcoin node accessible to web code?

You can't do that using Bitcoin-core. What you can do as an alternative is using electrum servers.

You can find all the information about using it and commands in here.

Features:

Broadcast transactions.
Getting legacy address transactions, unspent and balance.
Free and public and there are many available peers.
open source (python).

If you want to get segwit address balance, transactions.. you should convert it to script hash first.

Note: using third party APIs & servers are less secure than running a self-hosted full node. It's recommended to avoid third-parties when you deal with money.


Why is the longest block the one that gets accepted by all the nodes?

The problem here lies in a misunderstanding. It's not the longest block that wins out, but the longest blockchain (read "the blockchain with the most cumulative difficulty"). The length of a single block is hereby irrelevant and in fact usually the node that first confirms a set of transactions wins.


Is there any Cryto exchange that supports automatic sale when profit above X % and buy again when price drop to previous price and repeat this cycle?

I think it will be better to divide your deposit into two parts. Half in USD and another half in BTC. First bot tries to maximize your profit in USD. Second - in BTC. Any price moving makes you rich


Is CheckSequenceVerify only a stop-gap measure?

CSV is not a stop-gap solution. Before you can say that, you first need to define what the problem is.

CSV solves the problem that you can't use CLTV in contracts that need a spending delay where the output itself will not be broadcast for an unknown amount of time. This is a very abstract problem, but it does occur as a primitive inside more complex constructions.

However, the current Thunder implementation uses a stop-gap solution to transaction malleability, which just happens to rely on CSV.


In the same special "generation transaction" that collects the 25 newly minted bitcoins, the miner also collects the total of all the transaction fees in the block, and together can send them to an address(es) of his choosing.

No signature is required; it's a hardcoded perk to whoever manages to find a block.


What are the risks of in-person private currency exchanging for travellers?

I think that "personal safety risks" are outside the scope of this website, so I'll mention the technical risk - double spend. If you don't wait for one confirmation, a double spent attack can be performed, and you won't get your Bitcoins.

Luckily, you'll only have to wait five ten minutes on average for a block to be found (blocks are one every ten minutes, so the expected delay until the next block is five minutes).

After one confirmation, it's very unlikely such a small transaction will be double spent. If you want to increase your security, wait another block or two.

Traveller A doesn't need to have internet, he can use a Pimpcoin-like card (link NSFW), with SMS notifications of incoming transactions.


Bitcoin Core mempool after disconnecting a block

When a block is disconnected, its transactions are added back to the mempool (where possible). If the new branch connected afterwards does not remove them again, they remain there, and will be picked up by the block construction code.


How do you derive the public key from you random 256-bits integer?

The curve's base point is a well-known constant. Since Bitcoin uses SECp256k1, the base point is:

04 (uncompressed point)

79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9
59F2815B 16F81798 (first coordinate)

483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448
A6855419 9C47D08F FB10D4B8 (second coordinate)

(See page 15 of my link.)

The private key is an integer from which you can derive the public key and produce signatures that can be verified with the public key.


BIP148 isn't relevant any more, since BIP91 has activated on July 23.


Why isn't Bitcoin-QT or any other Bitcoin related app on the App Store for Mac?

As far as I know, there have been no submissions of Bitcoin apps to the Mac App Store.

A Bitcoin app for iOS was submitted to the App Store in May 2011 by Ehud Ben-Reiven. He reported that it was rejected because "...it involves intermediate currency...". He subsequently open-sourced the code, bitcoinApp, but, as of this writing, it hasn't been updated in years.

Blockchain.info had some success in submitting an Blockchain app which uses the site's API to do all the heavy work. However, it was removed without reason in May 2012 and later restored in August 2012. This app relies on Blockchain.info as a hosted wallet, though, and is not a fat client.

TL;DR Apple disallows Bitcoin clients because it considers Bitcoin to be an "intermediate currency".

Speculative TL;DR Apple disallows Bitcoin clients directly because it's a payments system that circumvents Apple's desire to take a cut of all money that flows within its app ecosystem. It's not known how Venmo and other payment networks are allowed to circumvent that, if they even do.


Such transactions are located only with the transaction creator. Nodes generally do not keep in their mempool transactions that cannot be immediately mined.


Simple example, using Python 3 and the websocket-client library.

from websocket import create_connection

ws = create_connection("wss://ws.blockchain.info/inv")
ws.send("""{"op":"unconfirmed_sub"}""")
while True:
    tx = ws.recv()
    print("tx!")
    with open("bitcointx.json", "a") as f:
        f.write(tx + "\n####\n")


Can't use Bittrex Exchange python-bittrex api call: no output

Try...

balance = api.get_balances()
print balance


The Blockchain.info API includes Bitcoind as a JSON webservice. It's pretty cool.


How i can extract all bitcoin output addresses from tx message?

Most of the output addresses follow one of the following 'standard outputs':

Legacy Outputs

P2PK: scriptPubKey: <public_key> OP_CHECKSIG. Output pays the public key directly and hence does not have a direct address.
P2PKH: scriptPubKey: OP_DUP OP_HASH160 <hash160 of pubkey> OP_EQUALVERIFY OP_CHECKSIG. For this kind of output you just need to base58check the hash160 of pubkey with version 0x00 and you will get the addresses that starts with 1.
P2SH: scriptPubKey: OP_HASH160 <redeem_script> OP_EQUAL. You again need to just base58check the redeem_script with version 0x05 and you will get an address starting with 3.
Multisig: scriptPubKey: M <public_key1>...<public_keyN> N OP_CHECKMULTISIG. In this case, you cannot get the addresses as the output pays the public keys directly.

Segwit Outputs

P2WPKH: scriptPubKey: <0x00 (version)> <hash160 of pubkey>. You will need to create a bech32 address using the version and 20-byte redeem script and you will get an address starting with bc1. You can find the python script for bech32 encoding here.
P2SH: scriptPubKey <version: 0x00> <sha256 of redeem_script>. Again a bech32 address starting bc1 but the redeem_script is 32 bytes rather than 20 bytes for P2WPKH.
P2SH(P2WPKH): scriptPubKey: OP_HASH160 <redeem_script > OP_EQUAL. The encoding is same as legacy P2SH. Base58check with 0x05 version. For a more detailed overview on how the 'redeem_script` and addresses are generated for P2SH(P2WPKH) see my other answer here.

OP_RETURN

Many times people like to encode some data in the Bitcoin blockchain. For that, you use a OP_RETURN opcode. The scriptPubKey:<OP_RETURN><OP_PUSHDATA1><bytes to push><script>.


How does number of transactions in the block affect it's mining time?

The number of transaction in a block negligibly effects the mining time. The only effect is that more computations need to be done to calculate the merkle root during block construction, but that is a very small fraction of the number of calculations needed to be done during mining itself. Mining only hashes a fixed amount of data so including more or less transactions does not really make a difference.


Can I get the same stats as are on blockchain.info and btc.com by running a full node?

"Relayed By"

Bitcoin Core doesn't track which node relayed a transaction, and I doubt most other nodes do either.  In addition, this information is likely to be different for different nodes as each one may first receive a transaction from a different peer.

  figure out hash rate of specific mining pool as a % of total in the real time

Full nodes don't have the information necessary to determine anything about mining in real time as they only receive information about blocks when those blocks are distributed (on average every 10 minutes, but with high variance).  Because block finding is so variable, it's additionally necessary to average results over large numbers of blocks to get reasonably accurate numbers, meaning the statistics you typically see are either trailing actual block production by several days or are probably quite inaccurate.

In addition, miners don't have to identify themselves in the blocks they create, and the way they do optionally identify themselves is not standardized, so no stock full node provides any method for telling you which miner created which block.


How do I generate a bootstrap file on Ubuntu?

Find your local blockchain:

cd ~/.bitcoin/blocks

Or, to bootstrap testnet, find your local testnet blockchain:

cd ~/.bitcoin/testnet3/blocks

Concatenate all your blkxxxxx.dat files and place the result in bootstrap.dat:

cat blk* > bootstrap.dat

Warning: Using tar -cf (as instructed by this answer) did not work for me.  I'm importing from bitcoind into btcd.


How do you build a Ripple gateway without rippled?

The documentation does assume you will run a local server. But anyone can build a gateway, with or without the server. To operate a gateway, you really only need to be able to process transactions just like a client does. When a transaction happens you need to know. When you need to perform a transaction, you need to perform it.

Probably the easiest way to do it is to implement the gateway's interface to the Ripple network using JavaScript and node.js -- this lets you use ripple-lib which is a supported, open source interface to the Ripple network.

If you do decide to run your own server, nothing really needs to change. Just point your gateway interface to your local server instead of the public server pool.

Whatever you do, please don't send your secrets to the public server pool. If you use ripple-lib, make sure local signing is on. If you use anything else, use ripple-lib's rsign.js program to sign transactions for you.


What are the potential security issues when running a Lightning Node on my home network?

This is not only related to Lightning but remains true for any critical application that you run on your PC when connected to your home network. If your home network is compromised then an attacker can possibly escalate privileges and compromise the machine on which your lightning node is running (as well as other critical applications). Lightning is thought to be analogous to how you carry cash in your wallet. It helps you make small transaction very easily while at the same time it is not the end of the world if you lose that cash from your wallet. Your major saving are stored in the bank, just like how you will use a hardware wallet to store your major Bitcoin savings. I can think of the below few cases at the top of my mind.

Send payment to any lightning node
Your lightning node has to continuously sign new commitment transactions in order to add incoming HTLCs and fulfill HTLC payments. As a result, the private keys associated with signing new transactions in the channel are exposed to an application that is continuously interacting with your home network. In case your machine gets compromised like we discussed before, your private keys are no longer safe. Thus, these keys can be used to send a lightning payment to any node that is indirectly connected to you.

Force close your channel
Since the transaction backups are kept on the machine that interacts with the home network, an attacker who has gotten access to your machine can use one of the transaction backups and broadcast it to the Bitcoin network costing you high fees as compared to a mutual settlement (in case you were the funder).

Broadcast previous commitment transaction state
The attacker might also broadcast previous transaction state making you lose almost entire balance of the channel through the revocation transaction.

Force crash your node and delete backup files
Unlike bitcoin stored in an on-chain wallet, funds in the lightning network are stateful. If you do not have backups and your channel counterparty is non-responsive, you will likely experience permanent loss of funds. This could be slightly mitigated by using the option_data_loss_protect feature, but that heavily depends that your counterparty node is honest.

The best practice will be to keep your machine clean from any shady applications, use a reputed anti-malware services and do not give share your home network Wi-Fi password.


How to resynchronize all blocks using `bitcoin-cli`?

-rescan is for your wallet. It will check for missing transactions on startup. If you want to resynchronize all blocks then I think you want to use -reindex which will rebuild chain state and block index from the blk*.dat files on disk. Of course, these are command line parameters.

You can probably use verifychain on bitcoin-cli. Type bitcoin-cli help verifychain for information.


What to do when you bought in BTC and the product hasn't been delivered

Bitcoin is non refundable. What you can do is use sites such as Trustpilot to register your complaint. Also leave a review on Google.


Are there alternatives to Bitcoin which take a different approach?

There are "digital bearer certificate" systems, which are an older concept.  They require a centralized issuer in order to prevent double-spending.  You can think of the certificates as electronic IOUs for a commodity (such as gold) held by the issuer.

Some DBC systems implement Chaumian blinding to anonymize transactions.

Open Transactions is a recent DBC system that has gained some interest.  It could be used with Bitcoin as a backing commodity, taking advantage of the properties of both systems.


How to open new wallet into Bitcoin Core and switch between?

the funds are linked to your "compromised" keys. They are not in your wallet. So you can generate a new set of keys (as you mentioned, by creating a new wallet), and then transfer from old address to new address. Before you start anything, think of backups! Procedure might be like this (attention: wallet dirs on Windows, Unix and OSX locations differ, depending on your OS, you may want to adopt):

0.) stop bitcoind or UI
1.) backup of old (compromised) wallet to USB stick
2.) rename bitcoin wallet directory to s.th. like "OLD_bitcoin_dir"
3.) start bitcoin (it will create new wallet and keys, get one of the public keys via MENU->FILE->RECEIVE ADDRESSES, cut&paste or write it down)
4.) stop bitcoind or UI
5.) rename wallet directory to s.th. like "NEW_bitcoin_dir"
6.) rename wallet directory "OLD_bitcoin_dir" to your original name
7.) start bitcoin
8.) transfer your funds to your new address from step 3
9.) wait until you "see" in a block explorer your funds on the new address
10.) stop bitcoin
11.) delete wallet dir
12.) rename wallet directory "NEW_bitcoin_dir" to your original name
13.) check if funds are all there
14.) don't forget to backup again :-)

Hope this is the way to go, if there is an easier way within Bitcoin Core, I'd be happy to hear from the experts...