What is the most optimal way to mine? Is it better to mine in a virtual machine or on the desktop?

I'm mining for Bitcoins and Litecoins, and am wondering how I can get the most hashes per second without altering my hardware. If it matters, I am on a laptop. I see a couple of choices, such as:

Mining within a browser
Using a dedicated machine, separate partition, or a virtual machine
Mining using an app on a machine used for other things (your daily computer, used for surfing the web, gaming, etc.)

So far I have tried running GUI Miner while doing other stuff. This doesn't work out well and I end up with only 32khash/s. Which of the above is the most optimal for doing this, or is there an even better choice?

My Laptop Specs

------------------
System Information
------------------
       Machine name: SAMSUNG
   Operating System: Windows 8 64-bit (6.2, Build 9200) (9200.win8_gdr.130531-1504)
System Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
       System Model: 520U4C/520U4X
               BIOS: P03RAL
          Processor: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (4 CPUs), ~2.5GHz
             Memory: 8192MB RAM
Available OS Memory: 7894MB RAM
          Page File: 3598MB used, 5510MB available

---------------
Display Devices
---------------
          Card name: Intel(R) HD Graphics 4000
       Manufacturer: Intel Corporation
          Chip type: Intel(R) HD Graphics Family
           DAC type: Internal
        Device Type: Full Device
         Device Key: Enum\PCI\VEN_8086&DEV_0166&SUBSYS_C682144D&REV_09
     Display Memory: 1664 MB
   Dedicated Memory: 32 MB
      Shared Memory: 1632 MB
       Current Mode: 1366 x 768 (32 bit) (60Hz)
       Monitor Name: Generic PnP Monitor
         Monitor Id: SEC0200
        Native Mode: 1366 x 768(p) (60.072Hz)

Without changing hardware, GPU mining is almost certainly the "best" option. For BitCoin ASIC is the fastest, anything else is a waste of electricity at this point. For LiteCoin GPU is the fastest, and CPUs are around breakeven (electricity usage vs LiteCoin value).

Keep in mind that LiteCoin is inherently about 1000x slower than BitCoin mining. Getting 32kh/s out of a laptop GPU is doing reasonably well (my work laptop does the same). That same GPU can get almost 30Mhps mining BitCoin.


Paying for testnet coins? If testnet coins are this difficult to get, what's the chance people start throwing in some real money to speed along the process?
If only to just have to not wait to test, say if you have an important time sensitive simulation you want to run?

I have recently created a TestNet Faucet. It is available on

http://tpfaucet.appspot.com/

I hope this remedies the situation

To answer your question - while there is nothing stopping people from charging for TestNet coins, I think they should be freely available to anyone for testing. It lets newcomers get a feel for what Bitcoin is without risking their money. I hope that a few Bitcoin developers (or even the Bitcoin Foundation) will provide TestNet Bitcoins for free as long as the Bitcoin project is used.


What is the formal code review process of the standard client? There are n developers with commit privileged.

After one of them merges a pull request, how many eyes review that code? When? Is a complete (holistic) code review done before releasing a version? Does every line gets reviewed by at least one other person?

According to the bitcoin.it wiki, as Stephen Gornick linked to in a comment, this should be the code review process:

  Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.

Assuming the bitcointalk.org forums, I can't really find any pull request discussion. On Github it seems pull requests do get discussed though, for example: Bloom filter pull request.


What is a simple explanation for how the number of bitcoins in circulation is determined? Often times when I explain to someone that there is a limited supply of bitcoins available that need to be divided across all the people who want to have bitcoins, the people who are computer illiterate will ask how I know that the number of bitcoins in circulation can not be changed or manipulated. They usually just get a glossed over look on their face when I start talking about decentralized protocols. Has anyone come up with a good way of phrasing it or an good analogy to get people to understand how these limits are determined, enforced, and protected?

You could explain the coin limit like this:

When Bitcoin started, its creator set a rule - "No more than 21 million Bitcoins will ever be created, and they will be given out gradually for creating blocks" (Add further explanation of block reward or proof-of-work here if needed). Everyone who joined Bitcoin knew about this rule, and they were all for it. As everyone can see all the money created by solving the blocks, everyone can check if someone tried to go against the rule and cheat. If cheating is detected, nobody will accept the solution, instead looking for one that follows the rule. Because everyone is checking everything, nobody can cheat and create more Bitcoins than is allowed.


Transaction with slightly changed script is never relayed I am playing with bitcoin transaction a bit now.

I have a question. Normally, the output script looks like

OP_DUP OP_HASH160 (hash) OP_EQUALVERIFY OP_CHECKSIG

Now that is understandable. However, when I slightly change the script with an outgoing translation to

OP_DUP OP_DROP OP_DUP OP_HASH160 (hash) OP_EQUALVERIFY OP_CHECKSIG

this transaction is never relayed (as far as I can say) and never reaches any miner, even when it's 100% legal.

What is going on? Why is it not relayed? I even added quite large fee on it.

And a second question - if my suspicion is correct and it is actually never relayed - what would happen if some miner actually accepted it and this transaction ended in the blockchain? Would it be a valid transaction? Would the client be able to "see it" when he is not able to relay it?

The standard client will not relay non-standard transactions. However, if you get them directly to a miner that accepts them, clients will process them correctly and the transaction will work.

You can send your transactions to 173.242.112.53. This is a server run by Eligius that will relay all valid transactions and they will include even non-standard transactions in the blocks they mine. Others who are willing to relay or include free and non-standard transactions also tend to link to this node, so it can get your transaction included in blocks mined by other pools as well.


