Does an Antminer S9 use Asic Boost? I recently got a couple Antminer S9's and I'm wondering if Bitmain sells their Antminer S9's with Asic Boost? I know of another miner called the Halong DragonMint Miner that achieves about 16 Terahashes with the same power usage and they say they use ASICBOOST. But does the Antminer S9 have ASICBOOST functionality built in and can you use that functionality?

Bitmain says that have tested ASICBOOST on the Testnet but have never used ASICBOOST on the MainNet...

  Bitmain has tested ASICBOOST on the Testnet but has never used ASICBOOST on the mainnet as implied in Gregory Maxwell’s proposal. We ask conclusive proof from whoever claims this to be false because such baseless claims are toxic for the Bitcoin space. We also believe the math used by Gregory Maxwell is incorrect and that the method is not practical in a production environment.

They also say that the chips they use for their miners have a circuit design that supports ASICBOOST...

  Our ASIC chips, like those of some other manufacturers, have a circuit design that supports ASICBOOST. However, the ASICBOOST method has not been used by us on the mainnet. We have not seen any evidence yet on the main net that anyone has used it in the patented way.

They even hold the patent in China for ASICBOOST...

  Bitmain holds the ASICBOOST patent in China. We can legally use it in our own mining farms in China to profit from it and sell the cloud mining contracts to the public. This, however profitable, is not something we would do for the greater good of Bitcoin.

And They say they don't use ASICBOOST on their mining farms...

  The mining equipment produced by Bitmain for its own use is in no way intended to be technically superior or more power-efficient than the equipment it sells to the public. The ASICBOOST method has not been employed by Bitmain to increase the power-efficiency of the miners in its own mining farms.

But they also say that whether ASICBOOST is used or not, they will continue to produce more efficient miners...

  Bitcoin mining equipment depreciates rapidly. Bitmain has constantly been introducing newer more efficient miner models for all. As such the statement that the deployment of ASICBOOST, which can lead to a 20% difference in power efficiency, is some kind of negative development for Bitmain’s business model is false. Bitmain has shown the ability to adapt and thrive in the constantly changing and extremely challenging Bitcoin mining environment. Whether ASICBOOST is used or not, Bitmain will continue to produce more efficient miners.

Given on how secretive Bitmain is and the nature of their business they could be using ASICBOOST but they also could be telling the truth and not be using ASICBOOST. Right now it seems that you can't use ASICBOOST on an s9.

Source:

Bitmain Blog


Block inventory messages I've written some code for connecting to the network, receiving inventories, and requesting data. What I am noticing is that my local node never sends me inventory messages with blocks in them unless I specifically request blocks.

So if I do a getblocks call with a zero stop hash I will get all of the blocks up to the tip, but never any inventory messages after that. Is there some kind of signalling necessary to tell the node i am connected to that I want inventory block messages to stream to me when new blocks are found?

I am connecting with protocol version 70002, relaybool is 1, nodeservices is 1.

I don't see other mentions of this issue so I'm wondering if there is a negotiation issue that isn't being caught or some other problem.

There is no visible ban score, connection is from localhost, I get a verack and normal tx inventory messages are streamed. This happens regardless of whether -whitelist is used. I just never get block inventory updates or unsolicited block messages unless I request blocks via getblocks. After I've retreived blocks up until tip streaming does not commence.

Update: The code has no problem syncing with a bitcoin-core instance on another computer, but the local bitcoin core instance will never send block inventories or respond to getheaders requests. Problem only occurs on localhost to localhost initated connections.

You need to issue a getdata on the last entry in the returned invs. This is used as trigger that you have processed the response, and the remainer will be sent automatically.

Note that since version 0.10, Bitcoin Core does no longer use the getdata/inv/getdata/block cycle to synchronize, but getheaders/headers (for synchronizing headers). Actual blocks are then fetched asynchronously from different peers after the headers are discovered.


Why is mining an important part of a digital coin? I have been playing with the blockchain lately and studying how Bitcoin works. I was wondering though, what is the functional reason for the mining process? I understand that you get a reward for mining, but you could implement that reward also in another way, or do away with it completely.

I first thought it would be to make the blockchain more tamperproof, because the mining will make it extra hard to change a block somewhere up the chain. But, using the signatures and the distributedness this is nigh impossible anyway.

So, why mine?

Why mine?

Money supply

It's a way of limiting the money supply in a decentralised system. You don't want anybody to easily create new money - no-one would trust a currency where anyone can make themselves a millionaire at whim.

Most of the conventional ways of limiting money supply require a central authority who manage the printing of banknotes and their destruction and a regulatory system that prevents banks declaring that they hold more money than they actually do.

Paying for transactions

An electronic payment system consumes processing resources to validate the transactions and to make the appropriate records available to anyone who needs them. There has to be some ways to pay for this.

In a decentralised system, both transaction fees and mining are ways in which this work gets paid for.


Nosey/disgruntled employees at my VPS company How can I take steps to prevent/detect bad employees stealing my money?

I'm running bitcoind on a VPS with Ubuntu 14.04. Only ports open are 22, 80 and 443. I have fail2ban and auditd enabled.

Anyone have any other practical tips?

The only real solution is to not keep private keys on that server. Keep them on a computer that only you can access, or offline in a paper wallet.

Encrypting the wallet will help somewhat, but a malicious administrator could log your passphrase when you unlock the wallet, or extract the decrypted private key from the server's memory.

If the server must have private keys (e.g. because it has to make payments), then your software should be designed to keep only the minimum balance necessary in the server's wallet, and sweep the rest to addresses whose keys you hold elsewhere.


Does all miners in mining pool increase the nonce variable one by one starting from zero? Let us consider we have n miners in our mining pool. Now the manager of the pool verified the transactions and packed into a block to be mined. Then it passed the block to all n miners in the pool.

Lets assume that out block is as below:

    to_mine_block = {
    Block No: 1000
    Prev Block:999
    timestamp: "1000-01-01 00:00:00"
    Data : "XYZ"
    nonce : ?
}

Now,to_mine_block is sent to all n miners. Will n miners runs the following code to

String target = new String(new char[difficulty]).replace('\0', '0');

while(!hash.substring( 0, difficulty).equals(target)) {
    nonce ++;
    hash = calculateHash();
}

Will all n miners run this code individually in the pool ? If so, this race will always be wined by the miners with the highest mining power. Because the one with highest mining power will move ahead in the loop than the ones with low hash power.

