How to generate a Litecoin Private key and correspondent Public Address in C#

That's odd, since BAU's docs say that they ought to work with Litecoin. In the drop-down menu that selects the coin type, have you selected Litecoin?

Alternately, if you're willing to run an RPC node, you could use BitcoinLib, and call CoinService.GetNewAddress(String).

Generally, it's exactly the same as generating Bitcoin addresses, except that the version byte is 48 instead of 0.


What is "Verifying last 288 blocks at level 3"?

It is to verify the block database has not been damaged or tampered with. It does not modify the databases in any way.


How to do mass payouts in my application to multiple addresses at once, or very quickly?

In Electrum you can use the CSV import feature to make bulk payments. It can accept either a CSV file or CSV entered into a text box. The rough format is:

ADDRESS, 0.12345
ADDRESS, 0.12314

This feature has been merged into the 1.9 version that is not released yet, but you can use it already.

https://github.com/spesmilo/electrum/pull/282

Example:

1PkeTTctdh2CvhW3fQLs93PWP9qupWV68X, 5
3NujXLC3LxNsmk2wr69CLBuXGfhXeenUyu, 5
1CNAnSb7d1XCA4AXBH2gip3mi8dNTQxzeo, 1
1LSBFJ1An9orRMU6Bz3NS1y3jr1eH9AexE, 1
16qRyDVZVpptJb4HZzv5rWkjqtJWVRjDep, 1
1PkeTTctdh2CvhW3fQLs93PWP9qupWV68X, 5
1Nnad832Zyob64wGbju49CC5RFbACAfCNZ, 1
1J2gFYBnf8K2wHJDndgr3iN1nPoZumHXap, 5

The amount is in the unit your Electrum is configured. In my case, for example, it is in mBTC. Be careful with this!


Payment Protocol: Is using different addresses for refunds just because of privacy?

Some hosted wallets are using addresses in elaborate ways. So you cant be sure the address sending the payment is the one "owning" the bitcoins.

An example is CoinJar, that uses addresses to indicate to what account the funds should be added. But behind the curtain CoinJar does anything it feels is best, making the most efficient use of all its previous outputs.


there is no such improvement planned for the protocol, only the expected BIP are listed in  https://github.com/bitcoin/bips/blob/master/README.mediawiki.
but you should understand why in bitcoin only a limited scripting mechanism is used instead a VM with a contract language as for Ethereum (security reasons). the project RSK aims to provide such opportunity through a sidechain, so explore it.


If I set assumevalid=0 after syncing the blockchain will Bitcoin Core go back and validate historical blocks?

No, it won't.

That's also not possible without rebuilding the UTXO set from scratch, as the unspent outputs being spent need to be known to validate spends against.

If you want to force a revalidation from scratch, start with -reindex-chainstate. This will blow away the UTXO set, and recreate it from the blocks on disk, and revalidate everything in the process (including all signatures, if -assumevalid=0 is set).


Export a list of addresses associated to blockchain.info account

I also faced this problem.
There is a neat trick to only copy a column in firefox http://www.alvinpoh.com/how-to-select-columns-of-text-in-your-browser-firefox/ (Just need to use Ctrl key) . For chrome install https://chrome.google.com/webstore/detail/columncopy/lapbbfoohlcmlbdaakldmmallcbcbpjb?hl=en

Goto Receive Money Tab and in the list use Ctrl with mouse to select first coloumn and voila you have a list of addresses.


Should I be using the "encrypt wallet" feature in Bitcoin Core?

If the computer that holds your wallet.dat file is ever connected to the internet (which it surely must be) then every second that it is turned on it is being probed by thieves attempting to break into it. If any succeed, your wallet.dat file is unprotected and will be copied and used.
If you use email or a web-browser on that same computer then every message you look at, every page you read, creates a very real additional risk that your wallet.dat will be copied and used.
You could buy a cheap letter-punch and stamp your password into a sheet of metal and store it in a very safe place. Don't store important passwords in tiny weak magnetic fields.


How public key is calculated from a base58 encoded private key?

The private key is just the 32B entropy you generated. Between wallets this private key can be encoded in a format, which provides further information such as the network(main/test/alt) and whether a compressed or uncompressed public key was used. This encoding is called the Wallet Import Format.

version (1B) (0x80 mainnet/0xEF testnet)
privatekey (32B)
0x01 compressionmarker (1B)
checksum (4B)

https://teachbitcoin.io/wallets.html#/2

Checksum is of everything which precedes it. The data is finally encoded in base58.

To take this WIF data and produce the public key, the wallet just needs to extract the private key 32B) and compute the public key point

private_key * Generator_point = public_key(x,y)

The resulting x, y public key point is your public key. If the compression market is on, take the x-coordinate and prepend a 0x02 or 0x03 depending on whether it is even or odd.

compressed public key: 0x02/0x03 + x_coordinate(32B)
uncompressed public key: 0x04 + x_coordinate(32B) + y_coordinate(32B)


What happens when a node cannot find the base Block of a newly received Block

Without knowing the parent, the node will hold onto the block and only do validation that can be done without context (i.e. the parent). It will also ask its peers for the parent block, and once it receives it, it will connect both blocks to its blockchain if they have more cumulative work than the node's current blockchain.

Otherwise the node ignores that block.

Keep in mind that this scenario is extremely unlikely, and not because a miner is unlikely to find two conflicting blocks nearly simultaneously. Rather nodes will relay blocks once they verify them, there is no such thing as "send to a peer but not the network". Sending a block to a peer sends it to the network as that peer will relay it to its peers and so on. So when Ma receives the block, unless it has been sybil attacked by the Adversary, it will relay that block to the network.

When Ma's peers receive S1 and B4, they will relay it to Ma and Ma will update its blockchain accordingly.


colored coin possible with ring signatures and stealth addresses?

Based on my understanding of Cryptonote's ring signature implementation, no, it cannot be used with colored coins.

With Bitcoin, there is a one-to-one correspondence between inputs and outputs of transactions.  Suppose there is a transaction X with an output X1 that sends 1 satoshi to Alice's address A, and everyone agrees that output X1 is colored so that it grants title to Alice's 1977 Chevy Nova.  If Alice decides to give the car to Bob, she creates a new transaction Y, with an input pointing to X1, and whose sole output Y1 sends 1 satoshi to Bob's address B.  Now Bob can prove, by creating a signature corresponding to his address B, that he is the rightful owner of the car.  If Mallory tries to claim the car by creating a different transaction with input X1, he will be found out, because he can't sign that transaction with Alice's private key, so it won't verify.  If Alice tries to give the car to someone else by creating a second properly signed transaction Z with input X1, it will be detected as a double spend because another transaction spending X1 precedes it in the block chain.

With ring signatures, this correspondence is broken.  When creating a transaction, in addition to the one output (of a previous transaction) that you really want to spend, you can list many others.  You create a signature that proves that you are authorized to spend one of the outputs you listed, but doesn't give any information about which one it was.  However, a linking algorithm ensures that any future attempt to spend that output again will be noticed and rejected.

In the above scenario, if Alice uses a ring signature on her transaction Y, including not only X1 but another output Z1, then her signature will not prove that she is entitled to spend X1 (and therefore is the rightful owner of the car and can give it away); it only proves that she is entitled to either X1 or Z1.

Furthermore, Mallory could create a transaction M that includes X1 and another output K1 that he is entitled to spend.  Since he has the private key corresponding to K1, he can properly sign the transaction M, but it won't be clear whether it is spending X1 (which would convey title to the car) or K1 (which won't).

Now, ring signatures are an optional feature in Cryptonote.  If you want, you can create a transaction with only a single input, which will make it unambiguous which previous output you are spending.  To avoid confusion such as Mallory's transaction above, a colored coin protocol for Cryptonote would probably specify that to convey title, you have to use a transaction with a single input; then Mallory's multiple-input transaction above would still be a legal Cryptonote transaction, but the community would agree it doesn't grant him title to the car.

In short, the whole point of colored coins is to create an unbroken chain of transactions that traces the title of the car, and the whole point of ring signatures is to avoid creating such a chain.  So if you want colored coins, you have to avoid using ring signatures in this way.


Here's a site with all the nodes on mainnet
https://1ml.com


Provide payment processing to my community

Yes, it is a very good idea to run a node for a community, where people trust each other, but not the entire world.

Your node provides the trust about a payment going/coming through. The key is to limit the trust to this and not more.

Let every person hold their own keys and wallet software to spend their received money. Let them only consult you about the state of the blockchain. You can do this by exposing your node as an explorer or by allowing people in community to connect to you privately(api, rpc calls etc)

If you are concerned about hosting due to legal/logistics business, provide people a method to access & compare as many publicly exposed explorers as possible, to consult for txs, but people need to hold their keys.

(A meta discussion is that over time you might even want to run a mining operation for a truly sovereign community.)


Could the BGP attack be used to split the Bitcoin network?

Having control over BGP and being able to split the Internet in two pieces can indeed be used to carry out an attack against some Bitcoin users. It might not even be that economically infeasible as you may think.

The adversary does not necessary need to have a control over a big portion of the Internet backbone infrastructure - he only needs to cut off a (small) region. This would effectively cause a split of the blockchain, without the victims noticing any problems with their connectivity to other peers as the communication is not signed (nor encrypted). In other words, if you can redirect the traffic going to a well-known Bitcoin node (by "stealing" his IP), you can easily replace him and act in his name.

Of course, that's not to say that this would go totally undetected by the public. People operating nodes in the cut off region would see a dramatic downfall in the Difficulty, and they could also see their inter-regional transactions not getting cleared and confirmed by their recipients. However, this kind of attack can still be efficient against a targeted victim, providing that it's performed carefully.


Is there actually a dilemma of whether or not to publish channel states for LN nodes?

I suggest we say channel balance instead of channel state (the state is encoded by a signed  commitment TX and if it leaks you could loose your funds)

As for the balance such a dilemma indeed exists. Indeed routing becomes more trial and error without public channel balances. Yet, there will probably be methods that allow to predict routes with higher probability.

On the other hand, there is not only the privacy aspect speaking against public channel balances. One would have to announce every balance update to the network which happens for every payment and  would result in an infeasible high payload of gossip messages.


Does my money still grow if I have it in Coinbase Vault?