Is transaction time correlated to block generation time As I unterstood in other answers (see https://bitcoin.stackexchange.com/a/8922/74399), a transaction is added to the blockchain, once a new block has been found/generated.
The average time between two blocks is about 8 minutes regarding the past 24 hours.

Does this mean, that my transaction will take an average of 8 minutes to become visible in the blockchain?
Is it known in the network as an "unconfirmed transaction" (so it's save)?

On average, based on Bitcoin protocol, a block takes 10 minutes to mine.  Transactions that optimize miner profit take precedence in the block. In other words, the transactions that pay the highest fee get incorporated into the block first and therefore get confirmed the fastest since currently the mempool is large. The mempool consists of all transactions that are waiting to be mined into a block. A transaction that pays a low fee can be stuck in the mempool for a very long time if the mempool remains crowded, so it’s hard to say how long a particular transaction can take; but, yes, a transaction that is broadcast to the network remains unconfirmed until mined into the blockchain.


Accidentally sent Bitcoin Cash to Bitcoin address held by a third party I made an exchange on Changelly to exchange my Bitcoins to Bitcoin Cash. These Bitcoin Cash would later be sent to my address. Unfortunately, I did not check twice and had the Bitcoin Cash sent to my Bitcoin address and not Bitcoin Cash address.

Is there a way for me to reclaim these Bitcoin Cash? They are on a Bitcoin Cash address, just not mine. I checked the address and it only holds my Bitcoin Cash, which means it probably does not exist as an address. Is there a way for me to custom create the address and claim them or how do I get them back?

This is the process of how it went

As BTC in Blockchain.info
Transferred to Bitcoin Cash via Changelly
Transferring done, Bitcoin Cash supposed to be sent to my Bitcoin Cash address, to my Bitcoin.com Wallet but after accidentally having written my Bitcoin address and NOT my Bitcoin Cash address, the Bitcoin Cash is now with that address. I can see the cash at the other address but don't know how to get it back.

Help would be much appreciated. Thanks!

You'll have to negotiate with your service provider whether they can help you.

Whoever holds the private keys for your Bitcoin wallet should be theoretically able to generate a transaction that sends the BCH from the Bitcoin address to wherever you wanted them to go.

In practice this may be difficult or infeasible: To keep large quantities of Bitcoin secure, the private keys are often stored in hardware devices or otherwise hard to access. The service provider will likely at least need to manually intervene to help you.

If the Bitcoin address was SegWit (which I wouldn't expect in this case), it might be even more difficult to recover, as you'd need the help of a miner, additionally.

It is unfortunate, that the Bitcoin Cash developers used the same address format as Bitcoin, even after this problem was well-known and in the media recently with Litecoin switching to a new unique P2SH address format for this very reason. However, I've read that they are working on a new unique address format, so at least this should stop happening in the future.


Do all weeks of blocks take the same time to process? Bitcoin is slowly synchronising

  Synchronising the  network... 78 weeks behind

Do all weeks of blocks take the same time to process? Or will recent blocks be slower because Bitcoin is more popular now?

It felt like going from '100 weeks behind' to '80 weeks behind' took longer than going from '200 weeks behind' to '100 weeks behind'

It's the number of transactions that counts. The progress bar in recent versions of the reference client (0.8.2 and higher) uses an estimation of this, so it represents real time better.

Also, after the last checkpoint (block 250000, as of 0.8.5), signature checking is enabled, which requires significantly more CPU to validate.


Bitcoin exchange where you can set your own wallet instead of using one provided by the exchange I'm looking for a European based Bitcoin exchange where I can buy bitcoin and have them delivered straight to my private wallet. I basically want to avoid the extra cost of transferring the recently purchased coins from the exchange's to my own private wallet.

I know Coinmama works in such way (you have an input field where you fill the account you want the Bitcoin to be delivered to) but it's quite expensive and only take card payments.

Does anyone knows about such a platform?

You forget something. Who pays it then?

  I basically want to avoid the extra cost of transferring...

That means that the people of the exchange have to transfer it for you and that means that they have to pay the fees because it's a default blockchain transaction and the miners want to be paid. And the exchange's owner does generally not want to donate you 20-30$ (average fees at the moment)

I don't think that there is such a platform you are talking about. Exchanges don't work this way


Is it possible to run a pruned node while being able to verify any TXID? I am building a web app that implements bitcoin payments. My server has limited resources, and I don't want to fill up it's data with the ENTIRE blockchain (takes up too much space).

So I enabled pruning on bitcoind, and ran:

bitcoind -daemon -txindex

I got the error:

Error: Prune mode is incompatible with -txindex.

Is it not possible to verify any TXID I want with a pruned node? Is my only option to depend on a third party if I don't want to store the entire blockchain? Thanks.

You're asking two different things, so it's not clear which answer is correct.

Yes, a pruned full node verifies all transactions. That's why it's still called a full node.

No, pruning is not compatible with txindex.

But, are you sure you need txindex? If you're only receiving payments to yourself you don't need txindex.


What's the advantages of using the block chain as opposed to L2 solutions I'm looking for a good example and explanation from a software architecture perspective BUT for general audience about the benefits of solving and having blockchain features on Layer 1 not disregarding any Layer 2 solution or blockchain but in fact comparing.
In example any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain.
It's not a fair comparison because both have their reasons, their strengths and their fame but if you take lightning or æternity state channels you will have some design flaws that should be talked about to help people to understand and decide based on more than just marketing.
Again this isn't in any way a critic towards any of the solution but an example to talk about design and architecture and not about which had better marketing.

From the point of view of an application developer, it is for now much easier to use layer 1 features.
This is due to being able to externalize your burden on the network.
1. Hey nodes, will you do my job?
Blocks are expensive to produce
You don't need to have much DOS concerns in your application if you are only reacting to onchain payments. But what happens if you do an expensive operation each time your Lightning node accepts an HTLC ?..
Backups are simple
You don't have to think much about backing up the state of your application for your user: your data is public and stored by everyone. Your user only has to back up a very small amount of data.
On Lightning, you are responsible for your own data. That's sometimes surprising to users who have been accustomed to (ab)using the block chain for years :).
In addition, on Lightning in its current form you are in a pretty bad position should you miss a single state backup. But this may be fixed in the future.
The security model is simple(r)
Even if there are some pitfalls and idiosyncrasies in Bitcoin, it's way harder to reason about assumptions you can reasonably make for your software and what you can convey to your user is a reasonable usage of your software.
For instance, "may i allow my user to re-import their HD wallet master account in another wallet?"

Bitcoin onchain: sure, what could go wrong?
Bitcoin offchain: meh. It's not that simple.

The same goes with "may i dig a hole, put my wallet in there, come back in a year, and still be in full possession of my coins ?"

Bitcoin onchain: sure, what could go wrong?
Bitcoin offchain: meh. It's not that simple.

Bootstrapping is simpler
Even if we usually make the analogy to "send coins to", Bitcoin onchain did not require interactivity. Just send the transaction to every single node on the network, make them verify it for you and call it a (lazy) day.
Now with Lightning for someone to start paying they need to find a way to connect to the payee, actually making the above analogy closer from the truth as they are actually transferring data.
For someone to start receiving payments, they also need to "be able" to be paid (have enough inbound liquidity).
Payments get increasingly more secure
Under Lightning's assumptions, a payment will be almost instantly "secure" :tm:
In practice, arguably even more so than a handful of onchain confirmations. However, maybe not more than a hundred. Or not than a thousand, or ten thousands confirmations.
For some applications (such as making very large payments), you may want to use this feature unique to the block chain: don't consider a payment to be made until a reorganization of the block chain that deep would put the entire currency down anyway.
2. Hey nodes, can you be more qualified at my job?
Of course, there are also drawbacks to (ab)using the chain.
Decent payment security is slow to bootstrap
Getting the first confirmation may be infinitely longer than on a layer 2 system. If you ask "if my payment can go through successfully, when is it going to be finalized?":

Bitcoin Lightning: immediately. (this assumes unstuck payments)
Bitcoin onchain: well, lemme explain you the block space market.

UTXO management
This logic is one you can't outsource to the nodes :). It's pretty difficult optimization problem that highly depend on the usage that is going to be made of your software. It takes a deep understanding of the tradeoffs and knowledge of the existing solutions to the developer to make a sensible decision.
On Lightning, you don't have to manage coins. The value is similar to a flux rather than to actual physical, indivisible coins.
Fees orthogonal to payments and fee management
Onchain fees depend on the actual transaction (in the database sense of the term) size, not on the actual payment. They are in addition very unreliable, in theory you really can't know for sure that your transaction is going to make it into a block in advance. You are really hoping for the best.
The counter measures for adapting to this always-moving block space market incur an additional cost in knowledge and understanding (and complexity of implementation) to the application developer, similarly to coin selection (which is tightly related).
"how much is my finalized payment going to cost me?":

Bitcoin Lightning: a proportional fee of x sats per million of sats transferred and a fixed fee of y.
Bitcoin onchain: well, lemme explain you the block space market.

Higher usage cost
As the demand for the finite resource of block space increases, so are average fees premium to be included as soon as possible in the chain. This makes some design of application not possible onchain anymore, re-aligning the incentives of (ab)using the network to incur less burden to the software / user of the software.
Lack of features
Onchain nodes are pretty restricted in what they can verify for you. Some more complex systems can be emulated on a L2 network with different trust assumptions than the base trustless network (eg with sidechains).
The advantage of not doing it onchain here is that it's opt-in: you don't have to make the entire network and economy accept to augment their functionalities in order to bear even more burden than previously.
Some features may be either backward incompatible or present tradeoffs that not everyone would accept. Their addition to the base layer would raise big questions about the censorship resistance of the system and finally the point of using it in the first place.


If there was a period of time with no transactions, what would miners have to do? This question is similar to a few others, but I haven't gotten seen a clear answer anywhere.  It came up as I was trying to explain mining to a newcomer.  And he asked: "If aliens came and put all humans to sleep ( and any automated transactions that may have been setup ) would miners have anything to do?"

So the question is, if zero transactions are happening, are miners still mining? And if yes, what exactly are they doing?

I explained also that eventually block rewards will end, so I'm looking for an answer that is agnostic of the bitcoin network now vs the post-block rewards bitcoin network ( after the 21 million are "mined" )

They would mine empty blocks. Block difficulty would remain the same.

Would they have an incentive to mine blocks? In the year 2140, all mining rewards will be from fees. If there are no transactions, there are no fees. Between now and then, rewards will step down over time. So either:

Clients will keep mining.
Clients will stop mining because there are no transactions.

I recognize that this is a useless answer (maybe they will, maybe they won't) but I hope you understand the difficulty of predicting what mining clients will be like in 5-10 years.


how to do address callbacks? I'm building a webapp that needs to update account info and send a message when an account's address gets a deposit, and/or confirm withdrawals.

I'm not sure what the best way to do this is. Would you have a separate application keep sending API calls to blockchain.info until a new transaction comes through? Then initiate the right callback function?

Using blockchain.info seems flimsy since it's a 3rd party service. How would you do this monitoring the bitcoin network? It seems like using any bitcoin client would rely on some commandline action. Would the best way be continuing to send the commandline action out until the returned data is different, and then initiate the callback? Is there a better design pattern that I am missing?

If you rely on bitcoind and JSON-RPC API you could try launching daemon with -walletnotify option.

bitcoind -daemon -waletnotify="process-txn.sh %s"

This will call process-txn.sh with transaction id on the input. Then you can query the daemon for transaction details.


Private key to WIF process I have a private key for a storage bitcoin wallet (there's not much in there I'm just testing methods) but it is in private key form and to import it to my main wallet I need to convert it into WIF.
My 2 questions are, what does the process to convert it involve? (Ie. Am I expected to use the BIP38 password when converting or is that a sign it's a scam?) And secondly are there any safe offline software I can use or shall I try and use Linux commands?
EDIT:
Thanks for the replies. In the end I found this website:
https://iancoleman.io/bitcoin-key-compression/
I saved the webpage and used it offline in a VM with the internet disconnected completely. Before I reconnected the internet I restored the VM to a previously saved state. The key it generated offline worked perfectly when typed into my wallet.
Further question: does that method sound okay regarding the information being available to the net and the fact I inserted my password into the offline page?

Firstly, you should never enter a Bitcoin Private Key on an online service (unless you're okay with never owning those Bitcoins again).
Secondly, almost all Private Keys are already in WIF format when you see them. Unless you literally generated a random large number, you probably were not given a raw PrivateKey.
Thirdly, If the data you have is really a PrivateKey, you should be able to import it to BitcoinCore with the importprivkey function. This will allow your bitcoin client to send and sign for the bitcoins you have. You do not need a BIP38 password or anything else. BIP38 Passphrases are used to generate the private key in the first place.


Can I, and how do I query the Bitcoin Core wallet to give me a list of all transactions for any specified address? I've read some conflicting things on this.  Given any address, what would be the json command and or how would I import into python, such a query to my bitcoin core wallet for an array of all the tx id's for all tx's associated with any given address (whether part of my wallet or not)?

Or is there even a way to do that to begin with?

You question deserves a very long explanation :-) Instead of repeating what was already discussed, I put some links here which will help you to begin.

  Given any address, what would be the json command and or how would I
  import into python...

first it is important to understand, that the wallet that you talk to (via RPC) is not the blockchain. You can only fetch information for the known addresses in the wallet.

  ... for an array of all the tx id's for all tx's associated with any
  given address (whether part of my wallet or not)?

This is a repeating pattern here in the forum, a quick search revealed this.

And how to send python commands to RPC is described here. A quick search for "RPC python" reveals many more sources of information.
The RPC commands themselves are well described here and here.

For sure we can't write the code for you, so maybe show us a bit how far you got, and then we can easily follow where you got stuck, and maybe even provide the help you are looking for.


Can a Butterfly Labs Mini Rig SC cause health concerns if stored in a bedroom? Assuming heat and noise factors are not a concern, are there any additional issues (radiation) to be concerned about?

How far should this device be stored away from children's play rooms and sleeping rooms?  Can it be in a locked ventilated cabinet?

I'm trying to understand if this device, when powered on at full capacity, causes any health and safety concerns.

I don't know the actual design of the Butterfly Labs machines, but I assume that the health risks should be similar to a traditional mining rig. Probably the main concern would be the noise level of any fans installed in the machine, as well as potential electric shock should the machine be operated haphazardly and without proper grounding. You also might be worried about potential static build up, high-temperatures and overheating (should the machine gather dust over a period of time). One way or the either, the common sense would dictate that the machine should generally be safe under normal conditions, but I would keep it out of kids' reach.

Again, I have no practical experience with dealing with any Butterfly Labs hardware, and while I have a technical electronics diploma, I'm not an expert in safety or similar devices.


It's possible to spend a BTC without fee to forge a payment? I would like to know if it is possible to make a transaction without fee (probably this transaction will never be confirmed) and some time later to take this money back and spend in another transaction?
If yes, can I protect myself against this fake payment?

While the transaction is waiting a confirmation, it's possible for the receiver uses this amount?
If yes, if the confirmation never happens, the third person loses this money?

The simplest protection is to not consider a payment to have been made to you until it receives some number of confirmations. The number can depend on the value of the payment. For small payments, one is probably sufficient. For large payments, some have decided to wait for as many as six confirmations.


Is there a way to make a crypto-currency stable by design? How? I'm just wondering if there's any way of creating a crypto-currency that is stable by-design.

How would one do so? Can there be something like a "central bank" built in into the currency client?

I know it defeats the purpose of a decentralized currency to have a "central bank". I believe bitcoin can be manipulated by someone with a large enough wallet (very large if you ask me) and it is possible for a single entity to act as a "central bank" of sorts if it has the required funds. Or if the government banned and seized all mining equipment to themselves, which would be very impractical manipulation scenario.

Neither can we think of it as a "currency", since it is currently too volatile to think of it as a viable store of value. However it is great for transactional users, which I think gives it the upper hand over current money transmission methods.

Edit 1:
My focus is on an built-in algorithmical solution. I've read about the difficulties of pegging the currency, or what a country would have to reinvent if Bitcoin were the official currency. This is not about having a P2P wallet loadable with fiat (as other questions would imply).

Edit 2:
The idea is something more akin "A Third Endgame For Bitcoin or, Creating a Truly Free Coin" by Owen Gunden. He proposes unbounding the coin quantity limit, and giving more coins to miners when the price goes up, increasing the amount and therefore lowering its value.

Can a crypto-currency be designed from the ground-up to be a stable and solid store of value? Zero inflation.

There is a few problems with giving a crypto-currency a stable value algorithmically:

Stability compared to what?

The algorithm would have to be specifically pegged to either an asset, a currency, or some kind of calculated wealth index. But, if it were stable in comparison to e.g. the USD, it would not be stable in comparison to other currencies, or a barrel of oil. There'd always be room for speculation, and it would become completely decoupled when the value it is pegged to ceased to exist.

Stabilizing the value requires control of the money supply

In order to guarantee a certain value, e.g. an exchange rate of 1 SC (StableCoin) = 1 USD, you'd have to create an unlimited offer to buy and sell SC at that price. Both is very hard to integrate into the protocol:

In order to lower the price to 1 USD/SC, you can easily have the algorithm create more SC. However, it is hard to algorithmically accept fiat payments in order to sell them! Essentially your algorithm would need to implement bank contracts, user management and all the other shenanigans exchanges do.
To increase the price to 1 USD/SC, you'd have to be able to buy any amount of SolidCoins at 1 USD/SC. That requires very deep pockets. You also have to provide all the exchange services as before.

Then, if you wanted a proof-of-work validation, you'd also have to be able to buy back any mining rewards.

In short, I don't think that stability can be guaranteed algorithmically. You would need a central entity that guarantees the price by buying and selling at a fixed value, perhaps for a trading commission. This cannot be implemented in the algorithm, as it would require interfacing with the fiat world, which is not completely digital.

Addendum:

After thinking a bit more about it, I realized that when you create a system that is stable compared to another unit of account, essentially you create a debt-based voucher system for that other unit. Unless your currency decouples from the central market maker by being more successful than what it derives from, your currency remains completely dependent on the well-being of the central market maker – it will lose most of its worth should the central market maker default.

If you follow through on that thought, you essentially arrive at the system that is ripple, where any user can be a "central market maker" and issue his own StableCoins in form of IOUs pegged to any unit of account other people trust him to owe them.


How do you generate a bootstrap.dat file? I think it's just a renamed blk0001.dat file, but I can't find any references as to what it actually is other than a "binary blockchain" ....

The bootstrap.dat file contains a serialized copy of the blockchain, usually up to the latest checkpoint released for the official client.  The official bitcoin client will read this file when starting to create the blockchain without downloading it from the peer nodes.  The file will then be renamed to bootstrap.dat.old so it won't be reprocessed when the client is restarted.

A Python script used to create the file can be found here.  You will need an up-to-date pynode chain database.

If you have the Armory code, you can compile this C++ program.  This uses the blockchain data blocks created by the official bitcoin client.


Transaction using too many pieces Transactions been formed with too many pieces of different ages, causing the transaction to have a huge size and therefore require very high fees.

Question

Is there a way to reduce the size of the transaction?

Story

I have a payment system that accepts bitcoins.
Therefore my client (the store owner) receives many transactions of relatively small amounts ($30 - $400 amounts).
And every now and then he tries to move what he has on his address to exchange that to dollars.
We use Blockcypher's API.
The problem is that when we construct the transaction, the script gets formed with all the sum of the different pieces, indicating which pieces will form the payment, as I see it, this is done using the age.

An example of how these pieces are in the input list is here:

"inputs": [
  {
    "prev_hash": "094be5d93ec5a5299fc8f64501855010649e3bb15d56f41ac9b5291d0XXXXX",
    "output_index": 0,
    "script": "483045022100d73dd1a8499caac0d237f5f2df17786722b4e50120756bc63c4f5f513b4f4244022019d20416762f21870e63fe035e2a0599217bc62323430ca428c2d1c8930b67270121035a3ce00ccf0701a28f124e634f4243ef2b40650aad5b0433eba4feXXXXXXX",
    "output_value": 1883692,
    "sequence": 4294967295,
    "addresses": [
      "1Lpua75bYTfeVUaEYDEkzY1vxwaVFvUNNr"
    ],
    "script_type": "pay-to-pubkey-hash",
    "age": 498654
  },
  {
    "prev_hash": "1917bb8a51642541f9d4b20beeec02a57193d5ede91e7fc79a6b7aXXXXXXX",
    "output_index": 0,
    "script": "483045022100d5f54e8b89fe080b16236a742bce0d4512f83d382a683bee96a25d5c1ff41a0802206844d81b0c2d909e4d893733a7f317caaa49a408f69c0414cee0685ac96883850121035a3ce00ccf0701a28f124e634f4243ef2b40650aad5b0433ebaXXXXXXXX",
    "output_value": 2470000,
    "sequence": 4294967295,
    "addresses": [
      "1Lpua75bYTfeVUaEYDEkzY1vxwaVFvUNNr"
    ],
    "script_type": "pay-to-pubkey-hash",
    "age": 498665
  },

Is it really necessary to indicate the age of the pieces used?
Is there a way to reduce the size of the transaction script?
This is costing too much in fees to my client. We are talking transactions that costs hundreds or more dollars.

Thanks in advance.

Is it really necessary to indicate the age of the pieces used?

The "age" is shown only in Blockcypher's API. Transaction itself does not have such field

  Is there a way to reduce the size of the transaction script?

Yes. Use segwit


How can create individual wallet for each user I am going to develop an exchange website in PHP something like http://coinbase.com,
Now, I have setup the http://bitcoindevkit.com/ for it and its running fine generating new addresses in the same wallet,
but now I need to create a individual wallet for each user, so how can create individual wallet for each user and then I can able to create address on that wallet.

I would suggest using the bitcoind Account feature to track the different user 'wallets', this way a single 'wallet' or account can have as many address's as required which can all be be accounted for to that named account.  However I would also suggest not having this on your actual server, use a database to mirror what the bitcoin client shows, and hand actual withdrawals manually, (at least the larger ones) you may want to have a bitcoin daemon linked directly with a small amount of float to handle incidental day to day transactions.


How to check a signature on an arbitrary message? I'm looking to have a p2sh transaction that inside the redeem script there is OP_CHECKSIG (or any other op-code) that verifies a signature on an arbitrary message (not a transaction).
I have been looking, but all I could find is that OP_CHECKSIG only verifies signatures on transaction. I need a signature verification that I'm able to give the message (hash of message) to the verification procedure.
Something similar to ecrecover that takes in a signature, verificationKey and the message. Is this even possible using the existing op-codes?

No, this is not possible. There are no opcodes that allow you to check a signature on an arbitrary message.


signed up in 2010-now trying to access Back when I signed up with bitcoin and received 2 bitcoins, I haven't done anything with my account/wallet since 2010 is there a way for me to access my bitcoins or have they been lost, I still have the same email address, thanks

IF you still have your wallet:

This means you still have your private key
This also means you have your public key (you call it the same email address i assume)
syncronize the blockchain on your bitcoin client in case of using bitcoin-qt. This will take some time (+-2 days)
Copy your public key and go to blockchain website and past you key in the search bar. This will show you if the bitcoins still exist.
In case they still exist on the blockchain then once the blockchain has been syncronized and completed it will also appear in your wallet.

If you lost your wallet and you never wrote your private and public key down then they are lost for ever!


Is it possible to assign a single "from" and a single "to" address to Bitcoin transactions? I am working on a project where we need to get the "from" and "to" address for every transaction across a number of cryptocurrencies. In account-based currencies, this is pretty straightforward, but in UTXO-based it's not. Are there known algorithms that "normalize" between the two?

No, Bitcoin transactions cannot be cleanly projected on a single "from address" or a single "to address". Bitcoin can facilitate many payments in a single transaction and there may be multiple senders and usually are multiple receivers.
Even in a simple transaction where one user pays another user, the sender may use multiple inputs, and almost always will assign a change output to themselves. Thus, there is one sender (or more) and two receivers.
Nothing stops multiple users to create a transaction together. E.g. in a PayJoin transaction, the receiver contributes an input to a transaction that pays themselves, thus making it two senders, and one or two receivers (depending on whether there is change).
Two users may also join to make separate payments in one transaction. In a so-called CoinJoin transaction, they each are contributing their own inputs and assigning some funds to receivers and sending change back to themselves. So you might for example have two senders and four receivers.
The challenge gets a whole new dimension when you think about how custodial services work. When you e.g. send funds from an online wallet service or brokerage, the service will often batch dozens of payments/withdrawals together and pay them all from their omnibus wallet. The initiators of the payments and withdrawals do not control any of the addresses that fund the transaction, but are "senders" in the sense that they mandated the payments. The custodian is the actual sender, but may not know who any of the receivers are and is only executing payments on behalf of customers. E.g. sending to any of the "from" addresses of the transaction would likely credit some random user of the service which is neither the service or any of the senders.
There is no such thing as a "from" address in a bitcoin transaction, and you can usually not distinguish whether an output goes back to the sender or to a receiver.
I would suggest that you assume a general case of multiple senders and multiple receivers for each transaction in your model, and track account-based cryptocurrencies as the special case of a single sender and single receiver. Note that even for account-based currencies, a lot of smart contracts also allow sending to multiple recipients in one transaction.


Bitcoin Address Wiki Issue I'm having issues following through the technical wiki here - https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Point 2 says to perform a SHA256 hash on the public key, which I'm understanding is "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6"

When I try and perform a SHA256 hash on this using an online calculator such as http://www.xorbin.com/tools/sha256-hash-calculator I get a hash of 32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce

Can anyone explain to me why I'm getting a different hash to their example given? Am I assuming the wrong public key? Is it only meant to be a segment of that? Or does the wiki have a mistake.

The SHA256 hash tool you're using doesn't decode the hex into binary before hashing it. You can test that by passing in a string that isn't valid hex, like 'fhwdgads.' The wiki article assumes that you do that.

This one will do what you want if you select the "Binary hash" option.


Are there any C# Bitcoin libraries and/or mining pool software packages? I was keen to write/launch a .Net pooled mining server as an exercise of getting into the Bitcoin universe.

Are there any C# ports of the libraries needed to achieve this?

If not

Are there any current tech mining servers that would suit my skill set, C#/Java?

I was keen to build out a site frontend & backend.

Welcome

1) Here's an old project to start from

2) Here is the Bitcoin.it wiki entry on pool servers, including the derelict PoolServerJ

Mining is changing radically right now, with new hardware technology (ASICs) soon to be delivered which will likely increase the network hashrate by some orders of magnitude in the coming months. As a result, the protocols are changing to accommodate this increase, namely to stratum and getblocktemplate, if I recall correctly.

Good luck!


Is there a way to see the precise time of when a transaction was sent out? I'm a developer. I'm not really knowledgeable in bitcoin development, yet.
Say, I'm using Electrum wallet. I share an address with someone. The thing is that I need this someone to pay a certain amount of BTC within a certain time-window, 15-30-60 minutes. It's because I have products that are priced in fiat money.
That person will send me BTC. I may open my wallet not right away but in 12-30 hours, to check incoming payments. Or, even if I open it sooner, there may also be delays in BTC network and I won't see a payment, right?
Goal: to prevent a customer from taking a potential advantage of fluctuation of BTC/FIAT prices.
I don't consider handling my payments via 3rd-party crypto-coin payment providers or their APIs.
Is the precise date and time of when a payment was sent attached to a transcaction and can it be retrieved? How, where?
Can it been seen in Electrum?

While Murch answers the technical side of it already, what you're trying to do is simply not possible. There is no provision in Bitcoin to know the exact time a transaction was broadcast (short of running several nodes that connect to enough of the network to attempt to deduce the first broadcast time).
If you're trying to protect yourself against price fluctuations, your best bet would be to have a system that requires a certain number of confirmations within a time window of your choosing (say, 30-60 minutes). If you have not received BTC in that time period, you can cancel the order. If you receive it after the window has closed, you simply refund the BTC back to the customer and ask them to place a new order (or let them use that BTC amount as a credit against their new order).
This ensures that you only have to sell BTC for fiat within a certain window of time, and if the BTC transaction occurs too far after the order is placed, you return the BTC, without touching fiat at all.


Getmemorypool responses What is the expected response for a getmemorypool RPC call to a standard client, when calling it with data field? I'm mainly interested in such factors as:

Will the call return true if a sent block is not at the end of a block chain (for example, creates a fork or otherwise invalidates some other blocks)?
Will the call return false if the client is BitcoinQT, not bitcoind?
Will the call return true if the same block is submitted more than once?
Will the call return true if the block does not contain all transactions sent earlier, or contains some transactions that the client does not know about?
Are there any other specific cases one should know about when coding for this call?

BIP 22 is the draft specification for getmemorypool, and should answer all the questions you asked.


Merged mining scrypt coins I've been reading around the last day or so on merged mining for coins, in specific scrypt coins but there seems to be conflicting answers, can someone let me know which of the following is correct

a) To merge mine coins they need to be specifically designed to merge mine from the start

b) You can patch a coin to merge mine (if so does the official release have to be patched to accept hashes from different blockchains or can you patch the coin yourself with auxpow to merge mine, will this not fork the blockchain im mining? )

c) This can be implemented by a pool, who submit the pow to multiple blockchains?

a) no need. you can fork your chain with the new chain-id at any time. but the wallets have to know the point of fork. The spanish coin pesetacoin forked the chain  near block 32000. and has no problems.