This is not how mining typically works in a pool. Mining software typically assigns a different extranonce to each miner, which is part of the coinbase transaction, and will result in a different merkle root (and different block header. Then they can all start on nonce 0 as you suggest, but they will not be racing each other for the same block because they are different. See https://bitcointalk.org/index.php?topic=9438.msg136344#msg136344.

Also, just for clarification, the data that is hashing during mining is the block header, which consists of:

Version
hashPrevBlock
hashMerkleRoot
Time
Bits
Nonce

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


Sent BTC to public key instead of my address Friend of mine was trying to buy BTC from ATM, instead of BTC address he scanned the public key from coinomi wallet (I dont know why the ATM accepted it, but it did). Is it possible to somehow access the BTC? Thanks!

Seems there is a little confusion here: are you talking about private keys or bitcoin address in form af a public key?

Anyway in coinomi wallet you cannot display any kind of uncompressed xPub or similar keys, so he should have sent the funds to a proper BTC address.

Otherwise he tried to send BTC to a private key but this should be impossible by protocol definition. Even if the BTM scanner somehow accepted a priv key as an input the software should recognize the issue and would stop the operation.


Is there a way to allow use of unconfirmed RBF outputs in transaction building? Bitcoin Core seems to not consider unconfirmed outputs that are marked replaceable in input selection. Is there a way to override this protection and allow use anyway? The transaction is created using bitcoin-cli.

Edit:
Turns out the unconfirmed output was not change but came from an external wallet. Bitcoin Core doesn't use unconfirmed external outputs.

Bitcoin Core will happily spend RBF marked inputs it doesn't avoid them much less prohibit them.

Perhaps you're being confused by the fact that it will not spend an unconfirmed input created by a third party? Or maybe you have spendzeroconfchange set off or only have long-chain unspents?


How does Zerocoin work? How does Zerocoin work?
I got the idea that it is used to add anonymity in bitcoin.
It converts bitcoin to Zerocoin and back to bitcoin. But how does this process work? I tried reading the research paper on Zerocoin, but the example provided is difficult to understand (for me).

  Imagine that all users share access to a physical bulletin board. To
  mint a zerocoin of fixed denomination $1, a user Alice first generates
  a random coin serial number S, then commits to S using a secure
  digital commitment scheme. The resulting commitment is a coin, denoted
  C, which can only be opened by a random number r to reveal the serial
  number S. Alice pins C to the public bulletin board, along with $1 of
  physical currency. All users will accept C provided it is correctly
  structured and carries the correct sum of currency. To redeem her coin
  C, Alice first scans the bulletin board to obtain the set of valid
  commitments (C 1 , . . . , C N ) that have thus far been posted by all
  users in the system. She next produces a non-interactive
  zero-knowledge proof π for the following two statements: (1) she knows
  a C ∈ (C 1 , . . . , C N ) and (2) she knows a hidden value r such
  that the commitment C opens to S. In full view of the others, Alice,
  using a disguise to hide her identity, 1 posts a “spend” transaction
  containing (S, π). The remaining users verify the proof π and check
  that S has not previously appeared in any other spend transaction. If
  these conditions are met, the users allow Alice to collect $1 from any
  location on the bulletin board; otherwise they reject her transaction
  and prevent her from collecting the currency.

One of the problems (or advantages) of Bitcoin is that funds can be traced. Even if each address is used only once, it is possible to link individual transactions to each other similarly to how it is possible to track bank notes by their serial numbers (with the addition that everyone records serial numbers of all the notes they handle).

Zerocoin solves this problem by providing a new kind of transaction outputs that are not linked to inputs that spend them. Actually, outputs are linked to inputs, but the link is cryptographically obscured, so that an observer can't find which input an output is linked to. However, it is still possible to check that there is only at most one input linked to any particular output, so that double-spends are not possible.

To obscure the link, a cryptographic construction is used which is called zero-knowledge proof. Zero-knowledge proof is a way to show that something is true without revealing any useful information. For example, a digital signature is a zero-knowledge proof that shows that the signer knows the private key. There is no way, however, to learn the private key from the signature.

Proofs used in Zerocoin are more complex. Basically, when generating a Zerocoin, a user picks a random serial number and includes a special irreversible function of that number in the output. When spending, he reveals the number and provides a proof that the number corresponds to one of the outputs. Only one serial number corresponds to each of the outputs, so double-spends are prevented by checking that each serial number is used only once.


Why Owner 1's Signature is in transaction #2, not #1 In Bitcoin, what is the Signature and why Owner 1's Signature is in transaction #2, not #1?

I'm implementing a demonstration of blockchain database. But I noticed that the Bitcoin whitepaper has many ambiguous things, such as what is a hash of previous transaction of the first transaction. But the hash problem seems to be resolved somehow. The problem is what is the signatures and why it exists in next transaction of its owner issued?

Owner #1's signature is required for Transaction #2 because Owner #1 at that point owns the bitcoin. It's being signed over to Owner #2.

Think of it this way, who signs a USD check where money goes from #1 to #2? It's always whoever owns the money beforehand.


What Do I Do? Unconfirmed Transaction For Almost 7 Hours :( Sorry if I'm acting like a noob. Never had a transaction take this long and it's worrying :/ It's been about 6-7 hours and still no confirmations. Do I just wait it out? Please help! :(

The transaction ID is
c3cfa18f21ab69dce87b269643cc841f0c16b7e69683afaad14a25d4b0740277

EDIT: My wallet will not synchronize now either...

Thanks

You can thank the China government and internet censorship for the recent blockchain issues considering the two largest bitcoin miners are in China.

I have payments from yesterday almost 18 hours that have not finalized so you are not alone.

It is the beginning of the end for bitcoin brotha better start learning Monero!


How do I set the transaction fee in Multibit? I can't see any options in View > Preferences nor on the Send tab!

I can't find any results in a DDG search!

The developers of Multibit have explicitly disabled such a feature to change the transaction fee, citing concerns that having little or very low transaction fees would result in the transaction taking too long to process (which is going to be unbearable for the average user only interested in sending and receiving money quickly).
From the GitHub issue originally submitted, the developer explains:

The reason for this is that whilst in theory it is possible to send BTC with zero fee in practice it is not. For the "regular user" (i.e. someone who just wants to use bitcoin and does not really know the details) their user experience is quite poor with zero fee tx. We have probably both experienced this with Instawallet (zero fees added) where you sometimes have to wait until the next morning before the miners decide to add your tx to a block.
It would create too much frustration to users (and too many support calls for me) to have zero fees.

Note: tx means a transaction.


How to get a wallet address and set label via RPC? I'm familiar with the basic RPC commands, but I'm having trouble retrieving/adding an address to a wallet, using purely RPC calls (i.e. bitcoind only, not bitcoin-qt).

My understanding is that addresses are associated with accounts, but I'm unsure what role "accounts" play, and how to create new ones etc.

In pseudocode, this is what I want to be able to do:

if (count(getAddressesByLabel("donations")) == 0) {
    address = wallet.createBitcoinAddress();
    address.setLabel("donations");
}

donationAddress = getAddressesByLabel("donations"))

You may have already read this, but make sure you read this if you want to know about how the accounts feature of the core client works: https://en.bitcoin.it/wiki/Accounts_explained. (It's somewhat of a legacy feature.)

Are you looking to be able to do this manually with the RPC methods, or automated?

For manually, do:

bitcoin-cli getaddressesbyaccount "donations"

If the JSON array returned is empty, then no address is associated. To create a new bitcoin address with that label, do:

bitcoin-cli getnewaddress "donations"

To get an address for the "donations" account, do:

bitcoin-cli getaccountaddress "donations"


ECDSA public key to private key hex I have an ecdsa public key how to get the private key of this public key;
0222d2deda24c03b2cc2b458c35780c62b6b5603c088709f17607b7ecf1399e4d7 how to solve this on python I am using Pydroid 3 on my mobile any sources to do this any code for this and also tell me how to do this on termux not random entering public key and finding private key hex can any body can help me

There is no math that would get the private key from a public key. That is the whole point of the Elliptic-Curve Cryptography. You can always get the public key from a private key, but not the opposite since this would mean that anybody could spend the Bitcoins of anybody and Bitcoin itself would be worthless.


Is "Reclaiming Disk Space" already implemented? How effective will it be? Some people are concerned about the scalability of Bitcoin. The blockchain already has reached nearly 1 GB to download and store, which is not exactly in the spirit of a modern thin client, especially in regards to mobile devices.

Now when consulting the Satoshi Paper, it seems they already came up with a solution:

  7. Reclaiming Disk Space

  Once the latest transaction in a coin is buried under enough blocks,
  the spent transactions before it can be discarded to save disk space.
  To facilitate this without breaking the block's hash, transactions are
  hashed in a Merkle Tree [...], with only the root included in the
  block's hash. Old blocks can then be compacted by stubbing off
  branches of the tree. The interior hashes do not need to be stored.

  A block header with no transactions would be about 80 bytes. If we
  suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365
  = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
  1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Is this already implemented for the current version? "4.2 MB per year" suggests that no. Is it already on the roadmap? Have the developers met any unforeseen obstacles? Will the solution be as effective as promised?

The blockchain already has reached nearly 1 GB to download and store,

The proposal in Satoshi's paper does not reduce the download requirements, only the storage requirements (see this post to the bitcoin-dev mailing list).  Unless you are able to rely on some trusted third party, you still need to download at least all of the block headers.

If you download only the headers and not the full blocks and treat "buried X blocks deep" as proof that a transaction is valid you are open to a new class of attacks that would not affect a normal full-chain client.  The normal client treats "buried X blocks deep" as proof that a transaction will not be reversed later on -- the check to ensure that the transaction's inputs are unspent is completely separate from this.  A thin client cannot check that a transaction's inputs are unspent because it has only the block headers -- it does not have a copy of the transactions themselves.

The most worrisome of these new attacks have to come from your ISP, but in this day of wi-fi cafes that isn't such a far-fetched scenario.  So, use at your own risk.

I've been picking away at a wiki page dealing with all these issues.


Is there a way to undo transactions with a "too low" fee? Suppose we reach a state where only transactions that pay a fee are accepted by miners. Further supposed that someone created a transaction using an old/odd client that allowed them not to send any fees.

In this case, what would happen to the transaction? Could it be undone? Would the coins be lost forever?

The transaction would have no effect. A transaction that wasn't accepted by the network has no effect on the ability to spend coins. The person whose coins were affected could simply delete that transaction from his own database. There's no need to undo the transaction since it was never committed to the block chain anyway.


Can I long USD/BTC instead of shorting BTC/USD? Let's say that I think that bitcoin has hit a peak. I want to short bitcoin, but in a far less risky way. In order to do this, I want to go long on USD/BTC. Let's say (as an example) that I longed this pair when Bitcoin was $13,250 (on the dropping side, I set that as strike price), and sold it when it was $8,000 and going up. I would have made a 65% return as opposed to a USD/BTC short of just under 40%. I want to do this to be able to make a higher profit during a bear market. I feel that this is a good idea.

The question is, to clarify: can I long the USD/BTC pair? This pair is equal to one divided by the USD price for one bitcoin. I think it is good because it offers an alternative to shorting, one with a theoretically unlimited upside and a limited downside. If one bought $250 worth of bitcoin at $100 and sold the position at $6,000 in the beginning of November of 2017 or 2018, it would have brought $4.50 as opposed to a theoretical owed amount of over $14,000.

As a commenting individual in the comments said, this move could have theoretically brought (and maybe has brought) very high returns. Even going back 1-2 years ago (roughly speaking, as of writing), such a move timed at the right time could have brought 500% or more returns depending on how good timing the trader had.

Long USD/BTC is the inverse of short USD/BTC, which is identical to short BTC/USD.


Moving Bitcoin-QT's location I have bitcoin-qt installed on my Ubuntu box which has an SSD as the main OS drive.

I understand that bitcoin-qt is a full client/node and uses a lot of disk activity, which is why I want it off my expensive SSD and want it on my cheaper HDD.  How do I move the client so all the node checking work it does which is disk intensive is done on the secondary HDD instead of the primary SSD?

I have Ubuntu 12.04 installed.

UPDATE:

I just edited the file:

/usr/share/applications$ sudo gedit bitcoin-qt.desktop

and changed:

Exec=/usr/bin/bitcoin-qt %u

to

Exec=/usr/bin/bitcoin-qt -datadir=/new_location/.bitcoin %u

I have just tried loading bitcoin-qt and it currently says Rescanning.

Have I made the changes correctly?  It's been scanning for 5 minutes now...

Use the -datadir option to specify a new location for the bitcoin data directory.  Copy the existing bitcoin data directory to the new location and then restart bitcoin-qt.  Check here for information on locating the default data directory.


Lightning network explaination (bidirectional channel funded by one party) Let's say Alice and Bob want a bidirectional lightning channel with common 2-2 multisig address C.

Alice is the only one putting funds in, say 100BTC. They agree on nLock of these funds to be 30 days (channel will be open for 30 days). This requires Bob to sign and give Alice a refund transaction with nLock 30.

Now during next 15 days Alice pays Bob 10 BTC three times, each time giving him a signed transaction with respective outputs 90Alice-10Bob (on day 5) 80Alice-20Bob (on day 10) and 70Alice-30Bob (on day 15).

If Bob wants to close the channel he needs to sign 70Alice-30Bob transaction and broadcast it. And these 3 transactions don't need to have nLock. (unidirectional channel)

But instead Bob wants to pay Alice 10 BTC (on day 20). So he makes and signs a new transaction 80Alice-20Bob and gives it to Alice. They leave the channel open for more transactions.

Which of the above transactions need to have nLock and with what value?

From what I understand, Lightning does not use absolute timelocks (nLockTime) for single payment channels.

The task of implementing a bi-directional channel is equivalent to the task of invalidating old states (i.e., preventing them from being broadcast to the blockchain). In Lightning, if Alice wants to update the state, she must first sign a "Breach remedy transaction" (BRT). Moreover, the party who initiates closing the channel by broadcasting some channel state must wait before being able to withdraw their funds (implemented with a relative timelock). Putting this all together, if Alice tries to cheat and broadcasts an old state (trying to withdraw more money than she is entitled to), Bob has time to broadcast his BRT and claim all funds in the channel.

Answering your question, none of the transactions inside one channel have nLock. The paper and a wiki page provides more details.


Which exchanges support U2F authentication? I got myself a nice security key (Yubico Fido) today, which utilises the U2F protocol. But to my surprise not a single Bitcoin exchange seems to support this yet, only Google itself.

So which Bitcoin exchanges (plan to) support U2F?

As you have correctly noticed none of the Bitcoin exchanges have implemented the FIDO standards there is not a large demand for this feature from what I gather.  If the standard were to gain mass adoption and many users began requesting it I'm sure it would become a greater priority for exchanges to implement.

As a side note the Ledger hardware wallet does support the U2F standard and would be a great way to improve the security of your wallet (as long as you don't connect the two to each other (i.e. same keychain)).


What are the bandwidth requirements of a mining rig? How much bandwidth consumption can I expect per 900 Mhash/s rig (for instance) for both pooled and solo scenarios? I'm looking for a ballpark number for the on going requirements, after the initial blockchain download.

With pooled mining, at 900Mhash/s, you'll need a new work unit every 3 seconds or so. Each work unit requires about 256 bytes out and about 768 bytes back. So that's 700 bits per second out and about 2,000 bits per second back. Essentially, zero.

Solo mining is a bit harder to estimate. You will need to receive and relay all new blocks as they are discovered, you will need to receive all transactions that are relayed by nodes you connect to. You can heavily limit the number of other nodes you are willing to connect to, but this will impact your stale shares level and may reduce your transaction fee income.

I measured the bandwidth usage of the client with 60 connections (you can drop down to 8 if you want) and made sure my sample included discovering a block. The inbound average bandwidth was 12Kbps (1.50 KB/s) and the average outbound bandwidth was 9Kbps (1.04 KB/s). So that should give you an idea what solo mining would be like.

Notice that the bandwidth usage is basically insignificant in both cases.

For multiple rigs, there is no adjustment in the solo mining cases. All the rigs can be configured to query the single client. The client's bandwidth requirements will be the same.

However, there is a change in the pool mining case. When a new block is discovered, each miner will need a new work unit immediately since its existing unit is stale. This happens on average about every 10 minutes. Effectively, increase the bandwidth requirements by .5% for every additional mining rig. Note that if you run more than one instance of the mining program on a rig, count it as more than one rig. (This still assumes the rigs total 900Mhash/s.)


How multiple unfinished payments in single LN channel work? I think I understand HTLCs, at least if they are on chain. I also have a basic understanding of how off chain channel looks like.

I understand it as follows. It is a 2-of-2 multisig transaction output, which is on chain and confirmed sufficiently. Before this transaction was put on chain, the parties created another transaction, which they haven't published yet. This second transaction is necessary in case either party would not be cooperative to provide its signature for the initial multisig.

This second transaction pays each party the agreed final balance as per current status of the channel. This transaction is ready to go on chain, it is fully signed, the parties just decided not to publish it yet because they may want to replace this second transaction with different finalising transaction.

Now the question is – When a payment is to be done through this channel using HTLC, what are the inputs to it? Is the output of the original multisig? If so, how would you do 2 or more HTLCs at the same time (i.e. you have enough liquidity on the channel to do multiple payments, but it takes time to finish current payment when someone wants to pay through you again)?

What would be the inputs for those other HTLCs? Exactly when is the finalising transaction spending the initial multisig updated in the database of the participants?

And would you need to close the channel and put a transaction on chain in case a single HTLC payment fails?

The htlcs are just an additional output in the commitment tx which spends the funding transaction (as you described)

So assume Alice and Bob have a channel of capacity 0.1 BTC in which alice owns 0.03 BTC.

On chain you have a multisig wallet that has 0.1 BTC and offchain you have a commitment tx with two outputs.

0.03 to alice
0.07 to Bob

Let's assume Bob wants to pay Alice 0.015 BTC or wants to forward an htlc through Alice of the same amount a new commitment tx is negotiated (by which the old one is invalidated) that has 3 outputs

0.03 to alice
0.055 to bob
0.015 htlc clsimable by Alice if she can show a preimage within a Timelock and afterwards by bob

Now if routing is successful alive provides the preimage and a new state is negotiated in which the htlc output is removed but added to slice balance resulting in

0.045 to alice
0.055 to bob

Otherwise the htlc is removed but the amount is added to bobs output.

I omitted onchain fees for simplicity


Is it possible to combine two separate transactions into one transaction by only using their signatures? I have two valid txs and two valid signatures for those txs.

Right now they look like:

1) A -> B
2) C -> D