The amount of cryptocurrency you deposited into the 'Coinbase Vault' will remain the same (unless there are some fees levied by Coinbase for the storage, etc). So if you put 1 bitcoin in, later you will be able to withdraw 1 bitcoin. The value of that 1 bitcoin (measured in USD) may change during that time, but you will still own the same amount (1 bitcoin).


For any of addnode, connect, port, bind, rpcport, rpcbind, and wallet you should move them into the [test] and/or [main] sections of your bitcoin.conf. You can also move any other setting that you want only applied to mainnet or testnet into the appropriate section.

Example:

server=1
daemon=1

[main]
prune=1000

[test]
rpcport=55555


Is Mining Bitcoin While The Price is Low or High better?

Does the reward for Bitcoin increase/decrease when the price goes up and down?

The reward for mining a bitcoin block is:
(the current block subsidy) + (the fees from the included transations) = (the block reward)
The block was originally 50 BTC, and this amount is cut in half every 210,000 blocks. At the time of writing, it is 6.25 BTC.
The price is an extrinsic property, it has no affect on the number of BTC included in the block reward (though obviously the dollar value of the block reward will change, as the price changes).

Is it more profitable to mine when Bitcoin is down, or when it is up?

Profitability entirely depends on the miner's costs, and revenue. It is a highly competitive free market.
When the price drops, some less efficient miners may become unprofitable, since costs are usually payable in fiat currency, and the block reward is realized in BTC.
When the price increases, miners will see a larger profit in fiat currency terms, but this also means that less efficient miners may join the network (as they are now able to operate profitably), thus netting the already-operating miners a smaller portion of the total rewards over time.
It is a constant push-and-pull. A higher fiat price per bitcoin will mean more revenue (denoted in fiat), but also more competition. We might expect this effect to roughly cancel out, so that profits trend towards zero on average (if they were higher than zero, we would expect more miners to join the network, to take a piece of this profit).


How many weight units does an input use?

What is the weight unit cost of an input?

2 things affect the weight of a tx, the total number of bytes , and the total bytes minus witness data.

Transaction Weight = Base transaction size * 3 + Total transaction size, where

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

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

See BIP141

  Can you batch/aggregate the inputs or is it linearly growth when you
  add more inputs to a tx?

You can't batch inputs, but you can combine them and send them back to yourself first in a larger amount, but that requires an additional transaction. Probably the best you can do now is to use a segwit address to receive funds so when you go to spend the inputs, the witness data lowers the weight of each input.


Implementation of tokens/assets/colored coins on top of bitcoin lighning nodes / channels?

Just wanted to add that Colu has been working on this problem since at least 2016, so i would dive deeper into their repositories, if you haven't already:

https://github.com/Colored-Coins

the most recent information I can find on these efforts is:

https://bitcoinexchangeguide.com/coloredcoins/


How isn't blockchain fundamentally broken?

The chain works by verifying every previous block, right? How does this not become an exponential problem?

I think you are assuming Blockchain growth is exponential with time, but it is linear with time (1MB / 10 min).

I have to verify, by checking every block of theoretically unlimited count?

In an extreme scenario, you are right. In the year 3000, we will have ~100 TBs to download and verify and it will keep on increasing ever after. But it's not as bad as it sounds like.

The rate of growth is low: Because it grows linearly with time, at a given time you will always have a finite amount of data to download and verify. As others have mentioned, there are solutions like SPV and node pruning in order to avoid full storage. If you want to run a full node with entire blockchain stored locally, this rate of increase 1MB/10min is considered small relative to the rate of growth of technology.

Increased efficiencies of node resource utilization: A lot of effort goes into managing the node resources to optimize network bandwidth, disk block compression, verification speed in order to mitigate to downfalls of ever-increasing blockchain size. In fact, if you look at the historical bitcoin-core Initial Block Download times, you will find these times have kept the same or improved over time despite the increasing blockchain size.


You can't. Most if not all wallet software don't keep logs as to who accesses recovery seeds or mnemonic phrases. (as would be stupid if not impossible)
(I'm assuming you're talking about Electrum here?)
The most you can do is see where your funds went using a third-party tool such as Walletexplorer
If you're lucky and he sent them to a regulated exchange, (coinbase et al), you can file a police report and they'll probably someday hand over the KYC data + IP adresses.
Don't get your hopes up though, your funds are gone.


Despite the popular consensus on the matter, banks probably aren't specifically Bitcoin-unfriendly.  The repeated bank problems for exchanges probably come down to three main things:

Automatic risk triggers -- Banks have a lot of mechanisms in place that throw up warning bells when a new customer starts moving lots of money around, is rapidly depositing and withdrawing large amounts of money, etc.  In the past, such activities have often been associated with money laundering, crime, and the sorts of things that are generally bad for business.  Even if a Bitcoin business isn't a problem, it looks like one to the risk algorithms.  If, over time, Bitcoin businesses prove to in fact be low-risk while driving significant business for the banks, the algorithms may be adapted to take this into account.  But they're not rewriting their risk algorithms for what is from their perspective one tiny new technology (and that's probably responsible of them).
Regulatory compliance -- When risk triggers are activated, the first thing the bank wants to know is whether a business is fully compliant with anti-money-laundering legislation.  Many Bitcoin businesses and exchanges are, but the fact is that some aren't.  They haven't been prosecuted for it, but they weren't doing all the paperwork that they really should have been.  Sometimes it's not really the business owner's fault either--financial legalities can be complicated and arcane.  Nonetheless, failure to comply is a huge liability for a bank.
Legitimate risks -- Finally, despite their volatility, bitcoins are a much "harder" currency than most bank deposits and transfers, in the sense that a bitcoin transaction can't be reversed, while bank deposits and transfers are all the time.  That means there is a massive incentive for individually shady customers to move ill-gotten gains out of the banking system and into bitcoins, and there's nothing the Bitcoin exchanges and businesses can really do about that.  This is a major risk problem for a bank, who could end up out some serious money if transferred cash is later "charged back."  At least one major bank recently has quoted risk assessments of individual customers, rather than the exchange itself, as the reason for closing an account.

TL;DR:  Bitcoin per se doesn't have as much to do with it as many people think, and in most cases all three of these issues will apply equally at any financial institution regardless of their personal biases, or (more likely) ignorance regarding Bitcoin itself.  So in the sense that you're asking, there may not be such a thing as a Bitcoin-friendly bank.


This is valid, and there are even smaller types as well. Be aware that Bitcoin no longer really uses ASN.1 DER, but a even more restrictive subset of it. ASN.1 itself as it turns out is not deterministic or platform independent in many implementations, which is a source of consensus failure. For reference, here is how to encode signatures correctly in Bitcoin, from the text of the withdrawn BIP62.

0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type]

    total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte.
    R-length: 1-byte length descriptor of the R value that follows.
    R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.
    S-length: 1-byte length descriptor of the S value that follows.
    S: arbitrary-length big-endian encoded S value. The same rules apply as for R.
    sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).


Would I have access to those bitcoin?

Pieter has answered this but see answers to Is it possible to brute force bitcoin address creation in order to steal money? for an idea of how likely this sort of thing is.
There's some other points raised by your question that I think are worth examining.

I understand bitcoin is a ledger

We all say that but really, in accounting terms, it's not a ledger it's a journal. A transaction journal.

Everything is accounted for.

That is not exactly true. The transaction journal known as the blockchain keeps a record of all the amounts but there's a lot it doesn't account for.

If something is debited from one side, it is credited to the other, and vice versa.

There are no debits and credits in the Bitcoin network itself. That is, there is no carried-forward number in the Blockchain from which an amount is subtracted (debited) or added to (credited).

If a coin is sent to a wallet ...

Coins aren't really sent to wallets, we say they are sent to Bitcoin addresses. A Wallet will have many Bitcoin addresses. But really coins are not sent to addresses, they are locked by a locking script, a kind of simple program. Bitcoin addresses are just a kind of abstraction of a standard script.

... with a public key, that doesn’t exist, ...

That is certainly possible. Though "exists" isn't quite right. You mean a public-key for which no-one knows a corresponding private key.

... the coins are considered “lost”.

Actually, no one can tell the difference between a lost coin and one that is safely stored in a wallet. If someone doesn't know the private-key corresponding to a public key associated only with unspent coins, they have no way to tell if someone else ever did or currently does know such a private key.

But they are still debited from the wallet that sent it and credited to the wallet that doesn’t exist

Yes, but coins are not debited from wallets. The Bitcoin network protocol doesn't know about wallets. It doesn't really do any debiting or crediting. It just keeps track of the creation and destruction of coins and makes sure that only the right number of coins are created when other coins are destroyed. The Blockchain has no information about wallets.

The above will seem like nit-picking. But we regularly see people ask questions here because they have been tricked out of money by people exploiting slight misunderstanding of how Bitcoin actually works.
the kinds of wallets I mean when I write the word wallet are programs like Bitcoin-core or Electrum. Some businesses provide accounts and provide a web-based interface or an app to manage the account and call these a wallet - that is not what I mean.


Generate address of 'private key' from user input

Assuming the private key string in this example is pk
Console.WriteLine("Enter private key:");
string pk = Console.ReadLine();
var bitcoinPrivateKey = new BitcoinSecret(pk, Network.Main);

var legacy_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Legacy);

Console.WriteLine("Legacy Address :" + legacy_address);

And if you want to get p2sh-segwit and bech32 address, add below lines:
var p2shsegwit_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.SegwitP2SH);
var nativesegwit_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Segwit);

Console.WriteLine("P2SH-Segwit Address :" + p2shsegwit_address);
Console.WriteLine("Bech32 Address :" + nativesegwit_address);


What are some essential features of Bitcoin classic?

According to https://bitcoinclassic.com/ there are no additional patches except the blocksize increase yet.

  It starts as a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB. We will have ports for master and 0.11.2, so that miners and businesses can upgrade to 2 MB blocks from any recent bitcoin software version they run.

In the times of git, nobody really controls a code base, it is just out there. The essential question is: What version is run/accepted by the majority of nodes (miners, merchants, users, ...).  You should read about hardforks if you haven't.


How are SIGHASH flags encoded into a signature?

The SIGHASH type is serialized as a single byte and then simply appended to the DER-encoded signature.

Example of a typical P2PKH scriptSig:

