Bitcoin recovery possible from some kind of private key?

Recovery using a private key
If your private key looks like a proper Bitcoin private key, you can recover control over your money.
A private key is just a large number. There are several different ways of representing that number.

Representation
Example

Hexadecimal
E9873D79C6D87DC0FB6A5778633389F4453213303DA61F20BD67FC233AA33262

Base58 WIF
5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

Mini private key
SzavMBLoXU6kDrqtUVmffv

(Don't use these values they are just examples)
Note the specific lengths and the specific mixtures of characters. I think WIF normally starts with a "5". Your private key needs to match these characteristics.
Wallet Import Format (WIF) is probably the most useful.
You should be able to choose a wallet and "import" or "sweep" your private key.  Sweeping is considered safer because it works better with normal backups and recovery-phrases of the new wallet.

Instawallet
If you used Instawallet, it seems unlikely that you have a true private key.
See https://en.bitcoin.it/wiki/Instawallet

Instawallet's service learned that its security was compromised and on April 3rd, 2013 closed the service. Those with funds in their Instawallet can file a claim form to get their funds.

This sort of issue is why custodial wallets are inadvisable for long term storage.


Forking Bitcoin how to prevent a 51% majority attack

How do I prevent a 51% majority attack when miners are not in abundance?

If an amount of hashpower larger than your network decides to 51% attack, there isn't much you can do. Ways to mitigate this include:

-Using a hashing algorithm that does not place your miners in direct competition with a larger coin (note: relevant to ASIC mineable coins more than GPU mineable)

-Enticing a group of miners to join your network right off the start

-Create a coin with a unique value proposition, so that others are less likely to attack. A coin that wants to directly compete with btc may be attacked by btc miners, for example.

Remember that an attacker has opportunity costs to consider, if it is more profitable to just keep mining another coin, rather than destroy your network, then you'll have a better chance of bootstrapping your network.

There are likely other ways you can introduce (centralized) 'administrator controls' for your network, but I won't go into any details on those, as such a system would be counter to the ethos of cryptocurrencies in the first place.


Lost mining shares when restarted GUIMiner

Your shares are towards a block, once a block is completed you start on a new block and go back to 0 shares. Depending on your pool, you get paid per block or per share. Don't worry, if you look on your pools website you should be able to find what you made off of the block and how many shares you contributed.

Restarting GUIMiner will not remove your shares, your shares are automatically recorded through your pool.


It looks as though you are not actually attempting to withdraw Bitcoin. Rather, it looks as though you have gambled with dollars, and are being asked how you would like to withdraw your money from the site. In this withdrawl, they are simply offering Bitcoin as one of their payout options.

Bitcoin is not something that can be 'withdrawn' in this regard; it is essentially a commodity that is exchanged between two people. You sell your Bitcoin to someone else who is willing to buy it at the agreed price.

With this 'Method: Bitcoin' you are seeing, you are essentially being asked to private a public key address in which the owner of Joe Fortune would deposit the equivalent market value of Bitcoin into. It's essentially like being asked to provide a bank account number in order for Joe Fortune to deposit funds into.

One Bitcoin is currently worth ~$4,635 USD, so instead of getting a payment of ~$310 USD, you would get a payment of ~0.07 Bitcoin (BTC).

Hope this helps! :)


How is the construction of atomic swaps improved by Schnorr?

To perform an atomic swap, both assets need to be locked up to ensure the eponymous atomic execution of both payments or neither. Traditionally, this uses a complex output script that has two outcomes. On both chains, funds are locked such that either the receiving party signs with their private key while also revealing a preimage, or the original owner can take back the funds themselves after a timeout has passed by signing with their private key. This way, whenever one of the two parties reveals the preimage to take the funds, the other party can immediately take the funds on the other network. The drawbacks of this approach are that the two transactions are easy to link due to featuring the same lock hash, that the script is fairly heavy and that everyone sees what is going on.

Atomic swaps can be improved with Schnorr signatures both regarding their privacy and their blockchain footprint.
Instead of the previously described output script, the funds are locked to a 2-of-2 multisig address with a timeout condition to return the funds. To ensure atomicity, one of the two parties creates transactions on both networks that make use of "adaptor signatures". These transactions are fully valid except that the creating party's signature is damaged by a linear offset. The creating party provides a zero-knowledge proof to the counterparty that they are both damaged by the same value and that they otherwise would be valid. After the counterparty also signs both transactions, either party can fix the damage on one of the signatures to make the transaction valid, revealing to the other party the original offset and thus enabling them to fix the other.

Due to Schnorr's compact multisignature the 2-of-2 multisig address with the timeout fallback looks like a standard 1-of-1 Pay-to-Schnorr-public-key-hash address, and the 2-of-2 transaction spending from it also looks indistinguishable from any other standard transaction. The transactions are not visibly linked, third parties cannot tell which public keys were involved, and since it would be trivial to recreate the damage after having the two valid signatures, it's difficult for either party to prove that this exchange ever took place.

In result, Schnorr allows to perform atomic swaps by creating two standard transactions on each network, whereas previous atomic swap constructions made use of 2-of-2 multisig addresses and HTLC contracts which were much heavier and easily distinguishable.

For this to work, at least one of the two networks has to support Schnorr signatures (preferably both).

H/T Pieter for feedback and for linking me to this more comprehensive writeup by Kanzure: http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/


1 block only allow about 2000 transactions. Does it mean every 10 minutes, bitcoin can allow 2000 transactions?

2-3000 transactions can be included in each block. But that does not mean that only that many transactions can be made every 10 minutes. There can be, and has been, several thousands more transactions made than can fit into the next block. That just means that several thousand transactions won't be confirmed in the next block and will have to wait for blocks that come later.

There are many proposals that are in their activation stages that will increase the Bitcoin's capacity so that much more transactions can be included in each block. However these are all not yet deployed; they either require miner signalling or community consensus (everyone, including miners) to activate, and none of those have happened for any of the proposals yet.

  Especially when there is a ICO going on

ICOs don't use Bitcoin.


Is transaction malleability the only consensus issue that needs fix to allow lightning network?

BIP62 has been scrapped and will never be implemented. Instead a much better solution with many more advantages, Seggregated Wittness, has been developed and is currently being rolled out. Its finished code is in 0.13, but not activated yet on main net, that will happen in 0.13.1.

As far as I know, yes, this is the last thing required to enable LN. From what I've seen LN was actually possible without malleability fix (as proposed in the original LN whitepaper) but it would have been so much more complex and less efficient that it was well worth fixing it in Bitcoin first, which was the plan anyway even before LN was proposed.


What would happen if you tried to follow two Bitcoin blockchains from the same computer?

Bitcoin is programmed to accept the most proof-of-work chain, which is many times also the longest chain. Every new block added to the blockchain references the previous block with its hash. Based on your question, there are a number of cases that I have come up with and how your new 'forked' blockchain will react.

You run the same software that Bitcoin is currently working on: your software will automatically accept blocks from other peers and add it to the genesis block. This will bring you to the current Bitcoin blockchain
You change the genesis block, but use the same DNS seeding: when the peers will send you new blocks, the previous block hash reference in block 1 will not match your new genesis block header hash and hence that block cannot be added. This you have now generated a completely new chain.
You fork the blockchain but change rules at certain point: This is how Bitcoin Cash was created. From a particular block height they increased the block size to more than 1MB, which resulted in the original Bitcoin nodes rejecting the newly generated blocks. So you now have a different chain from a particular height.


Online Store in Cheyenne, Wyoming Accepting Bitcoin for Payment

For absolute clarity, you should consult the appropriate lawyer / tax professional in your jurisdiction.

However, in general, accepting bitcoin for payment should be no different than accepting any other form of payment. Think of it like accepting a foreign currency, and apply the appropriate accounting practices. There are even services out there which allow you to accept payment from customers in bitcoin, but will then pay you out in your local currency.

KYC/AML type stuff usually applies to businesses that are money transmitters, trading one form of currency for another. But as I mentioned above, if you are truly worried, then you shouldn't take the advice of a stranger on the internet, you should hire the appropriate professional to advise you on the matter.


Anything that doesn't encode a form of zero is considered to be true. Here's the code Bitcoin uses:

bool CastToBool(const valtype& vch)
{
    for (int i = 0; i < vch.size(); i++)
    {
        if (vch[i] != 0)
        {
            // Can be negative zero
            if (i == vch.size()-1 && vch[i] == 0x80)
                return false;
            return true;
        }
    }
    return false;
}


How do payment processors like bitpay work?

They generate a private key and an address corresponding to that private key everytime you see BitPay's payment page (even if you don't pay they keep the private key and that private key is generated only for one payment). When they receive payment to that address, they send your money from that address to their main wallet.


Is an Xcode project for the Mac Bitcoin client available?

I don't believe the project itself is distributed, but there is a step-by-step guide to creating an Xcode project for Bitcoin in the answers to "What are the steps in building bitcoind on Mac OS X 10.6?"


Generate public/private key for bitcoin with openssl

Yes, it's randomness is trustworthy, so it's safe.

The only problem I see is that "rm" does not remove all of its traces from the hard drive. The private key may be recovered. The pedantic way to erase such secrets is to use the Gutmann method which overwrites files 35 times.

To derive the address you need to use something like https://bitcoin.stackexchange.com/a/67093


What will happend when a certain node is not connected to full node?

can he get new blocks updates?

no. you can test this case. just run your daemon with the parameters -connect=127.0.0.1 -listen=0 and you would not get new blocks


How can i access my bitcoin core payment if headers cannot sync due to insufficient storage

Have you tried to reduce storage with pruning mode?
https://bitcoin.org/en/full-node#reduce-storage


Who are creating all the alternate cryptocurrencies?

Many people have an interest in cryptocurrencies - some of them are interested enough that they would investigate and work on creating a new cryptocurrency.  Some people are in it for a quick profit, i.e. the scam coins, but others are genuinely interested.  Sometimes it is good to be associated with a currency, but often they prefer to be anonymous (to some extent) and watch and help from the sidelines.

A cryptocurrency is not just a once-off effort.  There is work needed to maintain it, especially when a problem occurs, or a security issue affects it.  It is necessary to update clients, maybe even fix a blockchain.

Another reason for the increase in alternate cryptocurrencies is due to the hardware investment in the coin mining community.  For most miners like myself, it is now almost infeasible to mine BTC unless you have or are prepared to buy into the latest ASIC miners, but even then, the timeframe for making a reasonable profit is very short.  What do we do with this hardware - we use it to mine alternate coins that suit the hardware.  USB ASIC miners for SHA-256 based coins.  GPU mining for Scrypt based coins.  Hence the alternate coins are actually filling a need by the mining community to have something to mine and have the chance to make a profit or get a return on their investment.


Ubuntu update litecoin-qt wallet software

found the instructions:

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

basically just need to run

qmake "USE_UPNP=-"
make

in the main directory to create the litecoin-qt file


Is the Lightning network a proof-of-stake system?