A and C are inputs & B and D are outputs.

I want to be able to combine them into:

1) A, C -> B, D

Is there a way that I can combine these two tx's and their corresponding signatures into one valid tx without having access to the keys?

The only possibility in Bitcoin today is the one described by kaykurokawa. Every signature specifies which inputs and outputs it signs for, so if you want independently-created signatures, it will be obvious to everyone which input and output were created simultaneously.

The general practice of combining multiple pieces of transactions into one is called CoinJoin. It works well in theory, but it does require the different parties to cooperate (each signs everyone's inputs and outputs).

A potential future development that could change this is, is based on One-Way Aggregatable Signatures (OWAS) (see the paper on https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf originally posted anonymously on https://bitcointalk.org/index.php?topic=290971.0). This mechanism would allow anyone on the network to take two transactions and CoinJoin them, without being able to tell afterwards which inputs and outputs were related. As a side benefit, it also combines all signatures in such transactions into one. Taken to the extreme, it would mean that a block can just be reduced to a single transaction, constructed by miners applying this joining operation on all transactions they want to include.

Unfortunately, OWAS relies on a signature scheme called BLS, which is much newer and not as well studied as ECDSA (which Bitcoin uses now), so its security is less certain. Furthermore it is far slower, and would need very invasive changes to Bitcoin. It is an active area of research, though.

More recently, a system called MimbleWimble has been proposed which supports offline transaction aggregation as well as cut-through transactions while only relying on EC cryptography.


Is it possible to execute a CLTV transaction in bitoin core 0.11 console? The title says it all. How can one perform a op_checklocktimeverify transaction using bitcoin core? I've searched around and I've found a few repo's on github but nothing about how to do it in the console. I was thinking it would be something that you would just tack onto the end of a raw tx like this:

createrawtransaction '[{"txid":"","vout":}]' '{"receive_address":0.02}' '{"op_checklocktimeverify":desired_block_height}'

OP_CHECKTIMELOCKVERIFY is implemented as of Bitcoin Core 0.11.2.

This release supports a soft fork to enable CLTV (BIP 65).  CLTV is part of version 4 blocks.  Once 951 blocks are mined with version 4 blocks, then the soft fork is complete on only version 4 blocks are valid from this point on.

You will need to construct the CLTV transaction using other software.  Here is an example that requires bitcore (NodeJS):

https://github.com/mruddy/bip65-demos


I live in viet nam and I want to buy bitcoin. How would I do that? I would like to buy bitcoins in viet nam. How would I do that?

I would say try https://localbitcoins.com
You can buy from other people in your area/country.


Can bitcoin transaction data be used to study markets? The nice thing about bitcoin is that it generates partially anonymous data about every single transaction. Can this data be used to gain insight about real-world markets? Or are there some fundamental differences that cannot be accounted for? If this data can be used, does anybody have any references on academic papers that use the bitcoin data?

There are no academic papers on Bitcoin market behavior.

If Bitcoin or another peer-to-peer currency ever develops a significant closed economy, then it would be a rich source of information on the behavior of markets and economies, as the transaction timing, value and locations (for both the sender and receiver in a transaction) of Bitcoin transactions is publicly broadcasted -and in the case of timing and value, already being recorded in the block chain.

Furthermore, information about the full Bitcoin transaction history of each pseudonymous individual can be deduced through network analysis techniques.

While Bitcoin is reserved for niche use and doesn't form a closed economy though, the data from the transaction history is of limited use for studying real world market and economic behavior.

Also, in the future the visibility of Bitcoin transaction data could be reduced if many participants in the Bitcoin economy begin to rely on private layers built on top of the Bitcoin network to conduct their transactions through, which is likely to happen given the implications for privacy that visible transactions create.


Tutorial on how to import a paper wallet into blockchain.info and send a transaction with message attached then delete it? Is there an API call on using the blockchain.info api on how to import a paper wallet and then send a certain amount of funds with a note attached?

Looking for just a sample code of how to do this via the blockchain.info api. Do I need an api key? As I was able to do other functions without an API key it seems.

I have the following api call:

http://127.0.0.1:3000/merchant/7a42f805-3132-4c3f-a6bf-xxxx/new_address?priv=5K1Y8iHsXHzLo4HUhURCdMrdzmrL5nomWKJqqp7cNxxxxx&label=mynewaddress&password=xxxxx

but it doesn't import that private key. It creates a totally new address. The priv setting seems to be ignored. I'm not sure what other api call is there in order to do an import.

I know it's a few months since you've asked, but just in case someone else is looking for it. If you have a paper wallet, the easiest thing is to import it into a desktop wallet, and from there you can send your BTC to someone or to an exchange or to another wallet, like the one on blockchain. Some online wallets allow importing the private key but the one on blockchain doesn't seem to - at Least I haven't found a way after looking around.


it is any command line to check the ammout of coins willl be create after build the wallet? it is any command line to check the ammout of coins willl be create after build the wallet?

i just cloned bitcoin and changed the ammount of coins to be 10 million

MAX_MONEY = 10000000

so i would like to know if it is any command to check this value I inserted.

i know i can check
the amount in circulation using the RPC call gettxoutsetinfo

No, there is no way to display the value of this constant. However, I am not sure that this constant is really doing what you want to do, so let me explain its meaning.

The constant MAX_MONEY is the maximum amount that can appear in an individual bitcoin transaction, for instance in tx_verify.cpp in CheckTransaction. Here, actually two checks are done:

The amount in each transaction output is checked against this value
The total across all transaction outputs is checked

So you could theoretically check that your new value is used after a recompile by submitting a transaction violating these constraints and wait for the error message.

However, what you actually want to do (if I read your question correctly) is to increase the total amount of bitcoin that can be mined. This number is not directly hardcoded, but the limit results out of the fact that every 210000 blocks, the subsidy, i.e. the amount of BTC that a miner earns in addition to the transaction fees for mining a block, is halved. This is done in GetBlockSubsidy in validation.cpp, using the parameter nSubsidyHalvingInterval in chainparams.cpp. Thus if you want to change that value (destroying consensus), you would have to make changes at these locations in the source code.


How can I import a private key into the Bitcoin client? I have a private key and I want to add it to the keys in the Bitcoin client.  Is there an easy way to do this?

Importing could be done with Pywallet or hopefully soon-to-be-official wallet export/import bitcoin patch, but make sure to backup your wallet first.


Would fees go down once more people start using segwit addresses for day to day activity? Since the fees are high today, when more wallets and people start using segwit (bc1) addresses. Would sending from legacy address fees go down as everyone is using the newer address? Or it doesnt matter?

Transactions which spend from segwit outputs (i.e. "send from" segwit addresses) will have less weight (as in block weight) than transactions which spend from non-segwit outputs. This means that to reach the block weight limit, blocks will need to include more transactions. This effectively means that there will be more block space for more transactions. Since more transactions can be included per block, the transaction fees in general will decrease.

So yes, when segwit is widely deployed and if it is used in all transactions, the transaction fees will likely be lower.


Shortest and Longest block interval time ever recorded in Bitcoin Bitcoin block interval time is on average 10 minutes, that is the difficulty is adjusted in such a way that every 10 minutes a miner will manage to find the right hash. This is just an average time though, the actual distribution for time confirmation is Poissonian.

What is the shortest and longest block interval ever recorded in Bitcoin?

(This data is current through block 535276.)

Based on block timestamps (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1.  The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and 15324.

For "shortest", since timestamps are not strictly enforced and can be fudged accidentally or intentionally, it is possible for a block to have an earlier timestamp than its predecessor, by up to 2 hours (7200 seconds), in which case the time difference is negative.  This has happened 13828 times.  The most negative difference is −7125 seconds (1 hour 58 minutes 45 seconds) between blocks 156113 and 156114.

There have been 222 blocks with the same timestamp as their predecessor, giving a difference of 0.

The script I used to gather this data is at https://github.com/neldredge/bitcoin-blocks.

Actual block intervals are hard to know precisely, since we have no way of knowing for sure the actual time at which each block was mined.  Some sites like blockchain.info record the first time at which their node received the block, but there is an unknown propagation delay between the time a block is actually mined and the time at which some other node receives it (though for a well connected node it is probably not much more than 1 second).  It is also possible to receive blocks out of order, so the difference in receive times could also be negative.  Moreover, such data is obviously not available for early blocks before the existence of the site in question.

In principle it could be possible to look for the longest and shortest difference between receive times, but I don't know how to retrieve that data in bulk.


In which order does the leveldb iterator iterate over utxos? I would like to know in which order the leveldb iterator iterates over the chainstate entries. I aim to serialize the chainstate and have to make sure that every node can calculate exactly the same serialization (to compare its hash afterwards).

The LevelDB iterator iterates through the keys in lexicographic order. From the docs:

  The preceding examples used the default ordering function for key, which orders bytes lexicographically. You can however supply a custom comparator when opening a database. For example, suppose each database key consists of two numbers and we should sort by the first number, breaking ties by the second number.

However, I am not sure that relying on the iteration order of one particular DB is what you should be using, since every other implementation would have to reproduce that iteration order for compatibility. So you would need to require a canonical ordering anyway, which can be implemented using comparators.


Create a raw transaction and broadcast it to blockchain using bitcoin core I have a address- n3xYQtxvVwpBPSbgGsGRdMWz1YTUjakiMV, amount  that i want to send-1 BTC and i have a private key. How can i create a raw transaction using it and broadcast it to blockchain using bitcoin core.

I have tried this command:

bitcoin-cli createrawtransaction '[{"txid":"dbdc2e2c7f143af70c5e7e8725f55d226b3c058d7bf34a303091b3c6a514848c","vout":1}]' '{"n3xYQtxvVwpBPSbgGsGRdMWz1YTUjakiMV":1}'

and this: bitcoin-cli sendrawtransaction XXX

EDIT: based on OPs request, I put examples in here:

there are a lot of examples for different tx types on bitcoin.org, in the developer examples. Basically you will need three steps. Assuming you are on OpenBSD/MacOS/Linux, you can go this way:

1.) createrawtransaction - this is what you have already, and it looks ok. I don't know if the previous tx ID or v_out is correct, assuming you know the details, your string is ok (otherwise check with "bitcoin-cli -regtest listunspent", and adopt TX_ID and V_OUT accordingly). I also assume, that the address is one which is in your wallet. Otherwise you might just create an address, and proceed afterwards like this:

UTXO_TXID=dbdc2e2c7f143af70c5e7e8725f55d226b3c058d7bf34a303
UTXO_VOUT=1
NEW_ADDRESS=n3xYQtxvVwpBPSbgGsGRdMWz1YTUjakiMV
bitcoin-cli -regtest createrawtransaction '''
    [
      {
        "txid": "'$UTXO_TXID'",
        "vout": '$UTXO_VOUT'
      }
    ]
    ''' '''
    {
      "'$NEW_ADDRESS'": 1
    }'''

you provide this returned hex string to another variable:

RAW_TX=01000...

2.) signrawtransaction - the previous command returns a hex string, that you will use to sign the transaction - again, see the docs. First I verify my created tx, and then sign:

bitcoin-cli -regtest decoderawtransaction $RAW_TX
bitcoin-cli -regtest signrawtransaction $RAW_TX

again you assign the result to a variable:

SIGNED_RAW_TX=01000...

3.) sendrawtransaction - again you take the hexstring of the previous command as parameter, and/or see the docs.