c) there is (at least) one pool mergemining with 3 main chains (you have to choose one) and 4 aux chains (pesetacoin orgcoin hutercoin and usc) have a look at http://manicminer.in


Which one is more effective for attacking the system, controlling 51% of the mining power or 51% of the full nodes? I used to think it is the miner who verify the transaction, but it turns out this is really a joint work by the miner and the full nodes; the miner broadcasts the newly discovered block, which contains transactions to the network of full nodes, but it is up to the full node to decide whether to accept them.

Then my question is, even if someone controls the majority of the hash rate, if he does not compromise majority of the full node, can the network simply reject to include the blocks that he broadcasts?

51% of mining power would be more effective for attacking the system. if you have 51% of all full nodes, you can't do any attack with your nodes.


How do I join the NXT 2.0 (Ardor) distribution if it isn't an ICO? And how does it affect NXT 1.0 holders? Can someone explain to me how to join the NXT 2.0 (Ardor) distribution? I've been reading you can't buy into the coin initially or can you? Also how does this affect NXT 1.0 system? It seems to be one of the first blockchain to implement a child-chain technology with Proof of Stake mining?

The Ardor launch will happen in 2017, but the distribution of the main ARDR tokens will be based on the Nxt 1.0 balances. And yes, as far as I know it is the first scalable blockchain platform using 100% proof of stake.