Calling Lightning a Proof-of-Stake system is orthogonal to the concept usually labeled as PoS. Him having done so will just generate loads of confusion.

What we usually describe as PoS is a mechanism to achieve distributed consensus among a network of participants. Staking there is providing updates to the whole network's state, where you earn fees for contributing to the validity and the security of the network.

On the other hand, Lightning Network is a system of bilateral smartcontracts, where you may earn a fee by providing liquidity to other users. Nodes along a payment path don't provide any proof whatsoever, they merely forward a payment. There is no global consensus in Lightning, contracts are created, verified, and executed between two or a small number of participants. Any need to create consensus in the case of disagreement is provided by the proof-of-work of the Bitcoin network.


How long does it take to Sync my Litecoin Core Wallet?

You are downloading the whole LTC Blockchain, hence the reason. I have the same issue taking ages to sync. Once downloaded, it wont take this long.

I guess you can look at other options, such as electrum LTC for your wallet.
Do you have your private key for the LTC to move your wallet around!


Assuming the key is the posted  compressed WIF KwDiBf89QgGbjEmUcXPRwPuKPFnFECvJkvovGNiyjaujMCrQXy98:

Decode the key you have using the encoder used (in this case base-58)
80-00000000000000000006f5d7d806edef2e1110b0b243f9a90c2aaaaaaaaaaaaa-01-098dbf37
Remove the extra bytes (version byte, compressed byte if present, checksum)
00000000000000000006f5d7d806edef2e1110b0b243f9a90c2aaaaaaaaaaaaa
Take the remaining bytes (in this case it must be 32 bytes) and convert it to an integer assuming it is positive and in big-endian (most significant value is stored first).
666666666666666666666666666666666666666666666666666666


Will the energy cost and deflationary nature of Bitcoins doom the currency to obscurity?

On the deflationary death-spiral part:

The bitcoin wiki has a good discussion of deflationary spiral, so that's a good place to get a counter point.

I'd like to make some of my own (amateur) observations:

Gold is currently not the most popular money used in the world not because gold is "bad" money, but because:

a) Laws make it more difficult/expensive to use for day-to-day transactions then nationals currencies (e.g. legal tender laws require capital gains tax to be collected at the time of purchases in gold), and;

b) Banks are incentivised to use fiat through the fractional reserve banking system. Why hold gold for customers when you can hold national currency and generate an order of magnitude more interest by loaning out 10x the deposit amount that is guaranteed by the central bank?

To put it another way, the absence of gold used today for your average transactions is not because citizens fear deflationary death-spirals, but because governments have purposefully made it less beneficial to use gold.
Bitcoin has been around long enough that we can at least get a sense whether falling prices has been a disaster. As far as I can tell that is not the case. All the major bitcoin  merchant services like BitPay, CoinJar and Coinbase record ever increasing purchases/sales made through the website. Yes, more people are using bitcoin, but one person spending money in the bitcoin economy is counter to the death-spiral theory. If the theory is correct, no-one should be spending bitcoins.
The deflationary death-spiral, when you think about it, describes something that in layman terms sounds pretty awesome. Theoretically prices will keep dropping to $0, meaning at some point, everyone on earth will be able to buy everything and any service for 0. Sure, the theory states that e.g. everyone will lose their job, but who cares when everything is free! At that point you don't need a job.
When I've heard the (in)famous cases of deflationary death-spirals mentioned, they seem to always conveniently ignore the broader context. For instance, the Great Depression happened at a time when the government purposefully reduced the money supply, i.e. it wasn't like the money supply was stable or predictable (like gold/bitcoin). In other words, I'm yet to hear of an example of "bad" deflation that "just happened" during a normal period of dropping prices. There's always something else going on in the economy.


Is Bitcoin network an Asynchronous network or a synchronous network?

In my understanding it is an asynchronous network: It works over the Internet. The Internet is the biggest asynchrounous network. An adversary cannot delay the transactions effectively if he doesn't control the majority of the hashing power. Therefore without making the asumption of a malicious adversary with that power, your transaction will eventualy be included in the network: the answer to your las question is no, the protocol is asynchronous and it will reach consensus.


Full list of "special cases" during Bitcoin Script execution (p2sh, p2wsh, etc.)?

As of January 2021, "high-level" script validation with all active consensus rules on the network is approximately this:
Top level evaluation

Execute the scriptSig, and call the resulting stack stack. If execution aborts, fail.
Execute the scriptPubKey with stack as input, and call the resulting stack result. If execution aborts, fail.
If result is empty, or its top element has numerical value 0, fail.
If scriptPubKey is exactly equal to an OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes inclusive:

If scriptSig not empty, fail.
Run segwit validation with the scriptPubKey as program, the n value as version, and witness as input (see further). If this execution aborts, fail.

If scriptPubKey is exactly equal to OP_HASH160 + a 20 byte push + OP_EQUAL, run P2SH validation:

If scriptSig does not consists of only pushes, fail.
If result is empty, fail.
Interpret the top element of result as a script, and execute it, with the rest of result as input. Call the resulting stack p2sh_result. If this execution aborts, fail.
If p2sh_result is empty, or its top element has numerical value 0, fail.
If the top element of result is exactly OP_n (with n between 0 and 16 inclusive) followed by a direct push of 2 through 40 bytes inclusive:

If scriptSig is not exactly a direct push of the top element of result, fail.
Run segwit validation with the scriptPubKey as program, the n value as version, and witness as input (see further). If this execution aborts, fail.

If no failure occurred before this point, the script is valid.

Segwit validation
Segwit validation for version version, with program program, and input input:

If the version is 0:

If the program is not 20 or 32 bytes, fail.
If the program is 20 bytes hash:

Execute the script OP_DUP OP_HASH160 hash OP_EQUALVERIFY OP_CHECKSIG, with initial stack input. If execution aborts, fail.
If the resulting stack is not exactly one element, or that element has numerical value 0, fail.

If the program is 32 bytes hash:

If input is empty, or its top element's SHA256 hash does not equal hash, fail.
Execute the top element of input as script, with the other elements as input. If execution aborts, fail.
If the resulting stack is not exactly one element, or that element has numerical value 0, fail.

If no failure occurred up to this point, return success.

This answer does not include the changes introduced by BIP341 and BIP342, as these are not active on the network. It also does not include various standardness/policy rules.
Source: https://github.com/bitcoin/bitcoin/blob/v0.20.1/src/script/interpreter.cpp, functions VerifyScript, VerifyWitnessProgram, ExecuteWitnessScript.
TL;DR: only the BIP16 P2SH pattern (OP_HASH160 <20 bytes> OP_EQUAL) and the BIP141 segwit pattern (OP_n <2 to 40 bytes>) are actual special cases that trigger additional rules. But the details are more complex.


Why sending bitcoin and one addresss shows (Unspend) and one address shows (Spent)?

The second address your transaction sent to is called a ‘change address’. If you search that term on this site you can learn about what a change address is.

Here is a breakdown of the different status’ blockchain.info reports on their block explorer website:

if it says ‘unconfirmed’, that means transaction is not yet confirmed (not yet included in a block)
if it says ‘unspent’, that means the transaction went through, and the funds are still sitting in that address
If it says ‘spent’, that means the transaction went through, and the recipient has already moved the funds to another new address


How do I sign and send a raw transaction using BitcoinJ?

I'm not an expert in this field by any means (and my error message was different), but I spent last week trying to make Bitcoinj sign a transaction and send in raw form (i.e. without using transport protocol which Bitcoinj provides) and here's what I've learned (the hard way): You can't sign transactions like that. If you call tx.addSignedInput in a loop, you'll corrupt transaction's signature and it's gonna to be invalid. The solution (after brainstorming with my team and trying a few recipes here (this one didn't work), at Bitcoin Stack Exchange) was add all Inputs to the transaction and then sign them manually.

Transaction tx = new Transaction(networkParams);
tx.addOutput(Coin.valueOf(amount), targetAddress);
addInputsToTransaction(sourceAddress, tx, unspents, amount);
signInputsOfTransaction(sourceAddress, tx, key);

tx.verify();
tx.getConfidence().setSource(TransactionConfidence.Source.SELF);
tx.setPurpose(Transaction.Purpose.USER_PAYMENT);
String valueToSend = byteArrayToHexString(tx.bitcoinSerialize());

and the methods:

private void addInputsToTransaction(Address sourceAddress, Transaction tx, @NonNull BalanceResponse.Unspents[] unspents, Long amount) {
    long gatheredAmount = 0L;
    long requiredAmount = amount + TX_FEE;
    for (BalanceResponse.Unspents unspent : unspents) {
        gatheredAmount += unspent.getAmount();
        TransactionOutPoint outPoint = new TransactionOutPoint(networkParams, unspent.getvOut(), Sha256Hash.wrap(unspent.getTxId()));
        TransactionInput transactionInput = new TransactionInput(networkParams, tx, hexStringToByteArray(unspent.getScriptPubKey()),
                outPoint, Coin.valueOf(unspent.getAmount());
        tx.addInput(transactionInput);

        if (gatheredAmount >= requiredAmount) {
            break;
        }
    }
    if (gatheredAmount > requiredAmount) {
        //return change to sender, in real life it should use different address
        tx.addOutput(Coin.valueOf((gatheredAmount - requiredAmount)), sourceAddress);
    }
}

private void signInputsOfTransaction(Address sourceAddress, @NonNull Transaction tx, ECKey key) {
    for (int i = 0; i < tx.getInputs().size(); i++) {
        Script scriptPubKey = ScriptBuilder.createOutputScript(sourceAddress);
        Sha256Hash hash = tx.hashForSignature(i, scriptPubKey, Transaction.SigHash.ALL, true);
        ECKey.ECDSASignature ecdsaSignature = key.sign(hash);
        TransactionSignature txSignature = new TransactionSignature(ecdsaSignature, Transaction.SigHash.ALL, true);

        if (ScriptPattern.isP2PK(scriptPubKey)) {
            tx.getInput(i).setScriptSig(ScriptBuilder.createInputScript(txSignature));
        } else {
            if (!ScriptPattern.isP2PKH(scriptPubKey)) {
                throw new ScriptException(ScriptError.SCRIPT_ERR_UNKNOWN_ERROR, "Unable to sign this scrptPubKey: " + scriptPubKey);
            }
            tx.getInput(i).setScriptSig(ScriptBuilder.createInputScript(txSignature, key));
        }
    }
}

I hope, it will help you.


Dogecoin daemon (dogecoind) returning "Method not found" error

In case anybody has similar problem in the future. It seems that my dogecoind build was somehow incomplete. node-dogecoin was trying to call methods that were not available for some reasons. Building from scratch again solved the problem.

As for the log, it seems that it grows at the beginning but stabilize after a while.


Lightning - Question about force-closures of channels and its impact on recovering funds

Sorry René, it seems you fell into a Bcasher trap here ;) OP phrased his question very vaguely and then proceeded to cry CENSORSHIP when you admitted there might be some truth contained in what he alluded to.