304402206e3729f021476102a06ea453cea0a26cb9c096cca641efc4229c1111ed3a96fd022037dce1456a93f53d3e868c789b1b750a48a4c1110cd5b7049779b5f4f3c8b62001 03ff1104b46b2141df1948dd0df2223720a3a471ec57404cace47063843a699a0f

The second element above is the public key, serialized as per SEC 1's Elliptic-Curve-Point-to-Octet-String Conversion. The first element is the DER encoded signature, with a 0x01 appended to specify it's a SIGHASH_ALL (whose values you've already found). To break the signature string down further, if you're interested:

30 <- a sequence
44 <- of length 0x44
  02 <- an integer
  20 <- of length 0x20
    6e3729f021476102a06ea453cea0a26cb9c096cca641efc4229c1111ed3a96fd <- r
  02 <- an integer
  20 <- of length 0x20
    37dce1456a93f53d3e868c789b1b750a48a4c1110cd5b7049779b5f4f3c8b620 <- s
01 <- SIGHASH type (not part of the DER encoding)

The SIGHASH type is also temporarily appended to the transaction before it is signed so that the signature precludes its modification, see this answer for more details.


What is the maximum number of inputs/outputs a transaction can have?

The total size of the transaction must be less than 100,000 bytes or it will not be relayed across the network or included in blocks.

There COULD be a miner that is mining >100K transactions, but I don't think there is; if there is such a miner or you mine the transaction yourself then the limit would be the 1,000,000 byte blocksize limit.


My pool shows no evidence of block that my computer discovered

Pooled mining lowers the difficulty that it reports to miners and the results are submitted as proof of work to the pool, so they can pay you.  Only a small portion of submitted shares are valid solutions to an actual block.


How does bitcoin core generate a receiving address without using my private key?

When the wallet initializes, it will generate a master private key for the you as part of the initialization. All subsequently generated keypairs will be related to the master private key, this is called a 'Hierarchical Deterministic' Wallet (HD wallet).

An HD wallet is nice, because you only need to backup the seed phrase that generates your master private key, rather than backup every individual address.


According to mining.bitcoin.cz, getwork protocol is removed. Use the stratum protocol instead. stratum.bitcoin.cz:3333

  08.07.2013
  Getwork protocol support ended. Please be sure your miners support Stratum protocol. You can still use your old getwork miners with Stratum proxy installed on your mining rig.


How did the first 50 Bitcoins come into being?

The first block is known as the "genesis block" or "block 0".  It was mined using the same hashing algorithm as any other block, but at difficulty 1.  It contains only one transaction, the coinbase, which gives 50 BTC to address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.

Once the block had been successfully mined its hash was hardcoded into the Bitcoin client's source code so that it and it alone would be accepted as the official genesis block.

src/main.cpp contains this line:

uint256 hashGenesisBlock("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f");


On Cryptowatch (or equivalent): see percentage change to custom reference point

Not the way you are putting it but i update my portfolio on
https://www.worldcoinindex.com/portfolio

This allows me to see in euro/usd and others.
For example you bought 1000 usd of any combination of currencies.
This profile wil tell you what it's worth approx (different markets have slight changes between them).


Changing p2p to create a quark coin mining pool?

I've been using the qrk.mime-pool.net for almost a week now and it is working fine:

They have instructions here:

http://qrk.mine-pool.net/start.html

All you need is a wallet address for it to pay into, the password can be whatever you want.  You can monitor payouts to your address from the Payout tab - if it doesn't appear after a few blocks have been  mined something is wrong:

http://qrk.mine-pool.net/index.html#mainnodepayout


I reused a previous deposit address and the recipient claims the address was invalid

If you've used this address before to deposit money to Sportsbook.ag, the address will still be under control of Sportsbook.ag. If they don't directly manage their Bitcoin deposits, their payment processor will still have received the payment in proxy.

They may not have expected you to reuse that address, but they should be able to fix it on their end. Contact them again and clearly explain what has happened. Good luck.


How often should I back up my wallet if I use Bitcoin-Qt client?

If you use default settings you have to backup your wallet.dat after you unlock each 100 your addresses. You also must backup your wallet.dat after you set a passphase on it. Do not create backups by copying your file while your client is running. Eigher create backup with a client menu or shutdown client and copy file to a different folder.


Different error messages under "Mandatory script verify flag failed."

But aren't both errors just variant of a failure in executing the OP_EQUALVERIFY? At what step of the evaluation each error is thrown and what can we make out of it?

No, they're different errors. There are two rules that must be satisifed here:

The hash of the public key must match a certain value. (A failure here means you have the wrong key, or no key.)
The signature must be valid for the message and public key. (OP_CHECKSIG does not error immediately. It returns 0, which causes the script to fail.)

There are other script errors, too. See this list: https://github.com/bitcoin/bitcoin/blob/master/src/script/script_error.cpp


No, only the third case is affected. And the reason for that is that channels are actually bi-directional and have two fee policies depending on the direction they are used.

For example, channel AB has a policy from node A, and a policy from node B. If B increases the fee - it will only affect the payments going from B to A, not the other way around.

That means that scenario 2 in your case is always controlled only by node A. Scenario 3 includes the payment from B to A, so fees will be higher. Scenario 1 can also be affected by node B, but it will need to increase fees on the channel BC, not AB.


Can wallets be shared by different machines?

It is a bad idea to have multiple copies of your wallet.dat running from multiple computers if both will be spending.  You risk getting double spend attempts that will never confirm and cannot be cleared without performing wallet surgery.

BlockChain.info/wallet has a "desktop sync" feature that will let their hybrid EWallet sync with your Bitcoin.org client (through RPC), but since BlockChain.info/wallet can be used on multiple machines why not just use BlockChain.info/wallet from everywhere instead?  You get to use the mobile app with it as well.


Does the fact that bitcoins are limited prove that the system is a scam?

You make a lot of interesting claims. The ethos behind bitcoin is similar to that of gold, hence 'mining'. Gold is also limited supply and I am certain that people who first found gold a long time ago are rich beyond their wildest dreams. That does not stop anybody trading gold for something of value.

  ... a kind of ponzi scheme ...

Ponzi scheme is a particular arrangement which Bitcoin certainly is not.


How to get the historical data from bitfinex.com with out a limit?

My suggestion is to get data by fragments for example:

Jan 1 2017 - July 31 2017
Aug 1 2017 - Dec 31 2017

Then merge on your code


Who was the person that told Satoshi "You will not find a solution to political problems in cryptography"?

It seems that no-one except Satoshi and the original author knows, as indeed the correspondence was not made on the mailing list and the rest of the message was not made public.


How to download bitaddress.org to use offline?

It is better to download the actual code from:
https://github.com/pointbiz/bitaddress.org
(this link is from the bitaddress.org site, no need to trust me :-)

Click the "Download ZIP" button.
Restart your computer. **
Make sure you do not have an internet connection enabled (WIFI disabled, Ethernet unplugged).
Open the zip file.
Open Chrome or Firefox.
Drag the bitaddress.org.html file into your browser.
Make your paper wallet using a complex, but impossible to forget password.  Ideally it is 16+ characters + numbers and punctuation.  You might want to write this password somewhere so it is impossible to forget, but then you are opening up another potential attack surface to be careful.
Make several prints (do not save a copy anywhere on the computer).
When done, close the tab and clear your browser cache and delete the printer spool file.**
Restart the computer to clear all memory, etc.

** For extra security, boot from a Linux LiveCD so that any trojans, viruses, key-loggers, etc you have on your "normal" computer are not able to interfere with the paper wallet creation process.

More good security tips here: https://bitcoinpaperwallet.com/#security


Get balance for an array of addresses with bitcoin core

You can use the scantxoutset command. This will scan the utxo set and return the utxos and the total balance for the addreses that you specify. Because it scans the utxo set, you won't have the transaction history for those addresses. But it does get you the balance and a list of utxos that can be used in a new transaction.


Is there any python library could be used to decodescript in output

I just added that to my toy library.

>>> from btctools import decode_scriptpubkey
>>> decode_scriptpubkey('76a914b3c2dc3a7f68a024a5d2ee9d4012dca1134dea8588ac')
{'address': '1HPVPU3xHMPcxmgdP9puPbnDcHDV5JhURh',
 'asm': 'OP_DUP OP_HASH160 b3c2dc3a7f68a024a5d2ee9d4012dca1134dea85 OP_EQUALVERIFY OP_CHECKSIG',
 'hex': '76a914b3c2dc3a7f68a024a5d2ee9d4012dca1134dea8588ac',
 'type': 'P2PKH'}


Issue with the BitcoinJ for Litecoin. Which dependency can be used for Litecoin?

use an alternative library to me I like this gives you more flexibility and uses bitcoinj

https://github.com/dogecoin/libdohj


The JSON-RPC has a method called getnewaddress that will generate a new private-/public-keypair and return it to the caller. You can use this to generate a new address for each user. In order to track the balances of users I'd suggest grouping a user's addresses in an account associated with the user by calling getaccountaddress with the user ID or the username. You can then use the getbalance <user> call to check its current balance. However, there are some caveats when grouping addresses with accounts.


Each scriptPubKey is limited to 10000 bytes.
Each individual push in a scriptPubKey is limited to 520 bytes.
Transactions are limited by the block weight limit.


Step by Step instructions on installing Bitcoin Core 0.14 on Raspberry Pi Zero and 1/2/3?

This is a guide I used to install a full node on a Raspberry Pi 3B with 1GB of RAM.
You have to compile the code and therefore need a RAM swap on an external HDD. Make sure it is mounted correctly, or it will wear out the sd card!
https://medium.com/@meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1


Possible to move specific transaction from one account to another?

The only way to do that would be to change the account associated to the address that received the transaction. Have a look at setaccount.


bitcoin block size and etherenum gas limit

What is the rationale that bitcoin block size is fixed unlike Etherenum?

The block size limit serves two purposes: to keep node operation costs low, and to create a fee market.

With a limited block size, there are only a limited number of transactions that can fit in a block and thus the blockchain grows linearly. This allows for blocks to have a limit on how much network bandwidth and disk space they take up, and also sets a limit on the computational work required to verify a block. Without these limits, blocks could be maliciously produced which are extremely large which take up large amounts of network bandwidth and disk space, and more importantly, potentially take down a node due to a large computational cost.

The limit not only helps with block relay, but also with syncing a new node for the same reasons as above. Comparing Bitcoin to Ethereum, you can sync a fully validating archival Bitcoin node in several hours on standard consumer hardware. It only takes up ~200 GB of disk space. Conversely, you cannot sync a fully validating archival Ethereum node on consumer hardware. Syncing one requires high end hardware (e.g. PCIe SSD) and the Ethereum blockchain also takes up over 1 TB of disk space.

The other reason for the block size limit is to create a fee market. Currently Bitcoin miners are paid through the block subsidy. However the block subsidy halves every 4 years and will quickly reach negligible amounts. In order to keep miners mining, we need to pay them in some other way, namely transaction fees. By having a block size limit, we can build a healthy fee market which organically grows over time so that by the time the block subsidy is negligible, there will be enough in transaction fees to cover the costs of mining.


Is there api for ripple.com to authentificate with username & password?

Usernames and passwords are client wallet functions. They have no meaning to the Ripple network and servers would have no idea what to do with them.

In fact, servers do not have permission to obtain encrypted wallets because if they did, they could attempt to brute force decrypt them, negating the security advantages of the blob vault. By design, is is as difficult as possible to ask someone else to obtain your wallet, purportedly on your behalf. This is necessary to prevent malicious web sites from sending javascript to your browser that causes it to brute force other people's wallets as you browse the Internet.


why is this transaction I made being rejected?

Seems I was spending the output of the previous tx thats why the transaction was rejected


The Scrypt algorithm started out as an "ASIC-resistant" algorithm, but it isn't anymore.

Because it is highly memory-intensive, it was thought to be prohibitive to design and use ASICs for it. Initially it kind of was. With cost of memory decreasing and the necessary research put in -- in order to unlock the profit potential attainable using Scrypt-capable ASICS -- that ASIC-resistance has largely vanished.

A great many ASIC hardware projects for Scrypt started out with great fanfare, but only rather few have succeeded and ever been delivered. A rather large part failed along the way or were scams from the beginning, with developers pocketing money for pre-orders and never delivering any product. Despite these numerous frauds, a number of ASIC development projects have actually been completed and mining hardware has been delivered. As soon as a successfully completed machine was deployed and hit the market, this was always visible in a significant increase in mining difficulty for Scrypt coins whose profitability has, as a result, steadily decreased with every new ASIC model delivered.

The only residues of Scrypt being ASIC-resistant these days are the lower hash rates you see with Scrypt-based Crypto coins as opposed to SHA-256 ones.


Does Bitcoin mining reward halving have documentation? Or is it just in the code?

This is not addressed in Bitcoin's Whitepaper, although Satoshi
Nakamoto briefly mentions the decrease of the reward, but never
explicitly talks about the amount of the reward.

Satoshi speak about the halving process since the release notes for Bitcoin v0.1 Alpha:
Total circulation will be 21,000,000 coins.  It'll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.

first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...

When that runs out, the system can support transaction fees if
needed.  It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.

Satoshi Nakamoto

On the Bitcoin wiki ( https://en.bitcoin.it/wiki/Controlled_supply )  you find this table that tell you when and how each of the 33 halving process will happen:

If you need a technical explanation of how the halving work in the code here you find a dissemination about it: https://ma.ttias.be/dissecting-code-bitcoin-halving/
Keep in mind that the halving are programmed by block height, so there are only estimates on which date these blocks will be reached (and the block subsidy will cut in half), but all other info on this topic are exact and well documented.


Why can't timestamps be a substitute for blockchain?

But then the next problem is transaction order and validity to prevent double spending. I don't understand completely why a timestamp can't just be included for every broadcasted transaction, and the transaction could have the correct, universally agreed upon time, and each ledger gets sorted chronologically. Is this because it requires a centralized system to prevent people from forging timestamps? Or what am I missing? To me, it seems like if the transactions were broadcast publicly to the entire network, there wouldn't be conflicts in ledgers / double spending.

You need to remember that communication networks aren't perfect. There are latencies, and there are nodes connecting and disconnecting. The system needs to be robust to these dynamics.

You also need to remember that the problem Bitcoin set out to solve is how can a merchant know that a payment to him is final and will not be reverted.

Suppose a double spender pays a merchant, with a tx timestamped at 13:05. The merchant see the tx and provides the goods. The attacker then broadcasts a conflicting transaction timestamped at 13:04.

A node receiving this new transaction has no way of knowing whether the timestamp on this tx was forged, or if it was indeed broadcast at the specified time, and he has simply missed it so far. Since the rules say earlier txs take precedence, the payment to the merchant will be reverted.

And that's when the node was actually connected to the network at the time these transactions were broadcast. What if it's a new node, or it had downtime at that point? How could he possibly ever know which of these transactions actually appeared earlier on the network?

That's exactly what proof of work and the blockchain are solving - they are a permanent record that everyone can agree on, which is hard to forge because it includes proofs that actual computational work went into verifying it.

  And how exactly does the main blockchain stay decentralized? Let's say I go offline and miss transaction broadcasts, and now I want an updated version of the main blockchain. I would have to rely/trust others for this main blockchain, which seemingly is centralized now in the way that all new users are pulling from this same copy of the blockchain. I don't quite see how that's different from the analogy with a community ledger with everyone just keeping their copy updated with that, or a main branch on a git repo which everyone continually pulls from. There is no single point of failure, but it seems to still be a community ledger in a sense.

The blockchain actually contains proofs. I don't need to trust any node - if I get conflicting blockchains from different nodes, I know which one is the correct one because it has proof of more computational work. This allows all nodes, everywhere, no matter when they connected, to agree on the same shared ledger.

And that's all that matters - agreement. As long as everyone agrees on which order of transaction is correct - in particular, the person who gave goods in exchange for bitcoins and the people he will later want to send these bitcoins to - the payment network works.


Is it possible to view others' transactions in bitcoin client?

Is it possible to view others' transactions

Yes.

  in bitcoin client?

No.

It's not terribly useful to look up the balance of somebody else's address, except maybe so they can prove they have a certain amount of funds.
These lookups would be slow, because it needs to work through millions of transactions. Creating the indexes that would allow you to do fast lookups on any bitcoin address would take a sizable amount of disk space.
All of them are there - it's a central part of the bitcoin protocol. What if somebody moves all of their money out of their account within a transaction you don't know about? Therefore, you have to know about all transactions, unless you want to be surprised when their payment "bounces."
There's already a website called Bitcoin Block Explorer that pretty clearly establishes that transactions are public. Even if there wasn't, you could still build your own.


In my view, we cannot move LevelDB index files such as chainstate, etc. to an external slow storage.
According to this link, we should only move the blkxxxxx.dat and revxxxxx.dat files to an external storage. These files are inside ${datadir}/blocks/ by default. Since the index directory (${datadir}/blocks/index) contains high i/o-frequency LevelDB index files, moving it to an external storage will increase the initial blockchain synchronization time.
So take the following steps (I followed the instructions of the link):

run bitcoind.

Let it run for a few minutes, or long enough that it has started synchronizing [ref]

Then kill the bitcoind.

Next, Move the "index" folder up one level (so that it may remain on the local storage):

mv -f ~/.bitcoin/blocks/index ~/.bitcoin/

Move the blocks folder to the shared directory:

mv -f ~/.bitcoin/blocks ~/blockchain/

Create a symbolic (soft) link to the local index directory at blocks directory in the shared storage (use absolute path):

ln -s /root/.bitcoin/index /root/blockchain/blocks/index

Now, create a symbolic (soft) link to the blocks directory at .bitcoin in the local storage (again use absolute path)::

ln -s /root/blockchain/blocks/ /root/.bitcoin/blocks


Whats a site or app where I can extract a public key just by typing in a private key?


What is the rationale for inclusion of previous amount in SegWit signing process?

It's not particularly required and may be considered redundant as that information is generally implied from the transaction outpoints referenced in the input. However, this form of transaction serialization allows wallet softwares to explicitly commit to the fees involved in the transaction. This is particularly useful if say you are using a hardware wallet where you have your private keys and at the same time you use a watch-only online wallet. Since the online wallets knows all the UTXOs that your private keys control, it can effectively create a transaction consuming some inputs.

To know how much fee you are committing to the transaction, the hardware wallet would have to query the input referenced, grab all the outputs of that transactions (which may be very large) and then only it will know what the fee is for this particular transaction. Otherwise, if it doesn't, the software that created the transaction could lie, and in fact convert a giant portion of the bitcoins consumed into fee without you knowing it. However, keeping the input amount as part of the message that signature commits to means the hardware wallet software knows the amount explicitly and hence can provide the user with an accurate measurement of the fees.


How do you switch your bitcoinjs integrationfrom TransactionBuilder to transactions-psbt.js?

You're only signing the first input? tx.sign(0, owner); Usually every input has to be signed somehow.

I also struggled with the switch to Psbt. Biggest difference was basically requirement to have a full transaction hex of every input for non-segwit inputs. Segwit inputs can be simpler but they can also be created using the full hex of the tx using non-segwit command so don't have to add extra logic differentiating between inputs. You can no longer just provide txid and vout, just add on the hex of tx that created each input for your object.

I really just followed examples https://github.com/bitcoinjs/bitcoinjs-lib#examples

So this is my take on a very general tx with psbt that I use for now:

import * as bitcoin from 'bitcoinjs-lib'

// not all parts of inputs have to be defined
// inputs - array of all data needed for inputs
// outputs - array of all data needed for outputs

const network = bitcoin.networks.testnet // or bitcoin.networks.bitcoin

const psbt = new bitcoin.Psbt({ network })
psbt.setVersion(2)    // default
psbt.setLocktime(0)   // default

// ************** create inputs **************

inputs.forEach(input=> {
  psbt.addInput({
    hash: input.txid,  // txid number
    index: input.vout,  // output number
    sequence: input.sequence, // often 0xfffffffe
    nonWitnessUtxo: Buffer.from(input.hex, 'hex'), // works for witness inputs too!
    redeemScript: input.redeemScript, // only if there's redeem script
    witnessScript: input.witnessScript // only if there's witness script
  })
})

// ************** create outputs **************

outputs.forEach(output => {

  psbt.addOutput({
    address: output.address, // only if not op_return type output (no address for those)
    value: output.value,
    script: output.data  // only if there's string (utf8) data to embed in op_return
      ? bitcoin.payments.embed({ data: [Buffer.from(output.data, 'utf8')] }).output
      : undefined
  })
})

// ************** signing **************

inputs.forEach((input, index) => {

  // sign regular inputs that can be simply signed
  if (!input.redeemScript && !input.witnessScript) {
    psbt.signInput(index, input.keyPair)

    // give error if signature failed
    if (!psbt.validateSignaturesOfInput(index)) {
      throw new Error('Signature validation failed for input index ' + index.toString())
    }
  }

})

// ************** finalizing inputs **************

inputs.forEach((input, index) => {

  // sign regular inputs that can be simply signed
  if (!input.redeemScript && !input.witnessScript) {
    psbt.finalizeInput(index)
  }

  // for p2sh or p2wsh script inputs
  if (input.redeemScript || input.witnessScript) {
    psbt.finalizeInput(
      index,
      getFinalScripts({
        inputScript: input.inputScript,
        network
      })
    )
  }
})

// ************** make tx **************

const tx = psbt.extractTransaction()

const virtualSize = tx.virtualSize()
const txid = tx.getId()
const hex = tx.toHex()

console.log('tx virtualSize:', virtualSize)
console.log('tx txid:', txid)
console.log('tx hex:', hex)

And for some reason finalizeInput for custom scripts is not exactly built in yet but I found it in examples and just added as a function I import or put somewhere in same file.

function getFinalScripts ({ inputScript, network }) {
  return function (
    inputIndex,
    input,
    script,
    isSegwit,
    isP2SH,
    isP2WSH,
  ) {
    // Step 1: Check to make sure the meaningful script matches what you expect.

    // Step 2: Create final scripts
    let payment = {
      network,
      output: script,
      input: inputScript,
    };
    if (isP2WSH && isSegwit)
      payment = bitcoin.payments.p2wsh({
        network,
        redeem: payment,
      });
    if (isP2SH)
      payment = bitcoin.payments.p2sh({
        network,
        redeem: payment,
      });

    function witnessStackToScriptWitness(witness) {
      let buffer = Buffer.allocUnsafe(0);

      function writeSlice(slice) {
        buffer = Buffer.concat([buffer, Buffer.from(slice)]);
      }

      function writeVarInt(i) {
        const currentLen = buffer.length;
        const varintLen = varuint.encodingLength(i);

        buffer = Buffer.concat([buffer, Buffer.allocUnsafe(varintLen)]);
        varuint.encode(i, buffer, currentLen);
      }

      function writeVarSlice(slice) {
        writeVarInt(slice.length);
        writeSlice(slice);
      }

      function writeVector(vector) {
        writeVarInt(vector.length);
        vector.forEach(writeVarSlice);
      }

      writeVector(witness);

      return buffer;
    }

    return {
      finalScriptSig: payment.input,
      finalScriptWitness:
        payment.witness && payment.witness.length > 0
          ? witnessStackToScriptWitness(payment.witness)
          : undefined,
    };
  }
}

I haven't tested every kind of input yet but this is basically what I use for p2wpkh and p2wsh inputs. I try to find examples spending exactly the type of input I need usually.


Can't connect Electrum to a Network so that I can receive my bitcoins

It sounds like you need to tell Tails to allow the Electrum client to connect through Tor.

There are very good guides already here and here.


Just generate some blocks.

bitcoin-cli -regtest generate 101

You will have them in your wallet and can use the funds once confirmed. 101 is the number of blocks to create.
You can use any integer that's at least 101 as the number of blocks.
You cannot use a smaller integer than 101 if you want to test transactions, because of the 100 block maturation time.


What prevents miners in a pool from retaining the reward?

The payout address for the miners mined blocks is the pool's moderator address. If the miners are working on blocks with a different payout address (ex. their own), the pool moderator can tell and act accordingly by either banning them or simply ignoring their work.


Time series data for issues listed on the (now defunct) GLBSE

A forum user captured the transaction and dividend history from the @GLBSE Twitter feed which can be used to determine daily pricing and dividends.  This is from v2 (April, 2012).

http://bitcointalk.org/index.php?topic=117491.0


Can you mine your own transactions yourself?

Theoretically, if you can mine blocks then you can certainly include your own transactions in the block.

Practically, you are competing with every other miner on the planet to find the next block. If you "win", you get the block reward plus you get to choose which transactions are included in your block. If somebody else wins, you get no say in the matter. Unless you have a very large mining operation, the chance of you winning is so small that it's never going to happen.

Miners who do make new blocks today (somebody has to, after all) may choose to include their own transactions in their blocks.


Imagine I want to share a key with someone that would allow them to generate the same addresses available for my seed words on the web wallet, but without allowing them to send any transactions.

I'm pretty sure what you suggest is not possible.
The only single datum of information from which you can produce all the addresses is the one that also allows you to spend money.


Understanding "Bitcoin Inflation vs. Time" chart

The blue line on the graph represents the total supply of BTC in existence at that point in time (right axis).
The red line represents the instantaneous annualized inflation of the BTC supply (left axis).
Looking at the link you posted, OP also posted with some explanations of the charts, this is a quote taken from one of their posts:

user/Fjordbit: The first curve should have met at 25%, but it looks more like 29%.
user/whitslack (OP):How do you figure? Before block 209,999, there were 10,499,950 BTC in existence. Then block 209,999 added 50 more, bringing the total up to 10,500,000 BTC. That was an increase of 0.000476193%. To calculate the annualized inflation rate, you take the natural log of 1.00000476193, multiply by the number of blocks in a year (52,595.9856), and exponentiate the product, base e, which yields 1.28461321188. So the annualized inflation rate at block 209,999 was 28.46%.


addrindex patch bitcoin core. it does not show unconfirmed tx

I am not a dev, so I can't tell for sure, but it appears addresses are indexed as they enter the blockchain.

  I'm sure that unconfirmed txes are showed normally before.

How do you know? I mean, maybe you used this on a server where the state was different, and compared against a server which hadn't received the block by that time?

EDIT: see this https://www.bountysource.com/issues/6995691-jmcorgan-address-index-not-updated-immediately-upon-tx-broadcast


Alternative uses of a blockchain-mechanism?

Provably fair games can utilize it. For example, Satoshi dice published the hash of their daily secretkey hash list in the blockchain. In that way, they can prove that they haven't altered they secret key list. Or you could do a simple "guess a number" game that kept an encrypted copy of the result in the blockchain. Later reveal the secret key and

Essentially any kind of system that relies on the escrow of a small amount of information could use the blockchain for that escrow. You could even use it to as a communication channel if your messages were small enough.


Where can I find research on wallet fingerprinting?

Is this the research article you are thinking about? It's blockchain.com wallet fingerprinting mostly on the basis of feerates by 0xB10C.


Month into crypto and have some questions

Private key: Your wallet stores the private key. With the private key, you can don transactions. Never give someone your private key or this person has controll over your coins. And: There are no bitcoins in your wallet. They are all saved as transactions in the decentalized blockchain!!

If you let your coins on the exchange, it means automaticly that you trust the exchange. If there is a security issue and all coin on the exchange are stolen, it's your problem. If you send them to an adress generated by the public key (also stored in your wallet), you only need to trust yourself.
If there is a hardfork (Bitcoin-Cash-hardfork for example) and the coins are on the exchange, you don't have access until the exchange allows you to trade the BCH.
So you should think wheather it's maybe usefull to store the BTC in your wallet instead of your exchange. But you could also wait a few months until the transaction fees are maybe lower.

The best way to protect your keys is letting them in your wallet and (of course) don't publish your private key.


Offline wallet (Electrum) + Trezor not signing transactions

Well, yes, sortof.  Signing a transaction requires the scriptPubKey from the transactions that funded the source addresses, and if you don't have a copy of the blockchain there's no way to get that information.
I believe Armory handles this by including the necessary information in the data it gives you to take offline, but Trezor apparently does not, and does not considers this use case "redundant."

that's normal. Trezor requires the list of input transactions.  your offline wallet did not have them and tried to fetch them.
we will not fix that. the list of previous tx will no longer be needed with segwit.
Electrum issue

If you wanted to work around this issue, you could modify the Electrum plugin to load the necessary info from, e.g., a text file instead of trying to use the internet.  The place you would need to change is shown in this post (.../plugins/trezor/plugin.py).


Can multiple different addresses in a wallet be linked easily?

Chain analysis companies use many heuristics to link addresses into wallets.
The most popular being:

common input heuristic where all addresses are grouped by the premise of being inputs to the same transaction
change analysis heuristic which looks at the transaction outputs trying to group them by recipient and change address
other methods, like grouping through SPV vulnerabilities, time analysis, pattern analysis

But the easier way of getting the identity of the address is (for the law enforcement) to subpoena the exchange, which will link your identity to any address you used to interact with this exchange. You can't just "convert" bitcoin to Monero without using service like an exchange, or if you are really lucky you may try doing it P2P but this poses another set of risks.
But if you are looking into privacy features, I'd point you to implementations of coinjoin (Samourai, Wasabi, Joinmarket) which may help with breaking said heuristics.

Sources: https://en.bitcoin.it/wiki/Privacy


Should I use a large random value for i in BIP 32 instead of sequential?

Sequential has the advantage of being able to recover without scanning for 2^32 keys.


What to do if my BitCoin Address is only 33 digits?

The wiki page on Bitcoin addresses mentions that addresses van be of length 27-34. So an address of 33 characters long is perfectly usable.


Do wallets save a backup of my private keys and seed?

It depends on what wallet you are using.

Most people prefer to use wallets that do not have knowledge of your private key outside of your machine, such as hardware wallets, electrum, Bitcoin Core. This is for safety, since any provider who has your keys could easily decide to move all your coins to an address that only they control, and rob you blind.

That said, there are some services that offer custodial services, usually in conjunction with exchange services. In fact, every exchange is a custodian keyhold for the deposit addresses they assign you on their platform.

A few years ago, perhaps there was some merit in trusting a reputable custodial service who had the infrastructure to always backup keys. In 2018, BIP32/39/44 can make a backup as simple as writing down a handful of words and keeping it very safely, so maintaining control of your keys is the preferred option.


Import two wallet.dat into Bitcoin-Qt client

There is (yet) no multi wallet support in bitcoin-core.

You can try to stop Bitcoin-Qt, replace your wallet.dat (rename the old one, place the new one) and start Bitcoin-Qt. If your wallet is really old, it will perform a rescan for new transactions and this can take some minutes.

To merge your wallets:

Open Console and enter dumpwallet <filename>
Stop Bitcoin-Qt
Replace wallet.dat with your new wallet file (move the current wallet.dat file to a save place)
Start Bitcoin-Qt
Open Console and enter importwallet <filename>.


Any good reason to prevent duplicated address in send transaction for Pos coin?

This is a limitation on the interface used for send many. The address,amount list is a dictionary internally within Bitcoin Core, and cannot have duplicate keys. As many other projects are forks of Bitcoin Core, the limitation applies to them as well.

You can work around this by constructing a transaction manually or with a library that doesn't not use the RPC interface, nothing at the actual protocol level prevents this.


Does mtGOX allow for buying on one exchange and selling on another through their API?

The Mtgox API can be used to buy or sell on Mtgox. To buy or sell on another exchange you'll need the API of that other exchange.

More information about the Mtgox API can be found at https://en.bitcoin.it/wiki/MtGox/API.


Can I run p2pool with a thin bitcoin client?

No. P2Pool, unlike a normal pool, requires you to verify incoming transactions, and you can't do this without having all of the unspent transactions in the block chain.


Blockchain is a chain of blocks. Every node connected to blockchain have to come to consensus about the state of that blockchain.

If you and I have a different view of blockchain then some transactions that are valid for you might become invalid for me and it just doesn't work. To make this thing work every node in a decentralized network should have the same view of the history of transactions, also known as blockchain.

Now if we allow every node to add a block to blockchain, due to network latency every node will have different view of the blockchain. Thus, we need a way to somehow select nodes that can add a block to blockchain for a particular round. For this, every node has to solve a cryptographic puzzle. Nodes who solve this puzzle can add a block containing proof of the solution to the blockchain.

As you can see, nodes have to put in some effort to solve the puzzle and thus we have to give them some reward. In bitcoin, newly generated bitcoins and transaction fees are given as a reward.

And this process of
1) Competing with every node for solving a puzzle
2) Add a block to blockchain if you found solution before everyone else
is known as discovering a block.