Starting the next 14th of July, the Nxt network will take a snapshot of all the account balances every hour. This will last for three months. At Nxt network block 1,000,000 (due for October 12th) every Nxt account will receive an amount of Ardor assets equal to the average of all the snapshots taken - so you'll get as many Ardor tokens as the average of your NXT balance during those three months. So anyone who holds NXT during the snapshots period, regardless of when the NXT were acquired, will participate in the initial Ardor distribution.

After Nxt network block 1,000,000 your account still keeps the NXT you are holding at that block, as usual. And from that moment, ARDR assets also become tradable in the Nxt asset exchange.

When the Ardor network goes live next year, the tokens for the main Ardor chain will be distributed according to the number of ARDR assets held in each Nxt account at the moment of launch. This main chain and the ARDR tokens are the backbone securing the whole network, including all child chains transactions.

As for the Nxt 1.0 system, it will stay running and it will have its own roadmap aside from Ardor.

There's another aspect to keep in mind: as said, Ardor will have a main chain, fueled by the ARDR tokens, that secures all the transactions done in the whole Ardor platform, including all of the child chain transactions that may be created by platform users. The first among these child chains will be included at Ardor launch, and while the main ARDR chain will only include basic transaction types and the staking/forging operations, this first child chain will use a "transactional" token and include all the features currently working at Nxt 1.0, like the Asset Exchange, Voting or the Monetary System.

The token for this first child chain (called "FNX" in development discussions so far) will also be distributed according to the existing Nxt 1.0 balances at the time of Ardor launch, and a percentage of this first child chain tokens will be held to fund the platform development. Initially a 50% of these first child chain tokens was proposed to sustain Ardor funding in the long run, but the percentage is still open and it might be smaller depending on how things unfold in this upcoming months.

So, as a tl:dr;

Nxt 1.0 users will receive at network block 1,000,000 an amount of Ardor tokens equal to the average NXT balance in their accounts from July 14th to block 1,000,000. The NXT will remain in Nxt 1.0 account balances, and then ARDR can be traded in the Nxt Asset Exchange.

At the moment of Ardor launch in 2017, every account will receive an amount of Ardor tokens equal to the number of ARDR assets it holds, and an amount of the first child chain tokens ("FNX") equal to the amount of NXT in their balance at that moment, multiplied by a % coefficient to be determined, but at this moment set at 0.5 (i.e. 0.5 "FNX" for every 1 NXT)


bitcoincore additional questions Following up from my previous question, I still have some questions left.

Does it really work if I turn off the internet before doing getnewaddress? Will it really give me something real and can get the private key while the  offline?

Because for example, bitaddress provides a fake address and private key key if I use it offline when it fails to send the private key to the website owner's database.

Do you think that Bitcoin Core will work offline ? If so will the info be real 100% and valid, or may find out i got fuc**d up after trying to use the address in years to get the btc i sent to it?

As i wish to keep it offline even before the first use, or better to create the getnewaddress and its private key while connected to the internet? Also if it is fine to do generate the address offline, how the blockchain will locate it when i send funds to it while it never been online before?

Also how can I import the address later on any other service? How does it know that the private key I wrote is the real private key of the address? Isn't it strange if there's no big database online for the addresses and private keys?

Your question contains many misconceptions.