bitcoin-cli -regtest sendrawtransaction $SIGNED_RAW_TX

and maybe a verification as step 4:

bitcoin-cli -regtest generate 1

this generates a block, and you can see on the $NEW_ADDRESS, if funds have been transferred.

I just entered the two keywords here in the search function, and also found a lot of answers.


How do I know my wallet.dat actually already contains 100+ addresses ready to be used? I'm using the standard commandline client (under OSX, in case this matters).

I've read in some threads that it is smart enough to pregenerate 100+ addresses to be used in future when you ask them, so that if you backup an earlier wallet, the future private keys are not lost.

This would be cool, but how do I check it is really true?

Every time I "get a new address", it seemed to me it took enough time to suspect it was generating it on the fly, not using it from a pregenerated pool. Maybe it was slow for other reasons, though, and that's why I'd like to check somehow.

you can check by directly exploring the content of your wallet.dat file, which is a bdb database. there are various tools for exploring the wallet, one of which is gavin's bitcointools: https://github.com/gavinandresen/bitcointools

Another exporter is pywallet.py.


Calculate BitcoinGold Block Header Hash I am trying to calculate block hash # 632295

{
'version': 536870912,
'prev_block_hash': '000000017590609fd72cadc5fd05732cfa1760bd882213afbb7b788c42e115c8',
'merkle_root': '20e8e04b62d9cd21dbcee23e445fda60a07bc5785a0a2b0b419227c6a2ec936a',
'reserved': '00000000000000000000000000000000000000000000000000000000',
'timestamp': 1588602316,
'bits': 486818083,
'nonce': '0085c0dd0000000000000000000000000000000000000000000000000106002e',
'solution': '441cf79198cc4b0fb4dd5f9fa7be645adc4197ff655b555d4139051c9d7b82419f4824f055a5c993390569681ac67061ce041776751d6d72129c18e446dd31d4cc1e78e5d7b4ba440b1d188caffe6da433f73d9d53cfefc36505da3b9270521650a6930064',
'height': 632295
}

This is what my code for calculating the hash for Bitcoin looks like, but it does not work for BitcoinGold.

block_array: List = list()
block_array.append(struct.pack('<L', block['version']))
block_array.append(bytes.fromhex(block['prev_block_hash'])[::-1])
block_array.append(bytes.fromhex(block['merkle_root'])[::-1])
block_array.append(struct.pack("<L", block['timestamp']))
block_array.append(struct.pack("<L", block['bits']))
block_array.append(struct.pack("<L", block['nonce']))

header_hex: bytes = bytes.join(b'', block_array)
hash = double_sha256(header_hex)

Next, I turned to the documentation:
https://github.com/BTCGPU/BTCGPU/wiki/Technical-Spec

This suggests that I need to add 3 more fields:

  nHeight, nReserved,nSolution

I believe that the code should look like this for bitcoingold:

block_array: List = list()
block_array.append(struct.pack('<L', block['version']))
block_array.append(bytes.fromhex(block['prev_block_hash'])[::-1])
block_array.append(bytes.fromhex(block['merkle_root'])[::-1])
block_array.append(struct.pack("<L", block['height']))  # 632295
block_array.append(struct.pack("<L", block['reversed']))  # 0
block_array.append(struct.pack("<L", block['timestamp']))
block_array.append(struct.pack("<L", block['bits']))
block_array.append(struct.pack("<L", block['nonce'])))
block_array.append(struct.pack("B", block['solution']))

header_hex: bytes = bytes.join(b'', block_array)
hash = double_sha256(header_hex)

But this does not work, because nonce is not int.

As a result of executing the code, should get this hash:
00000003dd91f04483e990a1ecc5176abdfb18f40ae2ca6b0d203127bc150998

How to convert "nonce" and "solution"?

It is resolved.

block_array: List = list()
block_array.append(struct.pack('<L', block['version']))
block_array.append(bytes.fromhex(block['prev_block_hash'])[::-1])
block_array.append(bytes.fromhex(block['merkle_root'])[::-1])
block_array.append(struct.pack("<L", block['height']))  # 632295
block_array.append(bytes.fromhex(block['reserved']))  # 0
block_array.append(struct.pack("<L", block['timestamp']))
block_array.append(struct.pack("<L", block['bits']))
block_array.append(bytes.fromhex(block['nonce'])[::-1])
block_array.append(bytes.fromhex(block['solution'])[::-1])