One of the very fist GPU miners was in java using OpenCL.  It was called DiabloMiner and you can find the source here;-

https://github.com/Diablo-D3/DiabloMiner

It hasn't been updated the the past two years but it is still fully functional.


What will be required to increase the "soft" 500KB per-block data limit

The 500kB limit is related to the fee rules. Miners won't include transactions into their blocks unless they have at least some minimum fee. The Satoshi client determines the minimum fee (for miners -- relayers and senders use slightly different rules) like this:

When the block currently being mined is less than 27kB, certain transactions are allowed without any fee.
When the block currently being mined is less than 250kB, the fee is 0.0005 BTC per kB of transaction size.
After 250kB, the fee per kB increases as the block size increases to an asymptote at 500kB. At 500kB and beyond the fee is infinite and no more transactions will be accepted.

To increase the limit, we'd only need a few significantly-sized miners to change their fee policies. DeepBit already doesn't use the Satoshi client's dynamic fee increase after 250kB, though I think they still have a limit at 500kB.


What is the average time for an honest network to find a block when its hash rate is p?

I do not agree with the assumptions.

In the Bitcoin network, the average block time is also a function of the difficulty, approximately:

(P*d)/p = 10 minutes

Where P is the average number of hashes to obtain a new block in 10 minutes (if d=1 and p=1 at base - it wasn't - then P=600), d is the current network difficulty and, p is the current network hash rate per second.


Sending Bitcoin from my wallet to a different bitcoin address

When completing a transaction via bitcoin, you never need the target's private key.  Never give your private key to anyone.  NEVER.  The private key is the only secret you have that protects your bitcoin.  If you give your private key to someone else, they can "spend" your bitcoin.

When sending money to someone, you simply need an "address"; the recipient should provide you with that address.  If you are attempting to send money from one BlockChain.info wallet to another waller on BlockChain.info, you can get the target address by clicking on the "Request" link inside your wallet.

See this BlockChain.info support page for details.


How do BIP8 and BIP9 differ, how are they alike?

Early soft forks each had their own activation method included in the proposal which relied on flagdays or block version signaling. The latter only allowed a single proposal to be considered concurrently as it relied on incrementing the block version.
BIP9 proposed an activation standard which allowed multiple proposals to be considered at the same time. Soft forks that were activated using BIP9 were coordinated by having a supermajority of hash power signal readiness for the upgrade (traditionally 95%). Miners are tasked to assess the network's uptake of the proposal and signal readiness by setting specific bits in the version field of their blocks. The miners readiness signal is measured over the last difficulty period at each retargeting height. For example, the segwit soft fork and the CHECKSEQUENCEVERIFY soft fork that activated BIP68, BIP112, and BIP113 used BIP9-based activation.
BIP8 is a variant and the successor of BIP9. BIP8 uses block heights rather than timestamps to bound the signaling window, and gives the option to either fail or lock-in the upgrade at the end of the signaling window. When lockinontimeout: true is set, nodes running the activation code only accept blocks that signal readiness in the last difficulty period before the timeoutheight. This forces the upgrade to lock-in to the end of the signaling window. In contrast, BIP9 would always fail after the signaling window passed without activation, so BIP9 worked equivalently to BIP8 with lockinontimeout: false.

via BIP8
Per BIP8, a proposal would get activated via the following steps:

The signaling period commences at start_height by switching from DEFINED to STARTED. The start_height would be set at least a month after release of the activation code. Note that the timeout_height must be the end of a difficulty epoch.

At each difficulty retargeting, every node running the activation code independently checks whether the signaling threshold was met in the concluded difficulty period. There are three possible state transactions from STARTED:

If the threshold is not met at timeout_height, the
proposal settles in the final FAILED state at the end of the signaling period.
If the signaling threshold was met, the proposal transitions to the
LOCKED_IN state.
If the proposal forces activation via lockinontimeout: true and
the last difficulty epoch of the signaling period is reached with
the proposal in STARTED state, the proposal transitions to MUST_SIGNAL. This causes upgraded nodes to reject any blocks that don't signal readiness.

The proposal remains in LOCKED_IN
state for one difficulty period and then transitions to the final ACTIVE state. Upgraded nodes now enforce the soft fork rules on the network.


RBF exploits are possible for 0 confirmation transactions.

The risk/reward is tiny so some merchants will accept small transactions and make delivery without waiting for a confirmation first.

99.9% of the people who have both the competence and lack of morality to double spend in this manner would not waste their time on such a low value theft.

All merchants should wait for (at least) 1 confirmation of possible but the risk is too small for many people to care when selling sandwiches. Any merchant selling a yacht should be waiting for multiple confirmations anyway so the RBF exploit should not be relevant for high value transactions.


farmers quest to exchange goods and services

this was a nice initiative. What I imagine is a ring of farmers where each and everyone produce different products and/or provide certain services. For instance, one farmer could sell milk and eggs, another one could be an expert at mending barns, and yet another one could be raising chickens and selling those.

Let's say it is a group of 20 farmers, and they want to use bitcoin for trading goods and services among them.

First of all there should be 1 or 2 super enthusiasts that could be the 'go to man' for the others in the event of issues.

There are several things that needs to be considered:

A. Determine what level of IT-strategy is advisable. Most farmers probably have some kind of IT-equipment already, be it smartphones, personal computers, tablets etc. As for accepting BTC, startionary equipment is fine, but when visiting another farmer, then a smart phone would be great to be able to pay. Of course there are several ways to go about this. Bitcoin.org lists many options in regards to wallets, and most wallets have their dedicated thread on bitcointalk.org, where you can learn about the wallet that you chose to use. Unless you deal with trivial amounts of BTC, there should be some backup strategies, this could include using cold wallets (educate yourself about this), and also regular backups regarding hot wallets. Remember hot wallets can most often be encrypted and protected by a passphrase. Backups are very important. If the farmer loses his smart phone in the dirt container, it's gone, and so is the bitcoins, but if he has a backup, he'll be safe in regards to retaining his bitcoins. There are so many ways to backup the bitcoins, so I cannot elaborate on that here, but it's a crucial part of dealing with bitcoins. A wallet with cash is lost when somebody steals it, or if you lose it on the field, bitcoins are safe as long as you have a backup. The bitcoin enthusiast in the group should research different options carefully and select what's best suited for the group of farmers.

B. Get bitcoins in the hands of the farmers in the first place.
- Solutions: Use localbitcoins or similar and do face to face cash trades. Alternatively, use an online service (exchanger or exchange), and deposit money through any method the site accepts. This might be a good starting point in that regard: https://en.bitcoin.it/wiki/Trade

C. Get tradin'. Farmer Joe buys a dozen eggs from Farmer Jane with 0.n bitcoins. How to determine the price? Some price finding service could be made by the enthusiast, or some existing web services could be used. Bitcoin prices are a bit volatile, so they need to be dynamically uptated by converting from USD to BTC. So when Jane drives over to Joe to get some eggs, he says, yupp, that's 10 dollars in bitcoins, and he enters 10 USD in his tablet, and out comes the number 0.03. He then points at his QR-code, and says: "Yupp, that's my payment address, just scan it Jane, and you could pay me directly". Jane scans the QR-code with her phone, and sends 0.03 BTC to Joe. Joe checks at his computers and sees the payment going in to his wallet, saying '0 unconfirmed'. As he trusts Jane, and knows Jane is not the double-spend type of farmer, he happily raised his thumbs and smiles. "Yupp, all done Jane - have a good one!"

The challenge as I see it is to keep the bitcoins safe for non-technical people. Perhaps some kind of bitcoin community union for the farmers would be the way to go?

As I see it, the transaction part of the project is the easiest part, while keeping the bitcoins safe demands that at least 1 person (preferably more) in the group has the technical knowhow to setup secure solutions. Perhaps even dedicated devices for such payments would be advisable.

The advantages would be that you would become independent of the traditional cash system, at least in the farmers trading ring. In addition, if done properly, no money could be confiscated by police if stopped in a control (I've heard cash confiscations are rampant in the US these days..). There could be no counterfeit money, not that it would be an issue with cash either, I would think. And you would not enrich the bankers with fees and so on. Now that bitcoin has become more widespread, the farmer could sell eggs and milk for bitcoins, and then use the bitcoins to buy linen, pillows, computers, tea - virtually anything, so he didn't really need to use cash for all things any more. And if someone breaks into a farmers house and steals his laptop, he's already got a backup stored encrypted on a server run by the IT-enthusiast in the group, or stored on an USB-drive hidden somewhere in the barn, so until the thief cracks the passphrase to the wallet, the bitcoins are already swiped to other addresses, and thus the thief will gain nothing.

When using a normal bank, all transactions are tied to your person and reported to the relevant entities. Now, the blockchain is public knowledge, but it's rather hard to track a single bitcoin address to a certain person.

All of this might sound quite complicated, and it kind of is as well, but using bitcoin to pay is not that difficult, just scan a QR-code, then input how much you should pay, and done with it - so what might be best would be to seek out some kind of solution that's already ready made for scenarios like this. I don't know if it exists, but look and you shall find.

In summary, you need a solution that hides all the complicated parts, and makes it really easy in a day to day usage.

I wish you the best of luck!


In this answer, I will go through the steps necessary to redeem the second output of the transaction listed above. The answer will be limited to redeeming an output of the particular type present in this transaction (an output which requires providing a new transaction signed with a private key whose corresponding public key hashes to the hash in the script of the output in question), as this answer is already fairly long, even without taking into account other output types.

Short summary: We begin by constructing a new transaction, with a scriptSig containing the scriptPubKey of the output we want to redeem. The scriptPubKey of this transaction will contain a script that pays to a hash of a public key (Bitcoin address). We perform a double-SHA256 hash on this transaction with the four-byte hash code type SIGHASH_ALL appended to the end. We sign this hash with the private key supplied above. The scriptSig of this new transaction is then replaced with a script that first pushes the DER-encoded signature, plus the one-byte hash code type SIGHASH_ALL, to the stack, followed by the DER-encoded private key's corresponding public key.

Step-by-step description:

We start creating a new raw transaction which we hash and sign.

Add four-byte version field: 01000000
One-byte varint specifying the number of inputs: 01
32-byte hash of the transaction from which we want to redeem an output: eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
Four-byte field denoting the output index we want to redeem from the transaction with the above hash (output number 2 = output index 1): 01000000
Now comes the scriptSig. For the purpose of signing the transaction, this is temporarily filled with the scriptPubKey of the output we want to redeem. First we write a one-byte varint which denotes the length of the scriptSig (0x19 = 25 bytes): 19
Then we write the temporary scriptSig which, again, is the scriptPubKey of the output we want to redeem: 76a914010966776006953d5567439e5e39f86a0d273bee88ac
Then we write a four-byte field denoting the sequence. This is currently always set to 0xffffffff: ffffffff
Next comes a one-byte varint containing the number of outputs in our new transaction. We will set this to 1 in this example: 01
We then write an 8-byte field (64 bit integer) containing the amount we want to redeem from the specified output. I will set this to the total amount available in the output minus a fee of 0.001 BTC (0.999 BTC, or 99900000 Satoshis): 605af40500000000
Then we start writing our transaction's output. We start with a one-byte varint denoting the length of the output script (0x19 or 25 bytes): 19
Then the actual output script: 76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
Then we write the four-byte "lock time" field: 00000000
And at last, we write a four-byte "hash code type" (1 in our case): 01000000

We now have the following raw transaction data:

01000000
01
eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
19
76a914010966776006953d5567439e5e39f86a0d273bee88ac
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000
01000000

(signing stage) Now we double-SHA256 hash this entire structure, which yields the hash 9302bda273a887cb40c13e02a50b4071a31fd3aae3ae04021b0b843dd61ad18e
We then create a public/private key pair out of the provided private key. We sign the hash from step 14 with the private key, which yields the following DER-encoded signature (this signature will be different in your case): 30460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7ebd7020cdc06 To this signature we append the one-byte hash code type: 01. The public key is: 0450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6
We construct the final scriptSig by concatenating:

One-byte script OPCODE containing the length of the DER-encoded signature plus 1 (the length of the one-byte hash code type)
The actual DER-encoded signature plus the one-byte hash code type
One-byte script OPCODE containing the length of the public key
The actual public key

We then replace the one-byte, varint length-field from step 5 with the length of the data from step 16. The length is 140 bytes, or 0x8C bytes: 8c
And we replace the temporary scriptSig from Step 6 with the data structure constructed in step 16. This becomes: 4930460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7ebd7020cdc0601410450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6
We finish off by removing the four-byte hash code type we added in step 13, and we end up with the following stream of bytes, which is the final transaction:

01000000
01
eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
8c
4930460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7ebd7020cdc0601410450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000

Python example code:

I have created an example Python script which does all the above. It is intentionally as verbose as possible, and heavily commented, with as few functions as possible, in order to resemble the step-by-step guide above. The number of code lines can easily be reduced to one half, but I choose to post it in this verbose format as I judge that it's the easiest to follow (ie. no 'jumping' backwards and forwards through functions). The script contains 76 non-empty, non-comment lines.
The script depends on bitcointools (for serializing and deserializing transactions, and base58 encoding/decoding) and ecdsa_ssl.py from my fork of joric's brutus repository (for constructing public/private EC key pairs and ECDSA signing). The easiest way to get the script to run is to clone bitcointools into a folder, and put ecdsa_ssl.py from the above URL in the same folder along with this script, and executing the script from there.
You will want to replace the address in the SEND_TO_ADDRESS variable in this script with the address you want the coins sent to, unless you're feeling generous :).

#bitcointools
from deserialize import parse_Transaction, opcodes
from BCDataStream import BCDataStream
from base58 import bc_address_to_hash_160, b58decode, public_key_to_bc_address, hash_160_to_bc_address

import ecdsa_ssl

import Crypto.Hash.SHA256 as sha256
import Crypto.Random

#transaction, from which we want to redeem an output
HEX_TRANSACTION="010000000126c07ece0bce7cda0ccd14d99e205f118cde27e83dd75da7b141fe487b5528fb000000008b48304502202b7e37831273d74c8b5b1956c23e79acd660635a8d1063d413c50b218eb6bc8a022100a10a3a7b5aaa0f07827207daf81f718f51eeac96695cf1ef9f2020f21a0de02f01410452684bce6797a0a50d028e9632be0c2a7e5031b710972c2a3285520fb29fcd4ecfb5fc2bf86a1e7578e4f8a305eeb341d1c6fc0173e5837e2d3c7b178aade078ffffffff02b06c191e010000001976a9143564a74f9ddb4372301c49154605573d7d1a88fe88ac00e1f505000000001976a914010966776006953d5567439e5e39f86a0d273bee88ac00000000"
#output to redeem. must exist in HEX_TRANSACTION
OUTPUT_INDEX=1
#address we want to send the redeemed coins to.
#REPLACE WITH YOUR OWN ADDRESS, unless you're feeling generous
SEND_TO_ADDRESS="1L4xtXCdJNiYnyqE6UsB8KSJvqEuXjz6aK"
#fee we want to pay (in BTC)
TX_FEE=0.001
#constant that defines the number of Satoshis per BTC
COIN=100000000
#constant used to determine which part of the transaction is hashed.
SIGHASH_ALL=1
#private key whose public key hashes to the hash contained in scriptPubKey of output number *OUTPUT_INDEX* in the transaction described in HEX_TRANSACTION
PRIVATE_KEY=0x18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

def dsha256(data):
   return sha256.new(sha256.new(data).digest()).digest()

tx_data=HEX_TRANSACTION.decode('hex_codec')
tx_hash=dsha256(tx_data)

#here we use bitcointools to parse a transaction. this gives easy access to the various fields of the transaction from which we want to redeem an output
stream = BCDataStream()
stream.write(tx_data)
tx_info = parse_Transaction(stream)

if len(tx_info['txOut']) < (OUTPUT_INDEX+1):
   raise RuntimeError, "there are only %d output(s) in the transaction you're trying to redeem from. you want to redeem output index %d" % (len(tx_info['txOut']), OUTPUT_INDEX)

#this dictionary is used to store the values of the various transaction fields
#  this is useful because we need to construct one transaction to hash and sign
#  and another that will be the final transaction
tx_fields = {}

##here we start creating the transaction that we hash and sign
sign_tx = BCDataStream()
##first we write the version number, which is 1
tx_fields['version'] = 1
sign_tx.write_int32(tx_fields['version'])
##then we write the number of transaction inputs, which is one
tx_fields['num_txin'] = 1
sign_tx.write_compact_size(tx_fields['num_txin'])

##then we write the actual transaction data
#'prevout_hash'
tx_fields['prevout_hash'] = tx_hash
sign_tx.write(tx_fields['prevout_hash']) #hash of the the transaction from which we want to redeem an output
#'prevout_n'
tx_fields['output_index'] = OUTPUT_INDEX
sign_tx.write_uint32(tx_fields['output_index']) #which output of the transaction with tx id 'prevout_hash' do we want to redeem?

##next comes the part of the transaction input. here we place the script of the *output* that we want to redeem
tx_fields['scriptSigHash'] = tx_info['txOut'][OUTPUT_INDEX]['scriptPubKey']
#first write the size
sign_tx.write_compact_size(len(tx_fields['scriptSigHash']))
#then the data
sign_tx.write(tx_fields['scriptSigHash'])

#'sequence'
tx_fields['sequence'] = 0xffffffff
sign_tx.write_uint32(tx_fields['sequence'])

##then we write the number of transaction outputs. we'll just use a single output in this example
tx_fields['num_txout'] = 1
sign_tx.write_compact_size(tx_fields['num_txout'])
##then we write the actual transaction output data
#we'll redeem everything from the original output minus TX_FEE
tx_fields['value'] = tx_info['txOut'][OUTPUT_INDEX]['value']-(TX_FEE*COIN)
sign_tx.write_int64(tx_fields['value'])
##this is where our scriptPubKey goes (a script that pays out to an address)
#we want the following script:
#"OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG"
address_hash = bc_address_to_hash_160(SEND_TO_ADDRESS)
#chr(20) is the length of the address_hash (20 bytes or 160 bits)
scriptPubKey = chr(opcodes.OP_DUP) + chr(opcodes.OP_HASH160) + \
   chr(20) + address_hash + chr(opcodes.OP_EQUALVERIFY) + chr(opcodes.OP_CHECKSIG)
#first write the length of this lump of data
tx_fields['scriptPubKey'] = scriptPubKey
sign_tx.write_compact_size(len(tx_fields['scriptPubKey']))
#then the data
sign_tx.write(tx_fields['scriptPubKey'])

#write locktime (0)
tx_fields['locktime'] = 0
sign_tx.write_uint32(tx_fields['locktime'])
#and hash code type (1)
tx_fields['hash_type'] = SIGHASH_ALL
sign_tx.write_int32(tx_fields['hash_type'])

#then we obtain the hash of the signature-less transaction (the hash that we sign using our private key)
hash_scriptless = dsha256(sign_tx.input)

##now we begin with the ECDSA stuff.
## we create a private key from the provided private key data, and sign hash_scriptless with it
## we also check that the private key's corresponding public key can actually redeem the specified output

k = ecdsa_ssl.KEY()
k.generate(('%064x' % PRIVATE_KEY).decode('hex'))

#here we retrieve the public key data generated from the supplied private key
pubkey_data = k.get_pubkey()
#then we create a signature over the hash of the signature-less transaction
sig_data=k.sign(hash_scriptless)
#a one byte "hash type" is appended to the end of the signature (https://en.bitcoin.it/wiki/OP_CHECKSIG)
sig_data = sig_data + chr(SIGHASH_ALL)

#let's check that the provided privat key can actually redeem the output in question
if (bc_address_to_hash_160(public_key_to_bc_address(pubkey_data)) != tx_info['txOut'][OUTPUT_INDEX]['scriptPubKey'][3:-2]):
   bytes = b58decode(SEND_TO_ADDRESS, 25)
   raise RuntimeError, "The supplied private key cannot be used to redeem output index %d\nYou need to supply the private key for address %s" % \
                           (OUTPUT_INDEX, hash_160_to_bc_address(tx_info['txOut'][OUTPUT_INDEX]['scriptPubKey'][3:-2], bytes[0]))

##now we begin creating the final transaction. this is a duplicate of the signature-less transaction,
## with the scriptSig filled out with a script that pushes the signature plus one-byte hash code type, and public key from above, to the stack

final_tx = BCDataStream()
final_tx.write_int32(tx_fields['version'])
final_tx.write_compact_size(tx_fields['num_txin'])
final_tx.write(tx_fields['prevout_hash'])
final_tx.write_uint32(tx_fields['output_index'])

##now we need to write the actual scriptSig.
## this consists of the DER-encoded values r and s from the signature, a one-byte hash code type, and the public key in uncompressed format
## we also need to prepend the length of these two data pieces (encoded as a single byte
## containing the length), before each data piece. this length is a script opcode that tells the
## Bitcoin script interpreter to push the x following bytes onto the stack

scriptSig = chr(len(sig_data)) + sig_data + chr(len(pubkey_data)) + pubkey_data
#first write the length of this data
final_tx.write_compact_size(len(scriptSig))
#then the data
final_tx.write(scriptSig)

##and then we simply write the same data after the scriptSig that is in the signature-less transaction,
#  leaving out the four-byte hash code type (as this is encoded in the single byte following the signature data)

final_tx.write_uint32(tx_fields['sequence'])
final_tx.write_compact_size(tx_fields['num_txout'])
final_tx.write_int64(tx_fields['value'])
final_tx.write_compact_size(len(tx_fields['scriptPubKey']))
final_tx.write(tx_fields['scriptPubKey'])
final_tx.write_uint32(tx_fields['locktime'])

#prints out the final transaction in hex format (can be used as an argument to bitcoind's sendrawtransaction)
print final_tx.input.encode('hex')


What other wallets can import Qt's backup .dat file?

You can use PyWallet, a simple tool for exporting wallet.dat files, to retrieve the private keys for your wallet addresses.

Most wallets nowadays can import private keys, which give direct access to all the funds in your backed up wallet.


In Fiat Interest and Inflation cancel each other and promote borrowing and thats a healthy thing, but bitcoin economy a borrower has to fight against deflation and interest, if interest rate gets lower to zero then lenders will have no incentive in lending

At a basic level, the person providing the loan hopes to receive a small return (interest) for providing the capital, and the person receiving the loan hopes to use that capital to make profits in the short term.

Removing inflation from the equation (eg by providing a BTC loan) does raise the bar for what could be considered a profitable venture for the loan taker, but that does not mean every loan will no longer be profitable. Rather, it just incentivizes individuals to seek out ventures which have a higher chance of turning more profit.

In my opinion, the argument of "nobody will spend a deflationary currency on anything!" is silly. Individuals will still have to spend, they may just have a higher threshold for the question of "what is worth buying? (or investing in?)". Even if your money is deflationary, you'll still have to pay rent, because its better to have a safe place to live than to have a little more money in the future, but nowhere to sleep.

  Further if somehow we make it work, where will the Interest amount come from ?There will be more btc to be repaid then actual btc we have

Interest on a loan will come from profits made by utilizing the loan. This is no different than a loan denominated in dollars: when you pay the loan back, the interest you pay is not 'freshly minted money', it is just money that already existed in the system, but you are now the owner of.

In general: Use-cases for bitcoin are not dependant on how well the system mimics the lending properties of the traditional banking system, in fact bitcoin is likely useful because it has different properties than the traditional system. Bitcoin is a decentralized, permissionless, borderless, immutable and programmable system of value. What exactly the implications of this are is a story that is still unfolding, but it certainly does promise many exciting things. I think one of the most important is that it grants the user financial sovereignty, which is a rare and important thing in our increasingly Orwellian tech world.


Usually this type of conf file works :

server=1
daemon=1
rpcuser=any_username
rpcpassword=any_password

if not then allow ip 127.0.0.1 in bitcoin.conf

rpcusername=your_usename
rpcpassword=your_password
allowip=127.0.0.1
allowport=8332

This may help, you may also try allowing ip 0.0.0.0 if both of the above does not works


I have over 10,000 shares accepted. How can I find out how much bitcoin that is?

The value of a difficulty one share is roughly the block reward divided by the difficulty. Right now, the block reward is 25 and the difficulty is 11,756,551,916. So 10,000 shares (assuming they're difficulty one Bitcoin shares) is worth about 0.000021 BTC.


Why do hard forks need special rules to allow replay protection?

The LegacyCoin network and NewCoin network are not distinctly separate from each other. Unless network magic and ports are changed, LegacyCoin nodes will be able to connect to NewCoin nodes and likely many will be connected to each other. So if you broadcast transaction A->B, on the LegacyCoin network, it will likely reach a NewCoin node which then causes the transaction to also be relayed on the NewCoin network.

Furthermore, even if the networks are distinctly separate, people can operate a node on both the LegacyCoin network and NewCoin network. Without replay protection, someone can take transactions that they are hearing on the LegacyCoin network and broadcast them through his NewCoin node and vice versa.

Lastly, two way replay protection should be mandatory because the process of splitting your coins with UTXO tainting is rather difficult. You need to have decent technical knowledge to do it and you will likely need to have modified software in order to do so. It is not something that ordinary users are likely able to do without some very specific instructions and there is a high probability that they will mess it up and possibly lose coins.


Bitfinex - 25% annual funding fee for margin - Fiat vs crypto - how to minimize cost?

What you fund your account with is irrelevant to this question.

If you take a long position against a USD pair, you'll borrow USD and pay USD interest. If you short a Coin you will borrow that coin and pay its interest.

Eg. Open long position on BTC/USD for $1000, you'll be borrowing $1000 for your position and would have to pay back $1000 + Interest.

If you short BTC/USD for 1 BTC, you'll be borrowing 1 BTC for your position and would have to pay back 1 BTC + Interest.


Using words to back up wallets is a process described in BIP 39.

Basically, the mnemonic is converted into a seed. This seed is then used as the seed to a Heirarchical Deterministic (HD) wallet, as laid out in BIP 32. The seed is used to generate a Master Extended Private Key, from which all other private keys can be generated. The child key generation follows the standard of BIP 44 so it is compatible with other wallets too.

Thus, by backing up your mnemonic words, any time you enter them in a wallet, it can recreate the seed, then the master private key, then all your other keys, so your wallet is back.

References:

http://support.ledgerwallet.com/knowledge_base/topics/how-to-restore-my-backup-without-a-ledger-wallet


Is it possible to reject a bitcoin payment?

The protocol doesn't include a way to reject transactions, for a variety of reasons (the protocol doesn't know which output is real and which is change; blocks can't be changed after being mined; etc) but it is possible to do something similar.

Accept payment, then return it

Pick one of the funding addresses at random, then send the coins back to that address.
Accept payment, then destroy it

Send the coins to an address that doesn't have a private key associated with it, like 1BitcoinEaterAddressDontSendf59kuE.

Implementations

To my knowledge, no client implements an easy way to do either of these things. The best way would be use coin control to select the offending output, then make a transaction that returned/destroyed it.


Libbitcoin How to generate addresses on demand from xpub?

Did you try this section from their documentation?
https://github.com/libbitcoin/libbitcoin-system/wiki/Addresses-and-HD-Wallets
// Load mnemonic sentence into word list
std::string my_sentence = "market parent marriage drive umbrella custom leisure fury recipe steak have enable";
auto my_word_list = split(my_sentence, " ", true);

// Create an optional secret passphrase
std::string my_passphrase = "my secret passphrase";

// Create 512bit seed (without optional secret passphrase)
auto hd_seed = decode_mnemonic(my_word_list);
data_chunk seed_chunk(to_chunk(hd_seed));
hd_private m(seed_chunk, hd_private::mainnet);

// Derivation of master public key M
hd_public M = m.to_public();

// Derive public children of master key M
auto M0 = M.derive_public(0); //Depth 1, Index 0
auto M1 = M.derive_public(1); //Depth 1, Index 1
auto M2 = M.derive_public(2); //Depth 1, Index 2

// Derive further public children
auto M10 = M1.derive_public(0); //Depth 2, Index 0
auto M11 = M1.derive_public(1); //Depth 2, Index 1