coin seems to have gone to a duplicate address in attempting to answer Bitcoin-qt multiple wallets and transferring between?, and teach myself in the process, I created a new wallet.dat file and saved it to group_wallet.dat after generating an address. I then restored my_wallet.dat to be wallet.dat, and sent an AmericanCoin to that address. almost a full day later, the funds don't show up. the transaction is in the blockchain, but they never made it to the wallet. I've switched wallets back and forth a few times since then; the one from which I sent the money is fine, and shows the -1.0 transaction.

jcomeau@aspire:~/.americancoin$ americancoind getaddressesbyaccount ''
[
    "AzpvNNAUFYjW79uCS1Q9ALNSVhABqrUC1U",
    "Argr7YW2enzC7TkFp4cJiVDJ1wSYPkh5ox"
]
jcomeau@aspire:~/.americancoin$ americancoind getreceivedbyaddress AzpvNNAUFYjW79uCS1Q9ALNSVhABqrUC1U
0.00000000
jcomeau@aspire:~/.americancoin$ americancoind decoderawtransaction $(americancoind getrawtransaction 9982de4dc77eab126d2ad4837db477577bbeee733ef381c1889576cfbd328473)
{
    "txid" : "9982de4dc77eab126d2ad4837db477577bbeee733ef381c1889576cfbd328473",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "45614d6a67973f9d4728a2724547f3b7e9274218df28599d63f50f112cfa1d8b",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "304602210088aacfccfe71532a5bbfc3145bbff8c1f3470e228b35e879146b30ec4b3526b8022100f566b0aa825ee6786af3619f1e73d89d2b3902468c4a15082af0e15324fc37c201 02047541ccbfea550183dcd9cc21b11af6975339f61c5908f13b8f8d6d2c42fbdb",
                "hex" : "49304602210088aacfccfe71532a5bbfc3145bbff8c1f3470e228b35e879146b30ec4b3526b8022100f566b0aa825ee6786af3619f1e73d89d2b3902468c4a15082af0e15324fc37c2012102047541ccbfea550183dcd9cc21b11af6975339f61c5908f13b8f8d6d2c42fbdb"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 25.74101000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 a1ddfc061b9f000cb647f3cd1c08e6fdeacf72ec OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914a1ddfc061b9f000cb647f3cd1c08e6fdeacf72ec88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "AusMMF3ETMkzvhfTUp61NoWBcCDoHcn9rQ"
                ]
            }
        },
        {
            "value" : 1.00000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 d840edbda2020b44b9fa4ad8ff912e79eb3cc000 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914d840edbda2020b44b9fa4ad8ff912e79eb3cc00088ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "AzpvNNAUFYjW79uCS1Q9ALNSVhABqrUC1U"
                ]
            }
        }
    ]
}

there may be multiple ways to find out what block it's in, but I stumbled upon one yesterday by attempting to resend the raw transaction:

jcomeau@aspire:~/.americancoin$ americancoind sendrawtransaction $(americancoind getrawtransaction 9982de4dc77eab126d2ad4837db477577bbeee733ef381c1889576cfbd328473)
error: {"code":-5,"message":"transaction already in block 29ddf391af012069f02a6e120348d5206548d50f818cad4d5182f28540d842fd"}
jcomeau@aspire:~/.americancoin$ americancoind getblock 29ddf391af012069f02a6e120348d5206548d50f818cad4d5182f28540d842fd | grep confirm
    "confirmations" : 167,

I'm well aware that one needs to get 120 confirmations on a block to get the block reward, but transactions, as I understand, are considered valid after 6. but this has surpassed even the 120. so where is the coin? I'm assuming someone else generated the same address with a different private key. if they instead stole my wallet (by cracking my netbook) it should still show up in the transaction list.

but is that the most likely possibility? there almost has to be something I'm overlooking.

bitcoind (and hence presumably also americancoind) keeps a separate database of "relevant" transactions so that it does not have to search the entire blockchain all the time.  Since you added a new address by copying wallet.dat, the daemon may never have figured out that transactions involving that address are relevant.

Try rebuilding this database with americancoind -rescan.  You can also try americancoind -reindex to rebuild all databases (this may take a long time depending on the size of the blockchain).

It's extremely unlikely that someone else managed to generate a private key with the same address.  If this were at all feasible, the currency would be useless.  Moreover, even if this had happened, what you should see would be your transaction sending one coin to Azpv... and then another transaction created by the attacker, sending the coin to an address controlled by him.


Extract the tag list from blockchain.info Is there any way to download the address-tags list as a file?
This would be very useful for a bitcoin data analysis project.

You can select the text and paste it directly into Calc, Excel or whatever spreadsheet-program you use.
They recognize the tabs as seperators.


How to prevent double spending Bitcoins? If I create a transaction, my node will check my UTXO's and if i have enough BTC to do this transaction it will be mined.

So let's say I want to spend 12 BTC to Anna.

The System will check if i have enough BTC and i do.
But the UTXO list will not be updated until my transaction is mined.

So what will happen if i do another transaction with 15 BTC to anna.

Would the System check the UTXO's again and accept the new transaction?

Or is there something like a second UTXO list with the spended but not mined Transactions?

When a transaction is created by your node and relayed to full nodes, they will check to ensure that the transaction is valid (no double spending is one condition amongst them). Full node maintains a set of UTXO list in the chainstate folder and is aggressively cached in memory. If a transaction is valid, the full nodes will remove the UTXOs that are consumed in the transaction and add the outputs of that transaction to the UTXO set. Then the node will add that transaction to the mempool and relay the transaction to other full nodes connected to it.

Most full nodes/mining nodes operate on first seen basis. That is if they see another transaction spending the same UTXO as to the first one, they will discard it as invalid and will not relay it further (unless it is RBF). So if you send two transactions consuming the same UTXO then it might be the case that half of the nodes will use a different transaction in the mempool as compared to the other half. This issue will be resolved when a block is mined containing one of the two transactions. The miner will only include first transaction that it has seen in the block it mines. When the full nodes receive the mined block, the ones that had seen the other transaction will roll back the changes to the UTXO set and converge on the transaction mined in the block.

If you want to include the other transaction, you will now have to mine two blocks: one at the height that was just received (by removing the mined transaction and including the other) and another block incrementing that height so that nodes accept that version of the chain (since nodes accept the longest PoW chain). That is the reason PoW is very important in resolving conflicts in a decentralized P2P system that does not have a central authority to dictate which transaction is the valid one.


Litecoin - how to calculate the difficulty from 2^-N In the following list I always see difficulty values like 2^-12
How to calculate the actual difficulty from it?

Comparison of mining pools

First of all, actual difficulty is defined as the number d such that the probability of a random hash being valid is 1/(d*2^32). In other words, the hash needs to have at least 32 + log_2(d) zeros in front of it to be valid. (This is not exactly the case if d is not a power of 2, but you get the general idea.)

In that article, a difficulty of 2^-12 means that the probability of a random share being valid is 1/(2^-12 * 2^32) = 2^-20. Note that typically, pool difficulty, is measured in multiples of 2^-16 for reasons discussed in the article, so a difficulty of 2^-12 would be a pool difficulty of 2^4 = 16.


How can you trust Bitcoin nodes? If you send send a transaction request to a node, what is to to ensure that node doesn't simply log your private key and do nothing?

What is to stop the entry node from taking a transaction intended to transfer 1 bitcoin, and transfer 100 instead? Or to stop the node from changing the receiver of the transaction to someone else?

Lastly, what is to stop a node from sending a completely made up blockchain?

Do you just have to choose a trustworthy node?

Bitcoin is meant to be a decentralized network not requiring trust to make/receive transactions. Transactions contain signatures to prove that they haven't been tampered with. Signature is not just the private key, it is something that is derived by the private key and some other parameters. This is called ECDSA, Elliptic Curve Digital Signature Algorithm. If the crypto implementation is proper, it's impossible to extract the private key from signatures.