In reality, the case OP is alluding to is a very rare edge case that could ONLY occur, if the following things are ALL true:
1. You don't back up your channel state.
2. You don't give your channel to a watchtower.
3. You lose your channel state.
4. Your channel partner knows this.
5. Your channel partner has an old channel state that is more advantageous to him.
6. Your channel partner is evil.

This particular combination is easy to avoid and doesn't really occur in practice.

In a normal force-close, OF COURSE your funds are automatically returned to you.


What are the chances that Bitcoin changes its proof-concept one day?

Chances of a replacement are very low. In fact, this is actually mentioned in the bitcoin community maintained wiki, which seems quite official.

See the "Prohibited Changes" list, where adding an alternative proof algorithm is listed under the "disputed" category.

  Disputed:
  Adding alternatives to Proof of Work such as Proof of Stake. This could change core bitcoin too much, but with widespread agreement of some sort might be possible.

Note that they talk of adding, not replacing.


How does Bitcoin use its communication protocol and its database model?

is it a great idea to use IPFS for blockchain communication?

Bitcoin nodes form a P2P network, using TCP to communicate bitcoin-specific messages between one another. By using a self-defined protocol, the Bitcoin network's communications can be optimized and made robust against attacks, while not having rely on any external dependencies to do so.

  Since IPFS can transfer large amount of data, then why not sending Blockchain data through it?

As far as I understand it, IPFS is designed to work as a distributed file system. In this regard, it may be a suitable choice for a user looking to download the blockchain during the bootstrapping phase of creating a new Bitcoin node, as an alternative to downloading the same files from the Bitcoin network itself. Similarly, there are copies of the blockchain available on the BitTorrent network.

Note that in most cases, it is safest to download the blockchain from the Bitcoin network itself, to ensure you receive an authentic copy, with no malicious files or code inserted into it.

  Bitcoin uses LevelDB to store data. Does that mean that there is a central server / authority where LevelDB is running the entire chain?

No, there is no central server or authority in the Bitcoin network. Each node builds and maintains its own database, so that it can independently validate the current state of the network.


I sent btc from my wallet to my web site balance, deposit never showed

You will need to contact the site, Alhabay, for support. This is your only way. The bitcoins have been sent and confirmed on the blockchain, and they are in Alhabay's possession right now.

Bitcoin is like cash. It's irreversible. Once you've gave someone cash, they have it and the only way you can get it back is if they give it back to you.


How does lightning network find paths with sufficient liquidity?

Lightning Network nodes have their own P2P network where they send messages to each other containing information about their channels and their states. So a node will receive messages from the other nodes on the network that describe the available channels and their liquidity. So a node can build an internal map of the network's channels and the balances for each node in each channel. With this map, it can then plot a route for each payment.


What is the difference between PSBT support in Coldcard and Trezor?

The Coldcard handles PSBT directly and natively. A PSBT can given to the device by writing it to a microSD card and inserting the card into the device. It will be able to load the PSBT and process it as a transaction. Additionally when communicating with the device over USB, PSBTs can be given directly instead of being packed into another data structure.
However other hardware wallets like the Trezor do not have this capability yet. Instead these must be given transactions over USB and those transactions must be packed into device specific data structures. The HWI software does this translation for users - it takes PSBTs and converts them into the format that each hardware wallet uses.


How is the amount of proof-of-work invested in a chain calculated?

Work is calculated as work = 2^256 / block_target, as stated in the linked answer, which is the minimum hash value that counts as a valid proof-of-work (note this only changes every 2016 blocks). The source code for this is src/chain.cpp L#121. The total chain work is the sum of work for all blocks in the chain, and is calculated here: src/validation.cpp L#3713. So to visualize, the lower the block target, the more work has been done.

Example

Block 0 target: 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Block 1 target:
00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Block 0: work = (2^256) / <block 0 hash> = 4.295 × 10^9
Block 1: work = (2^256) / <block 1 hash> = 4.295 × 10^9

You can see that they have both done the same amount of work. In case of a tie, the following rules apply, see https://bitcoin.stackexchange.com/a/37275/60443

Which one was received first? (This can be different for different clients, which is why the previous rule is applied first.)
Which one has a larger pointer address? (This is largely random, and different for different clients.)


I downloaded an Armory .msi and the checksum failed. What should I do? (Windows)

Looks like a SHA256 hash. Try fciv -sha256 or sha256sum.


I have set blockgeneration time to 15 second but blocks are generated with the speed of 1 block per min(avg)

Changing just the target block generation time does not mean that the average block interval will be that time. The block interval is governed by the Proof of Work target, and there is a limit to what that target can be. If you do not increase that target's limit, then the target will not be able to increase to the point where your blocks are being mined at the rate you want them to be mined at. You need to increase your target limit (it can be found in chainparams.cpp and is called powLimit) so that blocks can be found more quickly.


Any wallet that support cancellation of transaction?

Yes. Most software wallets will have this feature. It's called double spending with a higher fee.

There is not really a thing as "cancelling" a transaction, once it is broadcasted, it is unstoppable, unless you double-spend it. (The first tx will get cancelled)


How do I transfer all funds from one wallet to another?

You can create a transaction having an output value equal to the entire balance of your bitcoin core wallet. The last parameter of sendtoaddress is a boolean signifying whether to include transaction fees or not, which you can set as true. The sendtoaddress API has a mechanism of generating a new address for the change remaining from the value you have given.

Another way would be to manually create the transaction with all the inputs from the addresses which have balance and sending it to the new wallet address. Remember to keep some difference in the input and output of the values which would be treated as transaction fees.

As for the last question, if your question is pertaining to the addresses in your old bitcoin core wallet, then you can use the listaddressgroupings API to get a detailed balance of each of the address your wallet has created.
If the addresses don't belong to a core wallet, then you can simply search for the balance on https://blockchain.info/address/<your_address>


you have in the wallet on the right top the 3 points. click on it. click on "security" (or something like that, on my phone the language is not english). in my case i have several options including "save wallet" and "restore wallet" (or something like that). when you click the restore-option you should be able to choose your backup if the app finds your backup (in my case it finds my test-backup in the downloadfolder on the sd-card for example).


Yes you need to provide the UTXO details when building a transaction in bitcoinjs. One should not have to trust a library to provide blockchain data, the library works like a calculator and processes the data that it is given. It's not unreasonable at all, these details are easy to get from your node or an explorer.


P2PKH - Sharing a wallet address does not reveal my pub key?

Is it technically correct to say that if I share my address with the
  network, nobody has access to my pubkey still?

Yes, if your address is a standard address, then deriving the public key from an address is practically impossible (because it is hashed). But as soon as a transaction is made which spends funds sent to that address, then the public key is in the signature of the spending tx.

A P2PKH transaction contains:

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

So, once a P2PKH UTXO is spent, one can simply look at the script sig for the pubKey.

This is because in order to verify transaction signatures, nodes need the corresponding public key. For this reason, sometimes users will use different addresses for each transaction to help ensure more privacy.


The easiest way is the same as for other topics:
Search for an open source project where you can help. They often have a list of tasks, sometimes a list of jobs to be done in different categories, from translating their website over artwork to C++ programming or whatever they are using.

Another way is to create something that helps you. Maybe you want to check the blockchain size from your smartphone? Write some PHP program which checks the size of the file on your PC. Maybe you start reading about the format of the file and extract more interesting data and finally you created some useful project for others.
I do not know what interests you and what you can do, you need to find for yourself what you want to do.

For the knowledge part: There is documentation about the program, the protocol and BIP-documents for new (and existing) features. The client itself is open source and miners are as well. You will need to read some more technical documents or source code, but as a developer this will probably be not new for you.


green addresses are "generally considered a bad idea and not advisable to implement."?

Green addresses has receivers trusting the owners of the green address to not perform a double spend. However trusting anyone to not double spend in Bitcoin is inadvisable, regardless of whether they are actually trustworthy or are a corporation. Even if you do trust that the owner of a green address will not perform a double spend, double spends can occur by accident due to implementation failures (writing a wallet is hard).