header_hex: bytes = bytes.join(b'', block_array)
hash = double_sha256(header_hex)

Fun

def double_sha256(bytes_str: bytes):
    result = sha256(sha256(bytes_str).digest()).digest()
    return result[::-1]  # little endian


Is pruning transaction history implemented in Satoshi's bitcoin client? The original bitcoin paper suggests a method to discard old transactions. One should compute the Merkle Tree of the entire transaction history, and store only part of the tree.

However, I didn't notice this method implemented. BuildMerkleTree stores it in memory only, and seems to assume you're holding all transaction history, and the serialization method stores the actual transactions and does not store the Merkle Tree.

Is that implemented? Can you give me a reference to where is it in the code?

If not, is it planned for a specific future release?

Since Bitcoin Core v0.8.0, the validation database ("chainstate" or "UTXO set", or "account balance sheet") is separated from the blockchain. When a new block comes in, its effects (removing spent inputs, and adding outputs) are applied to the database. This means blocks are still downloaded and verified like before, but they aren't used for validation anymore afterwards. Blocks are still stored on disk in order to send them to other nodes that are synchronizing, or to rescan for old transactions.

Since Bitcoin Core v0.11.0, it is also possible to run in a true pruned mode, where the blocks on disk are actually deleted after a while. Since v0.12 it is possible to use the wallet while running in pruning mode. Since v0.14 it is possible to manually prune (by issuing an RPC command rather than have the application decide).

Note that neither of these mechanisms rely on the mechanism described in the Bitcoin whitepaper.


Will an approved Bitcoin-like system replace Bitcoin? What is the chance of another Bitcoin-like currency system to replace Bitcoin? Will Bitcoin still coexist with such systems? Will it affect then-current Bitcoin exchange rate?

By Bitcoin-like, I mean, government and banks approved, more privacy, some other means of mining, special purpose (only to buy cars), with different benefits, etc.

It's near certain that other Bitcoin-like currencies will continue to be introduced from time to time. Some of them will likely gain some traction.

Over time, more and more deficiencies of Bitcoin will become apparent and newly-designed competitors will be able to fix them. While Bitcoin can certainly make some changes, it will always have a trade-off because significant changes risk shaking to confidence of current users. At some point, Bitcoin's accumulated deficiencies will be too much and it will lose significant share to some competitor.

Of course whether that will be next year or next century, I don't think anybody knows.

Some such systems will likely coexist with Bitcoin without much interaction. Others may design in interaction with Bitcoins directly into their fundamental design. Nobody has a crystal ball though.

Some have imagined high-speed, high-volume systems that would move Bitcoins outside the regular blockchain with the existing Bitcoin system used only to "settle up" large transfers between smaller, faster systems. Will that be what happens? Who knows?


How can I protect my privacy? Let's say I want to send BTC to a friend. This friend can now explore the blockchain and find how much money I have or what other purchase I've done or will do. What can I do in order to prevent him from being able to do that or see all of that information? Will changing my public key help, or can he figure out that all the keys belong to the same wallet if they are used in the same transaction?

The simplest way is to not reuse addresses, something that wallets do by default anyways. Every time you want to receive Bitcoin, get a new address from your wallet and give that to whoever is sending you Bitcoin. You typically do this by going to the "Receive" page or tab in your wallet and clicking "Receive Bitcoin" (or similar). By doing so, the sender will not know how much money you have in your wallet and they won't be able to see all of your transactions.

When you send Bitcoin, you should also use new change addresses every time. This is the default behavior in wallets so this is not something you need to do manually or worry about.

By not reusing addresses, it is harder to link your transactions to you and it makes it more difficult for everyone you transact with (both receive and send) to know how much money you have and who you are sending money to or receiving money from.


ECDSA signature with r value of 31? occasionally on Android we are generating an ECDSA signature. This turns out to have a "r" length of 31 bytes. Is that valid?

For reference here is a nice diagram outlining the ASN.1 structure of such a signature:

how do you figure out the r and s out of a signature using python

Best regards, Rene

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

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

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


Does bitcoin-wallet support BIP148 Does anyone know if bitcoin-wallet on Andriod (https://github.com/bitcoin-wallet/bitcoin-wallet) supports BIP148?

I've been Googling and checked their GitHub page but I can't find BIP148 mentioned anywhere.

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


how to generate a bitcoin address for each user that registers I'm working on a marketplace type website and i want a bitcoin address to be generated for each user that registers an account. this needs to be done in php with no javascript

If you're running your own Bitcoind for JSON RPC calls via PHP then you can generate new address for each of your customers by this JSON Call command in PHP like this:

echo $wallet->getnewaddress();

This will echo the new address and stores it in wallet variable. Please refer to this doc https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

I hope this helps.

Thanks


Reproducible Gitian Builds .. but not the same hash as bitcoincore.org Bitcoincore.org and Bitcoin.org will let you download a tarball for bitcoin v0.20.1
When they do it
bitcoind:
4ec74161b2a90293926ae8e20a2efbe952bd23b53aeebf051e6a6285ace18271
bitcoin-0.20.1-x86_64-linux-gnu.tar.gz:
376194f06596ecfa40331167c39bc70c355f960280bd2a645fdbf18f66527397
They also say:

reproducing a binary for yourself will provide you with the highest
level of assurance currently available

So, it seems like the current method to do this is the "gitian build" maneuver.
When I do it
bitcoind:
c5fb850ed9e6afa0af5653e743084912c9bd71fb233acfe2d72738fc319f2181
bitcoin-0.20.1-x86_64-linux-gnu.tar.gz:
277599356bd2df760832c6636797fe5ea5a5c28d929d53635b685f5ac1e4689b
Went through the gitian process with Ubuntu 20.04 and Debian 10.
Both produced the same incorrect? tarball, 2 different setups/ 2 Operating Systems, same tarball.
Both my assert files are uploaded here for Debian and Ubuntu.
https://github.com/miketwenty1/images/tree/master/bad_asserts

As a pleb I can think 1 of 2 things..
Something is wrong/off with some of my packages / versions / env / OS / setup OR, All the verifiers are lying and bitcoin's been compromised. Help me narrow down the possibilities.
I would like to go through this exercise properly and reproduce the same binaries.. but unsure of the best way forward.. what are the next steps to verifying the build for v0.20.1? I can't seem to reproduce the tarball advertised on bitcoincore . org and bitcoin . org. I can however make a reproducible build which makes me question a lot of things.
Would love if someone could go through their process from scratch and see if they can produce the same tarballs seen in this repo by these people. https://github.com/bitcoin-core/gitian.sigs/blob/master/0.20.1-linux /*/ bitcoin-core-linux-0.20-build.assert's.
And share their complete process with me. After reproducing myself I would be happy to make a current walkthrough on the method and update the Docs, which (links below) are dated and broken for nearly all methods.
NOTE: If this is indeed the defacto way to currently do reproducible builds.. it would be nice to have documentation that is precise and current. I understand Ginx is something being worked on.. but would be nice to have a current doc in the interim for people who wants to verify builds. I would also be very satisfied if someone pointed something I was missing.
reference links:
https://gitian.org/
https://github.com/bitcoin-core/docs/blob/master/gitian-building.md
https://github.com/bitcoin-core/docs/tree/master/gitian-building
https://github.com/devrandom/gitian-builder/blob/master/README.md
https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-build.py
reference github issue
https://github.com/devrandom/gitian-builder/issues/235

I've done a rebuild of 0.20.1 and I get the same results that you do. This would indicate that a build dependency has updated to produce slightly different results than the version that was in use at the time of the release. The build dependency versions are pinned unlike the actual software dependencies. IIRC this is common for gitian builds and attempting to rebuild even older releases will result in similar mismatches.
There is ongoing work to move to a different reproducible builds system called guix. This build system will pin the exact dependency versions, along with the option to build the entire toolchain from scratch. This should enable fully reproducible builds that can be replicated at any point in time.

Here is a more in depth explanation of this particular mismatch, copied from my response in this GitHub issue.
If you look at the gitian build results, you will see a file named bitcoin-0.20.1-x86_64-linux-gnu-debug.tar.gz. If you untar this file, there will be *.dbg files, e.g. bitcoind.dbg and bitcoin-qt.dbg. These *.dbg files contain the debug data for their respective binaries, i.e. bitcoind.dbg contains debug data for bitcoind.
To ensure that you use the correct dbg file with the correct binary, gcc embeds a checksum of the dbg file within the binary itself. This means that bitcoind contains a checksum of bitcoind.dbg. This is to prevent attempting to debug bitcoind with another dbg file. For example, if you attempted to tell gdb that the bitcoin-qt.dbg file contained the debugging symbols for bitcoind, it would detect it does not and not attempt to load debugging symbols from bitcoin-qt.dbg.
The debugging symbols are initially compiled into the bitcoind binary, but later during the gitian build these are removed and placed into the bitcoind.dbg file. However because they are compiled into bitcoind initially, the debugging symbols have an effect on the build id that gcc embeds into the binary. The build ID is a hash of the compiled binary, including the debugging data.
So the end result is that the published binary contains two commitments to the debug symbols, but does not actually contain them itself.
You can read more about these separate debug files here: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
The crux of this issue is that the debug symbols from recent gitian builds differ from the debug symbols that were generated for the original release. This means that both the build ID and the debug symbol checksum that we find inside of bitcoind are different. This then results in the bitcoind hashes being different (as well as all of the other binaries). And of course that causes the tarfile hashes to be different.

Here is the diff of the binaries that diffoscope generates:
--- bitcoind
+++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind
├── readelf --wide --notes {}
│ @@ -1,15 +1,15 @@
│
│  Displaying notes found in: .note.ABI-tag
│    Owner                Data size     Description
│    GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)        OS: Linux, ABI: 3.2.0
│
│  Displaying notes found in: .note.gnu.build-id
│    Owner                Data size     Description
│ -  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 6b464617f7f91fd270ac86f43ef4a58eeeedff19
│ +  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 3a439a31a5157ff7052ed310050df5643a02ea3f
│
│  Displaying notes found in: .note.stapsdt
│    Owner                Data size     Description
│    stapsdt              0x00000036    NT_STAPSDT (SystemTap probe descriptors)        Provider: libstdcxx
│      Name: throw
│      Location: 0x00000000006e550d, Base: 0x000000000086d140, Semaphore: 0x0000000000000000
│      Arguments: 8@%rdi 8@%rsi
├── readelf --wide --decompress --hex-dump=.gnu_debuglink {}
│ @@ -1,5 +1,5 @@
│
│  Hex dump of section '.gnu_debuglink':
│    0x00000000 62697463 6f696e64 2e646267 00000000 bitcoind.dbg....
│ -  0x00000010 b25ceebb                            .\..
│ +  0x00000010 114d519d                            .MQ.

