What happens if the commitment tx fee is too low?

Only if the state changes fees are negotiated (and for mutual closing the channel) so in case the onchain fees change and the channel is not used for a long time just send a fake payment hash to adapt to onchain fees.

Regarding 2 and 3. Nothing Alice can do. She just has to wait until the traffic on chain decreases. There are some ideas to include a dust level anyone can spend output to the commitment tx without timelock which could use cpfp


What is the default number of transactions a full node have in its mempool?

The memory pool (mempool) is not limited to a specific transaction count, but limited by the amount of data the deserialized transactions take up in the node's memory. The default memory pool limit is 300 MB. The limit can be configured by passing -maxmempool <n> where the n is the number of megabytes allowed.


Zcash transparent addresses can be generated in the usual BIP 44 way. There is a Zcash coin_type defined in SLIP 44, which can be used with any standard Bitcoin library. The resulting transparent addresses just need to be re-encoded with the Zcash transparent address prefix for mainnet.

There is currently no library for generating Zcash shielded addresses deterministically. We are working on ZIP 32 which will define how to generate Sprout and Sapling shielded addresses from a seed. In practice, this will be the same seed used for transparent addresses.


Have you tried CMC's REST API? https://coinmarketcap.com/api/


Can new OP codes be added with a soft fork?

Yes. Before P2SH, the most popular proposal for solving the problem that P2SH solves was OP_EVAL, which did just that: it repurposed OP_NOP1 as OP_EVAL.

A P2SH script looks like this:
[script input...] [serialized script] | OP_HASH160 [script hash] OP_EQUAL
The equivalent OP_EVAL script would look like this to old nodes:
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_NOP1
Old nodes would only check that the serialized script matches the given script hash when hashed. The other stuff would be ignored.

New nodes would see:
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_EVAL
New nodes would understand OP_EVAL, so they'd check that the serialized script matches the given script and execute the serialized script. An OP_EVAL transaction might be seen as invalid for new nodes and valid for old nodes, but not the other way around. That's what makes it a softfork. If the majority of mining power is using the new rules, then this is not a hardfork because the longest chain will always converge to a state that is valid for both old and new nodes.

Depending on the new opcode's behavior, it may be necessary for new nodes to verify scripts twice to ensure that certain scripts can't cause hardforks. Scripts are verified once using the old script rules and once using the new rules.

The OP_EVAL proposal was eventually replaced with P2SH because it was discovered that OP_EVAL accidentally allowed Turing-complete scripts, which the Bitcoin developers didn't want. P2SH is very simple (and a bit weird) in part so that similar accidents would be easy to avoid. But there wasn't any technical problem with this method of adding a new opcode. Moreover, there's nothing restricting the behavior of new opcodes. For example, OP_EVAL could have interpreted its input in a different, Turing-complete language, though there are various reasons why this might not have been a good idea.


Unconfirmed balance in MultiBit HD plus unconfirmed transactions (failed bitpay orders)

Following this suggestion in the GitHub issues page solved the unconfirmed balance in MultiBit HD.

I performed the following in Windows 10:

Closed the MultiBit HD Application
Navigated to the wallet data in %AppData%\MultiBitHD\
Rename the folder mbhd-12345678-... to old-mbhd-12345678-...
Reopen the MultiBit HD Application.
Restored from wallet words (Requires words and datestamp).

Note: I did not have to close the application during synchronization like the GitHub comment suggested.
After synchronization, the unconfirmed balance was then confirmed. I was then able to transfer my balance to another address and software.

At the time it just appears to have been an over flooding of transactions making confirmation slow especially with my low fees (0.1 mbtc, 0.5 mbtc, 0.75 mbtc). Wallet balance transfer and the two unconfirmed transactions have been processed and confirmed.


Can free bitcoins from faucets be actually spent?

You could consider creating a new address with 0.01 BTC on it, then sending the concatenated amount at 0 trx fee to each of the addresses containing the smaller amounts.

So:

0.01 -> first address
First address (now including the 0.01) -> second address
second address (now including the 0.01+first address -> third address

... ad nauseum.


Replace-by-fee means transactions spending the same coin to the same addresses are not considered double-spends by the network and are still relayed, as long as they pay a higher fee than the preceding transaction.

Example:
Alice pays Bob with a coin worth 1 BTC, sending 0.5 BTC to Bob, 0.49995 BTC to herself as change, and 0.00005 BTC to fees. Alice sees that her transaction is quite slow to confirm, so she sends an identical transaction (spending the same coin), but with twice the fee. The network relays the updated transaction and rational miners quickly mine the higher fee transaction.

Child pays for parent means, as the name implies, that spending an unconfirmed transaction will cause miners to consider confirming the parent transaction in order to get the fees from the child transaction included in the same block.

Example: Eve spends 1 BTC at a shop owned by Alice. But Eve is greedy: she only pays the bare minimum fee, and her transaction will take hours to confirm. Alice spends Eve's transaction to her banker Bob, but this time with a higher fee. Miners will now want to confirm Eve's cheap transaction in order to be able to include Alice's more rewarding transaction in their block.

RBF is currently live since 0.12, but is opt-in for the spender: Unless the spender marks the transaction as replaceable with a non-maximal sequence number, the transaction is final.

CPFP is not a change in the protocol, but in miner strategy.
Since it is rational for miners to implement it (they make more money), it is expected that most miners do implement it. At least Eligius seems to have implemented it. As mentioned by Pieter in the comments, any miner using version 0.13 or above will mine using CPFP rules.

Which one should you use?

If you're the spender and want your transaction to confirm faster, use RBF. If you received a payment and are unable to convince the sender to up the fee, or the transaction is marked as non-replaceable, use CPFP.

Better yet, send your transaction with the proper fee the first time.


Difference between Bitcoin blockchain and Ripple ledger?

Ripple ledger stores history of ledgers 0 to N or it stores only N?

That's just a matter of definition. You can define the ledger to be just a single state of the network with a single sequence number. Or you can define the ledger to be every past state of the network as well.

Most commonly, we use the term "ledger" to refer to a single state of the network at a single time.

  Each Ripple ledger stores every account info or just accounts on which transaction occur recently?

Again, that's just a matter of definition. Most commonly, we use the term "ledger" to refer to all of the state entries (accounts, offers, trust lines, and so on) that were connected at a particular point in time.

The ledger design is passive. That is, a particular entry can be in ledgers 10,000,000 through 20,000,000 without anything special happening to it and without it requiring any processing as it just sits in the ledger and doesn't do anything.

If a new rippled server starts up with no data at all, it will not begin processing until it reaches some point where it knows every single currently valid/reachable ledger entry. That typically takes about two minutes (because the ledger's structure is specifically designed to make this efficient). At that point, it can process transactions and perform normal functions even though it doesn't have any network history. Of course, it can't tell you what happened in the past.


When do I get paid when mining with eligius?

You will never get paid, because your miner is too slow to provide useful work to the mining pool.


What is the state of the Wasabi wallet - when will it be ready for mainstream mass usage?

Wasabi Wallet is usable right now.

"When will it be ready for mainstream use" is a question of opinion / service availability, and those are off-topic here. See the help centre for more info.

  And who is validating the transactions in the wasabi wallet ? Is it a SPV concept or full node, or centralized, owned by wasabi company servers?

The Wasabi server validates the blocks. It creates block filters out of them and sends them to the client. From those filters the client can figure out which blocks it is interested in and it downloads those blocks from the Bitcoin P2P network, one block from one peer over new Tor stream. Optionally one can use his own full node for block downloading, but the ultimate source of truth is still the Wasabi server.

  And is (Wasabi) a HD (hierarchical deterministic) wallet??

Yes


How to retrieve unclaimed BTC for wallets whose private key is lost

If you lose the private key for some address that contains bitcoins, then you will never be able to spend those bitcoins. The private key is required in order to spend, and there is no known way to work backwards to discover the private key for an account.

If the private key is lost, the bitcoins become un-spendable.


I am afraid of private key collision... What is the solution?

Bitcoin addresses are 160 bits in length. That means there is an extremely large number of possible addresses. From the Bitcoin wiki:

Generating tons of addresses
Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.
Also, a collision is highly unlikely.
Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power) Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15 x 10^38)

In other words, don't worry. Even if someone deliberately targets your address for cracking, it would take them trillions of years. An accidental collision is even less likely.
Multisig isn't made to protect against private key cracking (which is impossible), but to allow the existence of addresses that must have the authorization of more than one device or person to spend from them.
Say, you have a 2-of-2 multisig address. One key is in your computer, and the other is in your smartphone. While an attacker won't ever crack even a single one of your keys, they could try infecting your device with a private key stealing trojan, or a keylogger to watch you type your wallet passphrase.
Now, it's much less likely that the attacker will successfully hack both your computer and your phone. So multisig does improve your funds' security, but not for the reason you mentioned.


How can I conveniently generate new addresses for my public key?

This is done using heirarchical deterministic (HD) wallets. Using an extended private key, you can generate an infinite number of children, grandchildren, etc. private and public keys. BIP 32 lays out exactly how this works.

A private key on its own cannot do this, you need an extended private key, which is a private key plus a chain code. So you will have to generate a chain code to go with your private key you've created, or use the private key you've created as a seed for a new extended private key as described in the Master Key Generation section of BIP 32. Once you've done this, you can use your private key and chain code to generate extended children keys, and use them to generate children of children (grandchildren) to your heart's content. Just remember to back up your master private key and chain code because if you lose that, you won't be able to regenerate the child keys.


If miners are creating their own mining algorithms or using something standard

The double-SHA256 is the mining algorithm. Miners merely decide which transactions they wish to include in a block, and they an adjust the random nonce field in the block header. Additionally, they create the coinbase transaction (the first transaction in the block), which pays them out for the block reward. There is some additional information they can include in the coinbase transaction which makes no difference to the result, but merely allows them to attach some metadata (such as the name of their mining pool, to indicate they mined it).

The choice of transactions to include can be arbitrary, but the obvious approach is to include them prioritized by highest paying fee, because this maximizes the revenue the miner takes if they are successful.