Yes, it is perfectly fine and safe to generate private keys and their corresponding addresses completely offline and not connected to the internet. In fact, people recommend that you do this because it is safer than doing it online.

There is no central database (Bitcoin is decentralized) where you must register a private key and address. That is not how Bitcoin works, and there is no need to do this. You don't have to send your address or private key to someone else or register it with the blockchain. In fact, if your private key is sent to someone else, then that person can steal all of your Bitcoin.

If some site or software must be online to generate keys and it is sending the keys to the site owner, then DON'T USE THAT SITE. The owner is trying to scam you and steal your private keys, which means they can steal all of your Bitcoin.

Private keys can be safely generated offline because of mathematics. A private key is really just a very large number. The cryptography that Bitcoin uses defines a private key to be any integer between 0 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, that's a lot of private keys. Any integer in that range is a valid private key. So Bitcoin Core and other key generation software will just generate a random number that is within that range. Because the range is so large, and because (in theory) good random number generators are being used, the probability that a private keys that you generate were also generated by someone else is so small that it is, for all intents and purposes, 0.

So any software where you can import that private key will recognize it as being valid and correct so long as the private key is within that range. From there, the public key can be computed, and from that, addresses.

You don't need to be online and register any addresses you create either. That is because the blockchain does not actually use addresses. It does not need to be able to find your address either. On a low level, the blockchain uses transaction outputs. When you create a transaction, it spends transaction outputs from other transactions, and creates new transaction outputs. These outputs are composed of two parts - the amount, and a spending condition.

Addresses are just a human readable way to represent the spending condition. When you send Bitcoin to an address, what you are actually doing is telling your wallet software what the spending condition for one of the outputs should be, so it will create a transaction with an output with the appropriate value and spending condition.

With most addresses (the kind that are associated to a private key), the address contains the hash of a public key. That private key for that public key is held by the person who gave you that address. When that person spends the Bitcoin you sent them, they consume the output you sent them and provide the public key and a digital signature. So the spending condition is that the spender must provide the public key whose hash matches the hash specified in the output, and a valid digital signature created using the private key corresponding to that public key.

So, addresses are not really identifiers or accounts that the blockchain needs to lookup, rather they are just a human readable way to specify the spending conditions for outputs. Thus there is no need to register addresses with anything. Furthermore, the blockchain doesn't even care what the spending conditions are. They could be completely invalid. The spending conditions are really just a blob of data and they are not checked in any way when a transaction is created. The spending conditions are only checked when the output is spent.


How to have my bitcoin-cli connect to an outside fullnode I don't want to run a full node in my laptop. I rather want to install bitcoin-cli only and configure it to connect to an external full node. Is that possible?

If so, two questions:

where can I get a list of full nodes?
where can I record a full node from the above step in my bitcoin-cli

This is just for a quick test of bitcoin-cli. If there is other way to do this without setting up a full node myself, that works as well

configure it to connect to an external full node. Is that possible?

Technically yes, but in practice, no. bitcoin-cli connects to a bitcoind via the RPC interface. This interface is typically not exposed to the internet nor are all IP addresses typically allowed to connect to it (specific IP addresses or CIDR blocks need to be explicitly allowed by the node operator). This connection limitation is because access to the RPC interface allows access to the wallet and can result in potential coin loss. Additionally, you will need to know the RPC username and password in order to connect.

So, in actuality, you probably won't find any bitcoinds with open RPC interfaces that you can connect to, and since the interface is authenticated, you probably won't be able to connect to any node. You will need to have explicit permission from the node operator.


Maximum number of block erupters raspberry pi can handle? I'm trying to figure out where the bottle neck in terms of bandwidth would be.

Assume:

no other processes running on raspberry pi (700MHz processor, no
overclocking)
no limit on internet up/down rates no limit on power of
external USB hub (5V, 12A power supply)