There is also no guarantee that a transaction "from" a green address (note that there really is no such thing as a "from address" in Bitcoin, you don't actually send from addresses) is not guaranteed to confirm, even if no double spend occurs. The transaction may have too low of a fee to be confirmed in a reasonable time, and may even be low enough to be evicted from nodes' mempools if it remains unconfirmed for too long. There may be third parties performing transaction malleation attacks on those transactions resulting in malleated transactions being confirmed instead of the one that you expect.

In general, using green addresses means that you are trusting unconfirmed transactions which are not guaranteed to confirm. Double spends are not the only risks with accepting unconfirmed transactions, there are a variety of other things that could result in an unconfirmed transaction never confirming which the owner of the green address cannot control. As such, it is inadvisable to use green addresses.


Is it legal to start a Litecoin mining pool in the US?

There is nothing illegal in the process of mining litecoins or bitcoins.

As far as cryptocurrnecies concern, you should be worried about "money transmition" and "money laundering". If you do not hold other people's coins you are not breaking any laws.


Is there any bitcoin fork which goal is storing arbitrary information?

Storj is a blockchain based solution for encrypting and storing data. More information can be found about the project at storj.io


I'm not an expert but I'm a good at digging through academic literature, and this is what I found about SHA3 with relevance to FPGAs and ASICS (and in comparison with SHA2).

Note that this paper dates back from 2011, the winner of SHA3 was not yet decided as NIST only released the SHA3 standard in 2015. Take a look at the Keccak result in this paper. The ASIC space, atleast ASICs with the specific purpose of hashing, have evolved a lot the past 6 years and the numbers are probably not up to date.

  These  graphs (and  the  corresponding  tables) have revealed that Keccak is the only candidate that consistently outperforms SHA-2 for all considered FPGA families and two hash function variants (with 256-bit and 512-bit output).

Another paper, which is also pretty old and dates back to 2010 has indications that Keccak (SHA3) is faster than SHA-256.

  Figure 5 illustrates how architecture differences affect the performance results. Some curves, like those of Keccak and Luffa, are very steep. This means that a small increase in area yields a significant performance improvement.

Also, I'm not aware of any ASICs for Ethereum, they are currently being mined using GPU's. As you probably already know: GPU's are magnitudes slower than ASICs thus being in MH/s range is no surprise.


Why is increasing block size in the Bitcoin network considered to decrease security?

Generally speaking, a larger block leads to more computational resources (tx validation, bandwidth, storage, memory) required for each person who wishes to validate newly confirmed transactions.

Higher validation cost lead end-users to rely on/trust
centralised services to "validate" their transactions.
Larger blocks require more time to propagate in the network,
increasing pooling pressures for more centralized mining-pools.

The lower the validation cost, the more we can push validation to the edge (end-user) of the network, the more decentralisation we can achieve. Decentralisation is ultimately the source of security, as it is harder for an external force to attack.


What API would I use to find the circulating supply of Ardor?

Yes, getConstants returns the totalAmount of tokens in each chain - inside the chainProperties field.


How is the random number R for transaction signatures created?

The nonce k is supposed to be an unpredictable number in the range 1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336, inclusive - one for each point on the curve except the point at infinity (note: not the size of the field, which is very slightly larger than the number of points on the curve).
One way of doing that is picking a uniformly random number in that range. This works, but makes your security crucially depend on having a good random number generator. This is a simple problem in theory, but in practice lots of problems do occur. Notable examples are the Playstation 3 codesigning system (which used a fixed constant as nonce), or a bug in Android that in some cases resulted in applications generating the same sequence of "random" numbers.
The most common (and recommended) way today is using RFC 6979. It essentially prescribes not using randomness at all at signing time, but computing the nonce using a (specific) hash function that takes the message and private key as input. Under reasonable assumptions, this is just as unpredictable to attackers (who don't know the private key) as using actual randomness, but avoids the engineering challenges with having access to a good RNG.
One word of warning: unpredictability is a very wide concept, and has lots of pitfalls. There are actual attacks against picking a nonce that is taken from a much smaller range, or against nonces that are picked in some related way. Don't try to be "smart" about it.


What is the fee policy suggested by the mainline bitcoin client?

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

  Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes.

So the rate is 0.1 mBTC for each thousand bytes (rounded up) the transaction is.


Can I see a transaction sent to me if I haven't downloaded the whole blockchain?

You can use blockchain.info to see transactions sent to your address.  Just go to https://blockchain.info/ and enter your address in the search field.


How does the network handle changing IPs?

That's a good question, but nothing really substantial changes.

The node will reconnect to a peer (whose IP address has remained the same) and the node's new IP address is added to the list of available peers. The old IP address remains in the list, but eventually removed when it gets older: the peer list also keeps track of the last time it saw the node.

  it shares its own ip to all of the peers

It doesn't actually, the node you connected to will tell you what your IP address is. (I'm not a 100% sure about this tho)

  what if the list if full of old IPs?

Well, that's why there are 'seed nodes' active on the network. They often use domain names, which get resolved to IP addresses (so they can change). They only exist to distribute peer lists. In Bitcoin Core, you connect to the seed node and disconnect after about a minute. You should have enough IPs in your peer list to remain connected to the network from then on.


Error: Prune mode is incompatible with -txindex

How do i remove this prune mode?

There is documentation which says

To enable block pruning set prune=<N> on the command line or in bitcoin.conf, where N is > the number of MiB to allot for raw block & undo data.
A value of 0 disables pruning. The minimal value above 0 is 550.

Related

How can I run bitcoind in pruning mode?


Which approach is better to interract with Bitcoin node : Rpc call or Library?

I think library like BitcoinJ or python-bitcoin does the same (rpc call in the background)

No, they do not.

BitcoinJ is an implementation of a Bitcoin client. It connects directly to the Bitcoin network and speaks the Bitcoin Peer-to-Peer protocol. It does not call RPCs for a node.

  f that is true is there any reason behind using such libries in place of rpc call

Libraries that do use the RPCs in the background allow you to abstact away the need to understand how the JSON-RPC protocol works. You don't need to have something that can send HTTP requests; you don't need to have something that can compute the basic authorization stuff; you don't need to have a JSON parser. Those libraries abstract those things away so that you can just deal with the RPC commands and the data they return.

There are no performance benefits. The only benefits are that the code is cleaner, easier to read, and easier to write.


The ability to solo mine was removed some time ago. You have to set up a stratum proxy server.


Do payment channels have an address? And where are their transactions actually being written to?

The payment channel between Alice and Bob is encoded as a 2-2 multisig Adress the balance of that Adress is the capacity of the channel.

A channel is opened by sending funds to that multisig Adress via a funding transaction. These funds do exist (on the Bitcoin network) and are by no means virtual.

Alice and Bob each control a key of that Multisig Adress meaning they cannot spend from that address without the help of the other party.

The balance of the channel (not to be confused with the capacity) is encoded by a pair of commitment transactions. One for Alice and one for Bob. This is a spend of the funding transaction. And has at least two outputs. One for Alice encoding the amount of funds she has in the channel and one for Bob encoding his amount of funds in the channel.

Commitment transactions have exchanged signatures and can be published any time and encode the distribution of funds that alice and Bob agreed to.
When Alice sends funds to Bob a new commitment tx is negotiated.

Only problem is to invalidate or revoke the previously signed pair of commitment transactions. This is achieved by creating timelocks one the outputs of the commitment transactions, and allowing that output to be spend without the timelock if a revocation secret is presented. This incentivizes both parties to only broadcast the most recent commitment transaction.

All of this works as a protocol on top of Bitcoin as such it is nothing but a clever (?) way to use Bitcoin.

As for trusting a man in the middle. The trust model relies on the Bitcoin network (as hopefully became clear). As long as we trust the Bitcoin network to be honest operating a payment channel works as expected.


Can I run a bitcoin full node on my laptop and use a external hard drive to store the blockchain?

If you're using USB 2.0, your problem is going to be the read/write speeds.

Minimum requirements state that you need at least a read/write speed of 100 MB/s.

Typical high-speed USB 2.0 connected drives only do about 40-50 MB/s.


It appears to be completely unrelated (hence the close vote I just casted).

  Ven is a digital social currency used to share, buy, sell and trade in
  the world of Hub Culture and beyond. The value of Ven floats against
  other currencies and the price is based on a basket of currencies,
  commodities and carbon futures.

,

  Can I trade my Ven back to national currencies like the Dollar, Euro or Pound?

  No

Apparently it's just a bad-old centralised virtual currency.

Nothing new, nothing special, nothing relevant. And definitely nothing related to Bitcoin.

since I just skimmed over it, I might have got something wrong, but as far as I've read that's unlikely


Bitcoin Core contains a tool to do this properly (filtering out any orphan blocks, putting everything in the correct order — which will work a lot better than just concatenating the block files. It's documented in its own README, here: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize

In short:

Launch Bitcoin with an rpcuser and rpcpassword set in your config file, with the correct location as per https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
Checkout the Bitcoin source from Github and cd to contrib/linearize.
Copy example-linearize.cfg to linearize.cfg and update it with your rpcuser/rpcpassword values, along with the maximum block height you want to output (max_height), and the path to your data directory (input), as well as the path to your desired output file (output_file).
Run ./linearize-hashes.py linearize.cfg > hashlist.txt followed by ./linearize-data.py linearize.cfg.


You need to get a receiving address from the client (or from an e-wallet if you prefer) and copy and paste it into the address field against your account in BTCGuild.

Bear in mind that if you're using the Bitcoin-QT client there is a very long synchronisation process to wait for, though you may be able to get a receiving address before it completes (but you won't see any received bitcoins in your wallet until it's synchronised). Depending on your hardware and bandwidth, synchronisation may take several days to complete.

While there's no receiving address against your BTCGuild account, you'll just be accumulating bitcoins against your BTCGuild balance, so you aren't losing anything in the meantime.

Bear in mind that the "difficulty" level of mining for the network as a whole has risen to a very high level due to the arrival of highly efficient dedicated ASIC bitcoin mining hardware. This means mining on graphics cards is likely no longer profitable (depending on purchase and electricity costs) and CPU mining hasn't been profitable for a long time.


Is it ok just to save wallet.dat from multiple altcoin clients and remove the client?

Yes, just make certain you do not make any more transactions with that wallet or you could lose coins going to a change address (an address that is used to send back extra coins. it is not the address you sent coins from).

also make certain that you remember your password and the most imperative part: shutdown your coin client before you copy the wallet

also id suggest you back up the wallet and then remove the wallet, and finally try to copy the wallet back over, if you see it load up and your coins are there you are golden.

another way would be do dump the privkeys and encrypt a file with just those keys in it.

source: Me, I'm an altcoin pool op


As a Bitcoin Trader, what tools are available to execute trades?

CrypTrader is a website that unifies the exchanges via your API keys, so that you can trade all on one platform.

MyBitAlert lets you set up email alerts when the price reaches a certain level.

CoinReporting lets you enter your trades (or import them automatically) and show your P&L, and can even export trades for your tax declaration.


Can a competing cryptocurrency make Bitcoin obsolete?

If it is a feature for the client that doesn't affect the Bitcoin network (like say, stronger wallet encryption or something like that), it is not a problem.

If the feature is related to the cryptographic security (say, SHA-2 becomes somehow obsolete), then adoption might be problematic. First of all, the developers would have to prepare the change and schedule it in advance (for example, "Starting with block X, we will be using SHA-3"). This would require all the clients, both standard and alternative, to get updated before that time or risk not being able to connect to the network.

Moreover, if the change is related to a vulnerability of a cryptographic algorithm of Bitcoins, then the entire network might get compromised before the update could happen. For example, if securing the old coins would require one to send them to a new address, then in a short period of time before everyone would do it, someone could potentially steal a lot of coins. Luckily, a scenario like this is very unlikely.

All in all, adopting new features into Bitcoin is possible, although time and consideration is required. Bitcoin's value is in its stable nature, so revolutionary changes could only destabilize it.


How can I determine the number of confirmations of a transaction and its fee using the Blockchain.info DATA API?

If a transaction returned from the http://blockchain.info/rawtx/$tx_hash endpoint has a confirmation, it will have a block_height member. You can then calculate roughly its number of confirmations by subtracting that value from the latest height retrieved from the http://blockchain.info/latestblock endpoint.

Code example, in Ruby:

#!/usr/bin/env ruby
require "open-uri"
require "json"
# call this script with `ruby block_height.rb <tx_hash>`
tx = ARGV.shift
puts "Getting info for #{tx}..."
j = JSON.parse open("http://blockchain.info/rawtx/#{tx}").read
if j["block_height"]
  b = JSON.parse open("http://blockchain.info/latestblock").read
  puts "%d confirmations" % (b["height"] - j["block_height"] + 1)
else
  time_since = Time.now.gmtime.to_i - j["time"]
  puts "It's been #{time_since} seconds since the transaction was created."
  puts "It's not been ten minutes yet!" if time_since < 600
  puts "It's due any time now." if time_since >= 600
end

Calculating the transaction fee is best done by summing the inputs and outputs of a transaction, then subtracting the inputs from the outputs. Difference is the transaction fee.


Forks/ alternative coins and paper wallets

No, you can, at any time you want, import those private keys into a Bitcoin Cash or Bitcoin Gold client and move those coins. You control the private keys, so you control those coins so long as the networks that they are on are still functional.


Can i recover exodus with 12 words form blockchain.info?

I would suggest:

Create a new blockchain.info wallet (or better yet, a wallet where you control the private keys)
Send all the BTC from your existing blockchain.info wallet into your new wallet.
Use your recovery phrase to generate any BTG-compatible wallet.  That should allow that wallet to "see" the BTG balance associated with that private key.

It's important to create a new wallet for your existing BTC since the 12 word passphrase is the only secret required to access those funds.  Creating a new wallet creates a new private key, which results in a new 12-word passphrase, thereby protecting your existing BTC (assuming you send it to the new BTC wallet).


Is there a website widget or javascript library that turns any Bitcoin address into a clickable widget?

You can create a QR code for any bitcoin address using Google's QR code maker:

https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=bitcoin:[your-bitcoin-address-here]

Just point to that as the img src and you'll get something that looks like this:

Note this address is used by a lot of tests as the private key is literally "1".


How does Nextcoin convert 256-bit Curve25519 public keys into ~20 arabic numerals?

According to these lines an accountId seems to be...

int(sha256(publicKey(sha256(passphrase)))[7:0], 256)

...which translates to 256^8 accounts or roughly 2 * 10^19, which fits the idea of around 20 arabic numerals.

Given there are only 2^64 unique accountId and the birthday paradox, you can check this collision probability table (the 16 bytes/64 bits row). If each person in the world had a single Nextcoin account, the collision probability is greater than 75%! I'm sure this is the least of their problems.

This looks really amateurish. Really amateurish. Really, REALLY, REALLY amateurish. Stay away from this coin!


It's just for convenience.

Make sure to d̶o̶u̶b̶l̶e̶ triple check and use a pen that's readable in ten years, too.


Checking external bitcoin address balances via JSON-RPC API

Bitcoin Core does not track each individual address, only the addresses associated with your wallet.

There are other clients, such as bitcore-insight and btcd, which maintain a separate address index.

Alternatively, you can implement an index yourself, or run an existing one such as ElectrumX.


How long should confirmation (spendable amount) take?

If you do not see the balance row with 'Spendable' appearing, it is because ALL your bitcoin is spendable. The row is just made invisible in this case.

It's only shown when the total is different (normally when you have incoming bitcoin that hasn't confirmed yet)


Is blockchain protected from history spaming?

Full nodes use checkpointing: they decide a past block (and all the blocks before it) to be definitive. Any block relayed to them that'd have happened before that checkpoint would be ignored. See this article for more details.


CPU mining is no longer supported. See CGMiner FAQ:

Q: What happened to CPU mining?
A: Being increasingly irrelevant for most users, and a maintenance issue, it is
no longer under active development and will not be supported. No binary builds
supporting CPU mining will be released. Virtually all remaining users of CPU
mining are as back ends for illegal botnets. The main reason cgminer is being
inappopriately tagged as a virus by antivirus software is due to the trojans
packaging a CPU mining capable version of it. There is no longer ANY CPU mining
code in cgminer. If you are mining bitcoin with CPU today, you are spending
1000x more in electricity costs than you are earning in bitcoin.


I sent bitcoin from my BitcoinQt wallet while it was unsynced to another wallet, do I have to wait for it to sync?

Yes, you have to wait. Otherwise you would be able to pay things with money you don't have in your wallet.

You could have spent all your bitcoins, but since your wallet is not synced you may be able to spend money you have already spent but has not been synced, thus it is not allowed to do that.


What is the preferred way to denote orders of magnitude in BTC?

I would write 36.2K BTC.

On the other hand, if I had 0.0362 BTC, I would write 36.2 mBTC.


How does bitcore handle transactions in orphan block situation?

If there are multiple chaintips that match in total work, Bitcoin Core will consider the one it heard first about the best chain. Only if another chaintip accumulates more work, it'll switch to that chaintip. As only one block can be part of the best chain at the same height, the competing block is essentially irrelevant unless it happens to become part of the best chaintip.

Example:
After block 99, there were two competing blocks found at the same time. Our full node first hears about block 100A (the asterisk marks the block our full node currently considers the chaintip), and a peer announces chaintip B with a different block at height 100. Bitcoin Core will not update its chaintip, but still consider 100A the best chaintip.

           100A*
98 ← 99 ↢
           100B

It's very unlikely that both 100A and 100B get a successor block at the same time. Let's say that the chaintip B is extended first.

           100A*
98 ← 99 ↢
           100B ← 101B

Upon learning about the new best chain, our full node will first revert block 100A: all of the transactions that got confirmed in block 100A get added back to the mempool and marked unconfirmed.

            100A
98 ← 99* ↢
            100B ← 101B

Then the full node follows the best chain by applying the two blocks 100B and 101B.

           100A
98 ← 99 ↢
           100B ← 101B*

Any transactions that had been confirmed in 100A might have now been associated with 100B or 101B instead, or they may still be in the mempool.


I have a question. Can the price change if your transaction remain unconfirmed for a couple of hrs

In terms of value, the Bitcoin network knows only about satoshis and has no awareness of what other currencies (JPY, AUD, GBP, EUR, USD) peg to against it.
So when you create a bitcoin tx to send value to another party, that's always denominated in satoshis on the network; that doesn't change at all.
As you've observed, the dollar value may change if you paid a low tx fee, or the network was busy for the fee you paid, and therefore by the time it is mined, more dollar value may arrive, or less.
You've got a few options to avoid this - one is to pay a higher fee to reduce the time you're waiting for the tx (make sense on large valuable purchases), or to use the Lightning Network where fees are lower and settlement is near-instant.


What nodes are best for lessening the risk of loss from a race attack

It would be recommended to connect directly to most of the major pools. This way one doesn't need to rely on any other nodes to relay the informations.

However, you should note that the conflicting transaction could already be pre-mined, rendering such precautions useless.


Bitcoin is pseudonymous, not anonymous. Sure public keys and private keys are tied and all transactions are public, but unless you have revealed your real identity and connected it to your public key, people do not know who you actually are when you make a transaction.

Furthermore, you can generate as many public-private key pairs as you want and those are not actually tied to your identity.

So with Bitcoin, what you really have are pseudonyms, the public keys. You can have as many pseudonyms as you want and said pseudonyms are not necessarily tied to each other or tied to your real identity. Thus you are pseudonymous, not anonymous.


Need sample compressed and uncompressed Public / Private key pairs for BigInteger

It's nice to see my work copied verbatim in appendix A "Blockchain: Blueprint for a new Economy" by O'Rielly... but they missed a few details. Someone from there should reach out to me

After generating 16 million keys,  comparing my results with the QT client over RPC, I've come up with the following test keys for compressed public keys:

Default

Test:
Private as hex 79186670301299046436858412936420417076660923359050732094116068951337164773779
Public address 1EE8rpFCSSaBmG19sLdgQLEWuDaiYVFT9J
Message: test123
Signature: IGP5aqo6+oKzUF4/Pq6dfksKxlcy1CehKv6aKA6GUMGOf9Jd62UWRMNwN3KXnOHi0PdBekVBlr23EKa7sGDgTtI=

___ debug data for above ___
Is public key compressed:True
Public key as hex  03A3D70082D23B32B26890EA01F6AF628F8D424DF3B025802D32FC3F2D5EF4D083
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 63F96AAA3AFA82B3505E3F3EAE9D7E4B0AC65732D427A12AFE9A280E8650C18E
Signature S (may need alignment to 32 bits): 7FD25DEB651644C3703772979CE1E2D0F7417A454196BDB710A6BBB060E04ED2
Signature Noncanonical: IGP5aqo6+oKzUF4/Pq6dfksKxlcy1CehKv6aKA6GUMGOAX/SXetlFkTDcDdyl5zh4s+x8Fcr8N9d8tB5Gj0xFpA=
S value noncanonical: 173607507099637907991191162345204054084248845170247593505487421300829521874963
Key recovery value: 1

Canonical formatting of S

Test:   SValueReducedToHalf
Private as hex 104418396969965692461517188368945301704108638856440619106351414329473623554759
Public address 18m1EvVCeFsupQSsdZ3rTPGjL6j9hQpoj5
Message: test123
Signature: H5TIq/7pLqy2M9lUGUa9i1kxML4EmWN+MwiyijquyMhcbTuAiOjffxRz7xayj4qaAig8Y1OZFn/aqWDkM5GXVqQ=

___ debug data for above ___
Is public key compressed:True
Public key as hex  0228E33569266CB496AC2808C68D217B542A1E769CA62F2144BEB4D602BDB28014
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 0094C8ABFEE92EACB633D9541946BD8B593130BE0499637E3308B28A3AAEC8C85C
Signature S (may need alignment to 32 bits): 0092C47F77172080EB8C10E94D707565FC927279931632206116717A593E9EEA9D
Signature Noncanonical: H5TIq/7pLqy2M9lUGUa9i1kxML4EmWN+MwiyijquyMhcksR/dxcggOuMEOlNcHVl/JJyeZMWMiBhFnF6WT6e6p0=
S value noncanonical: 66384857650308705735089161182204613834546990056514581767424835152008945003165
Key recovery value: 0

Canonical formatting of S, R is "short"

Test:   SValueReducedToHalf, RHasZeros_1
Private as hex 26841850108733854068844877092845755783895918659584173218404826715393242032133
Public address 1FRUjbVX9bbctP6y7Z7jmBufdW6KyoSvGw
Message: test123
Signature: HxypbxPc+0rICT/x6AWkGoQjE/rE7UtCLy0eS0uGn4WFGlrLkJxJDgJcIgwGDH6MdIiWL/E+cvPv2dqeHw5zCwA=

___ debug data for above ___
Is public key compressed:True
Public key as hex  03F87C4C73949612279398F2634B3D4D3DDC60EBD1D5A7F52133B9A08625DCFBC1
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 1CA96F13DCFB4AC8093FF1E805A41A842313FAC4ED4B422F2D1E4B4B869F8585
Signature S (may need alignment to 32 bits): 00E5A5346F63B6F1FDA3DDF3F9F381738A3218ACF570D5AC4BE5F7C06DC1C33641
Signature Noncanonical: HxypbxPc+0rICT/x6AWkGoQjE/rE7UtCLy0eS0uGn4WF5aU0b2O28f2j3fP584FzijIYrPVw1axL5ffAbcHDNkE=
S value noncanonical: 103871533985121725711649129661651907020330641311974510999031854527404235241025
Key recovery value: 0

Canonical formatting of S, has 4 zeroes

Test:   SValueReducedToHalf, SLessThan32_4
Private as hex 86520705923672484424543748367654505450021158466896423122495789612346391207140
Public address 1NQvJ2X1KVwuYPQRdeiDbFanLod72UPEjg
Message: test123
Signature: IAD0xd4DofuKthgkVUfH8JJF/zeKeGL9b4gdYCb6PxhVcHd4KiX7lFAN2Kun9wUC21T0Z0bPnrsTlAIHWN03P20=

___ debug data for above ___
Is public key compressed:True
Public key as hex  0357B8B24DF08BEFDBEE910A3D95034FEAC1C54CDC100662FF394EB72BB23FE003
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 00F4C5DE03A1FB8AB618245547C7F09245FF378A7862FD6F881D6026FA3F1855
Signature S (may need alignment to 32 bits): 008F8887D5DA046BAFF227545808FAFD2365BA759FDFA9E5282BD05733F2FF01D4
Signature Noncanonical: IAD0xd4DofuKthgkVUfH8JJF/zeKeGL9b4gdYCb6PxhVj4iH1doEa6/yJ1RYCPr9I2W6dZ/fqeUoK9BXM/L/AdQ=
S value noncanonical: 64921966049402308770510180383138525221043468997005421168542368100274768118228
Key recovery value: 1

R and S had leading zeroes (twos compliment confusion possible)

Test:   RGreaterThan32, SGreaterThan32
Private as hex 49271812223912890183372000738074590620901220493616955749035660411043423358313
Public address 1EAGUmQG2evn1ujibn1meucRt5URGr7TKS
Message: test123
Signature: H1z4EjRWIcxYLu82qXDKVwvX74EGr5Zc8hnkL8NEO9fRAGOALDrFakMTq+gVoF+qf+8jgZSI8Lomvi1sSx8Zy3Y=

___ debug data for above ___
Is public key compressed:True
Public key as hex  02A099AB8D17E11D044A495812D0619A833C03961ED0B090A06C2C81AB2CFB8C4C
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 5CF812345621CC582EEF36A970CA570BD7EF8106AF965CF219E42FC3443BD7D1
Signature S (may need alignment to 32 bits): 63802C3AC56A4313ABE815A05FAA7FEF23819488F0BA26BE2D6C4B1F19CB76
Signature Noncanonical: H1z4EjRWIcxYLu82qXDKVwvX74EGr5Zc8hnkL8NEO9fRAQBjgCw6xWpDE6voFaBfqn6p0l57ODlaYn3/ytfvUAw=
S value noncanonical: 115967891712688622791697912048921273624697397818356039879425919349736894106807
Key recovery value: 0

**Canonical formatting of S,  S has more than 32 zeros, R is "short" **

Test:   SValueReducedToHalf, SGreaterThan32, RHasZeros_1
Private as hex 4777466271014663949802819381765970429152817494201827532502916324303349007402
Public address 1Ea6tSV9wrofLkfqepnbLuwDKSMgUNd8k8
Message: test123
Signature: IKJKgEi+x77OgaW0fr884GZrSh+/0cuP+TpY7EUm00EMXODggkAxLPSGfXSNWEjP5jNcSGJjjsxO1SqnNxMnowA=

___ debug data for above ___
Is public key compressed:True
Public key as hex  03AB63D0D115D9C8C53A60989D1D25EFB5FB508E1F5BEEFD7D2487D12289751E71
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 00A24A8048BEC7BECE81A5B47EBF3CE0666B4A1FBFD1CB8FF93A58EC4526D3410C
Signature S (may need alignment to 32 bits): 00A31F1F7DBFCED30B79828B72A7B73018875294844BB9D3ECEAA7B755BD0E9E41
Signature Noncanonical: IKJKgEi+x77OgaW0fr884GZrSh+/0cuP+TpY7EUm00EMox8ffb/O0wt5gotyp7cwGIdSlIRLudPs6qe3Vb0OnkE=
S value noncanonical: 73781983922410365449727642718035935024524267847686688743716438700218775412289
Key recovery value: 1

**Canonical formatting of S, R and S look like two's compliment **

Test:   SValueReducedToHalf, RGreaterThan32, SGreaterThan32
Private as hex 30773778924833153278326239976267448371250861545391810261071816760957004408309
Public address 13a8JzTy6igoA7QfQyZVsDCpQvXY4eBj9i
Message: test123
Signature: H4jdYEux4k1zQaXby1OXSfdi6I7XgdkngA1F/E1rfcSHANqDQxCb3cAxnVG88p8jxyoJKPZh8y/XdYLwPhgmEMM=

___ debug data for above ___
Is public key compressed:True
Public key as hex  03C70FDC0743E19CCBF923FE5454FD6C63943E65C9BD8C1FE0847E3C365CFF8971
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 0088DD604BB1E24D7341A5DBCB539749F762E88ED781D927800D45FC4D6B7DC487
Signature S (may need alignment to 32 bits): 00FF257CBCEF64223FCE62AE430D60DC3790A5B3F04D5570644A4F6E4EB810307E
Signature Noncanonical: H4jdYEux4k1zQaXby1OXSfdi6I7XgdkngA1F/E1rfcSH/yV8vO9kIj/OYq5DDWDcN5Cls/BNVXBkSk9uTrgQMH4=
S value noncanonical: 115406010640357535068751835107045199953964590515092451110614826883136174960766
Key recovery value: 0

R is short

Test:   RHasZeros_1
Private as hex 61103943668025454604648533394738966390945260249802700793400423519535802730901
Public address 19AnGbm4ZxhcUQ18Ttcpxd5AjQTtk7TfUy
Message: test123
Signature: ICLRZEqnmnOe21ZmOiKKxIpgN3F8gyxkHRYuXVJucXQAYv2FSwhrBU7djsZcDx0hSy5ilsRMBzBBIsuqkxQBEb4=

___ debug data for above ___
Is public key compressed:True
Public key as hex  032275700C1D9D1312266E4A0601DF98906C1458ACE8410FD8B6B6748FE9E65F3F
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 22D1644AA79A739EDB56663A228AC48A6037717C832C641D162E5D526E717400
Signature S (may need alignment to 32 bits): 62FD854B086B054EDD8EC65C0F1D214B2E6296C44C07304122CBAA93140111BE
Signature Noncanonical: ICLRZEqnmnOe21ZmOiKKxIpgN3F8gyxkHRYuXVJucXQAAWL9hUsIawVO3Y7GXA8dIUnpEXOq+0/QfOKeCR/kN1I=
S value noncanonical: 160566680661011880010816576153459883182868735970539852654309056175300236759807
Key recovery value: 1

**Canonical formatting of S, twos' compliment formatting of R, S has 4 zeroes **

Test:   SValueReducedToHalf, RGreaterThan32, SLessThan32_4
Private as hex 73831678241472856909648189538766342154493645679368128703486299335910825024625
Public address 1MduqSPRnVWjYKNw9XyxDrTd4ScDGeB9h7
Message: test123
Signature: IADsZCQ4jSdVXJXFLMVmdvTL9Tj/P/ajJxOfbcsDUkqPANIxZZBd0aY4dqbglYBWzltXfGgVzRb6QSlDTps9bc0=

___ debug data for above ___
Is public key compressed:True
Public key as hex  03EC5FD98EA4AC0B31E9F416CE90C91297AB7DA551E413206DAD423E6EE61233AB
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 00EC6424388D27555C95C52CC56676F4CBF538FF3FF6A327139F6DCB03524A8F
Signature S (may need alignment to 32 bits): 00D23165905DD1A63876A6E0958056CE5B577C6815CD16FA4129434E9B3D6DCD
Signature Noncanonical: IADsZCQ4jSdVXJXFLMVmdvTL9Tj/P/ajJxOfbcsDUkqPAQDSMWWQXdGmOHam4JWAVs0WBllOxRW3NgD7odtrc68=
S value noncanonical: 116163468044648827127288252771819760996859021381472042992761249252296984080142
Key recovery value: 1

Canonical formatting of S, S and R has twos compliment zero appended

Test:   SValueReducedToHalf, RGreaterThan32, SGreaterThan32, RHasZeros_1
Private as hex 39596642972382804109878550299664212933475275372831393917296101877715292328542
Public address 1KTMQ9PR7BTV7wofHW74nekbsDi4GYAEzN
Message: test123
Signature: IC7iMUeYPL9SuwIfs2BDoUO3cuMUVFxegg50A5HkKLeAAHyXhyVmnwgH/EzkCpITKkkn5PTAoZ6ZZv8/4PR6bAA=

___ debug data for above ___
Is public key compressed:True
Public key as hex  02218C61C3BB82864EF5646985C0BD1412C9236016D5ECFE3BB99ABDCCE39523DF
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 2EE23147983CBF52BB021FB36043A143B772E314545C5E820E740391E428B780
Signature S (may need alignment to 32 bits): 00FF836878DA9960F7F803B31BF56DECD47186F7F1EEA701A258D31EABDBBBD541
Signature Noncanonical: IC7iMUeYPL9SuwIfs2BDoUO3cuMUVFxegg50A5HkKLeA/4NoeNqZYPf4A7Mb9W3s1HGG9/HupwGiWNMeq9u71UE=
S value noncanonical: 115571954394053739614724418392364175348093401631755466105511097999314105652545
Key recovery value: 1

Canonical formatting of S, s is short with 4 zeroes, r is short by 1 zero

Test:   SValueReducedToHalf, SGreaterThan32, SLessThan32_4, RHasZeros_1
Private as hex 27286465058545275041328003731375053608759800669744477817022805727071484951337
Public address 1KoZDczy6zyaRgHGVGC7pDYHVfsVo4Zo29
Message: test123
Signature: IADffy/L1F2PVhegdf0t4uFghkMH27nBSgOqK0Ikks+lUP33OvEckmcN1g1qfYRhE713I/KRT3DFJ1pP4xzwuQA=

___ debug data for above ___
Is public key compressed:True
Public key as hex  02444327032C13B19080452CED31222B90FB4F391A9E7FD8E1B01B855A759F2F4A
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 00DF7F2FCBD45D8F5617A075FD2DE2E160864307DBB9C14A03AA2B422492CFA5
Signature S (may need alignment to 32 bits): 00AF0208C50EE36D98F229F295827B9EEAFD37B8F41DF92F7698780EA9B3458841
Signature Noncanonical: IADffy/L1F2PVhegdf0t4uFghkMH27nBSgOqK0Ikks+lrwIIxQ7jbZjyKfKVgnue6v03uPQd+S92mHgOqbNFiEE=
S value noncanonical: 79158342722849373070469141236626058792498908884517253652334720352725196179521
Key recovery value: 1

Canonical formatting of S

Test:   SValueReducedToHalf, RGreaterThan32, RHasZeros_1
Private as hex 108826293911840673209374265929265828788892543057636454753466906283594659795938
Public address 1Ctimb69eWuR7treaygbPcASkoqUwPGPn1
Message: test123
Signature: ILFG8FtncxYlOIC3ts7r3YI86OWT2TMD108MAokN++YjUaUPLxi1hwa+4BYf6zJ/NYIuGWG+sfK7zv8GzvONAAA=

___ debug data for above ___
Is public key compressed:True
Public key as hex  0234F964166A1A393348D7789FB3792E189C5964A0438952DB4889EA07BE819F55
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 00B146F05B677316253880B7B6CEEBDD823CE8E593D93303D74F0C02890DFBE623
Signature S (may need alignment to 32 bits): 00AE5AF0D0E74A78F9411FE9E014CD80C93880C384F096AD7FF0D357BDDCA94141
Signature Noncanonical: ILFG8FtncxYlOIC3ts7r3YI86OWT2TMD108MAokN++Yjrlrw0OdKePlBH+ngFM2AyTiAw4Twlq1/8NNXvdypQUE=
S value noncanonical: 78863113940468318276170609985176761212205417632686831042339146260770630222145
Key recovery value: 1

R has 1 zero, R and S greater than 32 bytes

Test:   RGreaterThan32, SGreaterThan32, RHasZeros_1
Private as hex 35662537539778787177688141198176047348648692780898797308846230271410478493419
Public address 1CiLSHH4CXzgPkmbazysvEX8ykb8vU2feB
Message: test123
Signature: H3UW7wX01OMT7njU/f/PQtD+hCNPoIy0rALf0PEnZQYAAJYuisnyAVkVIC7qpGcSugPKnf8LHdCQLjtt60gczRY=

___ debug data for above ___
Is public key compressed:True
Public key as hex  025125B47BE00D50A535B5C9C09E86102BF182D9FE2F6F0AB4A8AC4335149C1C74
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 7516EF05F4D4E313EE78D4FDFFCF42D0FE84234FA08CB4AC02DFD0F127650600
Signature S (may need alignment to 32 bits): 00962E8AC9F2015915202EEAA46712BA03CA9DFF0B1DD0902E3B6DEB481CCD16
Signature Noncanonical: H3UW7wX01OMT7njU/f/PQtD+hCNPoIy0rALf0PEnZQYAAQCWLorJ8gFZFSAu6qRnEri+eXrlumZwy+4NzHgYUw4=
S value noncanonical: 116057437519104871322947020543239762978159794193905342046496826541933056953943
Key recovery value: 0

S is not changed, R and S are large

Test:   RGreaterThan32, SGreaterThan32, SLessThan32_4
Private as hex 23984934282846201135004307705980641080962872643161302353166056218330425914143
Public address 1BcN5pYGUUChE3dk5CCiQeULESZzFYGHPC
Message: test123
Signature: IOoKQ4fmynIUV5RxzPlgU3TZr6hyyH9wXqjqU1OFagAARsDeWu8rbvlpk8MQrs+ad33BFRl3hTU03UYHtm3Kefs=

___ debug data for above ___
Is public key compressed:True
Public key as hex  02260CA828D9D5A49C6C71B52A7C54CF5FEAF2F8599C07C96FDA238072A162364F
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 00EA0A4387E6CA7214579471CCF9605374D9AFA872C87F705EA8EA5353856A0000
Signature S (may need alignment to 32 bits): 46C0DE5AEF2B6EF96993C310AECF9A777DC1151977853534DD4607B66DCA79FB
Signature Noncanonical: IOoKQ4fmynIUV5RxzPlgU3TZr6hyyH9wXqjqU1OFagAAAUbA3lrvK275aZPDEK7PmnY4b/IAJs3VcJ0YZkM+ALs=
S value noncanonical: 147794757913853985161250377857925980185202154991282544344677638464716884982588
Key recovery value: 1

Rare signature format

Test:   SGreaterThan32, SLessThan32_4
Private as hex 19667464441218362309299491158177437155557792575544103707902999231594717797844
Public address 19cjvNftNKJBMcnuzHkcYrRQarjN7JMzkP
Message: test123
Signature: HwAAXzUsb6h+f1uwtl34AY6mZAhuUtzUhZwA85CjmoPfHs6AsOwzCCC3/1wjDws2JaUD0wesu1CwN9e/sFm/HmM=

___ debug data for above ___
Is public key compressed:True
Public key as hex  0372400B013BF5240116E431C1EADC00B9C2BC8A3DFFB669FB91987519ED0A20D9
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 5F352C6FA87E7F5BB0B65DF8018EA664086E52DCD4859C00F390A39A83DF
Signature S (may need alignment to 32 bits): 1ECE80B0EC330820B7FF5C230F0B3625A503D307ACBB50B037D7BFB059BF1E63
Signature Noncanonical: HwAAXzUsb6h+f1uwtl34AY6mZAhuUtzUhZwA85CjmoPfAR7OgLDsMwggt/9cIw8LNiRfsq/uXAPw6/eqHj0p9V8=
S value noncanonical: 129726333383516230935110821215596586503825072828858936394280121229644796354468
Key recovery value: 0

Very rare signature result

Test:   RGreaterThan32, RHasZeros_1
Private as hex 77359564092138606367423909782286964438584967790833203478204963256314910737690
Public address 1FAzeMcAsH16Vrib9AfRT569442nAxAyWs
Message: test123
Signature: ID/UoYIc6He5C1/UOEhNPj/N4r2OIqP2Zdku0ZtXv4MecyHvpOanKO2Jjy2gO+lMSHL8DJuj/WQhzHg9g3VqAAA=

___ debug data for above ___
Is public key compressed:True
Public key as hex  020070B083903DC8EDE561B2990461DC70938898C19346D7F2FEF866629B3B0CB1
Message Hash: 9C20FD5DCB51A6DBD21CFC172CBFFA7F59DE199ED53D567EC1CAF49A4E6F19BC
Signature R (may need alignment to 32 bits): 3FD4A1821CE877B90B5FD438484D3E3FCDE2BD8E22A3F665D92ED19B57BF831E
Signature S (may need alignment to 32 bits): 7321EFA4E6A728ED898F2DA03BE94C4872FC0C9BA3FD6421CC783D83756A0000
Signature Noncanonical: ID/UoYIc6He5C1/UOEhNPj/N4r2OIqP2Zdku0ZtXv4MeAXMh76TmpyjtiY8toDvpTEctqumCU0YEXYxKnBBFoEE=
S value noncanonical: 167868026740628245794433774394316657246741244361239390199489610006892252250433
Key recovery value: 1


Online Mining Calculators using prebuilt machines data

The problem is that the difficulty rating is going up, and going up significantly.  This happens for two reasons.  First, the number of mining rigs increases as people try to get involved with Bitcoin mining.  Second, ASIC-based miners which can run over 60GH/s using around 600W are just arriving in the market and once more generally available will cause a big leap in the difficulty.


How can you restore a password in MultiBit if you are given the wallet words BEFORE you even enter a password?

There is a copy of the password stored encrypted with an AES key derived from the wallet words.

Thus if you forget your password and still have a copy of your wallet you can use your wallet words to recover your password.


I have accidentally sent LTC coin(Using Bitcoin ATM) to my BTC wallet(Luno wallet). I have not received the coins yet

I have not received the coins yet.

You cannot receive LTC through the BTC network.

  how can i recover it back to my luno BTC wallet.

You cannot receive LTC into a BTC wallet. You generally cannot reverse cryptocurrency transactions.

I am not familiar with Luno. If Luno is a multicurrency wallet that supports both BTC and LTC, you may be able to use it to receive your LTC. Hoever it appears to support only BTC and ETH. I suggest you find wallet software that supports LTC.

The general principle is to export your private keys from your BTC wallet and import them into a LTC wallet, then sync the LTC wallet with the LTC blockchain.

I don't know how closely aligned LTC and BTC are, it may be that LTC doesn't support all the address-types supported by BTC - if so there is a chance your LTC are lost - or need more complex assistance to recover.

Remember to never give your private keys to a helper. Never give a helper passwords for or access to a funded wallet.


First off, is this your wallet. I know this is a dumb question but I always have to ask. Also, was this wallet "encrypted"? What version of the wallet did you use and was this wallet based on the same application you are using now.

For example, Bitcoin Wallet Qt, you have to match it with the same product. I've noticed for example if I tried my wallet import doesn't work on other Bitcoin wallet applications, even if I have the password for the encryption correct.

This should really be answered by the developer of said wallet and since I don't know which wallet you're using, I can't help you at the current time in this regard.


Thanks for asking this question. I see a lot of people all the time who assume GPU mining is profitable.

Try googling "bitcoin mining calculator" and see.

Presently (in 2015) the calculator will tell you that you would be able to mine one bitcoin in about 1000 to 10 000 years. But you have to consider that there are reward halvings every four years, which those calculators don't take into account. A more realistic scenario then is that it would take over a million years to mine one bitcoin.

Of course you don't have to mine a whole bitcoin. If you are lucky you could perhaps mine 0.01 BTC in 10 000 years. That's worth a little over three US dollars at the time I write this.

There are still a few people mining on GPU or even CPU. Some of them may have free electricity. But what they fail to understand is how extremely slow this is. Most ditch GPU/CPU mining when they see that you'd be lucky to earn three dollars in 10 000 years. But there are still some (in my mining pool) who refuse to give up.

TL;DR: no, GPU mining is not viable.


Is it Possible to Program AntMiner S9 or Other ASIC Miners?

Yes it is possible. To do so, you will need to modify the firmware and install your own firmware onto the S9. The source code for the firmware is available on Github. The firmware is really a lightweight operating system and includes software such as CGMiner preinstalled. Those preinstalled software are probably what you will need to modify, and those are likely written in C/C++.

Since what you want to modify effects the data that is hashed, it should not effect the hashrate at all.


How can I calculate the possible number of correctly formatted version one minikeys?

Because outputs of SHA-256 can be considered equally distributed for the whole space and this property passes for the first one byte of those outputs, you can calculate this number easily with a really good approximation. One in every 256 in the space you mentioned would be a valid minikey. This approximation would be very good, since the space is, as you noted, really large, so it follows the law of large numbers.

If you needed an exact number, however, your assumption would be correct, though, calculating this number would require to check every possible "candidate" minikey in the space, which would essentially be bruteforcing the whole space and won't be computationally feasible.


There is a multisig option for wallets.  Bitgo has a much more nuanced way to handle multisig.  Better for some environments, but not so good for others.  Try creating a multisig wallet in Copay and seeing if it will work for you.  You can do it across a few devices to make sure you see how it works


Everything but the last Comand looks correct. There is no command channel in c-lightning. In order to open a channel you need to execute

cli/lightning-cli fundchannel id satoshi [feerate] [announce] [minconf]
  Fund channel with {id} using {satoshi} (or 'all') satoshis, at optional {feerate}. Only use outputs that have {minconf} confirmations.

The thing that beginners sometimes oversee is that before opening a channel with a node you need to peer with it first via the connect command like you did.


Possible duplicate:- Does mining power of different miners add up in mining pools?

Mining is a lottery, not a race.

The fastest miner doesn't always win. In general, if you have X% of the hashrate, you will find X% of the blocks.

This is because not just all pools, but every every, every chip, ... is attempting to solve a different block proposal. Every attempt has an independent chance of winning. There are an infinite number of potentially valid blocks, but they're still only a tiny fraction of all possible blocks. Everyone is not trying to find the next block - they're trying to find a next block.

So:

Can I add up my hashpower and make it work like a single processor of 1000H/s

Yes. You can't distinguish the different processors - more hashpower just tries more block proposals at the same time.

Both both miners would be acting independently?

Yes. Everything always acts independently.

So this means a mining pool has combined power of all the associated miners and working on one block?

Yes.

All miner are working on different block of their own ??

Yes.


I have been in the same boat since last 2 weeks. Made a BTC clone out of a very old source code found online.

I have been a bit successful as well.

All the below assumes that you are running Ubuntu.

After compiling I was able to run it using the ./xyzcoind

I did find out that you would need at least two nodes to test. I read this somewhere and also validated this. Can not start mining till there are two servers talking to each other.

I have done this by setting up two small servers on Azure. One connects to the other.

./xyzcoind -connect=a.b.c.d

To test if it is running well or not you may goto .xyzcoin in your home folder and check debug.log

To set up the dns seed node, the parameter can be directly specified in chainparam.cpp if you are using bitcoin source in line that reads as "

  vSeeds.push_back(CDNSSeedData("someaddress.com or IP addy",
  "someaddress.com"));

And then you need to add all the seed node IP address to the A records where ever you have your domain name from. You might need to do it on your own if you have a privater server or can use cpanel depending on the scenario at your end. I did it via cpanel as I have domains hosted with siteground.

some more details on below link

  What is a DNS seed node vs a Seed Node?


What was the market cap of Bitcoin before and after the Bitcoin Cash fork?

On 31 July 2017 Bitcoin had 51.48% of total market cap.

On 1 August 2017 Bitcoin had 43.04% of total market cap where as Bitcoin Cash had 10.77% of total market cap.

For more information about market cap https://coinmarketcap.com/charts/


Why is last channel's expiry different in Lightning Network Routes?

After some searching through the BOLT documents and talking with the lnd slack community, I found an answer:

  B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
  neither charge itself a fee nor add its own cltv_expiry_delta, so it
  would use C's requested min_final_cltv_expiry of 9. Presumably it
  would also add a shadow route to give an extra CLTV of 42.
  Additionally, it could add extra CLTV deltas at other hops, as these
  values represent a minimum, but chooses not to do so here, for the
  sake of simplicity:

Also, although cltv_expiry_delta is default to 9 in BOLT, in lnd they use 144, but without checking for the final hop. That is, they do not add the final_cltv_expiry because they have already a big cltv_expiry (I presume). Olaoluwa said in the slack
that they plan to reduce the value of cltv_expiry_delta to get closer to the default value listed in BOLT. However, if they do this, I hope they take care of adding the additional cltv_expiry_delta, as it will be important to add in this case. For an example of what I mean, check the above-linked link for BOLT #007


Strange re-connection problem with python-bitcoinrpc

Both the RPC client and the RPC server have timeouts, if no request or response has been received for X seconds, they will close the connection. By default the timeout is 30 seconds. I believe you are running into the timeout since you wait a while before trying to send another command. By that point, one end has timed out and thus the connection is closed resulting in Broken pipe errors.


Is it possible to identify what online wallet service a Bitcoin address belongs to?

No, generally this is not possible.  Every Bitcoin address is randomly generated and carries nothing identifying the party that created it.

In principle it might be possible to infer something based on other addresses that sent coins to or from the address in question, if you know something about them through other means.


The CVarInt format is implemented in serialize.h

As the comment is extensive, I'll just quote it here:

  Variable-length integers: bytes are a MSB base-128 encoding of the number. The high bit in each byte signifies whether another digit follows. To make  sure the encoding is one-to-one, one is subtracted from all but the last digit. Thus, the byte sequence a[] with length len, where all but the last byte has bit 128 set, encodes the number:

  (a[len-1] & 0x7F) + sum(i=1..len-1, 128^i*((a[len-i-1] & 0x7F)+1))

  Properties:

  Very small (0-127: 1 byte, 128-16511: 2 bytes, 16512-2113663: 3 bytes)
  Every integer has exactly one encoding
  Encoding does not depend on size of original integer type
  No redundancy: every (infinite) byte sequence corresponds to a list of encoded integers.

  Examples:

  0: [0x00]
  1: [0x01]
  127: [0x7F]
  128: [0x80 0x00]
  255: [0x80 0x7F]
  256: [0x81 0x00]
  16383: [0xFE 0x7F]
  16384: [0xFF 0x00]
  16511: [0xFF 0x7F]
  65535: [0x82 0xFE 0x7F]
  2^32: [0x8E 0xFE 0xFE 0xFF 0x00]

To store CAmount values (integers representing numbers of satoshis), a transformation is applied beforehand that turns more common numbers (multiples of powers of 10) into smaller numbers first:

If the amount is 0, output 0.
Otherwise, divide the amount (in base units) by the largest power of 10 possible; call the exponent e (e is max 9)
If e<9, the last digit of the resulting number cannot be 0; store it as d, and drop it (divide by 10), calling the result n. Then, output 1 + 10*(9*n + d - 1) + e
If e==9, we only know the resulting number is not zero, so output 1 + 10*(n - 1) + 9


Is data that hashed as txid includes witness?

No, the txid is the hash of just [nVersion][txins][txouts][nLockTime] which is the same as a serialized non-witness transaction. That means the signature is not included in the transaction hash, removing the potential for TXID malleability due to mauling the signature. Only WTXID contains the witness, marker and flag as you wrote in your post.

  And will txid be presented in block, e.g. be counted when building Merkle tree?

Yes, the transaction ID is used in the same way that non-segwit TXIDs are used when building the merkle tree.


How should I handle cases like this where the documentation for Bitcoin Core states one thing, and the actual program does something else?

In the example RPC results, it will show whether the result is a JSON array by including brackets [] or it will show if it is a JSON object (associative array) by using curly brackets {}. If the result does not come with any JSON encoding and is a single string or other data type, then you will not see that in the example.

You can see an example of a result that comes in the form of a JSON array by using listlockunspent:

Result:
[
  {
    "txid" : "transactionid",     (string) The transaction id locked
    "vout" : n                      (numeric) The vout value
  }
  ,...
]

An example of a JSON object using createwallet:

Result:
{
  "name" :    <wallet_name>,        (string) The wallet name if created successfully. If the wallet was created using a full path, the wallet_name will be the full path.
  "warning" : <warning>,            (string) Warning message if wallet was not loaded cleanly.
}

An example of a return value that is not JSON encoded using getbalance:

Result:
amount              (numeric) The total amount in BTC received for this wallet.

I believe you may be mistaken with the assumption that sendtoaddress return a JSON object. The code clearly shows that the result is not JSON encoded:

return tx->GetHash().GetHex();

That is a transaction object, which retrieves the transaction hash (256 bit opaque blob), which is then converted to a string using the GetHex() method.

The code would use UniValue if it were to encode JSON. For example in the code of createwallet:

UniValue obj(UniValue::VOBJ);
obj.pushKV("name", wallet->GetName());
obj.pushKV("warning", warning);

return obj;


Maximum number of transactions in wallet.dat for Bitcoin Core

Large wallets take significantly longer to initialize and eventually bog down the client to the point of making it completely unusable (calls that attempt to sort usable outputs to spend for example get slower). Bitcoin Core's wallet really isn't designed for commercial scale use, but many people have found it usable with half gigabyte wallets (hundreds of thousands of addresses and transactions) or more in this sort of setting.

Once you get beyond the scaling of Bitcoin Core the only other realistic option is moving into a completely custom wallet system, though this has significant risk and cost involved.


How are transactions in discarded forks merged back into the blockchain?

The client will import all the lost transactions into its pool of transactions it's trying to commit. Miners will include those transactions into blocks mined for the new chain, if they're not already in it.

Since a miner won't keep a conflicting transaction in memory anyway, it's not possible for the client to cause a conflict by accepting the transactions in the blocks that are undone. Miners should immediately accept all transactions that meet its transaction fee policy and fit as many of them as they can, in priority/dependency order, into blocks they mine.

Of course, coinbase transactions (the payment for mining a block) are forever lost. This is the primary reason that many more confirmations are typically required before coins from these transactions can be spent.


Why is it bad to download the full chain from a third party with Bitcoin Core?

No, the chainstate is the nodes view of correctness. It would take many hours or days to re-verify the whole chain on most hardware, so an assumption is made that the state stored at the previous shutdown is most likely correct. There's some sanity checking of the previous couple of blocks to make sure there is no gross accidental corruption, but malicious modifications of the chainstate before that time will not be caught.
A maliciously modified chainstate can contain fake outputs that do not exist in the canonical one, meaning you could be duped into accepting a false transaction paying money to you that nobody else would consider valid. If any significant portion of the network was downloading unverified chainstate databases it would be a considerable issue.


Could I theoretically mine a block faster than 10 minutes?

Nope, nothing prevents it.  The actual time from one block to the next is random, and it very often happens to be less than ten minutes, just by chance.

Ten minutes is the target time.  The block difficulty adjusts with the goal of having ten minutes be the average time between blocks.  Of course if the average is ten minutes, then you would expect some blocks to be faster and others slower.


Downloading the pruned blockchain file directly from external source

It introduces too much trust into the download source. It's the same thing as just uploading a datadir. You aren't verifying any of the blockchain history; what you download could be a fork of the blockchain. Having such a download completely defeats the point of running a full node.

Furthermore, with downloading a pruned datadir, you will have to download the chainstate. This isn't even verifiable without downloading the blockchain itself. The uploader could have modified the chainstate to include UTXOs that don't exist, and your node wouldn't know that. You could be forked onto a separate chain or just contain invalid things in the UTXO set.

At least with a full blockchain datadir download, you could ignore the given chainstate and just verify the blocks. But that's equivalent to the old bootstrap.dat download, and isn't actually faster.


Are there any miners that will always include microtransactions even when no fee is paid?

Yes.  All miners using the default Bitcoin Core settings will include some free transactions in their blocks based on priority.

Let's say you have a microtransaction-sized 5,000 satoshi input (about $0.01 USD presently).  According to Bitcoin Core 0.10.0's estimatepriority RPC, you currently need 59985719 priority to get a zero-fee transaction mined within 25 blocks (~4 hours).  That means you'll only have to wait until your input is about 46 years old:

satoshis * blocks per year * years / tx size > priority
5000     * 52596           * 46    / 200     > 59985719

That's because priority is computed by input amount in satoshis, times the number of blocks since it was received, divided by the number of bytes in the transaction.

I haven't heard of any miners that have free transaction policies that are more generous than the Bitcoin Core defaults.


It is probably downloading the whole blockchain locally. It will take hours to complete.

the command  bitcoin-cli getinfo will display the information you're looking for.

If you want to see all available commands: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list


How to keep transaction generating time down?

You can always send whatever you have in your wallet to another address in the same wallet.
Depending on the size of the transaction you might have to pay a larger fee than normal.


Run Bitcoin and BitcoinCash in same server

The PORT (to receive data) for both of them is 8332 by default. So you must determine the PORT in the config file for one or both of them like this:

For BitcoinCash:

server=1
daemon=1
rpcuser=xxx
rpcpassword=zzz
rpcport=8355
port=6950

For Bitcoin:

server=1
daemon=1
rpcuser=aaaaaa
rpcpassword=bbbb
rpcport=8320
port=5380

Don't forget to allow the ports by firewall and specify different data directories for them.


Is bitcoinica.com planning to reopen after the 11th May 2012 theft?

Zhou tong has stated here that reopening is being considered, with a time frame of several months.

He has also stated that deposits will be refunded; Most recently, he has stated that a claim page has been opened at https://claims.bitcoinica.com/, but at the time of this writing it seems to be unavailable.

Update: I can now access it.