As you can see, there are only two differences here, one in the build ID, and one in the .gnu_debuglink section. From the documentation I linked earlier, we can see that this .gnu_debuglink section has the first line is the debug filename followed by enough 0 bytes to pad to a 4 byte boundary. The second line is the 4 byte CRC checksum. And it is this CRC checksum that differs.
So why do the debug symbols differ here? Again, diffoscope can help us a bit.
--- bitcoind.dbg
+++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind.dbg
├── readelf --wide --notes {}
│ @@ -1,15 +1,15 @@
│
│  Displaying notes found in: .note.ABI-tag
│    Owner                Data size     Description
│    GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)        OS: Linux, ABI: 3.2.0
│
│  Displaying notes found in: .note.gnu.build-id
│    Owner                Data size     Description
│ -  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 6b464617f7f91fd270ac86f43ef4a58eeeedff19
│ +  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 3a439a31a5157ff7052ed310050df5643a02ea3f
│
│  Displaying notes found in: .note.stapsdt
│    Owner                Data size     Description
│    stapsdt              0x00000036    NT_STAPSDT (SystemTap probe descriptors)        Provider: libstdcxx
│      Name: throw
│      Location: 0x00000000006e550d, Base: 0x000000000086d140, Semaphore: 0x0000000000000000
│      Arguments: 8@%rdi 8@%rsi
├── readelf --wide --debug-dump=info {}
│┄ error from `readelf --wide --debug-dump=info {}`:
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│ @@ -85052,36 +85052,36 @@
│      <29607>   DW_AT_decl_line   : 124
│      <29608>   DW_AT_decl_column : 16
│      <29609>   DW_AT_type        : <0x28761>
│      <2960d>   DW_AT_data_member_location: 12
│   <2><2960e>: Abbrev Number: 30 (DW_TAG_member)
│      <2960f>   DW_AT_name        : (indirect string, offset: 0x13aaf): __kind
│      <29613>   DW_AT_decl_file   : 108
│ -    <29614>   DW_AT_decl_line   : 148
│ +    <29614>   DW_AT_decl_line   : 128
│      <29615>   DW_AT_decl_column : 7
│      <29616>   DW_AT_type        : <0x287a6>
│      <2961a>   DW_AT_data_member_location: 16
│   <2><2961b>: Abbrev Number: 30 (DW_TAG_member)
│      <2961c>   DW_AT_name        : (indirect string, offset: 0x7a535): __spins
│      <29620>   DW_AT_decl_file   : 108
│ -    <29621>   DW_AT_decl_line   : 154
│ +    <29621>   DW_AT_decl_line   : 134
│      <29622>   DW_AT_decl_column : 3
│      <29623>   DW_AT_type        : <0x2879a>
│      <29627>   DW_AT_data_member_location: 20
...

There's a lot more output that I haven't included because it's pretty much all of the same.
Now this isn't terribly helpful, but we can see that for a bunch of functions, the line number for that function differs by 20 lines.
To get some more information, I used dwarfdump. This is what it says for the new build for the two functions I show in diffoscope (the functions are __kind and __spins).
0x0002960e:     DW_TAG_member
                  DW_AT_name    ("__kind")
                  DW_AT_decl_file       ("/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h")
                  DW_AT_decl_line       (148)
                  DW_AT_decl_column     (0x07)
                  DW_AT_type    (0x000287a6 "int")
                  DW_AT_data_member_location    (0x10)

0x0002961b:     DW_TAG_member
                  DW_AT_name    ("__spins")
                  DW_AT_decl_file       ("/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h")
                  DW_AT_decl_line       (154)
                  DW_AT_decl_column     (0x03)
                  DW_AT_type    (0x0002879a "short int")
                  DW_AT_data_member_location    (0x14)

As you can see by the given file name, these functions come from libraries installed to the system. These appear to be headers for gcc's implementation of the c++ stdlib.

So what's happened is that libstdc++ has updated in Ubuntu. Whatever updates hapened have moved some code in some header files that Bitcoin Core includes in its use of the c++ stdlib. In turn, compiling with those updated headers results in different debug symbols because function declarations have moved in those header files. This then results in gcc computing a different build ID and a different CRC checksum for the debug symbols. This lastly results in the final binaries being slightly different, which causes the hashes to mismatch.


Which serialization format the transactions use? I'm not very familiar with low-level structures, so I would like to know if bitcoin protocol follows a standard on how a bitcoin transaction data is serialized and sent over TCP.

Does it use any of these serialization format?
https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

All of the data structures in Bitcoin use a custom Bitcoin specific serialization format. The standard that is followed is the Bitcoin defined standard, not any other standard. A description of the non-segwit format can be found here. For segwit transactions, the format is described in BIP 144.


Re-indexing blocks taking more than a week - Cant access my wallet I've bought Bitcoins and had them directed to a wallet on the Bitcoin-Qt software. Unfortunately I was not aware of the sync process. And now I've got no access to the Btc's and I feel like the syncing will never happen.

Running on Mac OS X 10.8.5
2.3 GHz Itel i7
16 GB Memory

Running Bitcoin v0.8.5

Thanks so much.

You can quickly import your wallet to blockchain.info, which will give you instant access to your funds. From there you can send them back to a usable wallet on your Mac, such as Electrum or MultiBit which don't require lengthy synchronisation times. I do not recommend you leave your funds in a web-based wallet like Blockchain.info's for longer than you need to, but they are generally regarded as being trustworthy.

Find your wallet.dat in /Users/<name>/Library/Application Support/Bitcoin/, and follow the instructions on the page below.

https://blockchain.info/wallet/import-wallet

Some alternative, fast syncing Mac clients.

http://electrum.org/

https://multibit.org/

Good luck.


How does walletexplorer.com generate the wallet ID's? I was wondering how Walletexplorer.com determines what the wallet ID(entifier) of a certain set of adresses ( wallet ) is.

There seems to be no preset like the case with adresses (eg, they all start with 1....X)

more something like

0020bb2aef
5dbe0f39c2
43ba59ffbc
71cffa7b7f

But rather seems to be "randomly" generated.

Could anyone explain if this is the case, or if it's indirectly generated from something such as the private key, as the case is with normal adresses.

They're internally generated and have no bearing on anything but the internal database, some are sequential and some are random for historical reasons. All information displayed there is inferred, there's no direct relation to transactional information available on the Bitcoin network other than by derivation.


Bruteforce bitcoin address - I know the words + public address but not the order I have a long list of 1million+ permutations of a 12 word BIP39 seed. How can I try them all on a bitcoin address?

edit: I know the address and the 12 words but i don't know the order of the words

Doing this requires three things:

Permutations of the seed words
The address you're trying to locate
The derivation path for that address.

In this specific case, the address is the one this puzzle on reddit leads to, so we will assume the derivation path is m/49'/0'/0'/0/0

This is a simple nodejs script using bitcoinjs-lib to read seeds from a file, validate them, and then try the first address against the one you are searching for. You can parallelize it by splitting the input file into pieces and running it once per file.

Do note that 12 words means roughly half a billion combinations. While this is doable with today's computing power, it is still going to take you a very long time. Some quick tests show it would take about 4 days on my laptop, although you may be able to speed it up by using a faster language, or parallelization.

var bip39 = require('bip39');
var bitcoin = require('bitcoinjs-lib')

var lineReader = require('readline').createInterface({
  input: require('fs').createReadStream('addresses.txt')
});
var ctr = 1;
lineReader.on('line', function (line) {
    if (ctr%100 == 0) {
        console.log("Processing #" + ctr);
    }
    if (bip39.validateMnemonic(line)) {
        var roothex = bip39.mnemonicToSeedHex(line);
        var rootnode = bitcoin.HDNode.fromSeedHex(roothex);
        var basechild = rootnode.deriveHardened(49)
                .deriveHardened(0)
                .deriveHardened(0)
                .derive(0);
        for (var i = 0; i < 3; i++) {
            var child = basechild.derive(i);
            var keyhash = bitcoin.crypto.hash160(child.getPublicKeyBuffer())
            var scriptSig = bitcoin.script.witnessPubKeyHash.output.encode(keyhash)
            var addressBytes = bitcoin.crypto.hash160(scriptSig)
            var outputScript = bitcoin.script.scriptHash.output.encode(addressBytes)
            var address = bitcoin.address.fromOutputScript(outputScript)
            if (address == "3CcxyPhyvyc3S9UuPfu42GNZLvVVV11Uk8") {
                console.log("Found seed! " + line)
            }
        }
    }
    ctr++;
});

You will need to install nodejs, and bitcoinjs-lib for this.


Cloud Mining - Difficulty Increase I'm looking into signing up for a year contract on one of the cloud mining sites. However, I'm concerned about the increasing difficulty over time at the locked Gh/s. In what ways can I calculate the loss I would face over time as the difficulty increases?

Unfortunately Mining is a zero-sum game for the average individual at this point. If you sit and honestly think about it, who would sell a machine which literally generates profitable revenue after expenses? If you are planning to invest in the Bitcoin domain than I would highly recommend just obtaining Bitcoin and storing it in an offline wallet. This has proven to be the most profitable strategy thus far. Take for instance all the disgruntled miners who were delayed for over a year on receiving their hardware. Once they finally received their hardware it was obsolete and wouldn't even generate a profit versus electricity if being ran. Every single one of those miners wish they would've just saved their money and purchased or held Bitcoin.