What is the maximum data rate that the usb bus can handle?
What is the maximum data rate a block erupter could ever need (I don't know how to convert Hashes/s to Bytes/s on the USB bus)

Are there tools I can use to grab these numbers (e.g. some utility like netcat?)

Can I put a 10-port usb hub in each of the two raspberry pi usb ports?

You can probably go up to the maximum of 127 devices if you really wanted (the USB2 limit), remembering though that the Ethernet adaptor is one, and each hub also counts in one. Word on the street also indicates a 49 Eruptor limit, though that's probably just a software limitation.

The transfer speed will never be an issue.

The CPU speed will never be an issue.


Output and bitcoin spent what does it mean? I need help Hope you are doing well, I'm new to bitcoin. Please does this mean I received $61.213.88 in my account? Or the total output of all my transactions it shows 2 bitcoin addresses under, what does "spent" mean? And all the addresses are invalid when I look them up. THANKS

This transaction just means that, some time in the past, someone transferred an amount of Bitcoin (BTC) to two recipients, one was probably a second person providing goods or services to the first person, the other recipient was probably change being returned to the first person.

The amount of Bitcoin was roughly equivalent to $61,000 at some point in time.

Both the recipients subsequently spent the received amounts in further transactions.

It is possible that either or both recipients now control 0 Bitcoin.

It is possible that either or both recipients now control millions of Bitcoin.

Only the recipients can tell for sure. Their Bitcoin wallets will tell them.

Let's say B is new to Bitcoin and wants to buy some for 150 Canadian dollars. B meets a millionaire A who is willing to sell some. B gives A the 150 Canadian dollars. A does the Bitcoin equivalent of reaching into their back pocket and taking out a crocodile-skin wallet. A looks inside sees seven $1000000 banknotes and a $61,234.56 banknote∆. A gives B the $61,234.56 banknote and B then gives A a $61,134.56 banknote in change. B now has $100 more, A has $100 less.

A and B then immediately spent all their  money on a superyacht and a pair of trainers and are now broke.

Or maybe not.

∆ Such things exist in the cryptocurrency world.


What is the "sequence" and its details as referenced for the segwit application? On the segwit page there is a reference that the "feffffff" is the "sequence".  What does the "sequence" represent in relation to what?  Does it always have to be "feffffff"?  What happens if it's "feffffff" instead of "ffffffff"?  Does it help anything, does it hurt anything?  Am I just fine using just "ffffffff" instead of "feffffff" What other options are there and what do they mean?

Sequence is part of any input, before segwit as well. feffffff is the hexadecimal number 0xfffffffe because the bytes need to be reversed. This sequence number, as per BIP 125, is because:

  Wallets that don't want to signal replaceability should use either a max sequence number (0xffffffff) or a sequence number of (0xffffffff-1) when then also want to use locktime;

So this sequence number uses the locktime but does not signal replaceability

If instead you used 0xffffffff, the sequence number would have no effect on the transaction.

If you don't know what locktime is, check out this question: What is Bitcoin's locktime feature exactly? How can it be used?


Is there a chart of all combined orderbooks? I would like to view a chart where all bid/asks are combined from the various exchanges, instead of keeping multiple tabs open for each exchange. Is there a website that allows this kind of meta-overview?

All of the exchanges have APIs http://pubapi.cryptsy.com/api.php?method=singlemarketdata&marketid=155
you can create a script to keep the numbers updated with wget and a cron job
Cryptsy has a pusher API for live updates.
https://www.cryptsy.com/pages/pushapi


Do I need Bitcoin-qt to run Armory? Do I need Bitcoin-qt to run Armory? I keep hearing conflicting information.

My goal is to mine bitcoins in a pool, so ideally, I want a very secure wallet, and I would prefer not to download the entire blockchain if I don't have to.

Armory by default doesnt run Bitcoin-qt, it runs Bitcoind. Since armory installs the entire Bitcoin reference client by default, Bitcoin-qt will be present regardless (you can try to delete it, though):

  Bitcoin-Qt is the “Graphical User Interface” around the core Bitcoin
  protocol that is run by the majority of nodes on the network.
  ”bitcoind” is the same software but without the user interface — it is
  simply a process that runs in the background and only allows access to
  it through its API.  For the purposes of running Armory, either one is
  sufficient, but one of them must be running and synchronized.  The
  latest version of Armory will run bitcoind for you in the background.

Armory/Bitcoind does need to download the entire blockchain:

  Regardless of which one you use, it will download the entire
  blockchain

Source for both snips: https://bitcoinarmory.com/about/armory-and-bitcoin-qt/


What is the "Bitcoin Address" for standard multisig transaction? Question

A standard multisig transaction is:

scriptPubkey = m <p1> ... <pn> n OP_CHECKMULTISIG
scriptSig = OP_0 <s1> ... <sm>

Where: 1 <= m <= n <= 3.

Note, that it is not P2SH transaction!

So, what is the Bitcoin Address for this transaction?
In case of escrow, what Bitcoin Address should be provided to the trading parties?

Short glossary

p = public key

pH = public key hash, RIPEMD(SHA(public key))

sH = hash of serialized script, RIPEMD(SHA(ser. script))

C = first 4-bytes of SHA256(SHA256(data), where data is

X = bitcoin address prefix (0x00 for P2PKH transaction, 0x05 for P2SH transaction)

0pHC = concatenation of bytes (0: 1-byte, pH: 32-bytes, C: 4-bytes)

Bitcoin Addresses

P2PK transaction

The "Bitcoin Address" for P2PK is Base58(XpC), where "X" (bitcoin address prefix) is not currently defined for P2PK transaction type. See https://en.bitcoin.it/wiki/List_of_address_prefixes.

Where:

X is the bitcoin address prefix (for example, 0x02)
p is the public key
C is the checksum (SHA^2(public key))
XpC is the concatenation of X byte, p string and C 4-bytes

P2PKH transaction

The "Bitcoin Address" for P2PKH transaction is Base58(0pHC).

P2SH transaction

The "Bitcoin Address" for P2SH transaction is Base58(5sHC).

So, again, what may be the Bitcoin Address for standard multisig transaction?

Thanks,
--- Kosta Z.

A standard multisig transaction does not have a bitcoin address. This is precisely why it is wrapped as the redeem script of a P2SH bitcoin address.

Raw multisig transactions are not used anymore.


Validation Error: Error #-26: 258: txn-mempool-conflict I am getting this error message. What does it mean?
Validation Error: Error #-26: 258: txn-mempool-conflict

This error means that you're trying to spend the same transaction output more than once.

More specifically, when you submit a transaction, a check is done (on the node) against the previous outputs of your new transaction to see if they are already trying to be spent by a transaction in the memory pool.

The check is in validation.cpp in the bitcoin source:

// Check for conflicts with in-memory transactions
std::set<uint256> setConflicts;
for (const CTxIn &txin : tx.vin)
{
    auto itConflicting = pool.mapNextTx.find(txin.prevout);
    if (itConflicting != pool.mapNextTx.end())
    {
        const CTransaction *ptxConflicting = itConflicting->second;
        if (!setConflicts.count(ptxConflicting->GetHash()))
        {
            // Allow opt-out of transaction replacement by setting
            // nSequence > MAX_BIP125_RBF_SEQUENCE (SEQUENCE_FINAL-2) on all inputs.
            //
            // SEQUENCE_FINAL-1 is picked to still allow use of nLockTime by
            // non-replaceable transactions. All inputs rather than just one
            // is for the sake of multi-party protocols, where we don't
            // want a single party to be able to disable replacement.
            //
            // The opt-out ignores descendants as anyone relying on
            // first-seen mempool behavior should be checking all
            // unconfirmed ancestors anyway; doing otherwise is hopelessly
            // insecure.
            bool fReplacementOptOut = true;
            if (fEnableReplacement)
            {
                for (const CTxIn &_txin : ptxConflicting->vin)
                {
                    if (_txin.nSequence <= MAX_BIP125_RBF_SEQUENCE)
                    {
                        fReplacementOptOut = false;
                        break;
                    }
                }
            }
            if (fReplacementOptOut) {
                return state.Invalid(false, REJECT_DUPLICATE, "txn-mempool-conflict");
            }

            setConflicts.insert(ptxConflicting->GetHash());
        }
    }
}


I want withdraw from BitPay and send USD to bank account in Puerto Rico. I reside in Argentina. Is that possible? I want to withdraw/sell bitcoins that I have on my BitPay wallet. I need to transfer the results USD to account in Puerto Rico. I reside in Argentina.

I have already tried with Skirll, but does not allow Puerto Rico bank account.

You might need to list them for sale on a site like Coinbase (?) to convert them to USD. Then you would use your PR account to deposit the funds into. From there its a regular bank transaction of USD to Argentina or wherever.


What would happen if two public keys had the same Base58 hash? If two different public keys had the same Base 58 hash, what would happen?

Could one key spend money in the other account?

What would happen to the monies received by the shared base58 hash?

Then both of the people could spend the same coins if they were sent to their Address, rather than public key. If they instead received the money to the public keys, they couldn't spend eachother's coins.

All in all, the most important thing that would happen is that they would show RIPEMD-160 collision, which would most likely be the first one ever. A pretty improbable sight.


What are the advantages for an user that is running a Bitcoin full node? I am running a Bitcoin full node Bitcoin core version v0.19.1 (64-bit).

I know that is one of the most secure wallets, but the process to set up a full node is very painful, and even if you keep this full node running 24/7 you won't get paid.

So I just would like to know what are the advantages for an user that is running this full node, I only can think that the network will be benefit with that somehow, but I can't see any advantage for the user.

You validate your own UTXO without any external services that may play for your disadvantage, no middleman needed
It's the most privacy-preserving and secure way of using bitcoin. Lightweight-clients have some privacy issues, not too many people are reviewing their code.
The process of setting it up and using bitcoin core is a major step in one's education when it comes to bitcoin. More knowledge = advantage.
You have some voting power on consensus rules, like in UASF.


What problems identified with bech32 addresses have been resolved with the updated bech32m? What problems identified with bech32 addresses have been resolved with the updated bech32m?
I am aware of one problem with the original bech32, namely length extension mutation weakness but I don't know if there were any others.

As far as I can tell "length extension mutation weakness" is the sole problem that needed to be resolved and is resolved by bech32m. But "length extension mutation weakness" includes both insertion and deletion.

Insertion: if a valid Bech32 string has the suffix p, inserting a single q character immediately before the p will produce another valid Bech32 string.
Deletion: if a valid Bech32 string has the suffix qp, removing the q character will produce another valid Bech32 string.

There are also more complex insertions and deletions that are possible than just "q before final p" too (see Pieter's comment at the bottom) though I haven't found this documented anywhere thus far.
To resolve this problem a new checksum algorithm has been designed by:

replacing the constant 1 that is xored into the checksum at the end with 0x2bc830a3

Bech32m encoding will only be used for SegWit output versions 1 and above. Version 0 will continue to use bech32 as the length extension mutation weakness does not present a problem for version 0 as SegWit v0 addresses are restricted to two specific lengths (No such length restrictions are currently imposed on higher SegWit version addresses.) They are defined to only be 42 characters (P2WPKH) or 62 characters (P2WSH). Although technically you could insert 20 q characters to make a P2WSH address with a valid checksum from a P2WPKH address, the checksum is not designed to guard against adversarial situations or insertions this large. The goal of the checksum is to protect against typos, copy paste errors, transcription errors, errors from being relayed as spoken words.
Pieter added on GitHub:

I think it's a bad idea to have multiple addresses valid for the same scriptPubKey. It only results in confusion when decoding/recoding doesn't roundtrip. v0 outputs use bech32, and I don't think this should ever change, for better or for worse. It also worsens error detection to 29 bits (as every v0 output now has two valid checksums).

Once you have proposed two different encoding schemes (bech32 and now bech32m) this presents a challenge to wallets of knowing which encoding is used and the bech32m draft BIP hence decides to make the two entirely incompatible ie it is impossible for a bech32m address to be a valid bech32 address and vice versa.
Thanks to Pieter Wuille and Russell O'Connor for some corrections on the original post.


Bitcoin sent to Bitcoin Cash address in blockchain I sent bitcoin to a bitcoin cash address in my blockchain account. Are the coins going to the account and if not what if anything can I do to recover my bitcoins?

If you have the private key of the bitcoin cash address, you can import it into your bitcoin wallet and send it somewhere else.
If not, you have to ask the one, who has its private key, for example an exchange.


Musig Signature Interactivity 2 Questions:

Why is Musig signing always interactive?
Let's say I have a Musig wallet where keys are stored in secure locations with no internet access. What are some methods to sign from these secure, offline locations given Musig interactivity constraints?

MuSig is interactive because each signer needs to provide a signature nonce (effectively randomness) before signing. This is not specific to MuSig, but applies to any discrete logarithm-based multisignature scheme as far as I know.

Now to understand why multiple communication rounds are necessary let's look at what happens at each of them, starting from the last, the third round:

Round 3 Every participant creates a partial signature with their secret key. The sum of the partial signatures is the final signature. In order to compute the sum the signers must send their partial signatures. That's one communication round.
Round 2 In order to create a partial signature, the signers have to compute the hash of the combined public nonce R. This is the sum of the individual signer's nonces R_i. The nonces are somewhat similar to public keys in that they are random points whose discrete logarithm is unknown to everyone else Broadcasting R_i is another round.
Round 1 The reason for the first round is the most difficult to understand. If the signature hash would just consist of the sum of R_i's then an attacker would have control over the outcome of the hash function. For example, the attacker could first collect every other signers R_i and then choose his R_j such that the hash output is odd. This specific example would not be helpful to the attacker, but what he can also do in a similar way is to mount a Wagner's attack which results in signature forgery. This is why in the first round, the signers send a commitment (for example SHA256(R_i)) of their nonces. Therefore they have to choose their nonce before seeing the other nonces, because they will only be revealed at round 2.

While this is a relatively intricate dance where quite a few things can go wrong, our implementation in libsecp256k1-zkp should be misuse resistant provided that you

Never reuse a session id. The id can be the output of a cryptographic random number generator or an atomic counter.
Never copy a signing session state. Otherwise, nonces will be reused which results in a direct leak of a secret key. Also, it allows active attacks, such as Wagner's attack.

Now it should be easy to see that offline signing is difficult with MuSig. Before shutting down the signing device you need to store active MuSig sessions on a persistent medium. That's effectively a copy of the state and very dangerous. You need to be sure that you load the correct session state when powering up again and not a corrupted or old or wrong session. For that reason, the libsecp256k1-zkp implementation does not support serializing the session state right now. However, there are some ideas for how to design a serialization format that is maximally misuse resistant.

Another aspect is that nonce commitments can be safely "pre-shared" before a message is known. That means that when setting up your offline signing devices, you start multiple sessions in parallel and exchange the nonce commitments. Then, when you want to sign a transaction, you only need to go there twice, first to get the actual nonce and then to get a partial signature. If you have only one device at a remote location you can make it so that you only go there once (by having all other decommitted nonces ready when you go there). It's important to note that as opposed to nonce commitments, nonces can not be pre-shared because that would allow yet another Wagner's attack.

There is research in progress to effectively remove the nonce commitment round and the whole session state with zero knowledge proofs. This is exciting for the offline signing case, but of course also brings increased implementation and computational complexity.


Should Account-level in BIP32/BIP44 be Hardened? Let's say we have an ETH trading exchange where we employ BIP32/BIP44 to generate a unique wallet address for each user. For simplicity, each user uses the same wallet address
(unique to each user) for all subsequent deposits/withdrawals.

For safety reasons, we have a hot/online wallet and a cold/offline wallet, where the hot/online wallet is handled by a service (say a NodeJS app) that only contains an extended public key and not the mnemonic/seed of the HD Wallet root node.

We also use the derivation path structure similar to BIP44

  m / purpose' / coin_type' / account' / address_index

Question 1: Is it generally practised to let each user have a different account level node? Eg: User 1 has m/44'/20'/1, user 2 has m/44'/20'/2', etc.

Question 2: Assuming the above question is correct, should the account level key be hardened or not hardened?

From my (poor) understanding so far, If we use m/44'/20'/0 instead of m/44'/20'/0', we only need to the extended public key for m/44'/20' to generate deposit addresses for each user m/44'/20'/0, m/44'/20'/1, etc.

However if we use m/44'/20'/0', we need the extended private key for m/44'/20' to generate deposit addresses for each user, and this is less secure because if the extended private key on the online/hot wallet app is compromised instead of the extended public key, all the funds can be stolen.

Lastly, what is the best practice for implementing BIP32 in such an application (trading exchange, marketplace, etc)? Does the app that handles the wallet and holds the keys communicate via a REST/websockets/jobqueue method with the other services that accepts user input to request withdrawal/deposits?

For simplicity, each user uses the same wallet address (unique to each
  user) for all subsequent deposits/withdrawals.

Realistically, this wouldn't be the case - maybe for withdrawals but not for deposits as it gives away too much informations about the individual user. You should track balance by user in a different schema and use invoices to handle payments and withdrawals. The reason I bring this up is because you're asking what is general practice in Question 1.

  Question 1: Is it generally practised to let each user have a
  different account level node? Eg: User 1 has m/44'/20'/1, user 2 has
  m/44'/20'/2', etc.

I wouldn't. This system not only links the money in the system, it also links who has how much money.

  Question 2: Assuming the above question is correct, should the account
  level key be hardened or not hardened?

As you mentioned the derivation path is as such

m / purpose' / coin_type' / account' / change / address_index

This means the account depth should be hardened. Failure to do so will be an anomaly and if I put the master private key in a different wallet, different addresses will be generated. So the answer to your question is yes, it should be hardened.


Why is the output address a list in RPC/console? Vout contains a list of addresses, which I noticed to be always with size = 1, if it exists. The following is an example from Bitcoin Testnet:

{
      "value": 0.91840581,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 1416b8f3a1c1c7e3e73a05046f002e66004accc3 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9141416b8f3a1c1c7e3e73a05046f002e66004accc388ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mhMB2g88n42ghQ5p1VA7Mt9VgTp9QvpDXU"
        ]
      }
    }

Why is the "addresses" (address) field a list? Are there any cases when this can take more than one address? Who can spend that then?

This is due to historical confusion between addresses and keys.

The original goal of this field was reporting the public keys involved in raw multisig outputs. However, those public keys were referred to by the P2PKH address corresponding to them.

This is confusing because obviously every output only corresponds to a single address. The feature is also useless now due to the introduction of P2SH, where instead of putting all public keys in the output, just a hash of script involving all those keys is stored.


What does a double spend (CVE-2018-17144) look like if I gettransaction it? Just wondering what the output from gettransaction (or should I be using getblock?) would look like if I passed it a txid(or blockhash) that contained a set of transactions that exploited the double spend bug CVE-2018-17144? Is it distinguishable from a normal, non double-spend? Does the wallet being queried have to know about both the addresses spent to, in order to show anything out of the ordinary?


Why hardended xpub key cannot generate child public key? I'm trying to understand bip32 hardened mechanism, but I'm confused about it.

I got xpubKey from this site, and what I'm trying to do is demonstrate failure when trying to generate child pubkey from hardened xpubkey.

Here's my test details.

network : bitcoin testnet
mnemonic : dash axis fat pilot truly river guitar sea tonight popular type ill inmate quote upset
parent path : m/44'
parent xpubKey : tpubDA4h4NTsxqEXATU9dPS22ZVuBHd2jVketkP8RNhBZ6fMhW9WuMhrjf37qNmfmLQZoFreLmHf9LsTnvW2eJYx1fkzo7vVxsf7bKVixz2FjGw
target child path : m/44'/0 (non regular, just for test)

and I wrote some js code, and I assumed to fail, but succeeded.

const bitcoinjs = require('bitcoinjs-lib');

const xpubKey = 'tpubDA4h4NTsxqEXATU9dPS22ZVuBHd2jVk...';

const parentNode = bitcoinjs.bip32.fromBase58(xpubKey, bitcoinjs.networks.testnet);

////////
// I THOUGHT BELOW WILL FAIL!
////////

// trying to get m/44'/0
const derived = parentNode.derive(0);

// result was valid public key for m/44'/0
console.log(derived.publicKey);

In my thought, if I have a valid xpubKey(hardened or not), means that I have a valid chain code and public key for current node (means that I can derive children).

So what's meaning of

  Hardened public keys cannot derive any children?

FYI, I quoted that in this video (20:24).

Non-hardened parents effectively use the public key to derive their children, where hardened parents derive their children from the private key.

The derivation of a child private key from a non-hardened parent private key k uses the following hash function:

HMAC-SHA512(chainCode, point(k) || i)

We know that K = point(k), where K is the parent public key. Thus, if we only know K and not necessarily k, we are still able to derive the child key by replacing point(k) with K, and follow the regular process.

With hardened private keys, the hashing is done differently:

HMAC-SHA512(chainCode, 0x00 || k || i)

Here you can see that there is no possible way that you could compute this hmac without knowing k. Just knowing the public key K will not help.

It looks as though you need to use the deriveHardened function in bitcoinjs rather than plain derive.


Could this stop double-spending? Let's say you have a 15 second block time, and after your first transaction, your wallet's send button is frozen, and you have to wait for 2.5 minutes before you can send another transaction.

Would this prevent somebody from doublespending?

BTW: in case you want to ask how this could be enforced on the send button: Hmmmm maybe with something like scrypt which is timebased.

Double-spending has nothing to do with double clicking the send button.

It involves a malicious user, who will not use the standard client. It will hack one to avoid any client-side limits, sending two transactions to a different side of a blockchain fork, so both sides don't know about the transaction sent to the counterpart and includes the transaction in their forked version.

If you manage to do so while using both transactions to pay for something and are accepted, after the reorganization (the process by which forks are resolved) only one side of the fork will be mantained, so the blockchain will be OK as only one transaction will be kept, but you got both payments effectively using the same coins to pay two different merchants and one of them will lose what you paid.

As you can see, it is not an usual scenario. Forks are more or less common but not really deep as they typically get resolved within a single block. That's why it is recommended to accept a transaction only after six confirmations, as a fork of six blocks is almost impossible to appear under normal circumstances. But do note that even this has happened, when a bug between software versions kept some miners from agreeing to mine on what would otherwise have been the consensus branch.


Which software can I use to setup an e-wallet site? I am relatively new to Bitcoin and I have a very simple question: what wallet software is behind "online wallet sites" like http://www.blockchain.info? I would like to set up a mini-site to store my/friends online wallets and I guess I would need a daemon-shell-based Bitcoin wallet software.

Where should I start to do so?

Most eWallet services would probably be using the standard Bitcoin client running in the server mode. You would then control it through the use of the JSON RPC commands.

But for personal use, you probably want to just use existing eWallet solutions, or commission someone to help you set your wallet up taking into account such concerns as data security, proper wallet backup and so forth (shameless autopromotion - you can contact me;) ).