Everything else is simply random numbers in order to try and find a hash which is below the target. The miners can choose how they generate those random numbers, or how they might partition the range of numbers to attempt between members of a mining pool to prevent duplication of work among the members of the pool.


Bitcoin ABC, When Fed Bitcoin Core Chain Syncs to Aug 1 6:23AM 2017, Then Freezes

You copied the entire chainstate too, which will confuse the node and cause it to be unable to continue syncing because the chainstate says the Bitcoin Cash chain is invalid and the node things that the chain it is currently using is also invalid. You can fix this by removing the chainstate, in which case it will begin reindexing.

However this may not fix all of your problems because the Bitcoin chain is still on disk and it will still index and verify that. So you may need to delete some of the blk*.dat and rev*.dat files (the higher numbered ones) in order to get it to revert to a state before the fork and then sync Bitcoin Cash from that point onwards.

Details are that we copy the .bitcoin directory, but remove the .bitcoin/chainstate directory.  If you run the client now, it will freeze again when it gets to the blk*.dat files that are beyond the fork.  By running it while also running:

watch -n 1 'sudo lsof -c bitcoin | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | sed -E "s/^.+$/&   `date`/" | tee -a recent.blk'

and

watch tail recent.blk,

I was able find that the files that need to be deleted are .bitcoin/blocks/{blk,rev}00953.dat and above.  That is, keep 00000 to 00952.  Then when I ran the client again, it worked.  After the fork, it synced with the network.  You can save yourself running it twice by just going ahead and deleting both the chainstate/ directory and the relevant files in blocks/.  When you run the client, it will say, "Error loading the block database, do you want to rebuild now?"  Respond, "Yes", and then  it will say "Reindexing the blocks on disk", followed by "Syncing the Headers (478436)".  That last number is the number of blocks in blk00000.dat through blk00952.dat, and just preceeds the fork at 478558.


Are there any commercial nodes available so my transactions won't show my IP address?

Bitcoin will run over Tor. There an article on the Bitcoin wiki that explains the process.

Just install Tor and let it set up a proxy on its default IP (127.0.0.1) and port (9050).

For bitcoind, use the flag --proxy=127.0.0.1:9050.

For the GUI client, under Options, check Connect through socks4 proxy. Set the proxy IP to 127.0.0.1 and the port to 9050.


You don't need 2 accounts on each. CB for example lets your switch between BTC and BCH wallets under one account.

You just import the private key from the paper into say a "electrum" wallet for the bitcoin. Then transfer the bitcoins out. Then you import the same key into a bcash wallet like "Electron Cash"

https://steemit.com/cryptocurrency/@lukestokes/step-by-step-getting-your-bitcoin-cash-out-of-a-bitcoin-paper-wallet


Is it cost-effective to purchase an expensive card?

For $2800 (the price of Monarch 500GH/s, as of 23 Dec 2013), and $4680 (the price of Monarch 600GH/s, same date), you might as well purchase a 1TH/s mining hardware, such as from VMC, or CoinTerra.

The other alternative is to use these mining hardware to mine some other altcoin, instead of Bitcoin, and hope that the other altcoin would come to prominence one day, instead of bitcoin.

The answer to your question is that unless the difficulty drops, it is no longer cost effective to purchase mining hardware.


Automatically Get Bitcoin Difficulty, Bitcoins/Block, Exchange Rate Statistics

You can get...

difficulty from: http://blockexplorer.com/q/getdifficulty
reward per block from: http://blockexplorer.com/q/bcperblock
exchange rate from: http://api.bitcoincharts.com/v1/weighted_prices.json

or from: http://api.bitcoincharts.com/v1/markets.json

You might want to read this.

See list of other bitcoin stats here.


Keeping old blocks on an external hard drive and latest blocks on an SSD

Blocks are not accessed under normal operation, except:  When a peer fetches one (and the most recent block is usually served out of an in memory cache), when there is a reorginization that must undo the effect of a block (which is pretty rare), or when you use an RPC to look up a historic block.

With that in mind, perhaps you can just put your blocks directory on the other disk.

If you set your node to be pruned but set the pruned amount much larger than the amount of block data, you will avoid peers fetching large numbers of old blocks from you (but still keep the data around).

If you found high disk accesses while in this configuration, I think thats something that the project would like to fix.


Transactions are very big. So one is very expensive.

Less transactions is better for the network.

Large transactions, with old coins, do not need to pay fee. They can not be spammed with.

Any miner can choose a minimum fee. The miner chooses the math.

The commonly accepted fee is just chosen by bitcoin developers. It was their choice, no special math involved. We try to have a manageable amount of transactions per block.


I found it. The port 9735 is not open to the public.

Go to google cloud console

Home -> VPC network -> Firewall rules

+ Create firewall rule:

Name      Type    Targets   Filters          Protocols / ports  Action  Priority    Network
lightning Ingress Apply to all  IP ranges: 0.0.0.0/0 tcp:9735       Allow   1000        default


Would it be profitable to manufacture and sell my new mining hardware?

Depends on whether you can bring something to market that's better than what's already out there. I'm not sure how quickly you can set up something like that, but 200GH/s for $99 right now would probably sell decently. 12 months from now, probably not so much.

This is really an economics question you have to answer, and we'd need a lot more information about your costs and market in order to assess the opportunity properly.


Creating a bitcoin/litecoin miner with Javascript

Why reinvent the wheel?

I think there are several simple javascript miners out there, so I won't bother telling you more than to google it (or to duckduckgo it, if you prefer).

But whilst we are at it: Would you believe people have gone far beyond it and found a way to program a javascript-based miner using GPUs, as pointed out in an answer on bitcoin.stackexchange? That project is hosted here.


How do I determine whether an input or output is segwit?

I'm trying to go through the transactions in a block and determine how
  many segwit inputs or outputs there are.

BIP141 defines a segwit tx marker and a flag at the beginning of a transaction. So if you decompose such a tx, you would see with the flag, if there is SegWit:

raw tx is: ### raw tx is this:
01000000000102FFF7F7881A8099AFA6940D42D1E7F6362BEC38171EA3EDF433541DB4E4AD969F000000004948
30450221008B9D1DC26BA6A9CB62127B02742FA9D754CD3BEBF337F7A55D114C8E5CDD30BE022040529B194BA3
F9281A99F2B1C0A19C0489BC22EDE944CCF4ECBAB4CC618EF3ED01EEFFFFFFEF51E1B804CC89D182D279655C3A
A89E815B1B309FE287D9B2B55D57B90EC68A0100000000FFFFFFFF02202CB206000000001976A9148280B37DF3
78DB99F66F85C95A783A76AC7A6D5988AC9093510D000000001976A9143BDE42DBEE7E4DBE6A21B2D50CE2F016
7FAA815988AC000247304402203609E17B84F6A7D30C80BFA610B5B4542F32A8A0D5447A12FB1366D7F01CC44A
0220573A954C4518331561406F90300E8F3358F51928D43C212A8CAED02DE67EEBEE0121025476C2E83188368D
A1FF3E292E7ACAFCDB3566BB0AD253F62FC70F07AEEE635711000000

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
 TX_IN[0]
  TX_IN[0]       9F96ADE4B41D5433F4EDA31E1738EC2B36F6E7D1420D94A6AF99801A88F7F7FF
  TX_IN[0] hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length hex=49, decimal=73
  TX_IN[0] Script Sig 4830450221008B9D1DC26BA6A9CB62127B02742FA9D754CD3BEBF337F7A55D114C8E5CDD30BE022040529B19
4BA3F9281A99F2B1C0A19C0489BC22EDE944CCF4ECBAB4CC618EF3ED01
  TX_IN[0] Sequence (uint32_t)
  EEFFFFFF
 TX_IN[1]
  TX_IN[1] 8AC60EB9575DB5B2D987E29F301B5B819EA83A5C6579D282D189CC04B8E151EF
  TX_IN[1] OutPoint index hex=01000000, reversed=00000001, decimal=1
  TX_IN[1] Script Length hex=00, decimal=0
  TX_IN[1] Sequence FFFFFFFF

TX_OUT COUNT, hex=02, decimal=2
 TX_OUT[0]
 ...

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=02, decimal=2
 WITNESS data[0]:
  47304402203609E17B84F6A7D30C80BFA610B5B4542F32A8A0D5447A12FB1366D7F01CC44A0220573A954C4518331561406F90300E8F3358F51928D43C212A8CAED02DE67EEBEE01
 WITNESS data[1]:
  21025476C2E83188368DA1FF3E292E7ACAFCDB3566BB0AD253F62FC70F07AEEE6357

 LOCK_TIME
11000000

As this is a tx with two inputs, the first input is non segwit (hence a signature in the V_IN part), the second input is segwit (Script Length = 0), and the witness for second input is added at the end of the tx.

  Am I correct in interpreting this to say that you can't determine
  whether an output is segwit? Only an input?