If you are still curious or just interested in mining, then I suggest checking out CEX. They seem to be a longstanding and reputable company as far as the Bitcoin world goes. There has been an increase in scams lately which portray "profitable" virtual mining contracts, so please be aware of any "too good to be true" deals.


How to make a simple payment with the python-bitcoinlib? I've been using the bitcoin-python library for making payments from within Python. This worked pretty simple:

>>> import bitcoinrpc
>>> conn = bitcoinrpc.connect_to_local()
>>> conn.sendtoaddress('bitcoin_address_here', 0.5)

The Readme of that library now says that it is not maintained anymore and refers to the python-bitcoinlib as a successor. So now I'm trying to wrap my head around that lib, but it seems to be a bit more difficult than bitcoin-python used to be. I now understand I can connect to the running bitcoind using the following code:

>>> import bitcoin.rpc as rpc
>>> proxy = rpc.Proxy()
>>> proxy.getinfo()
{u'connections': 36, u'errors': u'', u'blocks': 295646, u'paytxfee': 0, u'keypoololdest': 1394108331, u'walletversion': 60000, u'difficulty': Decimal('6119726
089.12814713'), u'testnet': False, u'version': 90100, u'proxy': u'', u'protocolversion': 70002, u'timeoffset': -1, u'balance': 1856000, u'keypoolsize': 101}

So far so good. The problem is now that I have no idea how I can do a simple payment. I see there is a function called proxy.sendrawtransaction(self, tx), which apparently takes a raw transaction as an argument. I have no idea how to create a raw transaction though, plus I would expect that there is some kind of send_to_address(address, amount) available, but I can't find it around the library.

So does anybody know how I can send a simple transaction to an address with the python-bitcoinlib? All tips are welcome!

I just added sendtoaddress to bitcoin.rpc.Proxy:

from bitcoin.core import COIN, b2lx
import bitcoin.wallet
import bitcoin.rpc
try:
    # This moved between versions
    from bitcoin.base58 import CBitcoinAddress
except:
    from bitcoin.wallet import CBitcoinAddress

rpc = bitcoin.rpc.Proxy()
addr = CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))

Note quite as simple as bitcoinrpc, but that's the trade-off for having proper types and so forth.


Is Bitcoin inherently dependent on electricity? Obviously, the computing power necessary to create the blockchain requires access to fast hashing which requires electricity. Given that local power outages do occur, and this can cause a lack of network availability, does this act as the Achilles heel for Bitcoin?

Is it possible to conduct Bitcoin transactions in the absence of electricity?

The network is distributed, so it won't go down everywhere at once.

Locally, on one hand it is similar to debit transactions - they need to get online to be processed. One can use cellphones though, which have their own batteries to run for awhile, so it's not too bad.

Lastly, one can accept transactions offline (using QR codes for example) and later transmit them through the network, but that carries the risk of double spending.

And if you want truly offline transactions with little risk, use things like Casascius physical Bitcoins.


What is the "blockchain"? What is the blockchain? I keep hearing about other "blockchain technologies", does this mean other cryptocurrencies or what?

The bitcoin block chain is the record of every bitcoin ever generated and every transfer of bitcoins from one party to another. Each crypto-currency that is based on the same type of technology as bitcoins has its own block chain. When people talk about other blockchains, they mean other currencies based on the same distributed currency / published transaction model (namecoin, Ixcoin, and so on).

The phrase "blockchain technology" is a reference to this model of published transactions to implement currencies with no central authority.


what is the latest required hash rate to mine a block? What is the latest required hash rate to mine a block of bitcoin ?

How much power do you need to mine a block in a day ?
Thank you

I think you can estimate the value with "getnetworkhashps" command

  What is the latest required hash rate to mine a block of bitcoin ?

26,592,872 trillions of hashes per second

  How much power do you need to mine a block in a day ?

average hash power of 1 day is 35,683,280 trillions of hashes per second

$ date --utc
Sat Feb 16 12:23:48 UTC 2019

// 1 block
$ curl --user 'id:password' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getnetworkhashps","params":[1]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":2.659287272432074e+19,"error":null,"id":"curltext"}

// average of 144 blocks (about 144 blocks are generated in a day)
$ curl --user 'id:password' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getnetworkhashps","params":[144]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":3.568328058845101e+19,"error":null,"id":"curltext"}

// chainquery.com (I think a little bit buggy sometimes)

http://chainquery.com/bitcoin-api/getnetworkhashps

// blockchain.com hash rate

https://www.blockchain.com/ja/charts/hash-rate


What does it mean to "password protect" your wallet on Multibit? Isn't my wallet (i.e. my private key) already private? What does it mean to set a password for it? I assumed it encrypted the wallet file, but this answer seems to point otherwise. How can they verify the password? I don't feel very comfortable sending it to a server, and it doesn't seem any safer to store a password with the wallet file than just have a wallet file without a password. However if it does encrypt the wallet, what software is used?

I'm very unsure of multibit, it seems very non-transparent. The wallet file seems to be a binary file instead of a plain text one with my key (granted plain-text "isn't safe", but so isn't a binary file that can be used by an attacker on his multibit client). I don't even know what multibit is doing with that file...

Thanks... Noob here.

Your wallet.dat file contains your private key. By default this is saved in clear text. Meaning that anybody who gets a hold of this file, could see the private key and therefore spend your money.

When password protecting this file, to see the private key, you need a password. MultiBit uses a well known Java library to "password protect" it. It's all open source and well peer reviewed.

If you don't trust MultiBit you can still encrypt your wallet.dat file using other software. You must also understand that if you decide to unprotect your wallet file, it's not necessarily the case that people will be able to steal your money; they would still have to get a hold of the wallet.dat file.

So, it's best practice to password protect it, so in case you lose your file, or a hacker enters your computer, they won't be able to spend your money because they would need the password.


Are transactions still tamper-proof if blocks are hashed without nonces? If an alt were to forgo difficulty and timed release of new supply by removing the nonce from blocks therefore the whole difficulty/target system, is hashing without nonces still providing the same blockchain anti-tampering security?

If not, how could the blockchain's integrity be maintained without hashing difficulty?

As I understand it, blocks have nonces to satisfy difficulty so that the hashing process is slowed for the purposes of controlling the rate new crypto supply is produced.

Please assume that supply will be produced through a multiplier as described here instead of as a reward for mining.  In this case, block generation doesn't need to be slowed for the purposes of crypto supply inflation, but the blockchain does need to be made tamper-proof.

Is it correct that simply hashing in particular ways make the transactions tamper-proof, or is noncing a hash also necessary?

Ripple is an example that works without proof of work nor proof of stake (so no nonce needed). This mechanism is more vulnerable to sybil attacks, so it needs strong peer identity knowledge (but not trust!) to be secure. See https://ripple.com/wiki/Consensus.


Encrypting Bitcoin private keys instead of printing out paper I follow the procedure of making a cold storage wallet: downloaded copy of bitaddress.org using an off-line computer booted with Ubuntu from CD.