Bitcoin Core v0.21 RPC credentials going bad I have tried to upgrade to bitcoin core 0.21 but things are not going good. I need some help.
I'm using Debian Buster.
I was using bitcoin core 0.20.1 before.
The folder locations are as I have in my config file:
dbbatchsize=4294967000
dbcache=12288
par=1 -daemon
server=1
maxtxfee=0.00002000
mintxfee=0.00000002

\# Options only for mainnet
[main]
conf=/media/WdElements/blockchain-backup/bitcoin.conf
datadir=/media/WdElements/blockchain-backup
debug=net
debug=rpc
debuglogfile=/media/WdElements/blockchain-backup/debug.log
addresstype=bech32
changetype=bech32
txindex=1
listen=1

When I start bitcoin daemon I see the following output:
2021-01-24T15:24:36Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:24:36Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146
2021-01-24T15:24:41Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146
2021-01-24T15:24:41Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:24:45Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:24:45Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146
2021-01-24T15:24:49Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146
2021-01-24T15:24:49Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:24:53Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:24:53Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146
2021-01-24T15:24:58Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146
2021-01-24T15:24:58Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:25:02Z ThreadRPCServer incorrect password attempt from [::1]:34362
2021-01-24T15:25:02Z ThreadRPCServer incorrect password attempt from 127.0.0.1:36146

I already tried to generate my RPC credentials from ./share/rpcauth/ python plugin like this:
$ python3 rpcauth.py btc-user
String to be appended to bitcoin.conf:
rpcauth=btc-user:[REPLACEDHASH]
Your password:
[REPLACEDPSSWD]

and paste the first line into bitcoin.conf  like this:
dbbatchsize=4294967000
dbcache=12288
par=1 -daemon
server=1
rpcauth=btc-user:[REPLACEDHASH]
maxtxfee=0.00002000
mintxfee=0.00000002

\# Options only for mainnet
[main]
conf=/media/WdElements/blockchain-backup/bitcoin.conf
datadir=/media/WdElements/blockchain-backup
debug=net
debug=rpc
debuglogfile=/media/WdElements/blockchain-backup/debug.log
addresstype=bech32
changetype=bech32
txindex=1
listen=1

but I still get the same error messages when I start bitcoind as bitcoind:
2021-01-24T15:32:19Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:19Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690
2021-01-24T15:32:23Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690
2021-01-24T15:32:23Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:27Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:27Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690
2021-01-24T15:32:31Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:31Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690
2021-01-24T15:32:36Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690
2021-01-24T15:32:36Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:40Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:40Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690
2021-01-24T15:32:44Z ThreadRPCServer incorrect password attempt from [::1]:35906
2021-01-24T15:32:44Z ThreadRPCServer incorrect password attempt from 127.0.0.1:37690

Anyone can help me figuring out what might I be doing wrong?

Ok, I managed to find the culprit. It's actually an application I have running in the background that I simply completely forgot about it and it is trying to access to the RPC interface and as I have never paid too much attention to it, I think I never setup anything related to RPC in it. So, most probably that's the problem.
I used netstat -p -at and ps -ef to figure out what exactly was interacting with bitcoin core daemon.
Thanks every one. I think this one is solved.
Psy