With P2SH, you take an original set of data, and run it through a hash function. As the hash function is not reversible (to today's knowledge), you cannot know, what is inside a P2SH. Usual use cases are for example multisig transactions. But it can be other things as well, and only if the spending transaction is in the blockchain, you can see, what was previously inside. So this adds a certain layer of privacy for the time between funding the tx and spending the tx.


Why are there multiple input addresses in one transaction and are they linkable to one single address?

The bunch of input addresses (usually) come from a single HD wallet.

That's one possibility.  It could also be that they come from a non-HD wallet, so that they correspond to a bunch of independently generated private keys that happen to belong to the same person.  Or they could all belong to different people, who have agreed to combine their coins and send them somewhere.  There's no way for us to know for sure.

  a transaction input address is hierarchically derived from the previous one

That's not completely correct.  A public key in an HD wallet is derived from the previous one together with the master extended public key.  Unless you know the master key (which would normally be kept secret), you can't determine what the next key in the sequence would be.  Hence you cannot find out what other keys / addresses belong to that user.

The complete technical details of how key derivation is done are in BIP 32.


Yes you can use localbitcoins and find your country/city and sell it there. Becareful when selling in person. Always meetup in a public space like starbucks, bank, or police station.


I am wondering weather there will be a scenario where the miners do not accept a valid block or accept a malicious block

The only scenario in which this would happen is if someone on the network is running a malicious version of code with different consensus rules. In this event, anyone running that code will accept an invalid block (that is valid according to their incorrect rules), causing a fork in the chain.

However, everyone on the network using valid consensus rules would deem each block of the forked chain as invalid, and continue extending the real chain as expected.


Resources for HF Trading of Bitcoin & Altcoin

Check out my ccxt library on GitHub: https://github.com/kroitor/ccxt

With it you can access market data and trade bitcoin, ether and altcoins with many crypto currency exchanges. It provides quick access to market data for storage, analysis, visualization, indicator development, trading strategy backtesting, bot programming, building trading algorithms on top of it, webshop integration and related software engineering.

The code is in JavaScript / Python (2 and 3) / PHP. You can deploy it from PyPI, with npm (for Node.js) or by cloning from GitHub repository.

The ccxt library is under heavy development right now, but already offers a quick-start for trading and technical analysis with many crypto exchange markets out of the box.


bitcoin-cli error: couldn't connect to server on importaddress

The arguments for importaddress are:

Arguments:
1. "script"           (string, required) The hex-encoded script (or address)
2. "label"            (string, optional, default="") An optional label
3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well

So, you need to use ./bitcoin-cli importaddress mvcWTfVhCMhwvqQf2TKkEqpLrNdW7Uekod "" false

Also, you may consider adding a final true argument after the false.

Note that importing without rescan means your utxo's will not be found (using bad terminology, your addresses will have no balance).

Also, note that since you have so many addresses to import you may wish to consider using importmulti the usage of which is described via ./bitcoin-cli help importmulti


Trying to reconcile the amount sent versus amount transacted

Say I owe you $8, but all I have is a $10 bill. I'll make a transaction that spends my $10 bill and delivers $8 to you and returns $2 to me. The extra 0.02364322 LTC is Coinbase's change, just as the extra $2 is my change.

Coinbase didn't happen to have precisely 0.55177632 LTC in an unspent transaction output, they had 0.5734121 LTC. So they returned some change to themselves.


Maybe a little bit late, but for everybody who is interested, the easy command to check if a name exists is simply:

> ./namecoind name_show d/<name>

It will return some informations should the name already be registered, or it will return

error: {"code":-4,"message":"failed to read from name DB"}

if the name doesn't exist.


Computer Advice to Meet Bitcoin Core Requirements

As I suspected, my current machine (MacBook Air, lol) is not going to work.

That really depends on what model you're talking about. Modern Macbook Airs are definitely powerful enough.

It looks like I only have 61 gigs of 120 available disk space.

That's more than enough for running Bitcoin Core in pruned mode.
When pruning is enabled, old blocks are deleted from disk a while after they've been verified. This disables some functionality, but is equally secure - everything is still fully validated, just not kept forever. It doesn't interfere with normal functions.

I honestly don't even know how to check the read/write speed.

It's the speed of the disk. All new disks can do more 100 MB/sec, but for initial synchronization (the time your node needs to validate all of history) an SSD will be a lot faster than a spinning hard drive. Don't use an external drive connected through USB - such hardware is not designed for the kind of heavy database load Bitcoin Core causes.

an unmetered connection

That just means you want to make sure you don't pay per megabyte for your internet connection. Bitcoin Core will be downloading several 100 GBs of data from peers (all old blocks), so if you have to pay for that, you may want to reconsider.


There are a number of sample programs here: https://bitcointalk.org/index.php?topic=1026.0

Also see the wiki for the step-by-step algorithm for generating a valid address.


What is the rationale behind Bitcoin mining?

Why do we mine?

We need to all agree on who owns which coins.  If your idea of who owns what is different than mine then how can we trade?

To achieve this, the Bitcoin protocol keeps its ledger of all transactions in a series of blocks, with each block recording a collection of transactions.  Since we don't have a central authority to declare which blocks are valid, we run a 'lottery' instead.

Each miner bundles up all the new transactions he knows about, adds in an extra transaction which creates some coins out of thin air and pays them to the miner, mixes in a random number and hashes the whole thing.  If he gets a hash less than a certain number, he wins and his block is added to the blockchain.  If not, he tries with a different random number, over and over.  Everyone else can verify that his random number with his transactions hashes to a low enough number, so they accept his block.  The network periodically adjusts what this target "low enough number" is, in an attempt to keep the average speed of block generation at about 10 minutes.

Why do we need a GPU, not a CPU?

You generate coins by calculating hashes.  Each hash you calculate has a certain chance of making a block, and earning the associated reward, which is currently 50 coins.  The faster you can calculate hashes, the more chance you have of generating 50 coins.  It just so happens that ATI GPUs have the right kind of hardware in them to calculate sha256 hashes many times faster than an Intel CPU can do it.  That's why people use GPUs instead of CPUs.

The Bitcoin network automatically adjusts the "chance per hash" to try to keep the global rate of generation at one block every ten minutes.

In the beginning, before GPU mining started in earnest and not many people were mining, CPU mining worked just fine.  But as more people joined the network and hash rates became faster, the network difficulty increased to keep the blocks coming along every 10 minutes or so.  As a result, CPU mining became less rewarding per CPU.

Then when it became more common for miners to use GPU hardware to mine because it is so much faster and more energy efficient than CPU mining, the global network hash rate increased still further eventually making it completely useless to mine with a CPU; the expected rewards are less than the power consumed by the CPU.

Maybe one day FPGAs or ASICs will render GPUs useless for mining, like GPUs already did to CPUs.


What will happen when bitcoin's popularity multiplies and the number of transactions explodes?

According to Bitcoin Block Size - What are the rules? each block can be up to 1MB per size and contain roughly 2400 transactions. As transaction blocks are supposed to be found every ten minutes, this would mean that 14400 transactions per hour or 4 transactions per second could be handled.
If there should be more transactions sent they would compete for inclusion into the blocks. Transactions with smaller fees would gain priority by aging and would at some point be included at times of fewer transactions. People that require their transactions to arrive quickly would attach bigger transaction fees for faster inclusion. At some point microtransactions would cost more than the amount of value they transport and/or would have to wait very long. Perhaps some transactions would move off the blockchain,  some e-wallet services already allow their users to transfer balances to other users of the service for free and without wait.

The protocol as it is today would not be able to sustain a transaction volume of millions per minute (although that is too big a number, even VISA only has 150 million transactions per day, which are about 100k per minute). The bitcoin network is currently averaging just above 60000 transactions per day, so this is already about 1/6 of what the network can handle with the current block size limit.

However, apparently a significant amount of transactions are generated by gambling, so I am unsure how pressing the matter really is for the network.

Edit:
Reading more about the scalability of the system I learned that the bitcoin network could scale to more than 40000 tps on today's hardware. The regular users would probably not store the complete blockchain anymore, but only the unspent outputs without the entire history of the transactions.


What are the bitcoin dependencies for red hat linux? Bitcoin fails to compile

If you want to compile Bitcoin on CentOS 6, you will need more than just Bitcoin; several other dependencies are either missing or too old.

The particulars:

Boost is too old. CentOS 6 has version 1.41, but Bitcoin requires features first introduced in Boost 1.47.
Berkeley DB is too old. CentOS 6 has version 4.7, but Bitcoin wants version 4.8 (but see below for more on this).
OpenSSL may be missing some elliptic curve algorithms required for Bitcoin, due to Red Hat's extremely conservative legal stance with respect to ECC. (See bugs 319901 and 1020292, among others.)
The qrencode and miniupnpc libraries, necessary for the Bitcoin GUI to support QR codes and UPnP respectively, are missing entirely. (A server-only build doesn't need them, though.)
Older versions of the Bitcoin codebase did not work with Qt 4.6, the version shipped with CentOS 6, but required Qt 4.7. I fixed this with a one-liner, and it was patched upstream. This probably won't affect you, though, unless you're building old code for some reason.

You also need these packages, which do exist in CentOS 6:

db4-devel
autoconf automake libtool

And you also need this package from EPEL:

protobuf-devel

For a build including the GUI, you also need:

qt-devel desktop-file-utils

Then you need to patch Bitcoin to accept using Berkeley DB 4.7; by default the configure script bails if BDB 4.8 is not present, even if you pass the configure option that is supposed to override this. And be warned that wallets created by this build may or may not work with Bitcoin compiled with BDB 4.8.

Then you need to patch it again to make it compile on the older versions of gcc and glibc shipped with EL6, as the current Bitcoin code assumes a compiler supporting C++11 is being used. It's a one line patch, but it took me half an hour to track down.

As you can see, this is kind of painful, and the missing libraries alone cause most people to give up.

Most of these packages (except miniupnpc) are in CentOS 7, so if you're going down this road, that's probably a better starting point.

I've been maintaining versions of those libraries, along with an SELinux-enhanced Bitcoin build, for a couple of years now. It's much easier to just grab the repo and install the existing RPM packages since I've done all this work for you. But if you really want to cover that ground again, there's your road map.


Any methods or tech to reduce the size of blockchain?

In cases like VPS it seems that the storage on plans rarely increases much despite HDD size increasing nearly ten-fold since the beginning of 2009.

Depending on how you use the node there are several options to reduce storage requirements. Here are a few:

Enable pruned mode on the node.
Use an SPV client like Electrum in place of Bitcoin Core.
Enable inline file compression (if available) i.e. btrfs compression.


If you just want to play around or test your apps then bitcoin-core's regtest mode might be what you're looking for.

Developer examples on regtest mode: https://bitcoin.org/en/developer-examples#regtest-mode

A tutorial to get you started: https://geraldkaszuba.com/creating-your-own-experimental-bitcoin-network/

If you want to fork bitcoin and create your own altcoin this guide can be useful: https://bitcointalk.org/index.php?topic=225690.0


What if the blockchain saved space by trimming input txs on each transaction?

I see two problems here:
First problem is collision, since you chose only 24 bit out of 256 bit. You'll have to use a much bigger short form to mitigate that, so the big space you saved is now a lot smaller.

Second problem is when you have to convert the short form to the long form. Lets say you stored the outpoint of the tx as cb7f35:index, now another node wants the block containing this tx. To reply, you have to construct this outpoint in its long form first. The only way to do that is to go through the entire history and find the long txid cb7f357d7034f93b89a227c2109182740f1798f5a006e9cd0930a380c06aca7e and send that. That process takes a lot of time, you could however index the blockchain based on txids but then you'll need an extra space to store the index that negates the space you saved.
You could not communicate with the network (don't relay blocks) to avoid all that, but why store the blockchain in first place? A better solution would be "pruning" it.


These are native SegWit addresses, specified in BIP173 using a format called Bech32. They begin with 'bc1'.

Addresses that begin with a 3 are P2SH addresses, an address format that has been around for over 5 years now. They were originally used by multisig wallets like CoPay and GreenAddress, which only saw limited usage. However, SegWit can also be used in compatibility mode, using the existing P2SH format, so that old clients can send to it. This gave rise to the myth that '3' addresses are specifically for SegWit.


F2Pool (along with most today) don't offer share difficulties low enough for CPU mining, in this case the default is 1024. It will take on average one week to mine a single share at this point in time, and it will pay out less than 100th of a Satoshi (0.0000000001 BTC, 0.00000002608 USD) for the CPU time expended. CPU mining has been unprofitable since 2010 as the power costs for doing it are many orders of magnitude higher than the income you can make doing it.


Checkout time for consumers in stores accepting bitcoins

Why should it increase the checkout time?  In such a situation, the QR code would normally be displayed on a computer or tablet screen, not printed on paper, so a new one can easily be displayed for each customer.  Generating a new Bitcoin address doesn't take much time - a few milliseconds, maybe - and can be incorporated into the merchant's point-of-sale software so that it happens automatically as soon as the clerk touches the "customer paying with Bitcoin" button.  Alternatively, the addresses can be generated ahead of time and used one by one, which would be even faster.

The merchant does have to keep track of a separate private key for each address; but this is easily handled by software.  Bitcoin wallets are designed to efficiently handle large numbers of private keys, and automatically select coins from the many available addresses when sending a transaction.

What would increase the checkout time is if the merchant feels it's necessary to wait for one or more confirmations of the transaction.  Each confirmation takes, nominally, an average of ten minutes.  Most people assume that this wouldn't be used for small purchases; for large purchases, the customer might be asked to wait after sending the coins (but of course other customers can be served in the meantime).


SignRawTransaction - What is scriptPubKey and redeemScript? [SOLVED]

First of all, take a look at https://gist.github.com/gavinandresen/3966071.  That's a script that creates two raw transactions: one to fund a multisig address, and another to spend the funds.  It shows each of the steps necessary to create and spend from a multisig address.  Unfortunately, the script doesn't do a good job of explaining where the parameters come from.  I'll try to explain the parameters you need.

As you guessed, hexstring is the output from createrawtransaction, and transaction id is the ID of the transaction that sent the coins to the multisig address.  redeemScript is easy.  When you first generated the multisig address, the command returned both the address and the redeemScript.  If you don't have that value, you can recreate the multisig address with the same public keys and you'll see it in the output.  scriptPubKey is the one I'm not sure about.  I think I know what it is, but I don't have bitcoind in front of me so I can't be sure.  If you decode the raw transaction that send coins to the multisig address, you'll see one or two outputs, one of which sends coins to the multisig address.  (The other output sends the rest of the coins to a change address.)  There will be a scriptPubKey section in that output.  Copy the hex string from that section and use it as the scriptPubKey parameter.

Once you have those parameters, you can sign the raw transaction and send it.  If it doesn't work, leave a comment here and I'll try to work it out when I get home.


Will every message x reach all connected peers in time t?

Can we take for granted that if in time period t there were 10,000 connected peers (no new peers connecting, no peers disconnecting), all with good internet connection and hardware, then if every of those 10,000 peers originated one transaction (or any kind of message) to his peers, can we take for absolutely granted that eventually every single one of those 10,000 connected peers have in his mempool all 10,000 transactions, including his own and those of 9,999 other peers and absolutely no transaction will be missing in mempool of any of those nodes (they will all have same set of data)?

If you also include that no one is acting maliciously, then yes, under these perfect conditions with no malicious actors, you take for granted that a transaction will reach all nodes within some unknown time t. However, if there are malicious actors, then no.

  If yes, and would could be estimated time (seconds, minutes, hours)?

This is impossible to know. It depends on the hardware, what the transactions consist of, the internet connection, etc. At best, it would probably take a few hundred milliseconds. At worst, likely a few minutes. Without more specific parameters, it is impossible to know.


Here is the protocol: https://electrumx.readthedocs.io/en/latest/protocol.html. If get_mempool serves your use-case then you may use it. You may need to experiment with it to find what is more convenient with Core.
Some apps might be using the Electrum protocol under the hood. Only Electrum allows setting the server manually.
Electrum protocol has blockchain.scripthash.get_mempool which doesn't help you build a mempool observer. You need to connect to Core directly then


I heard a message was encoded into the blockchain, how can I read it?

I saw this tweet in which it was mentioned that F2Pool included a message in coinbase transaction related to Elon Musk's tweet: https://twitter.com/zackvoell/status/1355152428903985157
Block: 668197
Use the below commands to get the message:
getblockhash 668197
getblock 000000000000000000023c31edf49adb2306d0db74e6f1f032ef76deaa7a464a 2
The first tx that you see in the JSON results will have a coinbase value which can be converted from hex to ascii using https://www.rapidtables.com/convert/number/hex-to-ascii.html
Or you can use this command on Linux which uses jq and xxd to make it easier:

bitcoin-cli getblock `bitcoin-cli getblockhash 668197` 2 | jq -r '.tx[0].vin[0].coinbase' | xxd -r -p

It was mentioned by Sjors Provoost in https://twitter.com/provoost/status/1345726239676489728
Can be verified by comparing with the things that you see for block 668197 on a block explorer: https://bitaps.com/668197


Can you retrieve funds send to a legacy address created with a Segwit extended private key imported in Mycelium from a Ledger Nano S?

I actually discovered the answer:

The answer is described on Reddit: https://www.reddit.com/r/ledgerwallet/comments/7d39pu/legacy_to_segwit_wallet_transfer_nightmare/

But if that answer would ever get lost, a summary:

Apparently segwit xpub addresses are not a good marriage (yet). The Mycelium wallet imports the xpub address which is generated by the Ledger Segwit wallet, but creates legacy addresses from the key. As Mycelium is watch only, you cannot send your funds anymore as the legacy bitcoin address does not show up in a segwit enabled wallet, so you want the private key which signs for the public legacy bitcoin address. That's what you have to do know: find the public key which is hashed into the public bitcoin address.

The public key (not the bitcoin address) is the same for the address which appears as a legacy address and the segwit address. When you choose the right derivation path, you will see the address starting with a 1 and you'll see the public key next to it. That last part, knowing where to look, is not very straight forward foor n00bs like me. That public key corresponds with a segwit address, starting with a 3. And next to the segwit address you'll find the private key. After importing the private key in a wallet like Electrum, you can move your funds to a normal segwit address.

So, Mycelium uses m/44'/0'/0'/x path, which is BIP44, and a SegWit address uses BIP49 (m/49/etc)

If this is about a lot of funds, try to do as much offline as you can, but the advise is to create a new seed for your ledger and transfer all funds from all coins to the new seed. After you've done that, playing around with your private keys from your old seeds does do no harm as the balances are zero (except for that one address)

Now, go and search for a BIP39 tool, like: https://iancoleman.io/bip39/ (you can use it offline as well)

Copy the xpub address you got in the SegWit section of your Ledger Bitcoin wallet and copy the address into the tool. Be sure to select derivation path BIP32! Leave Client at Custom and derivation path at m/0.

Paste your xpub-key in the BIP32 Root Key field. On the bottom of the screen you'll see a list with Derived Addresses.

Go back to your Mycelium install and check which address was used for the transaction (or paste the xpub key into a blockexplorer). In my case it was the first one. On the right side of the Address starting with a 1 is the Public Key. Copy the public key into notepad or gedit or so. The private key part is empty (makes sense, everything we've done is with public keys, no option to derive a priv. key from that!)

Now, delete the Root Key and go to the tab BIP49. Paste your Mnemonic seed in the BIP39 Mnemonic field. Your 24 words in the correct order, separated only by one space, should derive a new address list.

If done correctly, there has to be a public key next to the list of public addresses starting with a 3 which corresponds with the public key you just copied into your gedit! Next to the Pub Key is the Private Key (yay!) and now you can import that key in a wallet supporting importing priv. keys and you can finally send your funds to a new bitcoin address, preferably one which you can reach ;)

In Electrum you can easily import private keys, create a new wallet, select 'import bitcoin addresses or private keys' at the first wizard screen, paste the priv. key and there it is!

Thanks again, user stiVal on Reddit! :)


Lightning network and lightweight clients

How will the lightning network handle lightweight clients?

Most steps during the payment process in an LN channel don't actually require full knowledge of the blockchain or even the unconfirmed (mempool) transactions. This is because the transactions involved deal with 2-of-2 multisig scripts, where both parties have to sign off on each transaction to make it valid, so they both can stay aware of all transactions made relevant to the channel they share without monitoring the blockchain.

The exception is for dispute mediation. If Alice tries to broadcast an older version of a commitment transaction, someone needs to see that transaction to take Alice's portion of the funds from it. This is an aspect that can be trustless-ly outsourced, though. It can even be incentivized with a small fee.

  Do I understand it correctly that opening a payment channel require writing on the blockchain to protect against double-spend?

First you establish a refund from the funding transaction, then you broadcast the funding transaction which needs to be mined into the blockchain before payments can be made in the channel securely.

  The integrity being protected by the penalty of losing all bitcoin in the channel if writing a older transaction to the blockchain than what the counterparty do.

Exactly, the payment channel is crafted in such a way that previous states of the channel cannot be broadcasted. Technically they can be broadcasted, the penalty for doing so is just losing all of your portion of the funds in the channel, so neither party will broadcast previous states of the channel.

  If I have a friend I trust and open a payment channel to him/her, I can afford having my bitcoin invested in the channel being locked while he/she is offline.

A lot hasn't been figured out in this area, but my guess is typical consumers wouldn't open a lot of channels with people who may be offline frequently. A consumer might open a channel with a business they frequent, and who has servers set up to be running with negligible downtime. Then consumers can pay each other through those businesses or other dependable nodes.

  If I lose connection to an "anonymous" node I automatically found on the network, I won't know if it ever will return online. Therefore I would like to reclaim my bitcoins invested into that channel. Thereby taxing the blockchain and incurring transaction fees. (In the worst case scenario a group of people want to mess with me and anonymously create a lot of dead payment channels. Sure they will only bind as much bitcoin for me as they collectively bind themselves. But unless someone already have found a way to mitigate this, you might not want to be a merchant selling burnable flags in a world with the Lightning network.)

I think you've essentially hit the reason that you don't want to just open up a bunch of channels with various anonymous nodes. They can become unresponsive, and you might have to wait a day or at least a few hours to get your funds out of the channel, plus paying transaction fees. Merchants still wouldn't mind connecting to many consumers, they just probably wouldn't be trying to route payments through consumers.

I should note that payment channels don't have to be funded from both parties. A channel you open with a merchant might have you putting 1 bitcoin into it and them putting 0 bitcoins. Then only you can pay the merchant, but the merchant probably isn't going to be trying to route payments through you (a consumer who would likely be offline 99% of the time), so that's okay with them.

  If I understand this correctly, won't this result in centralization? If I want to pay with the lightning network from my cellphone, I would need to use a full lightning network node (always online) or have pre-existing payment channels to nodes that trust me. (friends, my bank, full node in my cellar etc.)

The difficulty of running an always-online node would be so low, that there would probably be a lot of competition. Merchants would definitely be at an advantage. That is how I predict channels would form, through merchants, and merchants would act as the intermediaries.

  Is this a real problem? Has someone found a way to mitigate it?

Even if the network does become fully centralized around a small minority of nodes, those nodes still can't really do much harm. If one or two becomes unresponsive, payments will just route through other nodes. Like I said before, the barrier to entry for running a lightning node should be pretty low, so there will likely be a fair amount of competition.


Are there drawbacks to the Thin Block patch?

Compact Blocks in Bitcoin Core provides similar functionality (see BIP 152 for spec). The main improvement is in the way it gets rid of bloom filters, as those add a DoS attack risk.

There's a bit more in commentary from nullc (Gregory Maxwell) in this thread on Reddit


XRP can be divided into millionths. The reserve levels can be changed by consensus. By the time this becomes an actual issue, the system will be managed by consensus and there's no way to predict what stakeholders will decide to do. The rough expectation is that they'll try to keep the cost of opening an account consistent with the actual cost imposed on the network by having an additional account.

Also, just to point it out again, those 200 XRP aren't lost. You can use them to fund transactions. You just can't transfer or exchange them. The reserve is designed to discourage ledger spamming.


When forwarding the block to a non-segwit peer, a segwit-enabled node strips the witness data from the block before transmission, including marker and flag. Note that the stripped blocks still enable the non-segwit peers to arrive at the same UTXO set, since the stripped transactions specify which inputs get spent and which new outputs get created.
If a segwit-enabled node were to receive a stripped block, it would consider the block invalid due to the missing witness data on transactions with segwit inputs (and the presence of a witness commitment). Thus, a segwit-enabled node will not requests blocks from non-segwit peers as they wouldn't be able to provide the complete block anyway (unless the block had no segwit transactions and no witness commitment).
Segwit inputs were designed so that non-segwit nodes consider segwit transactions valid but non-standard. Non-standard transactions are not accepted into the mempool and thus not relayed. This means that non-segwit nodes will not relay (stripped) segwit transactions except in the context of a new block. In turn, this makes it safe for segwit nodes to request transaction inventory offered by non-segwit peers, since non-segwit peers will only offer non-segwit transactions.


How to securely update and verify C-Lightning release?

I have divided this post into three sections: Download, Verification and Installation to make it easier for people needing help with specific sections. The installation steps have been reproduced using Ubuntu 18.04 but can easily be used for other versions as well. Just make sure to download the specific pre-built binaries from the release page for the OS you are using.

Download

C-lightning implementation is designed to work effectively only in Linux environment as of now. All the c-lightning releases gets posted on the GitHub’s release page. You can download them directly from the browser or use the below terminal commands:

# Download the Ubuntu release of C-lightning from the release page
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v0.7.3/clightning-v0.7.3-Ubuntu-18.04.tar.xz

# Download the SHA256SUMS file that contains the hashes of the release
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v0.7.3/SHA256SUMS

# Download the digital signature file SHA256SUMS.asc
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v0.7.3/SHA256SUMS.asc

Verification

Before installing the software it is a MUST to check the signatures of the release. This ensures that the software has not been modified by a third party on the release page or has been tampered during the download process via a man-in-the-middle attack.

Following steps are followed to check the authenticity of the file:

Compute the SHA256 hash of the main file
Check that the hash matches that in the SHA256SUMS file we downloaded
Verify that this hash has been signed by a trusted developer

The first step is to check whether the SHA256 hash of the file that we have downloaded matches the hash produced in the SHA256SUMS file. Since SHA256 is a one way mathematical function it helps ensure that the downloaded file has not been modified as its hash matches that in the SHA256SUMS file.

# Calculate the SHA256 of the file that we downloaded in the last step
ubuntu@user:~/Downloads$ sha256sum clightning-v0.7.3-Ubuntu-18.04.tar.xz
e36d259696ad172d509be712c0ee96b64a454d9a836b7a576d0bc26a580b313e  clightning-v0.7.3-Ubuntu-18.04.tar.xz

# Verify that the above hash matches the hash in the SHA256SUMS file
ubuntu@user:~/Downloads$ cat SHA256SUMS | grep clightning-v0.7.3-Ubuntu-18.04.tar.xz
e36d259696ad172d509be712c0ee96b64a454d9a836b7a576d0bc26a580b313e  release/clightning-v0.7.3-Ubuntu-18.04.tar.xz

As you can see above, the hashes matched. However, just matching the hashes is insufficient. An attacker could have modified the zip file, and reproduced its changed hash in the SHA256SUMS file. Thus we need to ensure that the hash that is in the SHA256SUMS file has actually been signed by a trusted person. For this, we need to verify the signatures.

You can do that by using gpg. First we will need to import public keys of the developers who signs these releases. You can find them here.

# import Rusty Russell's key
ubuntu@user:~/Downloads gpg --recv-keys 15EE8D6CAB0E7F0CF999BFCBD9200E6CD1ADB8F1

# import Christian Decker's key
ubuntu@user:~/Downloads gpg --recv-keys B7C4BE81184FC203D52C35C51416D83DC4F0E86D

# import Lisa Neigut's key
ubuntu@user:~/Downloads gpg --recv-keys 30DE693AE0DE9E37B3E7EB6BBFF0F67810C1EED1

The below step checks the signatures against the hashes in the SHA256SUMS file. If the SHA256SUMS file is missing you will get a can't hash datafile: No data error.

ubuntu@user:~/Downloads gpg --verify SHA256SUMS.asc
gpg: assuming signed data in 'SHA256SUMS'
gpg: Signature made Mon 28 Oct 2019 11:15:50 PM UTC
gpg:                using RSA key 30DE693AE0DE9E37B3E7EB6BBFF0F67810C1EED1
gpg: Good signature from "Lisa Neigut <niftynei@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 30DE 693A E0DE 9E37 B3E7  EB6B BFF0 F678 10C1 EED1
gpg: Signature made Mon 28 Oct 2019 11:51:59 PM UTC
gpg:                using RSA key 15EE8D6CAB0E7F0CF999BFCBD9200E6CD1ADB8F1
gpg: Good signature from "Rusty Russell <rusty@rustcorp.com.au>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 15EE 8D6C AB0E 7F0C F999  BFCB D920 0E6C D1AD B8F1
gpg: Signature made Tue 29 Oct 2019 08:07:39 PM UTC
gpg:                using RSA key B7C4BE81184FC203D52C35C51416D83DC4F0E86D
gpg: Good signature from "Christian Decker <decker.christian@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: B731 AAC5 21B0 1385 9313  F674 A26D 6D9F E088 ED58
     Subkey fingerprint: B7C4 BE81 184F C203 D52C  35C5 1416 D83D C4F0 E86D

Installation

Now that we have verified the authenticity of the file, we can safely extract the zip file using the command tar xf clightning-v0.7.3-Ubuntu-18.04.tar.xz. The extracted folder will have folders bin, libexec and share as its contents. Paste the contents of these folders in the /usr/ directory (or /usr/local/). Note: Just replace the files within these folders. Do not directly replace these folders as these folders generally contain binaries of other critical software as well.


I'm new to Bitcoin, how do I keep my bitcoins secure?

Use a desktop or mobile wallet (Electrum or Mycelium) to spend bitcoins (be sure to write down your recovery seed and store it like a paper wallet). To receive and store them, use offline paper wallets. As soon as a paper wallet exceeds some amount (50mXBC for instance), put it in storage and start a new one. If you are spending and your online wallet runs dry, break open a paper wallet to complete the transaction, any leftover coins will remain on the online wallet.
NOTE: with "online wallet" I mean wallets like Electrum and Mycelium, not web wallets like Coinbase or the Blockchain.info wallet.
Someone posted instructions for paper wallets on bitcointalk:

https://bitcointalk.org/index.php?topic=1559277.msg17075677#msg17075677

Do your own research before risking your coins following what someone told you.

Do not use web wallets.

EDIT: Brain Wallets (memorizing a passphrase that is hashed to produce keys and addresses) are highly controversial in the bitcoin community. The proper way to use them is to choose the passphrase uniformly and at random from a large set (at least 2^128).
Security improvements include:
Adding salt (something unique but trivial to remember, like your full name, phone number, or email address) to the passphrase to prevent hackers from attacking everyone at once.
Using key stretching WarpWallet is an algorithm that derives keys from a passphrase using a difficult, memory-intensive algorithm, this makes them much harder to hack.

To generate multiple wallets from one passphrase, you can attach an index to it (append a number to the passphrase).

The main advantage of brain wallets is that there is no physical wallet to steal or confiscate, and plausible deniability of having bitcoin.
Disadvantages include difficulty of remembering the passphrase (if you forget it, the coins are gone), possibility of theft (there are hackers constantly monitoring addresses created from weak passphrases, and they steal coins immediately), and the fact that in the unfortunate event of your death, your family would not be able to recover your coins.
If you decide to use them, they can be used in place of the paper wallets in the first paragraph.


My wallet balance says I have 12 mBTC but only allows me to send 2.63 mBTC. How can I fix this?

It might be, that you collected a lot of small transactions in your wallet. And if Electrum assembles a new transaction, it adds a fee, which is calculated in satoshis per byte, and for sure deducted from the amount you have. This way you can only spend less satoshis, than you actually have. In times of high fees, it does not make sense to create a tax. But today, as of July 2017, fees are very low, and you can give it another try. I posted a similar reply here:

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


bitcoin dust spamming - could the blockchain be rendered useless?

Perhaps only for other dust sized transactions with minimal fees. Dust transactions with small fees are low priority and are NOT guaranteed to be confirmed in the order the transaction was placed but rather by the priority. So lets say there is a backlog of 1 million dust transactions, I could create a transaction using 1 output for 0.01 and include a fee of 0.0002 and it should be included in the next few blocks, well before any of those 1 million dust transactions.


What is the difference between signrawtransactionwithwallet vs signrawtransactionwithkey in signing unsigned raw transaction?

signrawtransactionwithwallet is used to sign transactions for your wallet in which you can avoid entering private keys for spending different UTXOs as the private keys are in your wallet. You may need to enter passphrase using walletpassphrase
signrawtransactionwithkey is used to sign transactions for spending any UTXO using private keys
Examples:

I create a transaction for spending UTXO associated with address tb1qlqyjzjuxel0r80gs97uf5snh0a0kesmjyxxzey that belongs to my wallet

createrawtransaction "[{\"txid\":\"a1a564ae1983e1a87e731c4b9b205f3e8edbd724bb03d4474090f32ccd8f55a0\",\"vout\":0}]" "[{\"tb1qlu4kjktgcdru8cjnlx47me2ha4phxgceg2v4mj\":0.01}]" 0 true

Sign the transaction using signrawtransactionwithwallet without entering any private key
signrawtransactionwithwallet 0200000001a0558fcd2cf3904047d403bb24d7db8e3e5f209b4b1c737ea8e18319ae64a5a10000000000fdffffff0140420f0000000000160014ff2b695968c347c3e253f9abede557ed4373231900000000

Or I could sign the same transaction using private key for tb1qlqyjzjuxel0r80gs97uf5snh0a0kesmjyxxzey
dumpprivkey tb1qlqyjzjuxel0r80gs97uf5snh0a0kesmjyxxzey

signrawtransactionwithkey "0200000001a0558fcd2cf3904047d403bb24d7db8e3e5f209b4b1c737ea8e18319ae64a5a10000000000fdffffff0140420f0000000000160014ff2b695968c347c3e253f9abede557ed4373231900000000" "[\"cT29Pb7V9kxCp6VRfwNNips8T9beVV6AkJDJ9PZcn1RSx3pCnfCd\"]"

I create a transaction in Bitcoin Core for spending UTXO that belongs to my wallet in Electrum and private key for it is in Electrum.

createrawtransaction "[{\"txid\":\"542646583f5bd9b8424832d84ccfd23148f1e19b1b75cf3945bc8693d2dcb82e\",\"vout\":2}]" "[{\"tb1qlu4kjktgcdru8cjnlx47me2ha4phxgceg2v4mj\":0.022}]" 0 true

I copy its private key from Electrum.

Sign transaction in Bitcoin Core using signrawtransactionwithkey:
signrawtransactionwithkey "02000000012eb8dcd29386bc4539cf751b9be1f14831d2cf4cd8324842b8d95b3f584626540200000000fdffffff01c091210000000000160014ff2b695968c347c3e253f9abede557ed4373231900000000" "[\"cSBRq5UwGRZdKwLh6XGf3XFkYDvLdz6WwMxmtTdTvrNyw76mHHAV\"]"


I sent Bitcoin to an address but the recipient hasn't yet received it

The Blockchain is the only truth
At the time I wrote this, that transaction has 204 confirmations. That means it was absolutely definitely received.
If the address is correct and the recipient says they didn't "receive" it, they are wrong. Either their wallet isn't properly synchronised or they are mistaken (or lying to you)
Note that Bitcoin doesn't actually send money from wallet to wallet, it isn't a process that takes time between sending and receiving. At no point in time is money really out of one wallet and "on its way" to another wallet.
The only thing transmitted is a new block being transmitted to every node (wallets etc) in the Bitcoin world roughly every ten minutes. So long as you have the latest block, you know exactly which address has the money.

What follows is to clarify my point about the process taking no time. You should skip it unless you are interested in this detail or find it controversial.
Duration of transaction
Let's consider in a little more detail what happens when you make a typical Bitcoin payment. Note that Bitcoin is pretty complex, so I'll be simplifying. There are exotic forms of payment I won't cover (RBF, n of m, ...). My knowledge is limited but I think I can shed a little more light on this subject.
When you make a payment in your wallet, what happens is that your wallet constructs a kind of proposal for a transaction. This proposal is sent out into some nearby nodes in the Bitcoin network.
After sending that proposal, your wallet will mark the input amount as reserved for that transaction and won't let you try to spend it again. Your wallet will however know that this amount is still under your control and still as much "in your wallet" as it ever was and not yet in anyone else's wallet.
After a short time your proposed transaction will have been passed from node to node, being checked at each, and will reach some miners. Eventually a miner will incorporate your proposed transaction in a block and successfully mine that block.
Before this instant in time, the miner considers the money to be yours. After this instant in time, the miner considers the money to be the recipient's. There is no time when the miner considers the money to be in transit.
The miner transmits the new block to nearby nodes. As each node finishes checking the new block, that is the instant that particular node stops believing the money belongs to you and   starts believing the money belongs to the recipient.
The new block is passed from node to node until it reaches your wallet, At the instant in time it finishes checking that block your wallet ceases believing the money is yours and starts believing (provisionally†) that the money now belongs to the recipient.
There is no time in between. No time when your wallet believes the money is in neither wallet, in transit between wallets, sent but not yet received. None of those are really possible.
There is time during which the proposed transaction is circulating, but during that time all nodes consider the money to be yours. All nodes will accept other proposals from you for another transaction involving that money. This is because until one of those proposals gets included in a mined block, the money is still yours, still unspent.
The circulation of a proposed transaction takes time. Mining takes time. The Bitcoin network is large, so there are times when some nodes have the latest block and some don't. We say the network has not reached consensus - although each node has no doubt about whether the money is yours or the recipient's.
The change in ownership of money is instant (at each node separately) and money  is never really "in between wallets".

†Blockchain Forking
Since there are many independent miners (and mining pools), it can be that there are two or more blocks mined at about the same time competing to be accepted as the generally accepted next block. This means that sometimes a recently accepted block is discarded in favour of another block which has a greater number of subsequent blocks mined "on top of" it. This is why nodes generally wait for at least five blocks to be mined on top of the block containing your transaction (six blocks in total) before they accept the change of ownership of money as being fully confirmed.
So there is a period of time between the first block being mined and the sixth block being mined when a node might regard the change of ownership of the money as not sufficiently confirmed. This doesn't mean a node is unsure about who has the money. It doesn't mean the money is in transit. It doesn't mean the Bitcoin network can issue a second transaction to take money back out of the recipient's wallet. It just means that there is a tiny possibility the Bitcoin network might collectively decide your proposed transaction never got mined in the first place, that it never happened, nothing to see, move along. In most cases where this happens, the forgotten proposed transaction automatically gets included in some subsequent block and everything is OK and everyone forgets there was ever a hiccup.
This doesn't happen to every transaction, this is rare, it isn't really a case of money being "in transit" or "not in either wallet" or "not yet received".

Terminology and philosophical aspects
Proposed Transactions
Above I talk about proposed transactions and proposals. Those words are not generally used in the Bitcoin community. Mostly people talk about transactions, unconfirmed transactions and confirmed transactions. I wanted to use a different word to clearly distinguish a transaction which is circulating which has not yet been mined.
What is in your wallet?
The reason I put "in your wallet" inside scare-quotes the first time I mentioned it is that Bitcoin wallets don't really contain money. They contain a secret number, called a private-key, that can be used to prove you control some money (own some money). Anyone else who knows that secret number can take money "out of your wallet" from afar without any access to your wallet! Money isn't stored inside Bitcoin wallets but we go along with the charade because it is a useful shorthand that makes it easier to talk about Bitcoin. It is a useful way to explain Bitcoin to beginners even though it is misleading and unsafe.
This is weird!
Other people will feel my description of the way Bitcoin works places too much emphasis on the underlying dry technical (scary?) nature of transactions and that it is better to describe the process as if paper banknotes were taken out of your leather wallet, moved through an intermediary organisation and then placed into someone elses leather wallet. I agree this view has some utility but I worry it gives the impression that there is time in which banknotes are not in the senders wallet and not in the recipient's wallet but in the hands of some intermediary who can be asked to return them or intervene to change the outcome. Consider a literal reading of the original title of the question at the top of this page.


Can I use current Bitcoin protocol and Bitcoin client to create my own controlled currency?

Bitcoin is a decentralised cryptocurrency, meaning there is no central authority to control it. What you need to look into are centralized currencies. If you want to go for the easiest route, all you need is knowledge of programming websites and databases and you can easily make some database storing arbitrary numbers representing an amount of your currency belonging to someone. This, however, would be like Facebook credits, Microsoft Points or the like, not really a cryptocurrency. You could look into centralised cryptocurrencies, like loom.cc . Also worth noting are Open Transactions.

One could, however, create an alternative decentralised cryptocurrency, like SolidCoin, LiteCoin and dozen of others, but that doesn't create as much solutions as it causes problems. If you'd modify the source code you could make it so that only one address is allowed to create coins, but the whole system would be vulnerable to numerous attacks as your computing power might not be enough to secure the system.

All in all, it is not hard to create a centralised currency, but Bitcoin model might not be the best to use for this problem.


How to spend from a custom P2SH script using bitcore-lib

I could not find anywhere on the web about it. I was hopeless until I noticed that I could, without modifying the library.
First choose a similar class in Bitcore-lib.

multisigscripthash (<== suggested) or publickeyhash for P2SH outputs
multisig or publickey for bare script outputs (don't use these, these are nonstandard)

Then copy it to a new file in your project such as this one**. Do not use typescript classes even if your project is of kind Typescript.
Then change require paths. Also require inherit from NPM. As in the boilerplates above, we need to inherit from Transaction.Input
A function such as "buildP2SHPushIn" in the example should produce the redeemscript. Remember, the last element of P2SH redeem scripts is a push of the P2SH script.
And finally use addInput instead of the higher-level function from to add inputs as shown here**

**The examples are for Bitcoin Cash, but they can be used the same way in Bitcoin. Do not copy from them, however!


What does it mean when addresses are labelled "beyond the gap limit (highlighted red)"?

If you have your wallet seed it is fine:
From what I understand, your coins are safe, they will not be lost as long as you have wallet seed. When reimporting, Electrum would just not look far enough to find everything, until you nudge it a bit.

Explanation:
The gap limit gives the number of addresses that Electrum will generate from the seed starting from the last address that it found a balance on.

The error message tells you that Electrum wouldn't find some of your addresses by itself, because Electrum would think that it arrived at the end of your transaction history, before all your transaction history is discovered.

Example to make it graphic:

Gap limit = 3
S is Seed
I address with balance
• address without balance.
X address with balance beyond gap-limit

An arbitrary transaction history:
You have a balance on a few addresses, already spent/didn't use some addresses intermittently, and then you skipped a bunch (five here) for some reason before receiving balances on some more.

SIIII•III••I•III•I•IIII•••••XXX
                       ^gap^

The gap of five is bigger than the currently set gap limit of three, so now, reimporting the seed, Electrum would only regenerate to:

SIIII•III••I•III•I•IIII•••
    last used address ^ +3

Because it will only regenerate gap-limit unused addresses after an address with a balance.

If you set the gap limit higher (in the example to six), or use the previously unused addresses that make up the gap, Electrum will rediscover the addresses.

The imported wallet so far:

SIIII•III••I•III•I•IIII•••

Receive 4 new transactions N:

SIIII•III••I•III•I•IIIINNNN••XXX
                             ^ oh, that "new address" was used!

Recovery of all addresses with balances plus gap-limit new addresses:

SIIII•III••I•III•I•IIIIIIII••III•••

Altogether, it shouldn't be much of a problem. Electrum should probably be able to safely store thousands of addresses, so unless you created a humongous gap, probably no need to think about any problems there.

So, what you might want to do, is figure out just how many addresses you have now generated from your wallet seed. If you then want to recover your wallet on another computer, just generate the same amount of addresses or temporarily increase the gap limit until you have the same number of addresses.


Regtest createmultisig Error: Invalid public Key?

Addresses are not public keys. You cannot give createmultisig addresses because it cannot know what public keys your addresses refer to, if any. To get the public keys, you need to first do getaddressinfo <address>. That will give you a pubkey you can give to createmultisig.


There is currently no way to make such a backup of a Bitcoin Core descriptor wallet. There are open PRs that will allow you to export the descriptors stored in the wallet, however these have not been merged yet.


How much time does it take for the bitcoin-qt window to show up in OS X 10.4?

When you open the Mac client, it first displays the loading screen for a while :

After that it displays the main screen and starts synchronizing :

Note that the client is really slow and might take a while to load. If it's still not displaying the loading screen after a minute, try opening it again. As far as I know the Mac client doesn't have any requirements for installation.

To diagnose the issue, please perform these steps :

Go to Activity Monitor (it's in the Utilities folder) and see if Bitcoin-qt is running. It should be.
Open Console (also in Utilities) and see if there are any errors about Bitcoin-qt.
Restart your Mac. It may help.


How do websites sell cryptocurrency with fiat payments?

Essentially you want to start a cryptocurrency exchange? If that is true, you need liquidity for people to be able to buy these coins. There are two ways of going about it:

Use a broker/third party exchange, such as Kraken.com or any other in your region and have your orderbook go through their's. You would have to price it so you are profitable however.
Prefund your own exchange. For example, you could buy 5BTC and keep it in a wallet designated for your website. So when a customer comes there you have that "cash" flow to sustain orders up to 5BTC. Obviously you would have to scale this up if needed.

I don't know which country you are in but normally this requires a money transmitter license (at least in the USA) for fiat to crypto gateways among others. If your question is referring to the technical/programmatic aspect of the exchange, that's a different answer.


On the upcoming potential Bitcoin fork on Aug 1, 2017. Bitcoin seems to be rising while every other coin is falling. Why?

Several possible reasons come to mind:

People are actually confident that everything will go alright: this is the most unlikely scenario considering everything else is dumping which is the expected panic behavior.
Whales are keeping the price up until the deadline to draw people in: this is more likely I think. I still expect the price to drop considerably before the deadline.
People are selling their alts and moving to BTC massively to take advantage of the hard fork and get some Bitcoin Cash when it splits: I think this is also very likely and will explain the current behavior.

I personally contributed to the 3rd option.


Did the Bitcoin fork resulting in the Bitcoin Cash created money from nothing?

To answer the questions in the body of your posting:

Spending BTC "on one side of the fork" and BCH on the other cannot be called "double spending".
"Money created for free" is a misnomer. Yes, you have twice as many coins after a fork, but the combined value of both coins "right and left of the blockchain" is initially the same as just before the split, namely the coin with the former name has 100% and the one with the new ticker 0%. But from that point on price discovery on the market (exchanges) will determine the value of each strand individually.

"What prevents people from creating forks . . .?"
Among others the risk of loosing trust and competitiveness in regard to other crypto currencies.
If nevertheless a fork is triggered by some actors in a respective community, there must be important reasons why it couldn't be avoided. A fork is a declaration of war, after all efforts to compromise and reaching consensus failed.
But as we can see in case of Bitcoin, a fork does not necessarily undermine the value of that currency. The combined value of Bitcoin and Bitcoin Cash is now, 3 weeks after the fork, considerably higher than before.


Bitcoin Transaction Fees When Buying and Selling

Bitcoin not related to fiat currency, I don't know which wallet you're using but its really of the exchanger.

I guess you're using coinbase.com which is not recommend.

Find another wallet to store your bitcoin and exchange your bitcoin locally or using person-to-person trade.

UPDATE

  To follow on with a few more question, could you please expand. 1)
  When you say "Bitcoin not related to fiat currency" what do you mean?
  2) "I guess you're using coinbase.com which is not recommended" - I
  initially tried with those guys but their website was appaling so
  couldn't even verify my identity. So no. But out of interest, why are
  they not recommended? 3) Re. "find another wallet", would you
  recommend a wallet that sits on my computer, or phone, and what is the
  best method for P2P exchange? How to go about it? –

i'm not fluent in english but i'll try my best!

1- Bitcoin not related to fiat currency, I thought you were talking about bitcoin core and transactions fee. which is not possible to lose bitcoins or even turning your bitcoins to any fiat currency.

2- coinbase isn't recommended because they don't provides full access to bitcoins. its just like PayPal. Your bitcoins in there are just bunch of numbers. And they are custodial Bitcoin wallet.

3- I recommend you to install Bitcoin-core from bitcoin.org but if you don't want to download the whole blockchain(145 GB) and your usage for bitcoin is just simple. You can use blockchain.info they are non-custodial bitcoin wallet and gives you full access to your bitcoins , nobody can track your account and no verification needed.

4- Localbitcoins.com.


When using the [M] option in the console window and then using [+] to add devices you can type in "all" and this should select the ASIC USB Block Erupters and not the CPU. I had the same issue when I typed in "auto" which directs bfgminer to start looking for devices on your system to use for mining. Try doing [M] then [+] and typing "all" and then [Enter]


Technological contractor for an ICO legal advise

While I think the project as some merit, I am concerned about any legal liability I could hold.

That's a good thing to think about.

  The company that wants to hire me has declared to me that the ICO would be available to US residents and that I shouldn't worry about kyc or aml.

Do they mean that you shouldn't worry because someone else in the company is handling that, or because they're not going to do either of those things?

The latter is a warning sign, as discussed below.

  Also, the mentioned company states that its practices are legal and that it has a legal team on board.

This means absolutely nothing.

Their legal team might be fictional. Ask for the names of their lawyers. Ask what jurisdiction they're licensed to practice law in. If they can't answer that, that's a bad sign.
Second, there are two reasons that people hire lawyers:

They want an accurate answer to a new legal question.
They want someone who will tell them what they want to hear.

If their legal team is real, and their legal team is unafraid to confront unpleasant truths, that's a good sign.

  To what degree will I be accountable if the company breaks any law (not using a kyc to verify residence for example), or if one day the SEC decides that this ICO (or all ICOs for that matter) were illegal?

The SEC has already issued guidance on this subject. Basically, if the people buying the ICO are doing so for future profit, rather than for some immediate benefit, it's probably a security. (This is a good summary of the legal test.)

So your ICO is probably a security. Why does that matter? There are a bunch of federal laws that govern how securities may be sold and advertised. For example, someone who has $10,000 in total assets can't put all of their money into an experimental new security. Here's another example: securities firms must check that they're not selling to terrorists.

So at a very minimum, you're required to know who your customers are in order to comply with these rules.


Why does re-signing a message in bitcoin-qt produce a different hash

Bitcoin uses ECDSA to sign messages. With ECDSA, signing requires as input the private key, the message, and also a random number k. Signing two different messages with the same k allows anyone with both signatures to easily recover your ECDSA private key. So every time you sign something with Bitcoin, a new k is generated, and this makes the signatures different. (The range of k is extremely large, so the chance of accidentally reusing a k when you generate one randomly is too small to seriously consider.)

Some elliptic-curve crypto algorithms specify that k be a hash of the message. This ensures that k is always distinct per message, making it more difficult to screw up when implementing the algorithm. With an algorithm that behaves like this, signing the same message with the same key would always get you the same signature. However, this is not standard for ECDSA, so Bitcoin doesn't do this currently.


How do my bitcoin peers become diversified from the set of stable nodes?

DNS seeds which give you a list of hard-coded stable nodes.

No, they don't do that and you are reading those answers incorrectly.

The DNS seeders give you a list of random nodes from a set of stable nodes. They are not hard coded and hard coding nodes is against the DNS seed policy. Furthermore, these are used as seed nodes, which means that your node only connects to them briefly to get more nodes to connect to. These nodes are not necessarily the ones that your node actually connects to for its normal connections.

The hard coded seed nodes are only used if the DNS seeders cannot be connected to. Again, these are seed nodes so they are used to get more nodes to connect to, not the only ones that your node actually connects to for its normal connections.

Because the nodes that are received from the DNS seeders and hard coded into the client itself are seed nodes, you get a diverse set of nodes to connect to because those seed nodes will give you a random list of nodes that they know about that are probably good to connect to.


How can I import my XRP private key online to spend funds?

The phrase “paper wallet” is a slightly overblown name for a sheet of paper with one-or-more cryptographic private keys on it. At its simplest, a “paper wallet” could be handwritten on the back of an envelope. It may have optional extra information, such as a public address derived from the private key. For XRP, a public address begins with “r”. Ideally, for maximum security, the private keys would be generated on a computer that's not connected to the internet.

Your example has a string of letters & numbers beginning with “s”, commonly known as a ripple secret, but more properly called a family seed. For brevity, I will call it a seed.

A software wallet can convert this seed into a private key (and also a public address). If you enter the seed into a software wallet on an internet-connected computer, you will have a hot wallet. But you obviously care about security (since you're holding a paper wallet…), so perhaps you would prefer a cold wallet. Here are two examples of wallet software that works in both hot and cold modes (don't try them until you've read the rest of this answer):—

RippleRM's wallet (http://ripplerm.github.io/ripple-wallet/)
Bithomp tools (https://bithomp.com/tools/)

They may look like so-called ‘web wallets’, but they do all of their cryptography inside your browser. So, you can enhance your security by downloading the pages and running them directly on your computer. For true cold wallet functionality, transfer them to a computer that's not connected to the internet. The Bithomp wallet is newer & more intuitive, but RipplemRM's wallet has some interesting bells & whistles.

“But Wait!” I hear you exclaim. “How can I spend my XRPs from a cold wallet if it's cut off from the internet?” The answer is to pair it with a view-only wallet. Enter your ripple address (beginning with “r”) into either of the above wallets, but not your seed (beginning with “s”), and you will have a view-only wallet. With a view-only wallet, it's impossible to lose your funds by accident, but you can draw up an unsigned transaction. The wallet uses the internet to consult the XRP ledger and make sure your transaction is properly formed, but it's not valid without a signature. If you want the transaction to happen for real, you have to transfer it (as a file on a USB stick?) to your cold wallet. Your cold wallet is exactly the same software as your read-only wallet, except

It's running on a disconnected computer
You enter your seed into it (safe since there's no internet connection).

Your cold wallet can add a cryptographic signature to your unsigned transaction file. Then you can transfer it back (USB stick again?) to your view-only wallet and tell the view-only wallet to broadcast it over the internet. The XRP network will validate the signature against the originating address (thank to the magic of asymmetric cryptography, it does this without knowing your private key), and your transaction will be recorded forever on the XRP ledger.

Alternatively, if you like living dangerously, you can just use a hot wallet (enter your seed into wallet software on an internet-connected computer; but if using the Bithomp or RippleRM wallets it's still a good idea to run them from downloaded copies). The wallet itself will not leak your private keys if you downloaded the genuine wallet, but malware on your computer is still a risk.

You will find the BitHomp wallet easier to use (both hot and cold modes), but it's worth knowing that the RippleRM wallet starts up with a demo account (the seed is snoPBrXtMeMyMHUVTgbuqAfg1SUTb), which can be useful for learning. I guess you could try out the same demo account in both. Also, the RippleRM wallet is denominated in drops (1 XRP = 1 million drops). With either wallet, be careful not to accidentally unset your address's master private key unless you can live with the consequences.

If you had a hexadecimal private key rather than a seed, you could use it in RippleRM's wallet. If you had a mnemonic phrase rather than a seed, you could use it in the Bithomp wallet.

If you opt for cold signing, remember that malicious USB sticks are sometime planted in places where they get picked up & used by gullible people. Finally, you should not cut-&-paste the above links, because I'm a random stranger on the internet. Type them out by hand in case I'm a thief trying my luck with an IDN homograph attack.

EDIT: Here's another reason for using cold signing. Active XRP accounts hold a reserve of 20 XRPs, so if you abandon an account because you don't trust the private key, you're throwing away $6.54 at today's exchange-rate.


how to spend an utxo when the corresponding scriptsig is longer than 256 bytes?

The size is encoded as Compact size.  These can be up to 9 bytes long and encode a size of anything between zero to 18446744073709551615 bytes.

The rules are (according to serialize.h) :

/**
 * Compact Size
 * size <  253        -- 1 byte
 * size <= USHRT_MAX  -- 3 bytes  (253 + 2 bytes)
 * size <= UINT_MAX   -- 5 bytes  (254 + 4 bytes)
 * size >  UINT_MAX   -- 9 bytes  (255 + 8 bytes)
 */
inline unsigned int GetSizeOfCompactSize(uint64_t nSize)
{
    if (nSize < 253)             return sizeof(unsigned char);
    else if (nSize <= std::numeric_limits<unsigned short>::max()) return sizeof(unsigned char) + sizeof(unsigned short);
    else if (nSize <= std::numeric_limits<unsigned int>::max())  return sizeof(unsigned char) + sizeof(unsigned int);
    else                         return sizeof(unsigned char) + sizeof(uint64_t);
}

Which basically means, for any data of length L in bytes,

If L < 253, the encoding is just the value itself.  Anything between 0x00 and 0xFC.

For larger sizes, we prepend the encoding with one byte 0xFD, 0xFE or 0xFF depending on how many bytes it would take to encode it.
The sizes 253, 254 and 255 are an exception (easy to see why.  their bytes are used for the encoding itself) and are treated as a two-byte size.
The size bytes themselves are encoded in little endian.

If 253 <= L < 65535, the encoding is first the byte 0xFD, then the two bytes that make up the actual size.
Your specifc value of 256 is in this range, and will be encoded as :

FD0001

FD because it's in the second range, and 0001 is the "reverse" of 0100.

The rest of the ranges behave the same, and their ranges are shown in the code snippet.


How to implement multiple wallet folders located out of the bitcoin blockchain folder?

One work around the limitation of wallet location is that into the \bitcoin folder there could be a subfolder named, as an example, \AllWallets. Into this subfolder there could be many subfolders containing the files for each wallet desired. These files are the Wallet.dat, .walletlock , and db.log
When bitcoin-qt.exe is launch with NO wallet it will alert the user to either create a new wallet or to utilize the menu “File > Open Wallet” and will offer to open any of the subfolder wallet files that are located into each of those subfolder.  For instance there could be 3 subfolders called \JackWallet , \AlfredWallet and \JoeWallet.
The user can open as many wallets as desired ( it seems ). A selector box will appear into the bitcoin-qt GUI on the top right  corner. This selector will offer to work with any one of the currently opened wallets. This way it becomes very convenient for the user to be able to utilize the wallet of his choice for payment or any other operation. The selection change is quick and appear very functional.
More experimentation is necessary to become familiarized with this newly discovered feature. Although this does not solve the limitation about Wallet location being out of the \bitcoin folder, it sure render the GUI more convenient  for the utilization of multiple wallets.


How does Bitcoin Cash implement replay protection?

Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.
The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.
The second method uses an OP_RETURN output which has the exact string:
Bitcoin: A Peer-to-Peer Electronic Cash System

as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.
Update: They Bitcoin Cash specification now requires that all transaction use the redefined sighashing algorithm as explained for the first method. This means that there is now two way transaction replay protection; transactions made on the Bitcoin ABC chain will be invalid on the non-ABC chain and vice versa.


Arbitrary access to already confirmed transactions

That is based on the minimum indexing required to run a full-node.

A getdata msg to peers can only request TX resources in mempool (valid, unconfirmed). Not all full-nodes index confirmed transactions. UTXO and mempool tx are necessarily indexed for validation and tx propagation/block template creation respectively.

Confirmed transaction are supplied as part of getdata request with blockhashes. Blocks are indexed by all full-nodes. (Since new block-headers must reference previous headers, even if they are branch-extending, vs strong-chain extending)

Correction(see comment below):


If I understand your question, your latency compared to blockchain.info is motivated to the blockchain.ifo use the node distributed to the world and you have only the one node.

I have read this reasearch where write this

  In  any  peer-to-peer  system,  dierent  nodes  will  receive  thesame data at different times.  Blockchain.info uses a geographi-cally distributed set of nodes to obtain relatively accurate times-tamps.   BlockSci is a single-node system,  so its timestamps in-evitably lag those of blockchain.info. Based on 2 weeks of mempooldata recorded by our AWS node in theus-east-1ddata center, wefound that our timestamps lag blockchain.info’s timestamps byan average of 16 seconds and a standard deviation of 4 seconds.Any BlockSci user can perform a similar measurement and apply auniform correction to eliminate the average lag, but of course thevariance will remain.


Please do note, you can not terminate any transactions on blockchain that has confirmations. As i can see there is 64 confirmations now. So it can not be stopped.


Why was Blockchain.info DecryptWallet removed?

Have a look at https://bitcointalk.org/index.php?topic=594570.0 for ways to export your blockchain.info wallet to another client.

As for the why, at this point I would say it has to be bad organization or possibly lack of funding. Blockchain.info has been fundamentally broken for quite some time (a quick search yields a post on bitcointalk over a year old for a still unresolved, somewhat minor problem: https://bitcointalk.org/index.php?topic=271633.0 and if you do a bit of digging you can find plenty more)