Instead of printing out the private keys and corresponding addresses for my bitcoin, I simply use a JavaScript file (http://prgomez.com/ursa/) to encrypt the private key, while I am using Ubuntu. I then keep together the address and encrypted bitcoin private key safely so I don’t lose it, but with no need for special security. All I need to keep in paper is my 80 bit plus password for the encryption of the key.

Logically, this seems to me safe, though I have so far only entrusted small sums of money to this procedure.

Is it safe?

It's challenging to answer this without a clear definition of what you mean by "safe." I'll assume your two main concerns are (A) loss by theft; and (B) loss by user error.

For (A) you're "safe." You followed offline cold storage wallet generation procedure and your private key was not exposed in an online-hackable way. You have the same level of theft protection as an offline-generated paper wallet -- with the added level of protection that your private key is encrypted. If your paper is lost or stolen, another party would have to know your method of encryption as well as your password. (Naturally, if your password is stored on the paper, then you effectively have the same security as a non-encrypted wallet in the case of theft or loss of the physical paper.)

For (B) there are a number of possibilities, but here's some scenarios to consider.

Are you entering the unencrypted or the encrypted private key into bitaddress.org? If the latter, then you gain no benefit from the encryption and might be confused when attempting to retrieve your funds.
How confident are you that you'll be able to recover the unencrypted private key when the need arises? Your use of a home-brewed step here makes it a good candidate for something to go wrong. Are you prepared to keep a working copy of the encryption/decryption software -- exactly as it was used at the time of wallet creation -- for the entire lifetime of the paper wallet? Did you test decryption at the time you generated the wallet to ensure the decrypted private key matches the original unencrypted key? Have you tested retrieving funds to ensure that your process works from end-to-end? Are you going to remember all the steps involved 10 years from now or do you need to keep written notes?  Etc.
Same with any password-protected item, how confident are you that you'll be able to remember the password when the time comes? People forget passwords so often that nearly every website with password-based authentication includes a recovery mechanism. Are you printing the password along with the paper wallet? If so, then what is the purpose of the encryption? Are you printing the password and keeping it elsewhere? If so, then will you be able to find it when the time comes? (How many times have you put something where you'll "never forget where it is" only to discover you can't find it later?)
Same with any paper wallet, how safe is yours from physical loss, disaster, etc.? Are you planning to keep a backup copy? How do the backup copies affect your risk of theft? How long will the paper and ink last?

Have a look into BIP0038. bitaddress.org can generate BIP0038-encrypted private keys. Three benefits of this are:

BIP0038 uses scrypt with parameters intentionally tuned to make brute-force password guessing attacks very slow. In this thread folks were getting 7 password guesses per second at the time, which is not very many for a brute-force attempt.
bitaddress.org generates the wallet in such a way that the actual private key never exists in the computer's memory while the wallet is being created. Counter-intuitive, but true -- it uses the "EC multiply" variation of BIP0038. (Of course your password exists in memory, so you will likely still want to do this offline.)
It is more of a standard than your home-brewed encryption step. BIP0038 is not officially an adopted standard as of this writing; but enough folks support it at this time that it may as well be a de facto standard. This means you have several options for retrieval, with less chance for human error or other issues presenting an obstacle to retrieving your funds.


Does submitblock require the wallets private key? I would like to know if invoking the submitblock RPC is supposed to work if the daemon that handles the RPC does not have the private-keys for to the coinbase output address?

submitblock is not a wallet RPC so it does not need private keys nor is it related to anything in the wallet. It can be used even if the wallet is disabled.


Please guide what should i do Am new in bitcoin world and didn't started it yet...
A man from USA saying to create blockchain wallet n top up then share ur email n wallet address not login not password to connect my wallet to a s9 machine for mining i 'll keep my money with me in my wallet he will create a node address to connect s9 ...I want know is it safe should I do it and if it's scam what is the real way to do it another question is mining profitable ?

connect my wallet to a s9 machine for mining ... is it safe

No. You will lose all your money. He will use your fear of losing your money to trick you into giving him more money (e.g. private-key release fees) and more money and more money until you have nothing left to give. Then he will tell you to borrow more money from your family, from the bank, from loan sharks ...

  if it's scam

It is a scam

  what is the real way to do it

Spend a long time (at least an hour a day for a couple of weeks) researching Bitcoin and mining. Don't proceed until you understand private-keys, public-keys, seed-phrases, recovery, different types of wallet, watch-only wallets, principles of mining and so on.

Read the answers to all these questions to innoculate yourself against scammers

Then buy a hardware wallet or download a good stand-alone wallet.

Buy a small amount of Bitcoin from a well-known exchange

Practice recovery of your wallet as if your hardware-wallet or computer is stolen. Don't proceed until you have proven you can recover full control of your bitcoin only using the recovery phrase without touching your existing wallet hardware or computer or  mobile-phone.

Write down instructions for your family to recover your money if anything happens to you. Make them follow your written instructions without any help from you and see if they really can. If necessary create a new wallet with new keys and transfer all your Bitcoin to the new wallet. Update your saved recovery phrase etc.

Never share your wallet-password, recovery phrase or private-key with anyone (unless they are someone you'd be happy for them to walk away with everything you own tomorrow). Never let anyone else log in or remotely access your computer or your wallet to help you, even if they seem to be the most honest person in the world, especially if they suggest you can secure your wallet afterwards by changing a password.

After becoming comfortable buying and using bitcoin for several months, re-think about mining, if you have a few thousand dollars you can afford to lose totally, you are probably ready to consider whether the process is for you.

  is mining profitable ?

Not unless you already have several thousand dollars to invest in ASIC mining equipment and a good source of cheap electricity in a building with very good air-conditioning and where noise does not matter. This isn't suitable for people new to Bitcoin. You must be prepared to lose that money without hardship.


Where is the real money stocked? Are exchanges banks? I'm trying to understand how cryptocurrency works, and there is something I really don't get:

Exchanges; some are calling themselves "cloud banks" but I thought there was no banks, no place to stock the money, nothing was centralised. how do they do? Where are the dollars going/stocked?

The first thing you need to understand is that cryptocurrencies like bitcoin are the real money.  They are not merely a measure of government fiat currency denoted in a different unit.  With that in mind, your question doesn't make a lot of sense.  It's like asking where the real money is stored when you purchase gold.  The gold is the value.  You have simply traded some other currency in exchange for it.

Exchanges, web wallets, and other "cloud banks" (although I've never seen this term) are just services that store your bitcoin for you.  They manage your transactions, and often your private keys, so that you don't have to run software on a computer to do so.  If you have given them US dollars, what you have done is purchased bitcoin with those dollars.  This is just like purchasing a bag of groceries with your USD.  Someone isn't storing the money you spent as a backing for the value of your bag of groceries in your pantry.  You've simply exchanged one thing for another.


When MtGox was hacked on 15th June 2011, how many bitcoins were actually stolen? When MtGox was hacked on 15th June 2011, how many bitcoins were stolen?

I remember at the time that news articles reporting the incident talked about the size of the sell order the hacker placed within the site, but failed to state the amount of bitcoins the thief managed to withdraw. Most of the stolen bitcoins were unable to be withdrawn, so MtGox was able to retrieve those by claiming them back from the controlled website account.

Please provide a link to support your answer.

Related question:
Were all funds stolen from Mt. Gox finally returned to all users?

According to MtGox, the hacker got about 2000 BTC.  A few real customers also appear to have purchased bitcoins at an artificially low price during the incident, withdrawn them, and kept them. This is estimated to amount to less than 650 BTC.

The details given at the above link are:

~June 2011 Mt. Gox Incident
Time: 2011-06-19T18:00 ± 1 h (theft), days ensuing (hacks & withdrawals)
Victim: Mt. Gox (some claim also customers)
Status: Thief uncaught
Amount:
Stolen by thief: 2000 BTC (official estimate)
Additional withdrawn from Mt. Gox: 643.27 BTC (lower bound)
Total: Lower bound 2643.27 BTC
Equivalent USD: 46970.91 $ (used last trade value; actual price at the time was not reliable)
Transactions: none released officially
The event's scale was widely disputed; some report a theft of almost 500000 BTC due to related account hacking. At this time, these reports seem to be unfounded and closer inspection puts the losses at closer to 2500 BTC. Some additional money was stolen by traders capitalizing on the dropping price and withdrawing in time, including toasty of the bitcointalk.org forums. Mt. Gox claims it has reimbursed customers for this theft.


RPC sendmany with multiple accounts? It seems that I can do sendmany(fromaccount, {address:amount,...}) which can have multiple outputs with one account, and sendtoaddress(bitcoinaddress, amount) can have one output with any amount of accounts. Is there a way to have multiple outputs with any number of accounts? I have small amounts of bitcoins distributed amount different accounts and I would like to put them in one transaction to minimize fees. It's odd that there is no rpc call for such a function, or am I completely missing something? Or is there a work around I can do?

Accounts are purely a client-side feature. It's just a virtual balance, allowing you for example to maintain a balance for different users of your wallet.

All coins in a wallet are always shared among all accounts, so the 'from account' field does not influence the actual transaction created in any way, or which inputs are used for it. It simply changes which virtual balance the amount is deducted from.

If you really are using the accounts feature (unlikely, it's only useful for a limited number of use cases), and really need to send 'from' different accounts, use the move command (which is local only, and doesn't construct any Bitcoin transactions) to move amounts from one account to another to correct before or afterwards.


How to decrypt a MultiBit private key? Looking for a way to decrypt a private key that was exported by Multibit WITHOUT using Multibit. I need to move they key elsewhere.

I need to go this route because I can't get the key to import into Multibit properly (even though I have the password).

Thanks!

The process to decrypt a password protected .key file exported using MultiBit is explained here: https://github.com/jim618/multibit/wiki/Export%20and%20limited%20import%20of%20private%20keys

To decrypt a MultiBit private key export file use:

openssl enc -d -p -aes-256-cbc -a -in \<ciphertext file\> -out \<plaintext file\> -pass pass:\<password\>


how bitcoin core generate addresses? how does bitcoin core generate addresses and where can they be found in the data directory?

Bitcoin addresses can be created anywhere with any programming language.
they're just like the result of 1 + 1 = 2.

if you are looking for the function they're using for getting a new address here you go:
https://github.com/bitcoin/bitcoin/blob/4ad3b3c72c73d61e0a0cab541dca20acf651320d/src/wallet/rpcwallet.cpp#L135

When you make RPC call 'getnewaddress' that function will be called, and addresses keys are already generated (keypool) and saved into wallet.dat file.


Exact definition of "Liveness" and "Safety" properties in a consensus? Two main properties of a consensus are "Liveness" and "Safety".

What are the exact and precised definition of "Liveness" and "Safety" properties in a consensus ?

Are the following definitions correct?

Safety: Achieving an agreement on a single state by all participants ?
Liveness: Possibility of updating this state with keeping the agreement ?

Safety: Any transaction deemed final by one properly-operating node will eventually be deemed final by every properly-operating node. No two transactions ever deemed final by two properly-operating nodes will ever conflict.

Liveness: So long as there is always at least one transaction suitable for inclusion that has not been deemed final by any properly-operating nodes, the set of transactions deemed final by at least one properly-operating node will increase in number.

Note that these are very, very minimal definitions and generally not sufficient for realistic systems. Also, for some systems (where a transaction can produce different results depending on the context in which it executes), you have to understand "transaction" to mean the results of executing the transaction.


What site should I use to create a Bitcoin wallet? I wanted to create Bitcoin wallet but I saw there are a lot of websites or software to create it. It's not like paypal.
I am thinking to chose Blockchain. Is it good? How to check if it's legal in my country?

I wouldn't recommend Jaxx wallet since, several weeks ago, it was found exploitable, giving an attacker the possibility to retrive your 12 words seed .
Usually, you choose a service that gives you the full control and ownership of keys. Blockchain.info doesn't give you this option.
Some service I would recommend are GreenAddress and Samurai Wallet.


Unclear Trade Volumes on Bitcoin Charts Many 'stats/charts' sites are reporting trade volumes, without ever specifying which trade volume they are referring to:

Number of Sent Bitcoins / 24h (Transaction Volume)
Number of Bitcoins sent to a Bitcoin/USD/EUR/etc exchange. (Trade Volume)

I'm trying to gauge exactly what both BTC volumes are using sites like CoinMarketCap, but I can't tell whether the USD Trade Volume figures are for the number of BTC exchanged for USD/EUR/etc or simply a dollar-conversion for the total number of BTC sent to any address over 24h.

Any help?

It just depend on the site you are seeing, on market charts/stats (like http://bitcoincharts.com/ or http://bitcointicker.co/) volume refers to trade volume, which indeed is not the money sent to the exchange, it is the BTC that changed hands inside the platform (there is no need to come from external and the same "coin" can be traded several times a day).

Sites that give information about a coin in general like http://coinmarketcap.com/ or http://blockchain.info uses Volume as the sum of the value of all transactions in the public ledger (blockchain), I am not sure if that includes mining transactions or not.

As how exchanges work, no trades in exchanges leave a trace in the blockchain, as they are just internal movements between exchange accounts, they only leave trace when people fund or withdraw coins to/from the exchanges.

Both volumes are unrelated, the first Volume (markets) gives you information about quantity of people wanting to buy or sell coins with fiat (or invest in them) while the second is real usage of the coin being handed between users, merchants, exchanges, etc.