Blockchain API support - receive payment IPN I'm having some real trouble setting up the Blockchain API on my server

First off is it possible to test it offline with local host?

Secondly, how do I set it up so when a tx is made through my site, it runs a php function to update a database with certain values

Has anyone successfully set up the API before and if so could they please walk me through how I would do it

Thanks

It is possible to test it offline. Check your phpinfo() to confirm, but I perform operations with the blockchain API from my XAMPP server all the time, as I am currently working on a site that uses the API. All you're doing is sending a request to a URL (like when you loaded this page) and getting the contents of that file. If you're interested, check out this class I wrote for using the blockchain API with PHP: https://github.com/lukesims/Blockchain-API-PHP-Class

With that, you could ad more functions or modify it to interact with your database simultaneously.


Can one tell which way the market goes from sell and buy orders? Among other open access (i.e. public) data available in exchange API's are the open order books. They are given on exchange websites sorted by coin value. Is there a way to tell which way the market is going, as in up or down for a given pair, from sell and buy order books?
If the only way is by taking two snapshots of these data, would that be a good way to do it, or is there a better way, using public API's?

Market direction, as with any direction, only applies when you have more than a single data point.

So, the value of the trade at t-1 compared to the value of the trade at t can tell you if the market moved "up" or "down".  The value of t, by itself can only ever tell you the value of t.  There is no way to determine direction or velocity from a single point value.

If an individual API provides direction, then you could use that; however that is up to the individual API to provide.


BitWasp Installation Problem I just uploaded the BitWasp code into /var/www but when I tried to install using extension BitWasp-master/install/index.php the installation page that I need to make config.php, database.php, and bitcoin.php files writable. And when done I should press F5.

How do I make these files writeable? I don't have permissions to view the contents of those files.

Please help! Thank you

Most likely, you need to change permissions on those files:

$ chown apache config.php database.php bitcoin.php
$ chmod g+w config.php database.php bitcoin.php

Of course, if you're not using apache or the groupid of the webserver you're using is different, you might need to change "apache" to something else.

Read up on linux file permissions to understand this stuff better.


Can government agencies trace if I mine bitcoin? I live in a country where the government has strict rules against using bitcoin. in fact, they are trying to find out the citizens who are related to bitcoin. I was just wondering if they can catch me if I just mine bitcoin without doing any transaction? if yes then I wanted to know if there are any alternatives which can make me untraceable.

Data linking is the only way there is any question of privacy. When you transact with Bitcoin, the goods or service you order will need to have a delivery address. Also, if you send your BTC to any merchant, service or, an exchange that has your personal data there will be a presumption that the sender was the owner of the inputs used and is the person that they have records for. There is no known way around this.

Apart from that question which exists for all cryptocurrencies, you may wish to consider implementing some of the configuration for privacy from here for your mining setup. Sound advice is, do not break the law.


Should earnings in Bitcoin converter to a traditional currency be treated as trading-income or non-trading income for tax purposes? Should earnings in Bitcoin converter to a traditional currency be treated as trading income or non-trading income for tax purposes (for example, in Ireland)? Reason for them being considered trading income is that the Bitcoins need to be sold at an exchange like a commodity. On the other hand, a business gains Bitcoin not necessarily through trading them for goods (say, SatoshiDice), so the other option appears viable.

Which approach should be taken into consideration when figuring out taxes?

You might not like this answer but the correct approach for figuring out taxes related to Bitcoin earnings is to ask the question to your local tax authority, in written form and get an answer that your local tax administration legally commits to.

I can speak only for France, but I assume the same kind of thing is possible anywhere. In France you can ask for a "rescrit" it is a written answer from the FISC (our tax authority). Once they gave you an answer they are legally obliged to stand by it.

There is no other correct way to account for your Bitcoin taxes than asking the people that actually can give you a definitive and legally binding answer.


Finding Transactions with seldom used opcodes for testing I'm trying to implement a script evaluator and would like to get some real testing data from the blockchain (testnet or mainnet). Are there transactions whose input scriptSigs combined with the previous transaction's scriptPubKey use any/all of these op_codes? I'd like to compile a collection of such transactions as test vectors.

98: op_ver,
101: op_verif,
102: op_vernotif,
107: op_toaltstack,
108: op_fromaltstack,
109: op_2drop,
111: op_3dup,
112: op_2over,
113: op_2rot,
114: op_2swap,
115: op_ifdup,
116: op_depth,
119: op_nip,
120: op_over,
121: op_pick,
122: op_roll,
123: op_rot,
125: op_tuck,
139: op_1add,
140: op_1sub,
143: op_negate,
144: op_abs,
146: op_0notequal,
147: op_add,
148: op_sub,
154: op_booland,
155: op_boolor,
156: op_numequal,
157: op_numequalverify,
158: op_numnotequal,
159: op_lessthan,
160: op_greaterthan,
161: op_lessthanorequal,
162: op_greaterthanorequal,
163: op_min,
164: op_max,
165: op_within,
168: op_sha256,
170: op_hash256,
171: op_codeseparator,

I did some digging with a parser I wrote and found 6 transactions that test a lot of the op codes:

efdf1b981d7bba9c941295c0dfc654c4b5e40d7b9744819dd4f78b8e149898e1
9aa3a5a6d9b7d1ac9555be8e42596d06686cc5f76d259b06c560a207d310d5f5
c5d4b73af6eed28798473b05d2b227edd4f285069629843e899b52c2d1c165b7
74ea059a63c7ebddaee6805e1560b15c937d99a9ee9745412cbc6d2a0a5f5305
e335562f7e297aadeed88e5954bc4eeb8dc00b31d829eedb232e39d672b0c009
dc3aad51b4b9ea1ef40755a38b0b4d6e08c72d2ac5e95b8bebe9bd319b6aed7e

These are all on testnet and test a very large number of the OP_CODES I requested. Here are still ones I'm looking for:

op_reserved
op_reserved1
op_reserved2
op_ver
op_verif
op_vernotif
op_2rot
op_2swap
op_1add
op_codeseparator


Where to find last x hour/minute trading volume for a given coin Coinmarketcap shows trading volume for the last 24 hour. Where can I find trading volume for the last x hour/minute? Or How can I calculate it myself programmatically?

cryptocompare has the utility you need.

Go to Coins at the top, find your coin
Analysis
Change the bar graph at the bottom to display by Hour
Use the interface to see the volume per second

If this is too unwieldy, cryptocompare does have an api and a useful npm package to play around with.


bitcored + vmware: disk space increases INCREDIBLY fast I installed ubuntu-16.04.3-desktop-amd64 within a vm maschine from vmware. After downlading and installing bitcored (I did these steps: https://bitcore.io/guides/full-node) the blockchain starts to syncronize but keeps adding disk space incredibly fast.
Insight says the blockchain is 1 % synced and already takes 30gb+ (I just installed ubuntu and there is nothing more on this system). Maybe this is some error with cache/temp not beeing deleted after progressing a block or something?

If I let it run it creates 400gb+ until the virtual maschine crashes. After that, vmware is not able to start the vm again. (current bitcoin blockchain is <200 gb. I dont know why this thing needs to write 400gb+ of data to my disk space).

Opening "disks" on ubuntu says the system uses ~13gb (which should be right). Where does the other endless GB come from?

Any help is highly appeciated!

It may be because of the nature of the entire blockchain, and the virtual disks itself. 400Gb+ can be the blockchain obtained from the network, temporally persisted, and 13Gb seems to be the amount that is really persisted.

Those numbers are fine in orders of magnitude when operating a full bitcoin node. To control the grow of the space, maybe creating a fixed-size virtualbox will help


Who controls the Bitcoin software? Is there anything comparable to a "board of directors" for Bitcoin or is the software on complete cruise-control?

There are a number of "core" developers. And the ones who have access to commit directly to the Github project obviously have more "power" than other people. Since the software is open source you can of course make your own copy of it and modify it to your likings but you won't be able to change any of the "rules" of the network unless you get the rest of the Bitcoin world to follow you and use your client.

According to bitcoin.org the core developers are Satoshi Nakamoto, Gavin Andresen, Pieter Wuille, Nils Schneider and Jeff Garzik. According to a recent message on the Bitcoin Development mailing list Wladimir (J. van der Laan?) is now also part of the core development team. Obviously Satoshi is not anymore, so I don't know how accurate the list on bitcoin.org actually is.

The ones who have push access to the Github project are according to this message:

Gavin Andresen
Nils Schneider (a.k.a. tcatm)
Pieter Wuille (a.k.a. sipa)
Jeff Garzik
Alex Waters

Gavin, who is the lead developer is active here so I'm sure he can give us a clearer answer himself. Also see Is there a list of core Bitcoin committers?


Second wallet needed to mine BTC? I am being invited to invest small amount of BTC. I am being asked to create second wallet. Is this legitimate?  I am trying to understand the mining process,  I did not think one needed to use bitcoin to mine more bitcoin.

I am trying to understand how this works, excuse my slow learning.

Thank you,
Andrea

You don't need a second wallet to mine. You absolutely do not need bitcoin to mine bitcoin. You need an ASIC miner (with power supply), electricity and an internet connection.

They are scammers trying to steal from you.

If you want to mine then buy an ASIC miner. But be careful, there are also scammers pretending to sell miners.


Gigahash vs Megahash So, 1 GHash equals 1000 Mhash's as far as I know. Then, why genesis-mining measures the bitcoin hashpower in terrahashes?? 1 Thash = 1000 Ghash. The whole hashocean is said to have 41.6 GH/s. On genesis you can buy 1 Thash for 400$. Who is naming their units in incorrect way?

Your 41.6 GH/s is certainly wrong. According to https://bitcoinwisdom.com/bitcoin/difficulty it's currently 757,561,871 GH/s = 757,561 TeraHash/s.

Also: it's "Tera", one r and capital T. Capitalization is important in the Metric prefixes.  https://en.wikipedia.org/wiki/Metric_prefix

Note also that cloud mining is usually a scam. Why would they give you money? Answer: they don't.