Changing the blockchain is a different topic. Each block contains "Proof Of Work", which means its hash (a value to check a block's authenticity, but no private key) would change if any part of the block is altered. This'd invalidate the block, and miners would have to re-mine that block (change little things until the hash is lower than a value, the target) But if you create a fake chain with lower targets for blocks, then your chain would have have less Proof Of Work accumulated and other nodes would switch to the chain with the largest PoW once they're aware of it. (But in practice there are checkpoint blocks, so the initial target for remining a chain is high)


Are Bitcoin Block Hashes Predictable to create the block chain, the Bitcoin network runs hashing algorithms for each block, is it mathematically possible to predict the hash value of say, the 100th block from the last block currently in the chain?

Bitcoin uses two rounds of SHA256 on the entire contents of each block (which includes a reference to the previous block) as well as a randomly varied nonce. When the result of those calculations are below a network-determined threshold it is considered to be a valid solution. These solutions are published along with the block as it is distributed to the network so finding the hash of old blocks is trivially easy, you just look them up. Verifying that the math was done correctly and that the result meets the criteria requires only a single iteration of sha256(sha256(block+nonce)) while finding the appropriate nonce the first time takes an absolutely insane number of attempts.

The insane number of attempts is necessarily because the output of sha256 is, effectively, pseudorandom and covers a huge space. The algorithm is deterministic, so sha256(x) will always have the same result, but the result is entirely unpredictable and minor changes in the value of x will dramatically alter the results.

The only way to predict the output of a cryptographically secure hash algorithm like sha256 is a pre-image attack: You would have to pre-generate the contents of all possible blocks, hash them and store the results. At that point solving a block would be as trivial as a database lookup, assuming you could store all 2^256 possible outcomes, which you can't, and that you could generate all 2^256 possible outcomes before the heat death of the universe, which you can't.


Why can't a 51% attack change past blocks on the blockchain? I have read that it is not possible to reverse transactions already added to the blockchain but I do not understand why that is not possible in a 51% attack.
If an attacker was to change the information of a past transaction, the hash of that transaction would change. This would result in a different Merkle root for that specific block. Since the attacker controls 51% of the hash rate, he would have enough computational power to find the new Merkle Root and the nonce this new block in order to produce a valid proof of work. Then the minder could broadcast the proof of work and approve it himself since he controls the majority of the network. In that way he could change the contents of a past block.
My logic above is definitely flawed somehow. Could someone please explain why a 51% attack cannot change past transactions?
Does the digital signature somehow play a role in this? If yes how?

Lets say the block height is currently 700000 and you computed a different version of block 699990 and broadcast it.
The old block 699991 cannot be considered a successor to the new 699990 because it references the hash of the old 699990, so the new 699990 is the top of a new fork of the blockchain.
Each node would consider the two forks, one has a block height of 699990 and the other has a block height of 700000 with ten more blocks worth of work in it, the nodes would choose the fork with 700000 blocks. Note that it isn't the length that matters but the amount of accumulated work.
So you can't just change one block, in this case you'd also have to compute successor blocks with a combined amount of work greater than the existing chain up to 700000. You'd have to do this faster then other miners are adding blocks on top of block 700000. So you'd probably have less than 10 minutes to do something that normally takes the best mining pools around 100 minutes.


How to mine in Ubuntu? How do you mine in Ubuntu 11.04? Are there any GUI miners like poclbm-gui for Ubuntu?

GUIminer can be run on linux, although the process (described in the official thread) is somewhat complicated.  To summarise that post, you will need to:

Get the source code from GitHub:

git clone https://github.com/Kiv/poclbm
Install OpenCL drivers and PyOpenCL.
Install wxPython:

sudo apt-get install python-wxtools
Run guiminer.py:

python guiminer.py

Note that (at least to use the poclbm backend) no compiling is necessary since GUIminer is written in python.  But I can still understand if you find that process a little daunting, since I don't know your level of technological familiarity with these sorts of tasks.


Which bitcoin client distribution to use on a secure pen drive? I have just purchased an Ironkey. Which version of bitcoin client can run without needing installation or download of the blockchain? One which may connect to a server to access blockchain info?

So essentially I can plug it in anywhere and send money direct from the secure drive.

You can run MultiBit on a pen drive in a portable manner if you include Java runtime environments (JREs) for the operating systems you are interested in.  By including a JRE on the pen drive you can be sure it will run on the target computer.  MultiBit runs on Windows, Mac and Linux.

There is some help on how to set up MultiBit on a pen drive here : http://multibit.org/help_runFromUSBDrive.html

You can create a shell script / bat file with the single line: 'local-path-to-jre/java -jar multibit-exe.jar' to start it up using your included JRE.  (Note that Macs are guaranteed to have Java installed so you do not need to supply a JRE for that platform.)

There is a detailed tutorial on how to install a JRE here: http://www.dreamincode.net/forums/topic/42544-putting-java-on-your-flash-drive/

You can store your MultiBit wallets on your pen drive.   By default the path to the wallets is stored in the MultiBit config file multibit.properties as an absolute path (i.e. with a drive letter/ name).   I think you can tweak this to put in a relative path which would then open automatically on any computer.   Alternatively you can just go to the 'Your Wallets' screen and press the 'Open Wallet' button to open it manually.

Strictly speaking MultiBit does keep a local copy of the blockchain but it is the bitcoinj block chain so is less than 20 megabytes.


Confirmed Transaction If a transaction gets a minimum of 3 confirmations, does that mean that the BTCs have reached the destination address? I have a case where the transaction has gone through multiple confirmations but the order status on the payee platform is still showing "unpaid".

if your transaction has 3 confirmations this means that your transaction is in the blockchain. well. many platforms have a "minimum amount of confirmations", for example i often see 7 or 10 transactions as requirement for acceptance of this payment. this has justified technical reasons. you should wait some blocks and then your payment will probably also be accepted.


Are change addresses visible from the GUI in the Bitcoin-QT client? I've seen this question pop up on reddit multiple times, and I don't know the answer.

However, I do know that in my own wallet, several unlabelled addresses have appeared over time without me requesting for them to be created. Are these be the change addresses used when I spend bitcoins, or are the change addresses invisible from the GUI?

Change addresses should be invisible from the wallet GUI.


How can I create a new Genesis Block? I'm trying to create a testcoin using litecoin. To create genesis block I changed some lines to :

block.nTime = 1390948469; // current time

uint256 hashGenesisBlock("0x"); //I dont now it's true or false

uint256 hash = block.GetHash();
        printf("%s\n", hash.ToString().c_str());
        printf("%s\n", hashGenesisBlock.ToString().c_str());
        printf("%s\n", block.hashMerkleRoot.ToString().c_str());
        assert(block.hashMerkleRoot == uint256("0x")); //I dont now it's true or false.
        block.print();
        assert(hash == hashGenesisBlock);

When I build daemon and launch it, I'm getting this error:

litecoind: main.cpp:2788: bool InitBlockIndex(): Assertion `hash == hashGenesisBlock' failed.
Aborted

When I check the ./litecoin debug.log file, I'm seeing the previous hashMerkleRoot and hashGenesisBlock that litecoin uses now. I can't create new hash and merkle root.

Create genesis block. Some people get stuck there, it's really easy:

find LoadBlockIndex() function, inside, change:

paraphrase (pszTimestamp) to any recent news phase.
get the latest unix time (do a google), and put in block.nTime.
set any nNonce (doesn't really matter),
you can change the time/nonce for testnet too, if you want to use it.

After you are done, save it. Now the genesis block will not match the hash check and merkle root check, it doesn't matter.

The first time you run the compiled code (daemon or qt), it will say "assertion failed". Just exit the program, go to
config dir (under AppData/Roaming), open the debug.log, get the hash after "block.GetHash() = ", copy and paste it to the beginnig of main.cpp, hashGenesisBlock. Also get the merkle root in the same log file, paste it to the ... position in the following code, in LoadBlockIndex()

 assert(block.hashMerkleRoot == uint256("0x..."));

recompile the code, and genesis block created!

BTW, don't forget to change "txNew.vout[0].nValue = " to the coin per block you defined, it doesn't matter to leave as 50, just be consistent with your coin per block (do this before adjust the hash and m-root, otherwise they will be changed again).

check https://bitcointalk.org/index.php?topic=225690.0 for complete info


Why miners try to produce big blocks i.e. try to put transaction in a block as many as possible? Why miners try to produce big blocks? What if, does a miner deliberately produce a block with a single transaction (and a coinbase transaction of course) without considering the whole unconfirmed transactions, in order to gain the reduce of network latency advantage or for some other purpose?

Why miners try to produce big blocks?

Because transactions pay fees. The more transactions they include, the more fees can be collected. They prioritize transactions with higher feerate to maximize this.

  What if, does a miner deliberately produce a block with a single transaction without considering the whole unconfirmed transactions, in order to gain the reduce of network latency advantage or some other purpose?

Some do that (though mostly because they just received a new block, and haven't had the time to construct a valid set of transactions on top).

In recent times, the argument for faster propagation also does not apply very much anymore. Techniques like Compact Blocks (BIP152), the Relay Network, and FIBRE can efficiently transmit blocks as long as they mostly consist of transactions that were seen before. This almost entirely removes the effect of size from the equation.


Mining new private alt coin derived from litecoin I have created an new private altcoin from litecoin(build on linux ubuntu) and it is working correctly. Now i want install any miner application (like cgminer) with CPU mining(for test). I have installed cgminer (Older version which support CPU mining) but miner not running and it always showing "No server could found exiting". Also i am confused with following doubts,

Can we mine coins with single node(Its my own private coin and it is installed only my pc)?
cgminer showing scrypt disabled(because its need OpenCL). Is scrypt only work with GPU?

Thanks In Advance,

Mufeed

I'm not the most familiar with altcoins, but...

Yes, I'm pretty sure you can. Because basically you're mining blocks using the info from your node, so I don't see any harm. I've never tested this, because i'm too lazy and I don't see a point in making my own altcoin. So don't quote me on this.
Scrypt doesn't require OpenCL. If i'm not mistaken, OpenCL is mainly used to allow GPUs to mine.


What happens to the transaction using the coinbase transaction output of a block later considered stale? As I understand it, a stale (orphan?) block is determined after it is out competed by its sister block. But I can't help but wonder what would happen to the coinbase transaction's output of the stale block.

Although stale block usually is shorter than 4 blocks. It is certainly possible that some transaction might have used the coinbase of a later staled block. Given scenarios when receiver might not be able to wait for 6 blocks of confirmation, it is possible that some recipient might end up having his transaction output invalidated.

For this kind of case, is there a common practice exist to prevent the loss of the recipient (other than 6 blocks of confirmation)? Or is this scenario considered rare enough to be neglected altogether?

Found the answer on Bitcoin Wiki short after.

  The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

Since practically no fork can survive longer than 10 block. This enforcement could prevent the scenario described in the question to happen in the first place.


Error Code 22 returned from bitcoind sendrawtransaction I've created a raw transaction on testnet:

http://pastebin.com/v8rBmGkx

however I'm getting error: {"code":-22,"message":"TX rejected"}

I've looked in the debug.log and there is no other clues. Can anyone tell me (pls) what's wrong with my tx?

Additionally signrawtransaction returned correct: true. And as far as I can see the fees and output values add up. I'm a little confused to what the problem is?

The problem, is there is no problem. It looks like there was two issues I had, which contributed to the error. So this is a bit of speculation really.

The first was that I had built bitcoind on the Mac (8.9+) and somehow the blockchain got somehow corrupted or something caused an issue. So I fixed this by running bitcoind -reindex

The second possible issue was that mempool had either already had the transaction and couldn't/hadn't resent it.

Either way, there is a (throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX rejected"); // TODO: report validation state in rpcrawtransaction.cpp), when validating the transaction and my c++ is not good enough to help report the validation state.

But if anyone else suggests how I can approach it then I would gladly!


Is CPU mining even worth it? I would like to start mining, but my GPU isn't the greatest and I don't really want to spend the money on a dedicated rig. Is mining from my CPU (in a Linux environment) still worth it? Or will I not be able to keep up?

For the amount of time you would spend setting up a CPU miner, at minimum wage in the US you would be at a loss.

Even GPU mining is barely profitable for most people right now. It would definitely be more profitable to speculate, and even more profitable to operate a Bitcoin business. There are a great deal of people who want to use their Bitcoins for purchases.

At the current exchange of under $10:1BTC, the most efficient graphics cards are taking months to pay off their initial investment (with free electricity).


In ScriptSig, which form of the public key is considered canonical? In the standard pay-to-pubKeyHash scriptSig, which form of the public key should be used. My understanding is that both the compressed (33 bytes) and the expanded (64 bytes) are both valid.

Is there any of these two that is considered "standard"? Will the reference implementation propagate transactions containing either form, or will it withhold one?

IMO, I should use the compressed version since it will result in smaller transactions.

Both are valid and accepted as canonical. They are NOT interchangeable however - the same public key in compressed form is hashed to a different address than that in uncompressed form. You can only use compressed form if the unspent output address is compressed.


How to tell if a transaction is valid? So I have been reading up on bitcoin and blockchain for awhile now, but I have yet to fully understand it. I understand that bitcoin leverage on DLT, which uses cryptography to verify transaction. This is what I have understood so far:

When I make a transaction, this transaction is added to a pool of unconfirmed transactions
This pool of unconfirmed transactions forms a block and miners will solve a mathematical problem as verification
The first miner to solve it will have the block verified and added on to the chain

However, how do they know if my transaction is valid? What if I have 1 BTC but decide to send 2 BTC, how does the solving of mathematical problem verify that I do not have 2 BTC? What if I just purchased 5 BTC from Coinbase using fiat, how will anyone know that I have 5 BTC?

I believe this should not be a very difficult question but I cant seem to understand it fully. Hope someone can point be to the right direction and enlighten me thanks!

When you spend Bitcoin in a transaction, the transaction must reference at least one existing unspent transaction output (UTXO) and provide a valid signature proving that you are authorized to spend it. The transaction then consumes the UTXOs in the inputs, and assigns value to newly created UTXOs in the outputs.
Other network participants running a type of Bitcoin software called "fully validating nodes" have followed along the full history of all Bitcoin transactions (the "blockchain") to maintain a complete set of all UTXOs in existence (the "UTXO set"). You can think of the blockchain as the journal of all transactions, and the UTXO set as the ledger of all Bitcoin balances.
UTXOs are uniquely identifiable by their "outpoint" which is composed of the transaction id that created the output and their position in the transaction's output list: txid:vout.
This means that each full node can look up whether the UTXOs the transaction spends in the inputs exist in their UTXO set. They also check that the transaction is correctly constructed, including whether the transaction fulfills the locking conditions of the UTXOs, whether the signatures are valid, and that the transaction does not create new money by assigning more to the outputs than the inputs brought in.


How do I make multisig transactions using hardware wallets truly trust minimized? I am experimenting with multisig transactions using hardware wallets. Is there some general guidance on what I should and shouldn't do to make the process truly trust minimized?

Ben Kaufman did a tweetstorm on Twitter on the 10 rules for verification on a Bitcoin hardware wallet.

Rule #1: DO NOT TRUST THE COMPUTER SCREEN.
The very reason for using a hardware wallet is that your computer IS
compromised, trusting it makes using the hardware wallet an expensive
security theatre (or 2FA at best). Always verify on the HWW device
screen!
Rule #2: Verify your "receive" addresses BEFORE accepting funds.
A compromised computer can be tricked into displaying addresses that
belong to an attacker. The only way to make sure you own the addresses
is to display them on the HWW device and verify they match.
Rule #3: Verifying change address should be done by the device when sending funds, not before like receive addresses!
It is pointless at best, and misleading at worst, to verify them
beforehand like receive addresses. All hardware wallets support
verifying the change address belongs to you AT TIME OF SIGNING A
TRANSACTION. Verifying before that is pointless and error-prone.
Now let's talk some multisig...
Rule #4: Verify the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
This is not 100% mandatory - but if you're no expert - you really
should do it. If a hardware wallet doesn't support displaying the
xpub, (like Trezor), it could be fine to just verify each address on
it - so long as you verify consistency on all other devices as well,
but I wouldn't recommend such a device for non-experts.
Rule #5: Verify "receive" addresses on EVERY device of the multisig quorum.
This is especially true for at least one address (see next rule) but
recommended for all. If using a device that you haven't verified the
xpub of on-screen, you should verify all receive addresses on it!
Rule #6: While it is best to verify each receive addresses on ALL devices in the multisig setup - you might choose to trust a specific
one, verifying the xpub/ first address on all - then the rely only on
the "trusted" device - ONLY IF YOU ALSO VERIFY XPUBS...
By that, I mean verify on the "trusted" hww used for general
verification, that the xpubs are consistent for all cosigners. This is
needed only once with wallets like ColdCard, Cobo Vault, Bitbox02, and
Specter DIY - since they allow saving the multisig xpubs on the
device.
With Trezor T - you have to verify the xpubs of cosigners every time -
which is why it's not recommended for that purpose - with Trezor One
it's simply not possible...
So while you might use a Trezor in a multisig, I would not recommend
it to non-experts.
Rule #7: Do NOT use Ledger in a multisig setup! (unless you are an expert or have a very good reason...)
Ledger currently does not allow verifying multisig addresses on the
device - nor displaying the XPUB on its screen.
This means you have no way to verify it was not swapped by an attacker
in your multisig setup - EVEN IF YOU DO A SUCCESSFUL TEST TRANSACTION!
It is still possible for a (very) sophisticated attacker to make you
think it worked, while it was him signing for you...
Rule #8: For convenience, you may print out/ write down a large batch of your receiving addresses - verify all at the same time, and
rely on that paper list for your day to day verification. This is very
useful for multisig! - where devices might be distributed in various
places.
Rule #9: Multisig change verification should be the same as with Rule #3 - on the device at the time of signing.
Popular devices (besides Ledger as said), can verify that the address
you send from and the change address used belong to the same multisig
wallet (from same xpubs).
If they fail to verify the change address - they will show it as a
standard, independent, recipient - in that case YOU SHOULD NOT MAKE
THE TRANSACTION. This is valid for both single sig and multisig!
(although even more relevant for the latter).
Rule #10: Hardware wallets cannot verify your balances - and that's great!
Verifying balances requires getting information from the Bitcoin
network - i.e. you need to be online - which would make hww more
vulnerable... This is where a full node comes in!
It is strongly recommended that you run your own Bitcoin full node -
and use it as your main source for verifying your balances and
transaction history! For redundancy, you could double-check against
block explorers or another node (use a different device for either!).
One last thing: These rules apply to any device you use as a
segregated signing device - be it a "traditional" hardware wallet, an
airgapped laptop, a mobile phone etc.
If you want to separate your keys without having a security theatre,
you should verify on your signing device!
Please note: Some things here might not be fully accurate for the
expert user (especially around multisig address verification), but for
the less advanced users' sake, I have tried to be on the safe side
when things get tricky...
Also check out some more info on multisig setups over at
https://btcguide.github.io (Michael Flaxman guide)


How does a miner put his vote for certain BIP? I understand that a miner is the only one who can vote for a certain BIP, but I'm wondering, how do they technically do that? How do they submit their vote? I found out that they  are doing it through the coinbase transaction, but I couldn't find any details on it.
Thanks!

See my answer here to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.
As for the actual mechanism used to signal, a number have been used in the past:
Time based: BIP16, BIP30
Early softforks (up to mid 2012) used a simple time based activation mechanism: node software that implements these proposals enforced the new rules on all blocks with a timestamp after a certain date. In the case of BIP16, this date was determined (and modified) in response to miner signalling, but this signalling was just for human interpretation; nodes took no automatic actions in response to it.
Specifically, the signalling used here was to put a string with a support message in the coinbase transaction's scriptSig field, which is otherwise free for miners to put anything in.
Block-version signalling: BIP34, BIP65, BIP66
A later generation of softforks used the block header's nVersion field for signalling (up to the year 2015). Each of those used a subsequent version numbers (BIP34 used version 2; BIP66 used version 3; BIP65 used version 4).
Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number of higher, block N would be subject to the proposal's rules. Whenever 950 out of blocks number N-1000..N-1 (so 95%) did, the next block would be required to also signal for it - resulting in a final lock-in.
Versionbits-based signalling: BIP68/112/113, BIP141/143/144, BIP91
The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, BIP9. It specifies using one specific bit of the block header's nVersion field for each proposal, and a finite state machine to determine when to signal and when to activate. Its purpose is/was to permit multiple concurrent proposals to activate, without needing to have one completed before the next one can roll out. This was a downside of the previous mechanism, as it would be impossible to activate the proposal with version 4 without also signalling for activation of the proposal with version 3.
Due to various reasons, segwit was not entirely uncontroversial, and eventual activation happened through a meta-proposal, BIP91. BIP91 itself used BIP9 to activate, which then on its turn made signalling for BIP141/143/144 mandatory, resulting in its activation in August 2017.
The future?
There are a variety of mechanisms available these days, and there is active discussion on what to use for the (likely) next softfork, specified in BIP340/341/342 (Taproot). This includes a variant of the BIP9 versionbits mechanism, called BIP8. An article on the various possible schemes can be found here.
Disclaimer: I am a (co-)author of several of the listed documents in this post (BIP9, BIP30, BIP66, BIP141/143/144, BIP340/341/342).


Bitcoin wallet on smart phone drains battery a lot? I downloaded Android Bitcoin Wallet (version 6.17) on my android phone, and realized that the app drains battery a lot. The system showed 40% of battery was used to the wallet.

Does anyone have same issue?
Or is this happen to other different Bitcoin wallets?
Or should I kill the process after I open the app?

If Bitcoin Wallet drains battery a lot compared to other apps like Whatsapp, Facebook that run background, the wallet is not suitable to smart phone...

I never tried the android version but from my experience from the desktop version, when you run the core, the bitcoin core will attempt to connect to another peer, when it received it, it will verify the transaction using your CPU which causes more power draw


Bitcoind under Windows 7; RPC port 8882 not opening Using Win7 64 bit I'm trying to get bitcoind (v0.8.5) to work.

Bitcoin.conf has the following content (in the %appdata%\bitcoin dir):
rpcuser=12345
rpcpassword=12345

I run using command line: bitcoind -rpcpassword=12345

I then use the NIRSOFT app cports-x64 which shows list of open TCP/IP and UDP ports on computer. Bitcoind is in the list but only with port 8883.

Why is the RPC connection not working such that port 8882 (default RPC port) is open and mapped to 127.0.0.1?

You need to be running bitcoind with the -server option set as well as -rpcuser and -rpcpass. These can alternatively be set as lines in your bitcoin.conf. The RPC port will only be open on 8332 if all three of these options are correctly set.


Where can I find a list of business which accept Bitcoin? I'm looking for business which accept Bitcoin, both online and in my community. Where can I find a list of these? Are there any community-maintained places which enumerate businesses which accept Bitcoin?

Black and Yellow Pages and Agorist Marketplace both have people who sell services in bitcoin, though there are some people on those sites who prefer to deal in gold or silver.


Is there any bitcoin fork which goal is storing arbitrary information? I know that there is Namecoin, which saves key:value pair.
Is thete other similar solutions?
Maybe for arbitrary textblocks?

Update: how they do it?
Delaware Blockchain Initiative to Streamline Record-Keeping for Private Companies
http://flip.it/wqxKJ

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


Are there live BitcoinJS Exit Nodes? Where can I find some live (trusted?) BitcoinJS Exit Nodes?

I'm looking it it from the client perspective - I want to write a Java app that doesn't store a blockchain. I don't want to setup an exit node, rather I want to find and use existing ones.

According the to the status message at the bottom of the page: https://github.com/bitcoinjs/node-bitcoin-exit

First permanent deployment is online at https://exit.trucoin.com:3125/


I sent money to a bitcoin wallet from Blizzcoin and there's nothing there? Using blizzcoin.com I sent bitcoins to the address I have for the bitcoin wallet client, and it took forever to sync the blocks. Once it had finished I was expecting to see the money there, but saw nothing.  Can anyone explain or tell me how to resolve this?

According to blockchain.info the coins weren't sent yet.

Here's a post from another blizzcoin customer saying that it took 2 days for his purchased coins to be sent:

  apparently because I Manually transferred money to them instead of ordering through their web interface, it wasn't an instant transfer of bitcoins.

Could that be your problem too?  How long has it been since you sent the money to them?


MultiSig address transaction high fee with no change I was testing MultiSig transaction on testnet with raw transactions. I sent a transaction of 0.0012 from MultiSig 2-2 to a bitcoin address:

  https://live.blockcypher.com/btc-testnet/tx/2aa89b860e677d17af65ac6d0e44aa9fb20dc7698d5b96e348c8bced839834c3/

The transaction consumed remaining in the transaction fee than returning any change which is very high than actual amount transferred.

Should I need to specify the fee for the transaction as well while keeping the same MultiSig 2-2 P2SH address for change.

Fees for multisig addresses (or P2SH in general) work exactly the same way as they do for P2PKH addresses. The fee is simply the difference between the inputs and the outputs.

In  your transaction, you only have one output, so by definition any left over amount is converted to fees. If you want to spend less, you simply need to add in a change output to another address you control, such that total input - total output = fee you want to pay.

There is no difference based on what type of address you use in how fees are calculated. Try setting your wallet/code to send the balance to a change output (I don't know of any wallet that doesn't do this)


Security via Proof - of - Work I am reading Satoshi's original paper, merely for the sake of understanding the concept. I have minimal computer science background (some), mostly just mathematics.

In Section 4. Proof of Work of Satoshi's original paper, he (she? who knows) says 'Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would require redoing all the blocks after it".

I think I understand the big picture in the above selection, but the technical details of what would happen in such situations are unknown to me. Questions:

  Assume a node did go back and redo the proof of work on a previous block (say block n) - with no intention of doing the proof-of-work on any following blocks - would this create a fork coming off of block n or would it sever the current longest blockchain between blocks n and n+1?
  Is the reason that 'the work to change the block would require redoing all the blocks after it' simply because there is no sense in
  changing a block unless the data in the changed block is validated by
  appearing in the longest chain. Since going back and changing block
  n as outlined in question 1 (by my interpretation) creates a fork at block n-1 to honest n and dishonest n, - by redoing the work for all other blocks following dishonest n, the hashes and timestamps coincide, and if this chain theoretically caught up to the current honest chain (which of course probabilistically can't happen), this chain would be the new honest chain by the definition in 5. Network.
  Suppose the unlikely happened, and the scenario of question 2 took place - would the proper analogy to regular currency be a) I gave
  you money in exchange for some good or service b) (presumably) I
  received the good or service c) I stole the money back. My point here
  is, even if the unthinkable happen, it would not be analogous to
  'duplicating' the money I gave you, it would be more like stealing
  it back?

I would prefer answers that mostly answer within the framework of Satoshi's original paper (which may be different than how bitcoin currently operates in the real world), but I am not opposed to hearing related facts about how this is actually implemented.

Also - new to this community: please edit tags or title at will :)

It creates a fork.  There's no way to "sever" an existing branch of the blockchain.  All valid branches remain valid forever, and a node will select whichever one is currently the longest (by total work) as the authoritative ledger.
Right.  If you just redo one block, you've created a branch, but it's not the longest one, so it won't be considered part of the authoritative ledger.
Yes, that's the right analogy.  "Double spending" doesn't duplicate money; rather, it rewrites history so that your payment is considered to have gone to someone else instead (typically back to you).  If someone else thought they had that money, and gave you some goods or services in exchange, then you've effectively stolen it back from them.  You effectively got to spend that money twice, but the blockchain thinks the first one never happened, so the official record only shows one spend.


How can services that use the bitcoin blockchain help secure it? There are many projects being worked on that involve using the bitcoin blockchain for its public verifiability and immutability. A few examples would be Counterparty, Medici, Factom, etc. But each use case for the bitcoin blockchain also adds an incentive to attack it.

For example, say some sort of a stock chain/ledger is secured by the bitcoin blockchain, and the total value of all stocks secured is more than 1 trillion USD. Then, even though the total market cap of the native currency to the ledger is only ~3.5 billion USD, there may be an incentive to reverse/modify the bitcoin blockchain in order to modify the stock market's chain of transactions. Miners do the necessary work to secure these types of services, but their fee does not correlate with the real-world value of the data they are securing.

Obviously, services that use the block chain like this can't be prevented, as it is a completely open peer-to-peer system.

  How can external services that add incentives to attack the network also add incentives for miners to secure it?

Notes:

Merged mining with Namecoin, a decentralized service that uses the bitcoin blockchain for security, adds to the security of the bitcoin blockchain by awarding Namecoins. Centralized services, like a stock exchange, do have an incentive to keep the chain secure, because if the bitcoin block chain is attacked, then very few people will use their service. And they may be able to add to the mining incentive in a way that encourages people to try their service, similar to a marketing fee.

One upside is that just the existence of such services may bring utility to and encourage confidence in bitcoin, raising bitcoin's price and, hence, raising the reward for mining.

I am looking for descriptions of technical solutions for a standard process by which services can do their part to keep the blockchain secure, while maintaining the decentralization of the network.

The Bitcoin network is fairly simple in terms of its core security, so technically there are three things these companies/projects can do to contribute:

Run and/or encourage development of the bitcoind codebase (including code reviews)
Run and/or encourage a higher number of solo miners
Run and/or encourage a higher number of full nodes

Point 3 is especially important and a no-brainer for any project that depends on the blockchain. Running your own full node(s) is a must, so that you don't have to trust a third party node. The tragedy of the commons does not apply to this point.

Each full node adds a layer of security to the network by verifying all transactions and blocks, reducing the chance for foul play, even from "malicious" miners.


How do I run Armory Testnet on Win7 x64 using Bitcoin Core 0.9.3 using remote datadir? Trying to use the testnet which I have no problems with using Bitcoin Core 0.9.3 with command:
Bitcoin-qt.exe -testnet -datadir=f:\data\bitcoincore

But running Armory using the Testnet icon attempts to connect to the testnet and crashes Bitcoind.exe

I'm on x64 architecture and believe the problem lies in Armory not finding my remote datadir. Obviously there's the testnet3 directory inside f:\data\bitcoincore ie f:\data\bitcoincore\testnet3

I should add I've made a junction point with mklink for %appdata%\bitcoin to f:\data\bitcoincore

Is anyone aware of either the correct flags passed to Bitcoin Core in the settings of Armory, or the Armory flags, or both, which allow me to run Armory on testnet?

I'm going to answer my own question for those interested in the solution:

Armory and Bitcoin-QT use confusing switches; Armory going for the --flag while the latter uses the -flag
A remote Blockchain directory is identified using --Satoshi-datadir= while -datadir= is used with Bitcoin-QT
Ensuring the Bitcoin.conf file is correct is the main issue. Correct values required are: listen=1, allowip=127.1.1.1


What prevents a pool miner from stealing an entire block? As I understand it,when mining BTC, and calculating a block, the goal is to find a SHA-256 hash below a certain value (with the previous block, a nonce, and other things as the input).  Are pool miners all performing that calculation directly (just with different nonces?)

If so, what prevents the miner who "finds" the block from keeping it, and not reporting it back to the pool?  I'm assuming there's some safeguard here, and the miners aren't actually going to find the full solution.

When you are running a miner in a pool, you communicate through getwork protocol. It basically boils down to requesting work and sending back shares (and in rare cases, solutions to blocks). Work in getwork is a Block Header, not an entire Block. The coinbase transaction is encoded in the merkle root, but is not known to the miner. The block hash that creates a share or a block solution is ONLY valid for a given merkle root. If you change the coinbase, giving yourself all the money, you invalidate your solution and have to start over. If you are mining your own blocks, no pool should accept your shares (unless it is dumb).

To sum up - a miner does not know the coinbase transaction, nor can it change the block without invalidating it.

On the other hand, a miner can withhold a block solution while still submitting other shares. This will make the pool get less money while still having to potentially pay for those shares. This exploit can be detected by statistics though, so over a long period of time such a malicious miner can be found out.


DDOS Safety Electrum? How hard would it be to successfully attack (all) the Electrum backend servers? I think there is about a handful of them.

I would consider an attack successful that stops Electrum from working for a day or so.

I'm not exactly sure if this is what you're asking; nevertheless the wiki says:

  Transactions are signed locally: Your private keys are not shared with the server. You do not have to trust the server with your money.

  Freedom and Privacy: The server does not store user accounts. You are not tied to a particular server, and the server does not need to know you.

It seems the storage of your keys is client-side, so if they were to get (D)DoS'd you could easily move you keys to another wallet.


Where can one find the best explanation of the blockchain? Sorry if these questions seem stupid but after a lot of research I still feel rather lost and confused !!
I understand what is bitcoin and have a fairly good understanding of the basic blockchain idea but I have a hard time understanding some concepts.
For example where can one download the source code for the blockchain ? How did Ethereum get the source code for the blockchain ?
How can an update be "scheduled" for a specific block and not be implemented immediately ?
Or how can one code apps for a blockchain platform like ethereum ?

I guess all these fall in the question, where can I find a thorough, complete explanation of the blockchain?

Thanks !

Since nobody answered and I continued my research I'll post something I found online that helped me understand the blockchain.

http://blockchaindemo.io - This website visually simulates a simple blockchain to explain how it works. Pretty well made in my opinion based on comparison with other explanations I found online.

Otherwise here is the white paper from Bitcoin's creator, Satoshi Nakamoto, even if outdated, it can help understand some of the original concepts:
https://bitcoin.org/bitcoin.pdf


What is the probability of mining a block by a miner controlling a fraction of hashing power? Suppose a miner controls α fraction of the hashing power and the chain on which he is trying to mine has the mining rate given by f. How to find the probability of mining a block by the miner?

Probability
As  MCCCS comented:

Your hashrate divided by total hashrate is the probability of you finding the next block.

As of March 2021

Item
Hashrate MH/s

Typical desktop computer's i7 CPU
24

Antminer S19 Pro
110,000,000

Bitcoin network
156,000,000,000,000

So every ten minutes a CPU miner would have a 1 in 6,500,000,000,000 chance of earning 6.25 BTC. You have a 1 in 139,000,000 chance of winning the Euromillions lottery so lottery tickets will give you an overwhelmingly better return on investment in the longer term than does CPU mining. In both cases you are more likely to lose lots of money than see any profit.

"Expected earnings"
You can also key your hashrate into an online calculator to find your "expected earnings".

Setting
Value
Units

Difficulty Factor
1.54660989356e+13

Hash Rate
24.0
MH/s

Exchange Rate
50809.85
($/BTC) [user]

BTC / Block
6.25000000

This Difficulty

Coins
Dollars

per Day
0.00000000 BTC
$0.00

per Week
0.00000000 BTC
$0.00

per Month
0.00000001 BTC
$0.00

this diff (est)
0.00000008 BTC
$0.00

Next Difficulty [estimated]

Coins
Dollars

per Day
0.00000000 BTC
$0.00

\per Week
0.00000000 BTC
$0.00

per Month
0.00000001 BTC
$0.00

Of course, you might get lucky.

References

https://www.blockchain.com/charts/hash-rate
https://alloscomp.com/bitcoin/calculator


How does Bitcoin coordinate time between nodes I'm curious about how Bitcoin nodes sync their time. There are delays within data transmission so if a node mines a block, how does the network determine whether it is the first?

Nodes determine which block is "first" based on whichever block they receive first.

Or in other words, the timestamp on a block is not used to determine which block a node will add to their blockchain; nodes simply add the first valid block they receive to their blockchain.

As a result, if two blocks are mined at the same time, it's possible that different nodes on the network will have different blocks at the top of their blockchain. To illustrate:

Node1    Node2
-----    -----

 [x]      [y]
 [c]      [c]
 [b]      [b]
 [a]      [a]

block [x] was mined "first"
block [y] was mined just after block [x]
Due to network delays, Node2 ends up receiving block [y] first
Therefore, Node2 adds [y] to the top of their chain (but they also keep a copy of block |x|)

So at this point in time, there is a disagreement about the state of the blockchain on the network. This happens.

This situation is resolved when a new block gets mined.

For example, if Node1 mines a new block on to their chain:

Node1
-----

 [z]
 [x]
 [c]
 [b]
 [a]

This new block [z] creates the new longest chain on the network. So when Node2 receives block [z], they will adopt the new longest chain:

Node1    Node2
-----    -----

 [z]      [z]
 [x]      [x][y]
 [c]      [c]
 [b]      [b]
 [a]      [a]

...and the network is back in agreement about the state of the blockchain.

Summary:

The order of blocks (or which block is "first") is not determined by the timestamp on blocks relative to any network time.

Instead, nodes will add the first block they receive, and are free to disagree on which block is at the top of the chain. The order is resolved when a new block is mined, and all nodes adopt the longest known chain.


The amount of coins in the wallet is too small for sweeping I want to make a present to my friend for his wedding - a bitcoin paper wallet.

I managed to print it and send 100uBTC (0.0001BTC) to the paper wallet for a test.

Then I chose "Sweep paper wallet" and I got a message that the coins are there, but "the amount of coins in the wallet is too small for sweeping".

What is the minimum amount that I can sweep?

Sweeping is just sending all bitcoins to another address. As such, there is a network fee involved.

Network fees will come out of the value of the paper wallet.

Depending on what you are using for sweeping, you can vary the fees. Though
a lower fee will take longer to complete:

https://bitcoinfees.21.co/

At the risk of dating this answer, I would currently allow 0.001 BTC in your friend's gift for fees for fast transactions, about 5 USD, (yes fees are pretty high right now.)


Distributed Consensus "Distributed" means operating on more than one devices which dont share physical memory and perform their task (which might be storage or computation) to perform one single task (which in our case might be to have same copy of ledger)

"Consensus" means when everyone is on the same page.

So,"Distributed Consensus" means we want all the different devices on the network which dont have a shared memory and communicate by message passing mechanism to have same copy of ledger. Is that correct ?

Yes, you are correct. In addition, we assume that there are adversaries which can operate arbitrarily and replace some honest-looking devices on the network and make them behave like a "malicious intelligence". They send data adversarially designed to disrupt your protocol.

You want your "distributed consensus" to be able to work under these conditions.

Furthermore, if an arbitrary number of such malicious devices can be injected and you cannot tell devices apart, we call it "anonymous distributed consensus", the problem that bitcoin is solving.


Bitcoin exchange, local or foreign? If I live in the USA, and buy/sell bitcoins from a Japanese exchange, are their any advantages/disadvantages for doing this, instead of buying bitcoins from a USA exchange?

There are legal differences. I won't go as far as saying I can tell you if any of them are advantages or disadvantages, because I don't think I can.

If both your exchange company and their banking is in your country, then there is no question if there is any legal obligation on your part to tell your government that you dared move money outside the country. Check your laws; if you're middle class, you'll be surprised how low the trigger amount for such issues that you might think would afflict only the seriously affluent can be.

One thing that is not very different is that no bitcoin exchange I am aware of is fully compliant with all laws fit for all sorts of similar enterprises for every location where they do business, and most probably are not compliant in any or only in hardly any. Some like to advertise their compliance, but I suppose the one case (campbx) where I did get more information on that by inquiring is typical. They wrote me earlier this year that they were then only compliant with the (comparatively easy) Federal FinCEN rules, not the rather tough state money transmitter licensing, although they emphasized their efforts towards progress on that front.

Whilst you may argue that this is mostly because many people don't get how these laws cannot possibly apply to bitcoin businesses, that hasn't stopped authorities in some countries from temporarily seizing a bank account of a bitcoin exchange (one case I know of was in Poland, and one not related to such laws in Germany) or even seizing a bank account for forfeiture (one case I know of in the USA).

So this is not different, but still there is the subtle but important distinction if there is even a chance that your exchange will be allowed to remain in business and at least try to continue honoring its obligations to its customers (as happened with MtGox, even after a possibly minor bank account they had in the US was seized for forfeiture for failing to have state licensing).

I wonder if it would go the same way for an exchange based in the US. Or in comparable countries, for that matter. For a UK company banking in Germany and Poland, the empirical answer is no (bitcoin-24 stopped doing business after its German bank acount was temporarily seized and hence released back to them, and their Polish bank account was simultaneously seized but at least not completely released back to them yet). Again, I wouldn't even try to venture towards judging which is better and for whom.


Bitcoin-Qt icon not showing in Top Edge Panel (Linux Mint) I've been using Bitcoin-Qt (now 0.6.2) for two months now with no problems. Now its icon is missing from my top edge panel (Gnome Desktop, Linux Mint 64 bit). How do I get it back? Or is there any other way to open the GUI window?

Restarting the system doesn't help.

I'm new to Linux (used Windows before, but used bitcoin on Linux only).

The bitcoin-qt client is running as I can see the process in System Monitor and also the log file keeps updating. (I don't see any apparent errors in the log.) The bitcoin-qt process starts automatically on system restart.

If I try to start bitcoin-qt, I get the message that it can't obtain a lock and that it is probably already running (which it is). The .lock file (0 bytes) is present in ~/.bitcoin.

What I can do is I can stop the bitcoin-qt process (using System Monitor) and then start it manually and then everything is fine. But after restarting the system, the problem is back.

Any ideas? Should I post more info (which?)? Thanks!

Known issue:

http://github.com/bitcoin/bitcoin/issues/1242


Lost funds on my lightning node? I've been using lightning network daemon (LND). In an effort to have a balanced node with somewhat equal amounts on both side of my channels, I've sometimes opened channels with the command lncli openchannel Xdest_nodeXX local-amt push-amt and specify push-amt to be approximately 50% of the local-amt. Over the last year or so I've opened and subsequently closed numerous channels in this way. This discussion on stackexchange indicates the funds are irretrievably send to the other node and my funds are lost! Is that true?

Yes. Unfortunately this is true. Using push-amt means that you send over an amount to the other side wich they own. While it takes place offhand it is final in a similar way as sending Bitcoin to an address.

The only way I see to get your funds back is if you talk to the owners of the nodes you opened channels with explain them the situation and ask to get reimbursed.


Broadcasting a transaction as a 3rd party In a scenario I have a signed transaction from A to B and ready to broadcast. As C, I want to broadcast it but the part I am having hard time to understand is as the transaction is already signed and everything is settled how can I change the transaction fee I would like to pay? Can I pay extra from my wallet for example? Thanks.

If you have send your transaction but it does not appear on the blockchain yet it mean it is still in the mempool, the place where transaction are waiting to be taken by a miner.
Miner incentive are to take the transaction with the biggest fees first, so yes you can "double send" your transaction using the same element but with an increased fee, so that it has more chance to be mined fast.
You can check this question for more detail:
When increase transaction fee three times in few minutes - transaction had an attempted double-spent?


I can't get into my NEO wallet At Neo.org I downloaded then saved this file Windows.Neon.Setup.0.0.5.exe on my desktop to set up a wallet for my NEO. I closed and reopened and put neo shares here. Now when I try to open it a window opens and says "installing, please wait and then the window closes but nothing opens. It doesn't give my any options to try anything else.

The first time I was able to get in and when it was open I created a short cut. When I try to open the shortcut I get this message, "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."  I have all my keys saved and when I look on neoexplorer with my address, I can see all my neo is there and transactions are listed. It is very frustrating. Is anyone else having the same issue and does anyone know how I can get into this wallet or get my neo out? Any help would be appreciated and sorry if I am overlooking something here as I am pretty new to cryptos.

It sounds to me like your antivirus program may be interfering. Check if neo has been moved to your virus chest, and if so, add it to your antivirus exclusions list


Convert between String/Hex/Byte in Java for sha256 - wrong format? I am trying to convert a bitcoin address and have the following code from here (Calculate Segwit address from public address, 2nd answer):

Step1: $ printf 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9 > adr.txt
Step2: $ printf $( cat adr.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) >adr.hex
Step3: $ openssl dgst -sha256 -binary <adr.hex >tmp_sha256.hex
Step4: $ openssl dgst -ripemd160  <tmp_sha256.hex
## result should be: 56379c7bcd6b41188854e74169f844e8676cf8b8

Now I want to do this in Java. I currently have the following code. No matter what I try, I dont get the correct result. :(

String address = "1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9"; // step 1
System.out.println("address: " + address);
String addressHex = toHex(address);
System.out.println("address hex: " + addressHex);
byte[] addressBytes = addressHex.getBytes(StandardCharsets.UTF_8); // step 2
MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] hash = digest.digest(addressBytes); // step 3
RIPEMD160Digest digest2 = new RIPEMD160Digest(); // steps 4
digest2.update(hash, 0, hash.length);
byte[] out = new byte[20];
digest2.doFinal(out, 0);
System.out.println("result: " + bytesToHex(out)); // = 62ab42cba5d2632d1350fafb2587f5d2ece445d3
                                                  // should be 56379c7bcd6b41188854e74169f844e8676cf8b8

Output:

address: 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9
address hex: 314c383853323643356f796a4c31676b58734265597748486a764776436369647239
result: 62ab42cba5d2632d1350fafb2587f5d2ece445d3

Can someone help me? I think the problem is somewhere doing the conversion String/hex/byte ...? I tried really hard, but cannot find the correct way to do it.

I also tried to convert the address to hex and after that to bytes, but doesnt work neither. :/

// updated post
... still doesnt show the correct result :/

// update2:

byte[] address = ("1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9").getBytes();
System.out.println("address byte array: " + address);
String addressHex = bytesToHex(address);
System.out.println("address hex: " + addressHex);
byte[] addressBytes = addressHex.getBytes();
MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] hash = digest.digest(addressBytes);
RIPEMD160Digest digest2 = new RIPEMD160Digest();
digest2.update(hash, 0, hash.length);
byte[] out = new byte[20];
digest2.doFinal(out, 0);
System.out.println("result: " + bytesToHex(out));

Output

address byte array: [B@108c4c35
address hex: 314c383853323643356f796a4c31676b58734265597748486a764776436369647239
result: 62ab42cba5d2632d1350fafb2587f5d2ece445d3

I have not the Java solution, but I can indicate the error. The conversion to hex is apparently missing.  When I do the hash on the text file itself, I also get the wrong result:

$ printf 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9 > adr.txt
$ openssl dgst -sha256 -binary <adr.txt >tmp_sha256.hex
$ openssl dgst -ripemd160  <tmp_sha256.hex
(stdin)= db151e871af66b1323893e3f527e22f7684718af

so the transformation into a hex byte array "addressHex" is for sure missing something.

Update:

I can see the "bytesToHex()" function, was this the code from the link I provided in the other thread? If so, try to dump the output of your java into a file, and use hexdump to verify. So you can concentrate on these two lines (I made the sed command shorter, without "cat"):

$ printf 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9 > adr.txt
$ printf $( sed 's/[[:xdigit:]]\{2\}/\\x&/g' adr.txt ) >adr.hex
$ hexdump -C adr.hex
00000000  31 4c 88 53 26 c5 6f 79  6a 4c 31 67 6b 58 73 be  |1L.S&.oyjL1gkXs.|
00000010  59 77 48 48 6a 76 47 76  cc 69 64 72 39           |YwHHjvGv.idr9|
0000001d

Here you should receive the same result by your java code, then you'd be good to go :-)


Bitcoin trading volume: what's going on? Since January, bitcoin trading volume on exchanges has been slowly dropping (more or less, on average), but it's had a significant drop around May 13th, and has stayed low since then. I checked the volume from BTC China mainly, but it seems several (if not all) exchanges exhibit this phenomenon. Up to this point, I'm just stating facts.

My question is: does anybody know about any reasonable explanation for this? I mean, based on facts, evidence, or meaningful experience on the subject. For example, has this happened before? If so, it could be some temporary/cyclic phenomenon, maybe (?). Also, if this happens to be some sort of pattern that has occurred before, can we expect the volume to go up again anytime soon? Is it some sort of "bad sign" ? (as in "this pattern is often followed by a big crash" or something like that).

I know nobody has the crystal ball, and I'm not asking for unfounded opinions; I just thought that maybe someone with more financial experience or knowledge on the subject (than me, which shouldn't be very hard) could shed some light on this.

This question could be asked of any financial instrument. Volumes decreasing is not a bad or good sign. It's simply something that occurs when volatility decreases. The market theory behind it might go like this.. Price has fallen to such low points sellers are no longer interested in selling. Buyers are still hoping for lower prices. This effect causes the price to trade within a range where anytime the price rises to an acceptably high level sellers begin to sell again and any time it reaches an acceptably low level buyers begin to buy. As traders notice the price is range bound more traders stop trading. This compounds decreasing volumes and also decreases the trading range. Eventually this will lead to reduced trading interest which can then lead to the price breaking out of the range in the direction of least resistance (as traders give up their respective buying or selling).

Sorry there is no provable answer to your question, as this is all market theory. However, if you were to look at different financial instruments historical volumes you would see many instances similar to what is currently happening in bitcoin's market volumes. This is a common pattern in markets and is normally described as not predictive of future events (range trading is often thought as having a random breakout direction).

https://en.wikipedia.org/wiki/Triangle_%28chart_pattern%29#The_symmetrical_triangle


How are Bitcoin Addresses generated when using bitaddress.org? I am trying to figure out in the the source code of bitaddress.org which files and functions that correspond to the generation of bitcoin addresses.

Link: https://github.com/pointbiz/bitaddress.org/tree/master/src

Can someone point me to which files and functions that generate the bitcoin addresses?

I would like to audit the code and also see how this all works since this can be done offline.

https://github.com/pointbiz/bitaddress.org/blob/master/src/bitcoinjs-lib.eckey.js#L65 seems like a good starting point.

The functionality you are interested in has been taken from https://github.com/bitcoinjs/bitcoinjs-lib, so you might want to have a look there as well.


Altcoin does not create .altcoin folder and debug.log I changed the source code of bitcoin and I ran it. However, it gives the following error:

chainparams.cpp:140: CMainParams::CMainParams(): Assertion `hashGenesisBlock == uint256("0xxx")' failed.

Aborted (core dumped)

It also does not create .altcoin folder in home folder, so I cannot see debug.log. Why is this so?

The latest bitcoin source doesn't output any debug log in chainparams.cpp.
You can,

Use GenesisH0 to find your Genesis block hash.
make && sudo make install
Run it again, then you will see debug.log within your bitcoin folder


How to close stale lightning channels with c-lightning I was running a lightning node using c-lightning about 9 months ago. Unfortunately the server was shutdown while a few channels were open.

I have restarted the server and updated c-lightning to the latest version (0.6.3). After restarting both bitcoind and lightningd I am left with the 2 stale channels.

zap:~# lightning/cli/lightning-cli listpeers
{
  "peers": [
    {
      "connected": false,
      "channels": [
        {
          "state": "CHANNELD_NORMAL",
          ...
          "status": [
            "CHANNELD_NORMAL:Attempting to reconnect"
          ],
          ...
        }
      ]
    },
    {
      "connected": false,
      "channels": [
        {
          "state": "CHANNELD_NORMAL",
          ...
          "status": [
            "CHANNELD_NORMAL:Attempting to reconnect"
          ],
          ...
        }
      ]
    },
  ]
}

I am unable to connect back to these pairs using lightning/cli/lightning-cli connect x, when I try I get timeout or route errors. (EDIT: which means the other nodes are now down).

The problem seems that the other nodes are also offline which is why you can't connect to them.

Luckily you don't have to be connected  as you can do a force close by publishing your channel state to the Bitcoin network (the disadvantage is that you have to wait for the timelock until you can spend your outputs)

Just try lightning-cli close ENTER-CHANNEL-ID-HERE in case you are not connected your node should perform a force close


Get Seed from wallet on regtest mode I am doing some tests for an application that signs Bitcoin transactions. I already downloaded the binary files bitcoin-cli,bitcoind and bitcoin-wallet from bitcoin.org. I need to know that the seed of the wallet created by regtest. It is available when the bitcoin-wallet -regtest info command returns:

Wallet info                                                                             │
===========                                                                             │
Encrypted: no                                                                           │
HD (hd seed available): yes                                                             │
Keypool Size: 1999                                                                      │
Transactions: 103                                                                       │
Address Book: 2

I need that seed for run recovery on my app and check if it sign correctly a Bitcoin transaction.

Thanks in advance

You are looking for the dumpwallet command.

While in regtest open the console a/k/a debug window, and type:
dumpwallet "C:\myfolder\dump.txt"

This will create a text file with all your keys. At the top you will see your extended master private key. And if you are looking for your HD seed, do a control+f for hdseed, you should find a key with the label hdseed=1.

https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/sethdseed/


Where does the blockchain come from? When I first download Bitcoin Core, and Synchronize with the network, where am I actually downloading the block chain from?  The point of bitcoin is that there is no canonical source, yet I must get the data from somewhere?

Does it use a bittorrent-like protocol?
Am I getting different blocks from different peers?
How does my computer discover peers initially?

The blockchain begins with the genesis block. The genesis block was mined by Satoshi and it a hard coded value in all Bitcoin full nodes. All blocks in the blockchain must be a descendant of this block.

When you synchronize with the network, your node will perform peer discovery and connect to several other nodes. It then proceeds to request from those nodes the block headers for each node's best blockchain. Block headers are received in 2000 header chunks (i.e. Core requests for 2000 headers and receives 2000 headers at a time from a node). Core will build a block headers chain and verify that the proof of work is correct. At the same time, Core will download the blocks for those block headers (blocks are received and synced much more slowly than their headers) from all of its peers. The sync is finished when it receives less than the 2000 headers it last requested for.

As you can see, there is no canonical source. Core simply connects to several nodes and downloads blocks from them. Then it verifies that those blocks fit the consensus rules that it is following.


Ubuntu command to download https://launchpad.net/~bitcoin/+archive/bitcoin/+packages What command do I use to get the latest bitcoin package under Ubuntu desktop 12.04 LTS?

Also, what needs to be done to uninstall previous versions?

It's relatively painless

sudo apt-add-repository add-repository
sudo apt-get update
sudo apt-get install bitcoin-qt

How you get rid of the old copy depends on how it was installed, if it was a default install this will probably get rid of that anyway.


Bitcoin Wallet Empty after importing using key phrase I've recently tried to recover my Bitcoin wallet after changing phones however after importing the wallet using the 12 word keyphrase my wallet is empty (there was Bitcoin in the before). I've scanned the wallet for transactions but none are found.
Any idea what has happened and if/how I can recover my Bitcoin?
Thanks

Any idea what has happened and if/how I can recover my Bitcoin?

First of all, try to find out what software have you used originally. Was it a desktop/mobile wallet? What was the name of the application you set up the wallet through?
Please check out this website and check the column Paths. If your original software wallet supported path like m/0' but due to software upgrades the new version supports a new path like m/44'/0'/0' or it's maybe a completely different software wallet that supports other paths like m/49'/0'/n' - in these cases new wallet won't show you any balances as addresses are being derived differently in these different paths.
If you know your addresses from a previous wallet you may also try the Iancoleman tool, remember to use it in offline mode and I would personally not use it for bigger amounts anyway.


What version of python is required to install electrum-ltc and electrum-dash in amazon linux instance? I am trying to install different wallets on my amazon linux ec2 instance. I already have a working electrum-btc.

[ec2-user@ip-xxx-xx-xx-xxx dash-electrum]$ python --version
Python 2.7.13
[ec2-user@ip-xxx-xx-xx-xxx dash-electrum]$ python3 --version
Python 3.4.8
[ec2-user@ip-xxx-xx-xx-xxx dash-electrum]$ uname -a
Linux ip-xxx-xx-xx-xxx 4.9.85-38.58.amzn1.x86_64 #1 SMP Wed Mar 14 01:17:26 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

But when Iam installing other clones for litecoin and dashcoin pip install command fails.

  sudo which pip3 install Electrum-DASH-2.9.4.tar.gz

  Running setup.py install for hidapi ... error
Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-y3d9_mm3/hidapi/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-ffxgn444/install-record.txt --single-version-externally-managed --compile:
running install
running build
running build_ext
cythoning hid.pyx to hid.c
building 'hid' extension
creating build
creating build/temp.linux-x86_64-3.4
creating build/temp.linux-x86_64-3.4/hidapi
creating build/temp.linux-x86_64-3.4/hidapi/libusb
gcc -pthread -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Ihidapi/hidapi -I/usr/include/libusb-1.0 -I/usr/include/python3.4m -c hid.c -o build/temp.linux-x86_64-3.4/hid.o
gcc -pthread -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Ihidapi/hidapi -I/usr/include/libusb-1.0 -I/usr/include/python3.4m -c hidapi/libusb/hid.c -o build/temp.linux-x86_64-3.4/hidapi/libusb/hid.o
hidapi/libusb/hid.c:26:0: warning: "_GNU_SOURCE" redefined
 #define _GNU_SOURCE /* needed for wcsdup() before glibc 2.10 */

<command-line>:0:0: note: this is the location of the previous definition
hidapi/libusb/hid.c:47:10: fatal error: libusb.h: No such file or directory
 #include <libusb.h>
          ^~~~~~~~~~
compilation terminated.
error: command 'gcc' failed with exit status 1

----------------------------------------
Command "/usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-y3d9_mm3/hidapi/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-ffxgn444/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-y3d9_mm3/hidapi/

What am I doing wrong? Can I install only one electrum wallet on one server?

Your likely missing the libusb dependency.  Electrum doesn't spell it out in their repo, but I always build it with trezorlib and it explicitly requests it.  Here's what I got to work.

sudo apt install python3-dev python3-pip cython3 libusb-1.0-0-dev libudev-dev python3-pyqt5
sudo -H python3 -m pip install --upgrade setuptools pip
sudo -H python3 -m pip install https://some-path-to-tarball


Basic overview of fees Can someone explain fees in layman’s terms
I thought I would throw a few dollars into bitcoins more for a laugh than anything - but the fees are confusing me.
I googled best wallet for newbies & most people suggested Exodus as simple and easy for beginners.
Using Apple Pay I bought $100 at around 44k - I got $99 worth of coins and paid $1 fee (seems fair)
They are now at 48k and my $99 is up to about $109
I have no interest in cashing out, but still leaning my way around so thought I would check how much the fee would be to cash out.
From what I can tell, I have to use a company like coin base to convert to hard cash and so I’m looking at paying a transaction fee to send the money to coin base plus a fee to coin base for converting my Bitcoin to hard cash / depositing in my bank account.
The transaction fee exodus shows me to send my coins anywhere is $15 which seems a bit steep.
Would I be better off having a coin base wallet so I’m not having to pay that $15 when I want to cash out on top of cashing out fees?
Looking online people say coin base fees are a few % and exodus is 5% plus - but they are quoting me 15% (or is that just because I only have small amounts & it would be cheaper if I had $1,000)
I may throw $50 or $100 a month into BC moving forwards, nothing big, an amount I can afford to forget about for years or even lose large amounts of, but don’t want to lose 20% when I cash out between transfer & cash out fees!
Any help would be much appreciated

Currently, there is a lot of demand for bitcoin transactions, you're sort of looking at "surge pricing".
Transaction fees in Bitcoin are paid for the blockspace that a transaction occupies. This means that the fees for a transaction scale with the number of pieces of bitcoin (UTXO you spend and create, irrespective of the amount of value you transfer. Assuming that you have actually taken custody of your funds in your Exodus wallet when you bought them, you would end up having a lot of UTXO in your wallet if you buy in chunks of $50 to $100. This could cause significant transaction fees when you finally want to move your funds.
To mitigate these costs, you could proceed in multiple ways:

Consolidate your funds: before you move your funds out of your Exodus wallet, send all your bitcoins to yourself. This will consolidate all your UTXO to a single piece. Create this transaction at a very low feerate. The transaction will likely take a long time to confirm, but most of your value will be preserved. After that, a more expeditious transaction to transfer your funds to another market or pay someone can be made at a higher feerate without as high of a relative cost.
Buy bigger chunks: bigger chunks means fewer UTXO and less fees.
Use a custodial market to buy: Buy on a custodial service instead, and withdraw at greater intervals whenever you have accumulated more bitcoin or when the blockspace market is less competitive.

If you want to find out more, I've written about the current situation a bit more here: https://bitcoin.stackexchange.com/a/99699/5406


Current FPGA Competitiveness I know CPUs and GPUs can't really compete with ASICs anymore but what about FPGAs?  Are they still reasonable?  Anyone have a ballpark idea of what kind of Gh/s (or Mh/s) has been done with something like a Spartan 6?

First a bit of perspective on FPGA mining.

Around 2011 some miners started switching from GPUs to FPGAs, (Field Programmable Gate Arrays), after the first implementation of Bitcoin mining came out in Verilog, (a hardware design language that’s used to program FPGAs).

The general rationale behind FPGAs is to try to get as close as possible to the performance of custom hardware while also allowing the owner of the card to customize it or reconfigure it "in the field".

By contrast, custom hardware chips are designed in a factory and do the same thing forever. FPGAs offer better performance than graphics cards, particularly on “bit fiddling” operations which are trivial to specify on an FPGA.

Cooling is also easier with FPGAs and, unlike GPUs, you can theoretically use nearly all of the transistors on the card for mining. Like with GPUs, you can pack many FPGAs together and drive them from one central unit, which is exactly what people began to do.

Overall, it was possible to build a big array of FPGAs more neatly and cleanly than you could with graphics cards. Using an FPGA with a careful implementation, you might get up to a GH/s, or one billion hashes per second.

This is certainly a large performance gain over CPUs and GPUs, but even if you had a hundred 141 boards together, each with a 1 GH/s throughput, it would still take you longer than 50 years on average to find a Bitcoin block at the current difficulty level.

Despite the performance gain, the days of FPGA mining were quite limited. Firstly, they were being driven harder for Bitcoin mining — by being on all the time and overclocked — than consumer grade FPGAs were really designed for. Because of this, many people saw errors and malfunctions in their FPGAs as they were mining. It also turned out to be difficult to optimize the 32‐bit addition step which is critical in doing SHA‐256. FPGAs are also less accessible‐you can't buy them at most stores and there are fewer people who know how to program and set up an FPGA than a GPU. Most importantly though, even though FPGAs improved performance the cost‐per‐performance was only marginally improved over GPUs. This made FPGA mining was a rather short‐lived phenomenon. Whereas GPU mining dominated for about a year or so, the days of FPGA mining were far more limited — lasting only a few months before custom ASICs arrived.

However- the cycle repeats itself.

It’s worth noting that several smaller altcoins have indeed used a
different puzzle than SHA‐256, but have seen a similar trajectory in mining as Bitcoin.

For ASICs there is still a long lead time between designing a chip and shipping it, so if a new altcoin uses an new puzzle (even just a modified version of SHA‐256), this will buy some time in which ASICs are not yet available. Typically, mining will proceed just at Bitcoin did from CPUs to GPUs and/or FPGAs to ASICs (if the altcoin is very successful, like
LiteCoin). Personally I'm quite interested in Zcash.

Much of the content for this answer was drawn from this excellent resource.


accept bitcoin payments for orders without 3rd party software I've been searching for an open-source alternative to blockchain.info's Receive Payments API (https://blockchain.info/api/api_receive). I want to run bitcoind on my own server and have payments handled in my own database.

Is there any project in existence that is kept up-to-date with the current version of Bitcoin?

Searching here, github, and Google has returned me no results.

I don't think you need a third-party library if you have a reasonable level of programing experience.  (If you don't, you probably shouldn't be handling money directly.)

Here are the steps from the Blockchain.info (BC.i) page recreated for Bitcoin Core.

Get A Receiving Address

Use the getnewaddress RPC.  The JSON-RPC result will be a string with the address.

Get A Callback When An Address Receives A Payment

Use the -walletnotify bitcoind command line switch to run a program every time a wallet transaction is received, sent, or confirmed.  Your program can use the following commands:

gettransaction to get details about the transaction, including everything BC.i would've sent you and more.  (See link for an example.)  When Bitcoin Core runs the walletnotify command, it can pass an argument with the TXID, so you would run gettransaction <txid>
Something like curl to send an HTTP GET to your callback URL with whatever details you need

That's it.  As long as you can write a script that can parse JSON, you can do everything BC.i does with just a few lines of code.  That's also probably why you don't see any code on GitHub: it's too simple to make a project out of.

Before you get started, I highly recommend reading the Bitcoin Wiki proper money handling page to learn how to handle high-precision bitcoin values.  Also, if this is your first money-handling program, please remember the high stakes that come with holding on to money.  Hackers love stealing bitcoins.


bitcoind error "mempool min fee not met" preventing me from sending btc on blockchain When I want to send btc in block chain this message is appearing:

  BitcoindException(super=com.neemre.btcdcli4j.core.BitcoindException:
  Error #-26: 66: mempool min fee not met, code=-26).

Who knows how to resolve this? Can anybody help me please?

It seems to be a known issue on Electrum. Try a different server:   https://github.com/spesmilo/electrum/issues/3555#issuecomment-352621941


If there are a significant number of pruned nodes on the network will it impact network security? The size of the Bitcoin blockchain is reaching 350 MB and adding more than 60GB per year. I feel verification node centralization a risk if the cost of storage does not drop.
My question 1:
Is using pruned nodes as good as full nodes?

I think a pruned node will have the same UTXOs as a full node (with a full blockchain) and it should be able to verify all incoming transactions and blocks.
It will not be able to provide blocks to a requesting node if it does not have them in its blockchain. But as long as newer nodes have the hash of the previous block this should not be a problem.

My question 2:
If there are a significant number of pruned nodes on the network will it impact network security?
Is there something I am missing?

Your points 1 & 2 are both correct. The good news is the only time those old blocks get requested is by new nodes that are still bootstrapping and downloading the blockchain for the first time. As long as those old blocks are available and accessible somewhere, those new nodes will sync up just fine.
Another fact about pruned nodes is they are required to store at least the most recent 288 blocks. So if your node has only been offline for a day, you can still sync up from a pruned peer.


How does MPOS communicate with stratum server? I'm setting up MPOS. There are 3 stratum server options: stratum-mining, NOMP, and CoiniumServ. How does MPOS talk with stratum server? AFAIK, MPOS does not speak stratum protocol. Is it through the shared mysql database, where stratum server writes to it (e.g., submitted shared) and MPOS retrieves from.

I'm trying to use a stratum server other than the 3 options above, thus trying to see how to make it compatible with MPOS.

NOMP actually implements MPOS compatibility mode, so you can reference the data format it writes to MySQL: mposCompatibility.js. For example:

Storing shares:

INSERT INTO `shares` SET time = NOW(), rem_host = ?, username = ?, our_result = ?, upstream_result = ?, difficulty = ?, reason = ?, solution = ?

Updating Miner Difficulty:

UPDATE `pool_worker` SET `difficulty` = ' + diff + ' WHERE `username` = ' + connection.escape(workerName)

New Pool Worker:

INSERT INTO `pool_worker` (`account_id`, `username`, `password`) VALUES (?, ?, ?)


How to get bitcoin address of any private key? calling bitcoin-cli dumpwallet returns wallet private keys and addresses.

Example

L34D2hAS9KBJQzJkHtmNt1bdSJ18cQUvfSnJEqPKH2oUj6sBxvXt 2017-11-23T05:11:13Z reserve=1 # addr=1D2mnuj9qeRAzmw8mjLDciyvqzQiiYZCfE hdkeypath=m/0'/0'/1030'

Importing this private key to wallet using importprivkey command returns null on success.

How to get bitcoin address related to this private key? or is there's any way get this private key details like balance or addresses?

the private key is a Private Key WIF Compressed, 52 characters base58, and can be used to convert into (compressed or uncompressed) public keys. These pub keys are usually hex codes, and can be converted into bitcoin addresses: 1D2mnuj9qeRAzmw8mjLDciyvqzQiiYZCfE and 1KWvNZB4Gf2Kars88aGR2cedUb81Q6gZKC. There is no easy way I am aware of to do this in bitcoin client.

Looking at the line you provided, the bitcoin address is behind the comment sign (#), and is part of a HD key, which complicates things even more, if I had to explain it. To understand the whole idea behind keys, you may want to read bitcoin.org or the book af Andreas "Mastering Bitcoin" (online available).

Looking then at e.g. blockchain.info, you can provide the addresses or the keys, and see that there is no value.

Hint: never ever (!) use this key again to transfer values. It has been disclosed, and people are only waiting to snipe the values from this address! - me too :-)


LedgerJS - How to P2SH sign multiple transactions from multiple wallets in 1 function call? First some explanation

I have made 2 raw transactions via Electrum using my Nano S Ledger as seed and exported them to .txn files.

let rawTx1 = "02000000000101bf00f7aca2e0d393ad0a762224ad4cd5a10d9950804fbc5a22fe970918301179000000001716001400ce8131595e014b45ec6ca49495d547ab8bd872fdffffff02a08601000000000017a91457fd0d41e459a4227b8932327786cf512d99399987bc72ca...";
let rawTx2 = "02000000000101bf00f7aca2e0d393ad0a762224ad4cd5a10d9950804fbc5a22fe970918301179000000001716001400ce8131595e014b45ec6ca49495d547ab8bd872fdffffff02a08601000000000017a914a66dff1bf27dd1a5944b5bc9ff2b0f410efb64cd87bc72ca...";

Then I turned them into UTXO objects using the splitTransaction() function:

const UTXO1 = await btc.splitTransaction(rawTx1, true);
const UTXO2 = await btc.splitTransaction(rawTx2, true);

Next, I get the Wallet public keys I used for these transactions:

const wallet_1 = await btc.getWalletPublicKey("m/49'/1'/1'", false, true);
const wallet_2 = await btc.getWalletPublicKey("m/49'/1'/2'", false, true);

So transaction 1 was made with wallet 1 and transaction 2 with wallet 2. According to LedgerJS, I have to respect that order when calling the signP2SH() function:

btc.signP2SHTransaction([[UTXO1, 1, wallet_1.publicKey], [UTXO2, 1, wallet_2.publicKey]],
    ["m/49'/1'/1'", "m/49'/1'/2'"],
    btc.serializeTransactionOutputs(???).toString('hex')
);

Here,

[UTXO1, 1, wallet_1.publicKey]

are the Transaction object, output index, and redeem script in that order. And

["m/49'/1'/1'", "m/49'/1'/2'"]

are the derivation paths of both of my wallets.

My question is about the third line:

btc.serializeTransactionOutputs(???).toString('hex')

I know for a single transaction from a single wallet, I just toss in the UTXO1 in there:

btc.serializeTransactionOutputs(UTXO1).toString('hex')

But now that I have multiple UTXO's, I don't know what to fill in there anymore. Any ideas?

EDIT

Thanks to @Pierre Pollastri's answer I figured out the hashed script form.

So this code

const outputScript1 = btc.serializeTransactionOutputs(UTXO1).toString('hex')
const outputScript2 = btc.serializeTransactionOutputs(UTXO2).toString('hex')

produces the Output script for both UTXO's. Since we are processing two transactions we need to merge these output scripts. These scripts look as follows:

outputScript1 = 02404b4c000000000017a914c436f95c2ab5062dbc884a7c76ac805b58c00fe5879eaa7f000000000017a914429b7a8975c97dad6f90604faf732d9c7045279a87
outputScript2 = 02404b4c000000000017a914c436f95c2ab5062dbc884a7c76ac805b58c00fe587ee337e000000000017a914284c4c58d659cd485a283b48b4dc79da7571043587

They both start with 02, which indicates that each script handles 2 transactions. So what I did was simply change 02 into 04, remove the 02 from the 2nd script and then concatenate the 2nd script after the 1st script:

finalScript = 04404b4c000000000017a914c436f95c2ab5062dbc884a7c76ac805b58c00fe5879eaa7f000000000017a914429b7a8975c97dad6f90604faf732d9c7045279a87404b4c000000000017a914c436f95c2ab5062dbc884a7c76ac805b58c00fe587ee337e000000000017a914284c4c58d659cd485a283b48b4dc79da7571043587

Then call the function as stated above:

btc.signP2SHTransaction([[UTXO1, 1, wallet_1.publicKey], [UTXO2, 1, wallet_2.publicKey]],
    ["m/49'/1'/1'", "m/49'/1'/2'"],
    finalScript
);

It worked and I was able to sign the transaction :)

The third parameter is just your outputs script (actually it's the whole outputs part of a transaction) so depending on which address you want to send the funds it will change.

It's using the same format as in bitcoin transactions. The data are serialized like this

TYPE | Description
VARINT   | Number of outputs to create
8 byte   | Amount to send to the first output
VARINT   | Size of the output script
x bytes  | The actual output script

In most case you can consider that VARINT is only 1 byte (special cases if you data is bigger than 255 bytes but if that's the case you probably have an issue somewhere :P)

Regarding the output script depending on which address you want to send you have different type of scripts to use.

btc.serializeTransactionOutputs(???).toString('hex') is just serializing the outputs part of the transaction from a split transaction. If you use it on an existing transaction you're basically sending to the same addresses (the same amounts to the same addresses).


Could increasing Block size solve the "End of mining" issue Disclaimer: I am new to this forum and Bitcoin/cryptocurrency in general.

After all 21 million bitcoins are released into circulation, it seems that the incentive to mine is gone unless transaction fees are used. But if transaction fees are too high the incentive to use Bitcoin is reduced.

If the block size is increased the total number of transactions per block would increase, which results in more total reward for that block. This would also allow individual transaction fees to be quite low.

So, is this a feasible way to solve the "End of mining" problem?

That will be part of the solution, of course. But it's already assumed that in the far future there will be more transactions. That's not a solution in and of itself.

Keep in mind also, that the more transactions there are, the more valuable the system is, and so the greater the incentive to attack, and the more mining is required to defend it.