How does the transaction received from getdata relates to data from blockchain.info?

Blockchain.info (and other block explorers) do additional processing of the transaction data in order to make it more user friendly to follow the path of coin movement through multiple transactions. Additionally, it seems that whatever you are using to print out the transaction details is not showing you all of the information.

In a transaction, each input specifies the output that it is spending by using the transaction id of the transaction containing that output, and the 0-based index of that output in the list of outputs. Blockchain.info in their own internal databases links these two transactions together thus allowing you to visit the page for the previous transaction.

They display addresses in inputs because they inspect the output that is being spent, determine the address it corresponds to, and shows that address as the input for a transaction. Bitcoin does not actually use addresses and you won't see addresses in the inputs of transactions.

For the outputs, it appears that whatever software you are using is not displaying the full output information. Outputs contain both an amount and an output script which is not being shown to you. This output script typically corresponds to an address, so blockchain.info will determine the corresponding address for an output script (if it has one) and display that. Because they have databases that index addresses and their transactions, they are able to both give you a list of transactions for a particular address as well as point you to the transaction that spends that output.


Can't connect to rpc.blockchain.info with bitcoin-cli

It appears this service is no longer available per other discussions (and a failed ping of rpc.blockchain.info).

An alternative would be to use the address query on blockchain.info's api:

https://blockchain.info/rawaddr/$bitcoin_address

Example

Single Address

https://blockchain.info/rawaddr/1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F

Address can be base58 or hash160

Optional limit parameter to show n transactions e.g. &limit=50 (Default: 50, Max: 50)
Optional offset parameter to skip the first n transactions e.g. &offset=100 (Page 2 for limit 50)

{
    "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
    "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
    "n_tx":17,
    "n_unredeemed":2,
    "total_received":1031350000,
    "total_sent":931250000,
    "final_balance":100100000,
    "txs":[--Array of Transactions--]
}


As per: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

We have,

  [target-confirmations] intentionally does not affect the list of returned transactions, but only affects the returned 'lastblock' value.

What does this mean? It means the lastblock entry in your returned object is the last block you can see on the blockchain (as it the block that currently has exactly 1 confirmation as indicated by the argument you passed in). The lastblock entry is the only field you can affect by changing the target-confirmations argument.

This means that if you want all transactions with at least 1 confirmation, you need to filter this list. This begs the question, why isn't the target-confirmations argument used to do this filtering?

This is because the way the function works currently allows for a use-case in which you can constantly call listsinceblock with the value of lastblock that was returned in your last call. By doing this, your transactions list will contain transactions that reach X or more confirmations on the blockchain in exactly one of those calls, (where X in this case is 1).


The security of the Bitcoin system depends on time passed since the transaction was included in a block.  Let's call this confirmation 1.

  Are you having trouble getting your trades into a block, or want to have more confirmations?

The fact remains is that you should wait 1 hour after the transaction is included in a block before spending that output.  That one hour just happens to roughly correspond with 6 blocks.

So why do we wait 1 hour? It's because we want to make reasonably sure that no one out there has a computer strong enough to spend the output twice, and causing a split in the ledger.

I wouldn't plan on basing my business on short block times, and would instead only use the block chain for deposits and withdrawals from your private system.

If you're having trouble getting your Tx included in a block the easy solution for that is to pay transaction fees, or run a private mining rig that will accept such transactions.


There are no limits set by the wallet itself. As long as the co-signers agree you can do what you like.


Does Ethereum support the features necessary to create the Lightning Network?

They don't need to support those. As mentioned by Roman you could build the entire LN in one contract. You can even implement the LN Relative OP_CHECKLOCKTIMEVERIFY requirement in a much better way.

In fact you can add more functionality than is possible with the Bitcoin LN, you could allow people to add more Ether to their side of the channel with offchain transactions.

Tx malleability also doesn't need to be solved (a very difficult probelm in Bitcoin) because it doesn't pertain. A LN contract wouldn't have to chain offchain transactions in any way, just passing signed offchain 'notes' of a sort that contain information relating to amounts, blocknumber for available release, etc...

It is also somewhat trivial to add the hub and spokes part where a random value R is hashed to create H and allow payments to hop through multiple parties (but in Ethereum you could do it without the problem of locking up funds that they need an extra OP CODE to solve).

Disclosure: I'm actually working on this in my spare time.


Doesn't an Oracle go against the Blockchain principles?

The use of an Oracle does somewhat go against the founding principle of transacting without the need for a trusted third party.

As Nakamoto's whitepaper states:

  What is needed is an electronic payment system based on cryptographic proof instead of trust,
  allowing any two willing parties to transact directly with each other without the need for a trusted
  third party.

Of course the majority of transactions do not need trusted third parties such as oracles or escrow agents. But for those that do, trust is a key issue.

Other people have suggested trust minimisation strategies that can be used with oracles.

  multiple independent oracles
  trusted hardware
  Amazon AWS oracles


Provided both wallets support BIP39, you should be able to restore a seed from one into another easily.

Using the seed simultaneously on two different wallets is not a problem, since address generation is deterministic.

Note that BIP39 simply defines the seed process. BIP44 defines multiple coin types, BIP32 defines accounts. At a minimum, any seed based wallet must support these three. Most wallets these days support BIP49, BIP84, and BIP141 for segwit compatible addresses of various types. However, not all wallets support these, and even the ones that do might require you to explicitly select the correct address type and path (such as electrum). Make sure that the second wallet you use supports all the features of the first one.


Custom altcoin won't sync with node and neither will accept a miner connection

Although this is rather old, I thought I should at least provide my knowledge on this - although it shows "0" blocks of transaction history, and continually states that it is catching up, it is however up to date - depending on the circumstances. First, you need to open "checkpoints.cpp" and remove all the checkpoints in the file (they'll be somewhere in the first 20 lines, it's fairly self explanatory), and create one checkpoint at 0 with the genesis block hash - the genesis block checkpoint. After you've done that, rebuild both clients, connect them, and instead of using minerd (or equivalent), instead use "setgenerate" through the console for at least 1 block. After that 1 block, you should be able to use minerd (or equivalent). Hope this helps for you


Resyncing bcoin brings up database version error

If you're running master, there was a recent migration that would cause this.

you can run this to fix it:
node migrate/chaindb2to3.js /path/to/chaindb.ldb

That will take a very long time, but if you don't mind pruning your DB at the same time, you can run this instead and it will be much faster:
node migrate/chaindb2to3.js /path/to/chaindb.ldb --prune

If that doesn't work you can always reset the DB and resync.
Just remove all .ldb files from ~/.bcoin dir and restart bcoin.


Custom Payment Gateway UX Help (in app purchases)

I think you may be looking for "Bitcoin Universal Resource Identifiers (URIs)" as specified by BIP21, a standardized string format for bitcoin payment requests.


Eligius has a hidden service for Tor mining.


Your image shows two messages:

There is a message

  ERROR:root:Couldn't open wallet.dat/main

It suggests you should close Bitcoin if it is already running. I would use Windows' task-manager to see if bitcoin-qt, bitcoind etc are running (Ctrl+Alt+Del in Windows-10 should bring up a menu from which you can select task-manager). You can close those processes from task manager if necessary.

Since your screenshot shows a second attempt without this error, it looks like you shut down Botcoin-qt OK and the command completed OK.

and

  WARNING:root:pycrypto or libssl not found, decryption may be slow

This is just a warning, it doesn't mean that the command won't work, just that it may take longer than normal.

The message suggests pywallet will use slow internal cryptographic functions if it doesn't have access to a fast external library of cryptographic functions.

So your wallet.txt file should show you the information you wanted to extract.


Are there any works of science fiction out there that relate to blockchain technology?

Found one: Stephenson's Cryptonomicon.

See also Digital Currency: ten years before Bitcoin, Neal Stephenson's Cryptonomicon


Is there a crowdfunding site for Bitcoin?

For donation-based crowdfunding:

http://www.BitcoinStarter.com
http://www.CoinFunder.com
http://www.nestorbooster.com
http://ignitiondeck.com/id/bitcoin-crowdfunding

There's also:

http://www.Propster.me
http://www.PirateMyFilm.com
http://www.Booster.io

and some day coming back:

http://www.BitcoinChipIn.com

Of course, the "equity" markets for equity-based crowdfunding:

http://www.BitFunder.com
http://www.MPEX.co
http://www.CryptoStocks.com

And a forms of microlending from the crowd include:

http://www.BTCJam.com

and others.

[Update: Thanks to others answering this question as well, I've updated this list with their input as well.]


Where can I trade BTC/USD with a small transaction fee?

Base fees:

Mt. Gox: 0.6%
Bitstamp: 0.5%
Intersango: 0.65%
Bitcoin-Central: 0.498%


BIP 44 is scanning external chain really enough?

I got it - the paragraph in the BIP 44 proposal I referenced is about "Account discovery" - i.e. discovering whether an account was used at all. It's not about used addresses discovery within the account which is another thing of course, and it apparently requires scanning the change addresses as well, given the example in the question. So I just misunderstood it.


BIP44 generation tool has Account xpubkey & bip32 xpubkey, what's the difference?

BIP 44 just specifies a structure for organising keys using BIP 32 style generation. The tree structure is this:

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

Generally, m refers to your BIP 32 master private key generated from the mnemonic in BIP 39. But all children extended keys are also extended parents if you want them to be - all can have children. So Account extended public key will just be the extended public key generated as a child of the coin_type extended key from the hierarchy above.


Addresses starting with 3 are Mainnet P2SH addresses. For testnet your require a valid base58check/RIPEMD160 encoded scripthash for a P2SH address (starting with 2).


Open source, how can I view "Transaction Create a new transaction" and "Sign Transaction"?

The original Bitcoin client did not have a debug console or many things that we see in modern Bitcoin software. Furthermore, it is a compiled software (C++ needs to be compiled) so you can't inspect the thing being run for its source code. However, Satoshi did publish the source code along with the pre-compiled binary. For transaction creation, you can find this in the repo you linked in src/main.cpp. It is the function named CreateTransaction. Another copy of the original distribution can be found on nakamotoinstitute.org.

Lastly, Bitcoin Core is based on the original client's codebase. It's commit history goes all the way back to 0.1.5 so you can see code that is very similar to the original release and view the code for any version between 0.1.5 and modern Bitcoin Core.


Why does my wallet need to download the whole transaction history?

The short answer to your question is "no". The reason is actually pretty simple: Without the entire block chain, there is no way to know that funds that are claimed to have been sent to you weren't actually sent to someone else. There is no way to prove the absence of a conflicting transaction, other than to check every valid transaction.

With a bank, the bank clears your checks for you. Here, you clear your own checks. Without knowing every check an account has received or sent out, how can you know the account has sufficient balance to cover your check?

Of course, you don't have to run the Bitcoin client. Your alternative is trust someone else with your coins.


Who bears the burden of the cost ? Is it the user or is it the network?

Just like what happens when more dollars are printed, the value of all the existing currency goes down.

  If its borne by the network, wouldn't this cause an increase in circulation of bitcoins in a network and lead to reduction in their value making them unstable?

It leads to a predictable increase in the total supply. There's no reason to expect a predictable change in supply to cause instability in value.

Think about oil, for example. If there are unexpected changes in the supply of oil, then the price will jump in response. But if we knew that the supply of oil would increase at a very predictable rate that changed only gradually, there would be no such jumps.

  If the this cost is borne by the user, then how does it make it an alternative to native banking transaction cost?

The idea is that by reducing transaction costs relative to existing cross-border payment systems, the Bitcoin system will create enough value to pay the miners and still be competitive. The mining reward drops over time, so it doesn't need to produce value forever to hold its value.

  If the mining of bitcoins also lead to circulation increase, how can the system handle the volume of transaction relating to a global economy? How would this effect the public book keeping system and the miners ?

The number of transactions or their size has no effect on the generation of Bitcoins which occurs on a predictable schedule up to the fixed limit at which time it stops.


Is it possible to keep bitcoind running with the blockchain synced up to only a certain height?

You can run with -connect=0. If it's not connected to anything, it can't sync further.


Bitcoin wallet shows empty after I installed Windows on SSD

Depending on how recently you purchased/mined your bitcoins, the fact that your client hasn't synced might be why you don't see any balance being shown.

The reason for this is that your wallet doesn't actually contain any physical data representing coins, it simply contains keys that allow you to spend the values associated with a specific address. The way that the bitcoin network determines the number of coins associated with an address is by traversing the entire blockchain and summing all of the transactions including that address. When the bitcoin qt client is syncing, it is downloading this blockchain. Therefore, if all of your transactions happened in the blocks that you have not downloaded yet, it will look like your wallet contains no coins.

This means that the solution to your problem may be to just wait until the bitcoin client has fully synced. If/when your client downloads the blocks with your transactions in them, your balance will be updated. If your client syncs and you do not see your balance change, that means that the bitcoin client is not reading the correct wallet. Make sure that you have copied the wallet.dat file from your old hard drive to the correct place on your new one. NOTE: Make sure that the bitcoin client is CLOSED when you copy the wallet.dat file.

If your client has fully synced and you are sure that the correct wallet.dat file is loaded, and you still do not see your balance updated then you are probably out of luck. If you have lost the cryptographic keys stored in your wallet.dat file, the damage has already been permanently done.


On the subject of why LevelDB is used, core developer Greg Maxwell stated the following to the ref:

  I think people are falling into a trap of thinking "It's a <database>,
  I know a <black box> for that!"; but the application and needs are
  very specialized here. . . It just so happens that on the back of the
  very bitcoin specific cryptographic consensus algorithim there was a
  slot where a pre-existing high performance key-value store fit; and so
  we're using one and saving ourselves some effort...


Can 2 blocks have the same previous hash?

Can two blocks have the same Previous hash after being created.

Yes, two otherwise valid blocks could be created that both link to the same parent block, but importantly: only one of those two blocks will become a part of the valid chain. So ultimately, only one of them will be valid, and the winner will be the block that miners build on top of first (and thus it becomes a part of the longer chain).

The other block will become what is called an 'orphan block' (though some people prefer the more exact term, 'extinct block').

You can look through the orhpaned-blocks tag for more info.


Install 2 Electrum wallets in a same computer

Is it possible to have 2 Electrum Wallets in a same computer? If so,
  how can I install it?

You able to have as many wallets as you want. You dont need install electrum twice, all you need it is create new wallet.

I assume you already have a wallet with password.
Run electrum and choose your wallet from the dialog:

Save that wallet somewhere in other place, and create another one with a new seed and new adresses. Then send from one to other.


I've got an answer on Reddit:

It's likely to have been written in a PM or an email to some developers, and it seems that Mike Hearn (BitcoinJ) was the one who published this statement:

  Mike Hearn - February 25, 2013, 12:48:54 PM

  He communicated with a few of the core developers before leaving. He
  told myself and Gavin that he had moved on to other things and that
  the project was in good hands.

Source: Re: Could Satoshi come back and tell us what he/her thinks about the block size?

Still, if someone has additional information I would be glad to know about.


What would happened if two transactions have the same hash?

Per BIP 30, transactions are not allowed to have the same TXID as another transaction which has unspent outputs.

This means that there can be transactions that have the same TXID, but only after the first transaction's outputs are already spent. So in this case, the duplicate TXID does not matter.

For transactions that do have duplicated TXIDs (there are a few of them), only the most recent of those transactions can have its outputs spent. The earlier transactions with the same TXID cannot be spent from and their Bitcoin are lost forever.


Specific instance of Tx using a malformed null byte vector for P2SH; insight req

Another very interesting question!

First, note the date of the transaction. Specifically:

"created_at": "2013-10-25T13:16:51.598Z"

It turns out that until this issue, ANY value could be used instead of OP_0. To quote Peter Todd:

  While normally OP_0 is used, the actual value of this argument is not
  checked, and thus creates a source of mutability for any transaction
  with CHECKMULTISIG inputs.

The patch here actually made it so that the first argument of a standard multisig had to be OP_0 as to not cause transaction malleability.

Given that this transaction was before this commit got into the standard bitcoin client, that transaction was perfectly fine. You literally could have put almost any value as the first byte and it would have gone through.

Also note that this was a soft-forking change. It's still legal to put OP_INVALIDCODE instead of OP_0, it just won't be propagated by the standard bitcoin client and thus probably won't get into a block. Otherwise, this would have been a hard-forking change.

Edit: It looks like the API from biteasy is different than other places like blockchain:

Note that the script begins with 00, not ff as with biteasy.

https://blockchain.info/rawtx/fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e

{
"ver": 1,
"inputs": [
{
"sequence": 4294967295,
"prev_out": {
"spent": true,
"tx_index": 38094378,
"type": 0,
"addr": "35aHovjnZ9xdfYZsB2yBVTs6CWqnBpHNDY",
"value": 100000,
"n": 1,
"script": "a9142a9ada309638ec606f67e6b107867184c58a3aab87"
},
"script": "00473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd014cc9524104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf24104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf241046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc53ae"
}
],
"block_height": 265976,
"relayed_by": "24.212.184.180",
"out": [
{
"spent": true,
"tx_index": 38095095,
"type": 0,
"addr": "1QKjwQ7tJGaWrXyftce4ns47gvZ67GoqMt",
"value": 80000,
"n": 0,
"script": "76a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac"
}
],
"lock_time": 0,
"size": 435,
"double_spend": false,
"time": 1382706718,
"tx_index": 38095095,
"vin_sz": 1,
"hash": "fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e",
"vout_sz": 1
}


Transaction verification up to coinbase?

They achieve the same result as if they did this, though not by actually doing it. (There are a number of obvious optimizations, for example, maintaining an indexed database of unspent outputs.)


What are the trade-offs between transacting on Lightning Network and Bitcoin mainchain?

Below describes these points during what's planned to be normal operation. Once a channel needs to be torn down because of a problem with one of the nodes (evil or accidental) some of these answers are a little different.

privacy - Privacy is not a linear scale, but there are a few factors that clearly improve privacy:

Very few transactions actually end up on the permanent and public blockchain. And those are a payment from you to an LN node (or vice versa) and there is no record on the blockchain of the actual destinations (or sources) of the money.
Routing of messages (and LN transactions) will be done in a Tor like fashion (Onion routing) with encryption of the message such that intermediate nodes can't read the transactions nor do they know the true origin or destination (IP address) of the transaction.
To obfuscate your actions, you can pay to yourself from one channel to another, and I'd assume it's a lot easier to do quick and trustless mixing through LN.

confirmation speed - You don't need to wait for any confirmations at all, so transactions are truly instant. Network latency (multiple hops) will be the deciding factor as all encryption and other overhead is low even for relatively low end hardware (phones).
fees - Every hop will want a little bit of fee for the service of forwarding your transaction. This can be pretty tiny though, allowing for true micro payments. In some cases nodes might want to balance out their channels and give you negative fees depending on which direction the money is flowing. This will create an interesting market between all the nodes offering their services and keeping fees fair and low.
time until spendable - Immediate. Any money you receive on a channel you can immediately spend again (through the same channel). If you want to settle on the blockchain and then spend the bitcoins there, you'll first have to close the channel, which under normal conditions requires the standard 10 minutes confirmation time (you don't need more confirmations, although the person you are sending the Bitcoins to might still require 6 confirmations).
centralized - The software is fully open source. Any one can start up a node, put some Bitcoins in and start offering their service to the network and earn some fees for doing it. This low barrier to entry and ease of use should provide enough competition and enough nodes to make it decentralized.

There are some caveats: people will have to put some funds into the node that are at risk if the device gets hacked (initially possibly through bugs in LN, but in general through any malware or badly secured and outdated operating systems). This might be a slightly centralizing force as security is relatively cheaper to do at scale.

DOS protection might be something to think about too. Maybe have the option of using a 3G phone or other channel invisible to the attackers (even sneakernet!) when a true attack is underway and you need to close some channels before they expire. Very little bandwidth is necessary to do that, I'm not sure a DOS attack make uploading a few transactions impossible anyway.

Also I think it's required (or maybe just wise) to run a full Bitcoin node (possibly pruning) on the LN node. LN needs to have access to the blockchain data in a trustless way and need to be able to send transactions to the Bitcoin network reliably in case it's necessary to tear down a payment channel (within a certain timeout). A pruning full node is not that bad to run, but there's a bit of cost that would be lower in a centralized situation.


Restrict the Bitcoin usage only during a particular period

This can be accomplished with a simple smart contract between you and the recipient using a transaction's locktime.  Here are the steps:

Create a transaction to the recipient's address spending UTXO's (unspent transaction outputs) that you own, and setting the locktime to the start date of your grace period.
Create a second transaction spending the exact same UTXO's back to an address that you own, but without any locktime restriction.
Sign the first transaction, and give it to the recipient.
When the grace period begins, the recipient can broadcast the transaction and receive the coins.
When the grace period is over, sign and broadcast the second transaction.  If the first transaction has already been broadcast, it will be invalid and not relayed or included into a block.  If the first transaction has not been broadcast, then you will want to reclaim the coins, thus invalidating the first transaction.

This plan assumes that you are in control of the second transaction and paying attention, such that you remember to broadcast the second transaction.  It also assumes that the recipient trusts you to respect the grace period, and not broadcast your transaction until the time is up.  Problems like these could be solved with a more complex scheme involving multi-sig transactions and setting locktime on both transactions, but it doesn't sound like you need anything that complex.

See also:

https://en.bitcoin.it/wiki/Protocol_documentation#tx

https://bitcoin.org/en/developer-guide#signature-hash-types


What will happen, if transaction's rate becomes very high?

This will not slow down the finding of a new block, because it is not necessary to include every new transaction in the next block. Miners can decide which and how many transactions to include and can only update the transaction set they mine on at arbitrary times. They could for example only update the data set every time they receive a new block, or every minute.

below line is the answer to the previous edit of the question.

The scenario you describe cannot come to pass.

The Bitcoin network is self-regulating and automatically resets the difficulty every 2016 blocks to sustain an expected time of 10 minutes between blocks. The difficulty will be adjusted by up to factor four.

Extremely fast verification cannot be sustained

If a new block would be found every second in average (still magnitudes slower than your scenario calls for), the difficulty would be reset after 2016 seconds (33.6 minutes). The difficulty would quadruple, so in order to sustain that verification speed the networks hashing power would also have to increase four-fold in the same time! I am sure it is obvious, why the hashing power of the Bitcoin network will not quadruple every half hour for a significant frame of time.

Between blocks transactions are collected and verified together in the block

Every miner will collect all transactions transmitted to him, and whenever he tries to find a new block, he will try to include all unverified transactions together in that same block.

Once somebody finds a block, it will be broadcasted to the network and any receiving miner will check if it is valid and increases the length of his blockchain. If both is the case, he will accept it as a parent for the block he is trying to find. He will remove any transactions that have now been verified from his "unverified transactions" pool and will recommence to find a new block to verify the remaining transactions. Whenever more transactions are relayed to him, he will add them to his "unverified transactions" pool and will adjust the parameters of the block he is trying to find.

Blocks cannot be changed after they have been found! However, there can be several blocks that compete with each other to be accepted into the blockchain next, but such races will eventually be decided when a successor is found for one of the competitors. These "mini-forks" happen every once in a while, but is very unlikely that competing blockchain ends find new blocks several times in the row at the same time. Eventually, one will definitely be first and all other competitors become invalid.

Block size limit

There is some concern that the current block size limit will become a problem, because it cannot handle a sufficient amount of transactions. Should this come to pass, however, it would not change the amount of time between blocks, but rather that every block would be filled with transactions and transactions that didn't make it into the block to be on a waiting list for a future block. There is currently an ongoing effort to adjust the blocksize limit in order to support a bigger number of transactions per time.


Does the public key associated with an address become part of the public record after it has been used to spend?

You're right that public keys are generally unknown until coins are spent from their address, and that until coins are spent only a hash of the public key is published.

While it's technically possible to use bitcoin public keys for the kind of encryption you're imagining, you're the first person I've seen talking about doing so.  The satoshi client has an interface to allow users to sign messages using their private key which others can verify using the associated bitcoin address, but using public keys to encrypt messages which only the holder of the private key can decrypt is something I've never seen.

Notice that signing a message with your private key in the satoshi client includes the corresponding public key in the output signature.  This allows the recipient to verify the message.  It's possible that otherwise they wouldn't know the public key, having only the corresponding bitcoin address.


Are there still miners or mining pool which refuse to implement SegWit?

No, in the past year, there were only 15 non-empty-non-segwit blocks mined which account for less than 0.03% of all blocks.

Non-empty blocks without segwit transactions

I've looked up the last twenty blocks that confirmed transactions but did not include any segwit data. The newest of these was mined on 2018-12-18, more than four months ago. The 21st-newest block in that series was mined on 2018-03-13 at height 513,267.

Given that we're currently at height 573,220, there were only 20 non-empty blocks that did not include segwit transactions among the last 59,953 blocks. Or put differently, over a period of time exceeding the past year, there were fewer than 0.034% non-empty-non-segwit blocks mined.

The two known miners that created such blocks without segwit transactions appear not to be doing that now:

Bitcoin Russia's last ten blocks were segwit blocks.

Bitcoin.com's last ten blocks were segwit blocks.

Empty Blocks

I did not count empty blocks (blocks that contain only a coinbase transaction) as the coinbase transaction has no inputs and therefore cannot be a segwit transaction. However, BIP141 specifies that the Witness Commitment is optional if there is no segwit transaction included. Therefore, there is no reliable way to determine whether or not an empty block is segwit or non-segwit.

Images via blockchair.com


Bitcoin transactions are traceable, public and are recorded permanently. Although, there are some ways to minimize that, by not reusing addresses and have multiple wallets for different purposes. But even that is not foolproof because there are analysis services that can group addresses through data crunching.

Now imagine you get coins from someone that got them from someone, etc. Nothing wrong with that right? Unless, those coins are part of a bunch that were hacked from an exchange or traced back to a payment for some illegal activity.  And some exchanges start blacklisting them.

A mixing service tries to remove that linkability/traceability.

IMO you would be better off just using a crypto currency with unlinkability and untraceability built into the protocol in way of a mixer.


Wallet design: What to do with dust amounts in change?

I've done some research on a related topic* and I'd say it depends on your assumptions what will happen with the value of Bitcoin, the fee rate, and the cost of creating transactions in the long run.

Under the assumption that the fee rate (in [sat/B]) will remain roughly the same level or increase, it saves the user money to add the change to the fee when the change is smaller than the cost of creating one output and spending one input:

change ≤ (bytesOutput + bytesInput) × feePerByte ⇒ add to fee

For P2PKH at 150 satoshis per byte this is for example

change ≤ 27,300 satoshis = (34 bytes + 148 bytes) × 150 satoshis per byte

You may also want to consider that adding the change to transaction fees causes transactions to confirm more quickly, take less blockspace, and reduce the UTXO set.

However, smaller amounts may become spendable in the future, if fee rates would drastically drop, or the cost of spending inputs would significantly decrease. The former could happen due to blocksize increases or introduction of a second layer payment system, while the latter could be brought about by new transaction formats, signature aggregation, or a lowering of the minRelayTxFee.

Alternatively, you can either try to directly match the amount you're trying to spend or just select a sufficiently large amount to create a useful change output. Thank you, Pieter, for the reminder.

* my Master thesis on Coin Selection [PDF with 943KB]


How do you accept bitcoin donations on a steam group?

The easiest way would be to create a wallet and to dedicate a single address from it to receiving donations. For the convenience of the donaters you could present it both as a QR-code and a bitcoin URI. As with Jonas' answer you wouldn't want other people to be able to change the information on the page where you provide the donation address, as someone might replace the donation address with their own.

For improved privacy, you could replace the address with a new one every once in a while.

For a more advanced, private setup check out Jonas' answer.


How to get xpub or mpk(bip32) for my bitcoin core wallet?

Bitcoin Core (since 0.13) uses HD after BIP32 with only hardened private key derivation. Exporting the xpub would be useless, because other apps could not derive public keys (hardened derivation requires the xpriv).

Though, you can export the xpriv with dumpwallet <filename> (RPC or Debug Console). But be careful with that.


How does mining pool ensure the miner works on the problem?

Miners regularly send "shares" to the pool server. The shares are solution to a low-difficulty bitcoin puzzle. Each share stands some chance of being a solution to the current bitcoin puzzle, of much higher difficulty.

By sending shares, miners show that they are working on the problem, and may potentially reveal its solution to the pool server. They are often remunerated based on the number of shares they find, and of their difficulty.


use the GUIMiner-scrypt instead .... I could not get the guiminer to work.


How does one work out hashrate based on number of submitted shares

A share has more often than not the maximum Target value (as in Difficulty 1). To create a share one needs on average 2^32 tries, or hashes. Multiply the number of submitted shares by 2^32, divide over the period those shares were submitted in and you have your hashrate estimate.


You can use fundrawtransaction and specify a particular input to be used in the transaction. Bitcoin Core will then choose the rest of the inputs to meet your output amount automatically.

You can also use lockunspent to prevent specific UTXOs from being selected for coin selection thereby limiting which UTXOs can be used. Then any time that coin selection is used to create a transaction (i.e. in sendtoaddress, sendmany, fundrawtransaction, walletcreatefundedpsbt), only outputs that are not locked will be selected.


Multibit images/screenshots in educational website

I'm one of the MultiBit devs.

Everything with MultBit is MIT licence so you are free to reuse anything. The website is also open source and is on github as the project multibit-website.

There are some larger icons in the github for multibit - it's in something like src/main/resources/images. I think there is a 512x512 pixel one in there


How do bitcoin adresses get into the Bitcoin system when they're created offline?

Addresses are not made known to the Bitcoin network when they are created. An address only gets "into the system" when someone sends bitcoins to said address. If you're not the sender of that transaction, the address can be communicated to the sender by any fashion, e.g. by email, postal letter, or coconut laden African swallow. ;)

Thus, after you've created your keys offline, you may tell the prospective sender of the transaction the address in any fashion and to spend the received coins, you may import the private key into whatever wallet software you prefer.


Is this article wrong/scammy? Is it possible that miner earn more by mining several different coins at once through minergate?

You can possible optimize revenue by switching to mining another coin dynamically, but it isn’t possible to mine two different coins in a given grind attempt.

The exception are chains which are merge-mined. Each merge-mined chain block is committed to a block of a main-chain block, a Bitcoin block for example. Validators of the merge-mined coin can validate POW of the main-chain (eg Bitcoin) and enforce separate consensus rules.

The difficulty of a merge-mined coin can be equal or higher than that of the main chain.

Therefore, if there is any significant value in the merge mined coin, a Bitcoin miner would be incentivized to include valid block commitments in each Bitcoin block it attempts to mine.


How many coins been mined on the Testnet?

By visiting http://blockexplorer.com/testnet you can browse the testnet blockchain.

As of this writing, it shows that 128558 blocks have been mined on the current iteration of testnet (testnet3).  Since each block has a reward of 50 BTC (it has not decreased), that's a total of 6427900 BTC mined to date on testnet.


How to buy bitcoins with Dwolla now 6/14/13?

Try to buy at localbitcoins.com if you are comfortable dealing with strangers. May be use escrow.

https://localbitcoins.com/buy-bitcoins-online/usd/dwolla/


Why is scriptSig filled with scriptPubKey before signing a transaction?

There seem to be no reason: Ken Shirriff's blog explained it this way:

  Then the signature is turned into code in the Script language,
  creating the scriptSig script that is embedded in the transaction. It
  appears that using the previous transaction's scriptPubKey during
  signing is for historical reasons rather than any logical reason.[17]

and the link points to a thread from 2013:
https://bitcointalk.org/index.php?topic=102487.msg1123257#msg1123257


I plan to buy any FPGA boards, any idea for a good sources of information? and what coin is profitable?

https://fpga.guide/en/ is a good place for beginners who want to learn about fpga mining. they also have a calculator page so you can find out which coin is the most profitable


Yes you can use bitcoind: https://en.bitcoin.it/wiki/Bitcoind

and use the

the bitcoin json rpc api https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list


how many miners should validate a block before its considered valid?

Miners don't really actively validate blocks during the mining process. Miners find valid blocks and broadcast them to the network. It is up to the full-validating nodes on the network as to whether a block is accepted or rejected.


Was it always required for the Coinbase transaction to be the first transaction in a block?

This is not true. Code and code comments in v0.1.5 (the oldest tagged version in git) enforce that there always is a coinbase transaction and that it must always be the first. There cannot be a coinbase transaction elsewhere in the block. Coinbase transactions are defined as transactions with one input whose previous transaction hash is all 0's and whose previous output index is -1 (because it is an unsigned int, this becomes 0xffffffff).

You can also find a copy of the original 0.1.0 source code and find the same code and comments in the same place in main.cpp.


They payment is failing because you have opened a channel where node 1 has 10000 sat, and node 2 has 0 sat, and then you are trying to make node 2 pay node 1.

From what I understand, in point 4 you are attempting to have node 2 ‘add funds’ to the channel you opened in step 3. This is not how a lightning channel works: a lightning channel is a bitcoin UTXO, and you cannot ‘add bitcoins’ to an already existing UTXO. Each channel is defined when it is created, and then resolved when closed (the appropriate balance is sent to each participant).

Considering your setup, you can make a payment from node 1 to node 2. Once that is done, you’ll be able to make payments from node 2 back to node 1 (until the whole balance is pushed back to one side).

What you could also do to achieve a similar result is opening a new channel from node 2 to node 1. I’m not familiar with c-lightning, but I know that LND let’s you open two channels with the same peer. As you mentioned, dual-funding is possible but has not yet been implemented.


Yes it did, on April 1, 2012.

[removed link to chain of orphaned blocks]


Bitcoin Core doesn't use an oldest-first selection but a more complex solver, it will probably end up spending outputs you don't want to in this particular case. You can do manual selection of the outputs you want to spend using the Coin Control section of the advanced GUI, which will let you ignore the dust if you don't want to spend it.


Transactions don't have an accurate timestamp so their chronological ordering comes at the granularity of which block the transaction was included in.

Access to the "raw transactions" is available using the Bitcoin.org client's API, however it is not necessarily trivial to do so.

http://en.bitcoin.it/wiki/Raw_Transactions
Armory provides some methods to pull transactions -- see the code in the extras directory.
Other methods might include libbitcoin
or perhaps the library with picocoin
or maybe ABE (blockchain explorer


Possible to temporarily reduce the supply of a cryptocurrency?

This is possible through the use of a multiplier. For example, you could add it to Bitcoin as follows:

You add a "currency multiplier" and "next currency multiplier" to the block header.
All Bitcoin amounts presented are multiplied by this multiplier.
You have a set of rules for how the next currency multiplier changes. For example, miners could be permitted to change the "next currency multiplier" by a small amount in each block.
Periodically, say every time the difficulty is adjusted, the currency multiplier is also adjusted by up to 2% (or whatever) towards the next currency multiplier and the next currency multiplier is set to the new currency multiplier.

So if I want to pay you "1 Bitcoin", I actually have to pay you an internal amount that depends on the multiplier. Changes in the multiplier would change everyone's displayed balances. This way, if miners believed there were too many Bitcoins in circulation and the value was dropping, they could "vote" to reduce the multiplier. This could result in a more stable price and thus make it easier to price goods in Bitcoins. At least, those would be the arguments in favor of such a scheme.


How can merchants accept Bitcoins while keeping it in line with the original USD value?

Until Bitcoin stabilizes sufficiently, prices will be listed in local currency and be payable in an equivalent amount of Bitcoin, or if prices will be listed in Bitcoin, this price will have to be constantly updated.

I.e. price would be listed in USD and the amount of XBT due would be calculated just before the bill.


What's the best Android wallet client for bitcoin?

If you want to keep your private keys secret (on your phone, that is), I'd recommend

Bitcoin Wallet for Android

The app also does not imply any trust in single servers, as it manages the block chain on-device.


How does one make multisignature transactions with the bitcoin client?

Bitcoin version 0.6.1 doesn't have useful multisignature support yet, either in the GUI or via the RPC interface, because there is no support for partially signing a multisignature transaction.

What is supported:  creating a multisignature transaction (using addmultisigaddress), and sending to a multisignature address (either your own or somebody else's).

Testing spending of multisignature transactions-- if all of the private keys required to spend a multisignature transaction are in the wallet, then those coins are added to the wallet's total bitcoin balance and that transaction will be spent if the normal coin-selection code decides to use them for a spending transaction.

Pull request 1456 adds low-level support in the RPC interface for multi-device/multi-person multisignature transactions.


It is trying to acquire a lock on the lockfile in the data directory, which likely fails due to not being supported on the network file system you use to access your NAS.

Even if that could be safely ignored (the lockfile is just there to prevent you from running multiple Bitcoin Core instances on the same directory), it is a warning that more problems exist. In general, running a database on a network filesystem is a bad idea because of lack of support for operations or guarantees that databases require. It would either just not work, be very slow, or get corrupted very easily.

However, this is all because of the databases used (blocks/ index/, chainstate/ and wallet.dat). The block data itself is not a database, and could be moved elsewhere. Bitcoin Core does currently not support moving just the block data elsewhere, though.


Why is a GPU a better tool for bitcoin mining than a CPU and is an FPGA better than both?

Bitcoin mining is essentially just the repeated calculation of sha256 checksums. Given that sha256 is a fairly simple algorithm that uses only basic integer calculations absolutely any processor core should be capable of churning out sha256 checksums very quickly and any added complexity beyond the basic instructions required for sha256 is wasted. To that end the ideal candidate for mining hardware should have the least complex cores necessary for sha256 but the largest possible number of cores.

Your CPU has probably between 2 and 8 cores, each of them insanely complex. Your GPU has comparatively simple cores, but probably has over a thousand of them. Still, even GPU cores are more complex than they need to be for sha256, which is where FPGAs and ASICs come in.

An ASIC is a custom chip, designed to do only one thing - in this case it's designed to perform two rounds of sha256. It has only the necessary components for its one and only purpose. An FPGA is a device commonly used to prototype ASICs, it's basically a chip whose components can be rearranged to mimic another kind of chip. Because they retain this multi-purpose capability FPGAs are significantly less efficient than ASICs.

The only (temporary) benefit we saw from FPGAs is the cost curve. FPGAs are pre-manufactured consumer devices, you can buy just one of them and they usually don't cost a huge amount of money. An ASIC is something you have manufactured, and the minimum order size is usually absurd, requiring a huge up-front investment to get your chips made.


Is the contest period really necessary for cross-chain transactions in 2-way-peg sidechains?

she submits a SPV proof to S2.

The way this worked in the first implementation of the sidechains paper by the same authors (called Elements Alpha, now elements) is as follows: The genesis block of the sidechain S2 creates a bunch of outputs with a new opcode OP_WPV that can be spent with an SPV proof showing that some amount on S1 has been "sent to a certain-locked output". Note that S2 follows the UTXO model of Bitcoin and there's no global state that OP_WPV could look up. That means that it's possible to provide exactly the same SPV proof to another OP_WPV locked output and effectively transfer your coins from S1 twice. That's why there needs to be a contest period where honest nodes have the opportunity to provide a fraud proof and lock the coins back into the OP_WPV.

Now if there needs to be a contest period anyway, we can make the confirmation period shorter than what we would assume to be secure against reorgs. Instead, the contest period is used to provide a window for reorganization proofs.

You can find more information about how this mechanism worked in this article: https://github.com/jonasnick/elementsproject.github.io/blob/master/source/_posts/The-Federated-Peg-in-Elements-Alpha.md.


nSequence win OP_CSV in child tx must be equal to nSeq parent tx?

I believe your misconception is that the nSequence value must be set on the transaction that creates the CSV output.

This is not required. All that's needed is setting it on the spending transaction's input which spends it. This will indirectly require that output to have a certain age when it is being spent.


P.S. After all above I closed BTC Core and started it again. I get notification like this "Blockchains integrity failured. Start reindex blockchains?".  I just click "Abort" button to close BTC Core and restart it. I get both tx on the right side in gray. But after 20-30 minutes old (conflicted) tx disappeared forever,  simultaneously the new (confirmed) tx painted in black. Long Life "Rolling Stones"!
That's all.


You can use the command bitcoin-cli getrawmempool to get a JSON array of all transactions that are stored locally in your mempool.

Since v0.9 release you can also pass a verbose boolean to get more info related to the transactions in your mempool like size, fees, or ancestor/dependent transaction within the mempool.

Do note that there is no one global copy of the mempool. The mempool is node dependent and stores valid transactions that your node has seen but has not yet been confirmed in the block. Since you have just downloaded and spun up your Bitcoin Core node, your mempool information might be limited when you compare it to nodes that have been running for days.


How to send everything in a bitcoind account?

I would highly recommend that you not use the accounts system as it is deprecated and has been removed for Bitcoin Core 0.17 and beyond. Furthermore, the way that you want to use the accounts system is not how it actually works. Accounts are only associated with addresses for receiving; for spending, when you "send from" an account, all that happens is the numbers for the account are deducted, not that addresses that were associated with the account for receiving are the ones actually used in the inputs.

To send everything from an account, just use the sendfrom command with the balance of the account. This will change the accounting entries so that that account is deducted however much you sent. Note that this will not necessarily choose the inputs that you think are associated with the account; it can choose any input in the wallet to create the transaction. However if you call getbalance <account>, you will see the account's balance be 0.


The Bitcoin developers would have to hard fork the chain to allow it.
I also don't think Bitcoin can get that expensive. Your talking 1 BTC = $100,000,000. If that's the case, the Bitcoin market cap would be $1,670,673,700,000,000 (1.6 quadrillion dollars). There is no such figure of money similar to that in circulation.


Q1: It depends on the sidechain. Every sidechain can implement their own rule to create and represent/encode adresses.

Q2: This is an active area of research. Some people propose implementing sidechains via Zero-Knowledge proofs or other ideas that either require Bitcoin rules to change or mining cooperation or both. Some sidechains already deployed, like RKS, propose there are a set of nodes you trust to hold custody of bitcoins transferred to the sidechain, much like a bank.


How many times can I reuse my bitcoin address until someone has enough information from all my transaction data to break my private key?

An arbitrary number of times.
Assuming the discrete logarithm problem for secp256k1 is hard (the basic security assumption underlying Bitcoin's digital signatures), it does not matter at all how many signatures an attacker sees. He will not be able to find the private key, or be able to forge a signature.
There are two contexts in which the advice for not reusing keys appears:

Privacy. Reusing addresses increases the linkability of your transactions, which reduces your privacy as well as everyone else that you interact with through that address.
Post-quantum security. As soon as you've spent an output assigned to a given address once, its public key becomes public knowledge. Before that point, someone with a hypothetical machine that can compute private keys from public keys cannot even start their search. I personally think this is not a particularly strong reason not to reuse addresses though (the real reason not to is privacy); see What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses? for why.

What is the term for this case/matter? is it "chosen cipher text attack", "plain text attack" etc.

This crypto SE answer is relevant: https://crypto.stackexchange.com/a/32715/72983
What you really want is protection against existential forgery (the ability for an attacker to sign a message he has never seen a signature for). That is a stronger notion of security than what you were talking about (as forgeries do not require the attacker to actually learn your private keys).


What applications of clients use bitcoin JSON-RPC?

As far as I understood, the Bitcoin JSON-RPC is one of the ways (if
  not the only way) in which applications can be built that can access
  the bitcoin wallet.

There is also a REST interface, but that is for read-only type commands like getting blocks or transaction info.

  So far, I have just figured our that only bitcoin-cli is such a local
  application which uses the RPC.

bitcoin-cli is just a cli interface to the RPC, it doesn't really do anything on it's own. Also, the RPC interface isn't just for wallet commands. A list of commands can be found in the documentation at https://bitcoincore.org/en/doc/0.16.2/. The commands expose functionality including:

blockchain
control
generating
mining
network
rawtransactions
util
wallet

  Are there any other examples where the JSON-RPC is used?

Many software libraries will communicate with the Bitcoin Core RPC, too many to list, but this might be a good start: https://github.com/igorbarinov/awesome-bitcoin. Not all use the Bitcoin core RPC, some implement their own full node (like copay).


The sweep function will send all coins related to the imported private key(s) to a new address (from the deterministic wallet). After sweeping, the private key is no longer capable of spending coins.

There is no need to "import" the private key in advance.

Mind that you need to pay a fee for the sweeping transaction (which is very little).


First, lets get the terminology straight. Hyperledger is composed of 5 different blockchain technologies, each with it's own consensus algorithm.

Here are two supported by Hyperledger Sawtooth blockchains:

PoET Proof of Elapsed Time (optional Nakamoto-style consensus algorithm used for Sawtooth). PoET with SGX has BFT. PoET Simulator has CFT. Not CPU-intensive as with PoW-style algorithms, although it still can fork and have stale blocks . See PoET specification at https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/poet.html
RAFT Consensus algorithm that elects a leader for a term of arbitrary time. Leader replaced if it times-out. Raft is faster than PoET, but is not BFT (Raft is CFT). Also Raft does not fork.
Hyperledger Sawtooth has the advantage of having Unpluggable Consensus. An algorithm can be changed without reinitializing the blockchain or even restarting the software.

Here are some other consensus algorithms:

PoW Proof of Work. Completing work (CPU-intensive Nakamoto-style consensus algorithm). Usually used in permissionless blockchains
PoS Proof of Stake. Nakamoto-style consensus algorithm based on the most wealth or age (stake)
PBFT Practical Byzantine Fault Tolerance. A "classical" consensus algorithm that uses a state machine. Uses leader and block election. PBFT is a three-phase, network-intensive algorithm (n^2 messages), so is not scalable to large networks


Can I claim Segwit2X with a blockchain.info wallet?

You just need the private key. A wallet (irrelevant which wallet) stores your private keys. You will probably not be able to send segwit2x with the blockchain.info-wallet, but you will be able export your private keys of your blockchain.info-wallet and then you can import them into a new segwit2x-wallet.


Recovering wallet from MultibitHD backup file

If Hashcat has uncovered a password for a mbhd.wallet.aes file, what's next?

I would either

use MultibitHD to recover the wallet or

manually decrypt the file and manually extract all the private keys

The second method probably requires a lot more knowledge of the internals of a Multibit wallet.

One thing I'm confused about is why did Multibit HD create a wallet file with the .aes ending when it's not even a AESCrypt file

From what I've read, Multibit HD wallet backups are encrypted using the AES algorithm where the AES encryption key is the "wallet words" (not the wallet password).
You don't say what caused you to think the file with the .aes filename extension was not AES encrypted?

it doesn't really matter as long as I have the wallet password, I guess.

If what I've read is right, the "wallet password" is of no help in using a wallet backup.
However maybe what Hashcat recovered was the twelve "wallet words"? If so you would be able to use those to recover the wallet.

I read that Multibit HD wallets are not safe and should be converted to something else

Multibit became defunct in 2017. I vaguely recall there was a Multibit classic that became defunct long ago. If I remember correctly it was superceded by Multibit HD. Anyway the multibit.org URL now redirects to an unrelated project which makes me suspect it will be hard or impossible to find any official documentation or support.
This is of course a good reason to never depend on any specific software to hold your backup of your private keys. Its probably safest to have a BIP-compliant recovery phrase or private keys in WIF format. Either of these would still be usable even if your wallet developers disappear and the software becomes unusable.

I do not have the 12 seed/secret words

Then it seems to me that hashcat has been of no use to you.

how does one go about getting public keys or addresses or both from private keys?

The easiest method is probably to use established wallet software
The algorithms are public. There are many libraries or bitcoin toolsets. Its a fairly broad subject. If I wanted to do it outside of an actual wallet I'd maybe look at PyWallet, btcutils and some of the other popular toolsets.


Minimum transaction fee to COMPLETE when mempool is +50 MB

I know that it increases probability as it ages. However many miners won't touch transactions at all, unless there's a fee attached, OR all the fee-based transactions have been satisfied. Correct?

As far as I can tell the system of giving older coins priority is no longer in use.

If we assume that miners will always take the 1MB with the highest fee rate out of their mempool (which is likely true except for their own transactions and accelerator activity), the only interesting question is:

What fee do I need to add to a transaction in order for it to be among the top 1MB for any of the next X blocks when I want it to confirm within X/6 hours.

Notably, the number of transactions in the mempool is not predictive in regard to this question. Rather interesting are:

lowest "natural" fee-rate in the past blocks
fee rates in the top X MB of the mempool
expected influx of competing transactions

  So, what is PROBABLE TIME with the following mempool sizes would a $3 value / .001 transaction be confirmed with a 3 satoshi fee?

Since that is even below the minimum fee of 1,000 satoshi per kB, it will never confirm.

Update: I was wrong in the last sentence. This past weekend transactions with zero fee were confirmed. So, let me correct 'never' to 'once in a blue moon'.


How to cash out E*Trade stocks (transfer funds from US to the EU) with Bitcoins?

*You basically need to get money into E*Trades US back account.*

E*Trade will either want a wire transfer (from Europe) or a bank transfer from the US.
They have to be very careful about Anti Money Laundering. So  wont want to accept money directly from a Bit-Coin Exchange.

You can open a US account from your local EU bank. Your local bank will act as a proxy to make the required AML and KYC checks. You can then use bitcoin to route the money via a bitcoin exchanges to that account.

However if this is just a one off. You will probably find the costs, (fees at the EU exchange and the US one) and risk of bit-coin volatility; not worth the effort.

Remember this is a problem which existed before bitcoin. So there will be ways of getting it to work with out bitcoin.

I would contact E*trade EU and US and ask them what would be the best way to find you purchase. (E*trade EU may have an arrangement to do this simply, already)

If you are buying a large enough quantity of shares, then the wire fees etc will only amount to a few percent anyway.

That being said having a US acc would be useful for BTC stuff later on. For example if want to work remotely for a US company, and need an efficient way of transferring money regularly to you home currency personal bank account.


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

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

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

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


Can you make a water heater by mining Bitcoin?

More or less... computer chips produce heat, so sure, it is theoretically possible. First you should know that, compared to a heat pump, a miner's efficiency is zero: heat is the byproduct, not the main goal, so it would take much more energy for the same amount of heating than a decent electric heat pump. But since you are generating Bitcoin in the process, we hope it pays off (wouldn't cut down your bills, would increase it instead, but you would have Bitcoins to pay for the increase, hopefully).

The management of the setup and the economics would be hard: an AntMiner S9 consumes 1200W (and consequentially, can heat water by this same amount). You would have to replace the casing and air cooling system with a kind of water cooling system, using water from your hot water tank as cooling fluid.

Then there is the problem: if you water gets to the desired hot temperature, it won't serve anymore as a good cooling fluid. Then you have two options: if you live in a place where bitcoin mining pays off the electric bill, you can mechanically switch the cooling fluid from the hot water tank to an alternative water circuit, this one designed to dissipate the excess heat (an ordinary PC water cooler radiator, for instance), so that you won't have shut down your miner.

On the other hand, if bitcoin mining is economically unsustainable per se, you would have to shut down the miner when the water is hot. In this case, you would have to be sure that the cost of operating the miner minus the bitcoin it produces is lower than operating a regular heat pump (which is more energy efficient, as I said). Not to mention the cost of equipment and installation and R&D to get everything right is much higher with a miner than with a heat pump designed for this purpose.


Is a mined block invalid as soon as another block is added/accepted?

Blockchains can conceptually easily acquire two or more heads if blocks are solved at the same time. Eventually one of the heads will grow longer than the other, in which case the transactions in the shorter one cease to have ever happened as miners switch to working on the longer one.. This is one reason to wait for a reasonable number of confirmations (blocks on top of your block) before letting the guy drive away in the car he just paid bitcoins for :)

There's another stackexchange thread discussing the longest orphaned chain heads - What is the longest blockchain fork that has been orphaned to date?


Anything that makes ASICs suitable for applications other than the Specific Application the Integrated Circuit was designed for would probably slow it down or make it more power hungry or expensive.

One side effect they do have (along with anything else electronic) is that they convert 100% of the electricity into heat. So you could use them instead of an electric heater.

Note that heat pumps are actually more efficient, so it's not optimal. And in a lot of countries burning natural gas for heating is cheaper too.


How does Exodus wallet (or other wallet) exchange bitcoin to other cryptocurrency?

If I exchange bitcoin to litecoin/ethereum, does the wallet software itself
  send the request the buy order of litecoin/ethereum to some other exchange?

Yes.

  If there is no litecoin/ethereum exchange in my country (Australia) what will happen in exchanging litecoin/ethereum back to bitcoin? I don't know whether it needs to have a litecoin/ethereum exchange in the country to do so...

Cryptocurrencies are international. The wallet does not know nor does it care about where you are located. There is only one exchange the Exodus uses anyways: Shapeshift (it isn't really an exchange though).

  In case if I want to exchange litecoin/ethereum back to bitcoin, how does the Exodus wallet software handle it OR how does a wallet software generally handle it?

It uses Shapeshift. It sends a request to Shapeshift, sends some of one coin to Shapeshift and Shapeshift sends you an equivalent value in the other coin.

  Basically, what are the risks associated with the exchange between cryptocurrencies, other than their price going down?

Because you are only exchanging between cryptocurrencies, there are little to no risks (other than financial) as few or no countries are regulating cryptocurrency to cryptocurrency exchanges.


Bitcoin Core includes code which rolls back a block from the chain when it is orphaned.  All transactions from that block are checked against the new best block chain to see if they've already been added to a block or if they spend the same input as a transaction already added to a block; if they aren't---meaning they're valid transactions on the new best block chain---they're re-added to the memory pool.

The re-added transactions will not be automatically rebroadcast like a newly-received transaction, but if a remote peer sends the mempool message to the local peer, the local peer will tell the remote peer about the transaction (using a standard inventory).


Lag of minutes for poloniex API `returnChartData`?

No, you are not doing nothing wrong. It's internal issue of Poloniex.
Every day I see that most of cryptocurrencies have missed candlesticks. And after up to 40 min are updated.
Even on charts you can see that


Paper wallet imported to blockchain.info with private keys

does that mean that blockchain.info now holds my private key?

Yes, but not exclusively. You still have your private key on paper, so you still hold it. If you don't (i.e. you lost your paper wallet or destroyed it), you can still get your private key from blockchain.info.

  In that case, I won't be able to add my wallet into another similar app because it's already synced with blockchain.info with my private keys!

No, that is not how Bitcoin works. Anyone who holds the private key can spend your Bitcoin. You also hold it on your paper wallet, so you can still import it into another wallet software. There is nothing that prevents you from doing that; it's not like something that can only be imported once.

If you don't want blockchain.info to have your private key, just make a new paper wallet and send your Bitcoin there from blockchain.info. If you want to access your Bitcoin from a different wallet than blockchain.info, then just import your private key into a different wallet.


Do transactions in Ripple have a TXID of sorts, or not?

Ripple transactions have a 256-bit transaction ID that is a hash of the inner transaction and the signature.


A block is just an arbitrary grouping of transactions.  It makes a convenient chunk of data for a proof-of-work to be performed on.  You could hypothetically do the proof-of-work on the transactions themselves, and then chain them one after the other.  This, however, would fail miserably.  Blocks must reference the previous block, so if you just go by single transactions instead of blocks, you'd have wait for the proof of work on each transaction.  It means that you could only have a single transaction on the network per target time for the proof-of-work algorithm.  It's a terrible solution in terms of scaling.  This would also create other problems, particularly having to do with a miner's incentives, and the censorship-resistant nature of the network.  Groups of transactions are better to work with.


How can multifactor authentication be used when there needs to be two people with access?

With Google Authenticator, you scan a barcode into your phone and it generates a temporary 6-digit key every minute, regardless of whether the app is open or not. It is not limited to one person, just to one account. These codes rely on times being in sync so that when an authenticator code expires, it expires on the site as well. Most use two protocols - HOTP and TOTP.

Highlights from this answer: https://security.stackexchange.com/a/35159

HOTP = Client and server share a counter, when code generated, timer increments, producing a new one-time login code.

TOTP = HOTP except the counter is replaced by the current time. So long as the system times are in sync, both the client and the server will be on the same page as far as what 2FA code is currently the correct one.

If multiple people scan this barcode, they will all generate the same keys. Thus, all you need to do is have both people present when setting up two-step authentication (or save the barcode if they have incompatible schedules, but be sure to shred it later), and they will both be able to access the account whenever they want.

Due to best OpSec practices, it is best to have separate 2FA keys, or use an alternative method, such as key-pair authentication where each user has their own key to access the server. This is better for auditing purposes where you can determine more easily the difference between different users, especially if one user decides to do something malicious using a shared authentication code.


How to reconstruct a transaction detail from the blockchain?

I can see the answer now here concerning the fee:

https://blockchain.info/tx/a712e4036222c2cc821443bfbbeb33f94903d2fee08b8e8f1eccada75cf6a9d8

so yes, 809679 is the transaction fee.


This is normal, especially on testnet. What you are seeing are known as stale blocks (or also incorrectly as orphan blocks). These occur when miners complete a block at around the same time so some nodes receive the two blocks in a different order. The conflict resolves when the next block is found.
You will commonly see stale blocks on testnet due to testnet's low difficulty. Furthermore, you see these towards the chain tip because it is only possible to receive these when you are not attempting to do the initial sync. So you won't receive stale blocks during the initial sync, but once you exit that and begin normal operation and your node receives new blocks, you will end up receiving stale blocks (but they aren't necessarily stale yet).
You will need to modify your code to handle stale blocks.


What's to stop someone from making a ton of mining nodes as an attack method?

When two blocks are found at the same height, only one can ultimately become part of the chain with the most total work. Miners do 'vote' which of the blocks to accept, however this is not by casting a ballot, but by producing a succeeding block and thus making one of the two chains longer than the other. Miners thus vote with their hashpower by trying to extend one or the other chain-tip.

Thus the "attack" you describe is impractical: if miners only used their expensive mining hardware solely to decide chain splits, they'd be losing out on a lot of revenue. Instead, they mine all the time to find as many blocks as possible.

Also see:

Why doesn't the same miner always win?
How much would it cost to execute a 51% attack?


Why do we need a "routing" process in Lightning Network?

Even though Pieter Wuille has sad most of what was needed in the comments I will summarize this as an answer.

Technically you could open a payment channel with every other person instead of creating a network with the ability to route. The drawbacks are that your total bitcoin amount has to be distributed over several channels and will be very small in each channel. Also creating channels with everyone would need way more on-chain transactions which would not directly help to reduce the load to the blockchain.

--> Routing is needed to really reduce the amount of onchain transactions needed and to have higher liquidity per channel available.


Can I use Ripple to keep track of loans to friends?

Yes, Ripple is created precisely for such purposes. Both you and your friends need some small balance in ripple first to "activate" your accounts. After that, you need to grant your friend trust for at least the amount he will owe you, and then he needs to send you money. After that, you will see a net positive amount on your account, and they will see a net negative amount.

If you don't trust your friend with the money but you are connected through a web of trust, there is still a possibility of them sending you money. The transaction will appear from them, but your balance will show some other friend owes you money, and in part your borrower will owe them money.


Is transactions in bitcoin blockchain always coin transaction?

All transactions are "sending bitcoins to somewhere".

Some of these transactions are "sending bitcoins to nowhere". Some others are "sending bitcoins to the same place". And some transactions are "sending zero bitcoins to somewhere"

So, there are no other data structures in bitcoin blockchain except of moving bitcoins from one place to another. But the transactions can handle portions of arbitrary data.


When does a miner decide to stop collecting transactions and start calculating hashes to try to win?

I am confused about whether a miner chooses to wait for more transactions (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?

Yes, they can begin mining as soon as they see the previous, and update the block template with new transactions they see whenever they would like. The early Satoshi client updated the template every few seconds, modern miners seem to do it every half a minute or longer depending on the software. There's no advantage for them to update the block template other than that they might get more fees if they do, if they miss transactions there's no real harm done.

  If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?

No, this isn't correct, no miners break ties with the number of transactions in a block. First seen is generally going to be the behavior most people use if they can see two competing blocks at an equal height with an equal difficulty target. If they did tie break with the number of transactions then miners could make blocks stuffed with their own fake ones and always win any races.

  So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct?

No, the header of a block is always 80 bytes long irrespective of the number of transactions the block actually contains. This is because the block header only includes a hash of the transactions, rather than the transaction contents themselves. The difficulty is the same for a block with no transactions other than the one paying the miner or a block with thousands.

  Can someone clarify how this transaction grouping is done by mining nodes?

Hard to answer this because most pools run completely custom software, they have their own criteria and their own optimizations which they perform. Generally they will collect all valid transactions which have the fee they want to accept, and assemble them into a block of the maximum size they wish to create, any which are not included are left in the memory pool for later or for someone else to mine.


Technically speaking, many other cryptocoins are based off of the source code of Bitcoin. However, a quick look at the Anoncoin website (https://anoncoin.net//) suggests that it's been heavily modified from that of Bitcoin (using the darknet, i2p, and all that). Therefore, an API that works with Bitcoin, such as those at inputs.io or blockchain.info is really unlikely to work with Anoncoin in particular. On a more specific note, Anoncoin is a Scrypt-based cryptocurrency, while Bitcoin is SHA-256 based. Therefore, they're even less likely to be able to use the same API. Even if you did try to perform operations on Anoncoin (or any other lesser known cryptocurrency) with the API of a Scrypt-based coin, you're pretty much doomed to fail, and if the API doesn't catch that and the coin does make it into the system, then things could get very strange on the server side regarding how the server should process your request.

In conclusion, most cryptocurrencies, if not all (there are so many that I cannot make a giant umbrella statement here) are handled by their own API depending on the website (for example, inputs.io and blockchain.info use two completely different APIs). It also means that lesser known coins will have difficulty gaining support and usability.

Of course, given that Anoncoin doesn't seem to have a notable exchange to support it yet, perhaps you could make your own API, website, or exchange to handle transactions with it to say other cryptocurrencies. Otherwise, it might just be smartest to sit back, wait, and hope for someone else to do it.


What founders obliged to do if their ICO hadnt raised the required sum

It depends by the terms of the ICO your are investing in.

Some ICO will refund users if they do not reach a minimum amount of funds before the end date scheduled for the ICO itself.

Some others ICO can however hold the funds also if they do not have reached the maximum cap and if they haven't set a minimum cap to consider ICO successful.

Every ICO has its own terms & details, and different specifications about timelines, roadmaps, coins/tokens distribution etc.

You should do your due diligence and read carefully the ICO terms each time you are willing to send funds to any projects.

Hope this helps.


If I send Bitcoin from the USA to a friend in India, do I have to pay capital gain tax on it if he sells it and makes a profit?

If this is a true gift, that is, not part of any larger transaction and given out of the kindness of your heart, then you're probably going to have to consult a tax professional because this will depend on the precise tax treaties between the United States and India.

Generally, when you give a gift to another person in the United States, you do not have to recognize the appreciation in value of that gift as a capital gain and the recipient gets the same basis you had, so they will have to pay capital gains tax when/if they sell it.

But generally, when you give a gift to someone who is not a US citizen, you do have to recognize the appreciation of the value of the gift as a taxable capital gain before you can gift it. However, this can be modified by tax treaties.

If this is not a true gift and is part of some other kind of transaction, then you absolutely must recognize the change in value of the bitcoin as a capital gain before you can give it to someone else, domestic or foreign.

You asked:

  Even if they know it was sold, how can they tax me as I am not the person who sold it?

The tax is not on the sale, it's on the increase in value which is a form of income. Generally, whenever you dispose of an asset, any increase in its value is a taxable gain. There are exceptions, such as a true domestic gift, those made by international treaty, and if it's transferred because of your death.


Where is the code that specifies when a block is released?

Every time a block is successfully mined, the miner releases it immediately. The mining difficulty is adjusted over time to keep the average block release rate at roughly ten minutes. Successfully mining a block is so difficult that all the miners in the world only successfully build a single block, on average, once every ten minutes.


Mining Bitcoin at 40 MH/s is not profitable.

Unless you get free electricity and consider 4 cents a year profit, there is no point mining Bitcoin with that hash rate.

Does your friend's dad have $10 in Bitcoin from mining with that hash rate? Simply put, no. Your friend's dad could have, however, been mining a different cryptocurrency without knowing. 40 MH/s mining Ethereum produces $3 a day.


lot of bitcoinj clients have connected to me

If their IP addresses are all 52.*, then they're lying about being BitcoinJ and are really attacking you / the network. If so, ban them. If their IPs are all different, it's fine.


Does bitcoin.conf expand environment variables?

No, bitcoin core does not expand environment variables in bitcoin.conf.

See here to see how options are parsed.

You can expand environment variables as arguments for bitcoind:

$ bitcoind -rpcuser="$RPC_USERNAME" -rpcpassword="$RPC_PASSWORD"


What would happen if you send bitcoins to a non-existent Bitcoin address?

There's no such thing as a "non-existent" address.

Other than valid addresses created by a client in which the private key is kept secret there are also are:

Invalid addresses (which will fail the client's sanity checks and thus cannot be used when building a transaction)
There are also valid addresses in which no key exists.  The private key is required to spend the funds.  If the private key was lost or one was never generated (such as for 1BitcoinEaterAddressDontSendf59kuE) any amounts sent to that address are lost and can never be spent.  There is no way to know if a private key exists for 1BitcoinEaterAddressDontSendf59kuE or if it was a purposely created throw-away address.
There are also valid addresses in which no key can exist.  An answer to a related question provides an example.

There is no way to know for sure that a valid address has no private key.  What is known is that a program like VanityGen would not be able to create an address that includes many readable words like the address 1BitcoinEaterAddressDontSendf59kuE contains using the type of computational capacity that exists today.  So it can be assumed beyond any realm of possibility (but not absolutely, positively 100% guaranteed) that bitcoins sent to that address are gone for good.

Related:

Can a bitcoin be destroyed?
How to generate a valid bitcoin address for destroying bitcoins?


Try this:

access.move(name, name2, balance)


fixed! The main trouble is time. I set my time in genesis hash +3hrs, i changed my pc time +3hrs and voila! Mining works!


Is there a way that we can report a Bitcoin scam?

The primary way to report scams is to contact your local police.

Since Bitcoin is a peer to peer payment system, there is no hierarchy of control, no Bitcoin central authority to whom you can report scams or who can act or coordinate actions against scammers.

There are some social media and other websites that collect lists of scams, so you could report your problem to those. For example, search for bitcoin scam blacklist. I doubt that this is very effective though. It might alert a few of the more diligent people but many people who fall for scams don't seem to have done much research of this sort beforehand.

Scams that exploit weaknesses in, for example, wallet implementations can be reported to the developers of the software concerned (see recent phishing attack on Electrum by malicious servers issuing false update warning dialogues).

I don't know of scams that exploit weaknesses in the underlying network protocols - but those tend to get noticed by developers and result in Bitcoin Improvement Proposals (BIPs).

  People wishing to submit BIPs, first should propose their idea or document to the bitcoin-dev@lists.linuxfoundation.org mailing list.


Transaction shows transferred instead of sent and zero bitcoins sent to zero recipient

The TX id you posted is wrong. The correct one is https://live.blockcypher.com/btc/tx/a6334b9b391d98083b3f011d6fcf5e097f5c67dbe10ecf41442d335a4694ae2f/

It is showing that 0.00185 BTC was indeed sent to: 14UdCugXpW3ukYgGPNM18v3VqVxyp3S3Ak

After that a large TX was sent that contains 58 inputs one of which is 14UdCugXpW3ukYgGPNM18v3VqVxyp3S3Ak

TX: https://live.blockcypher.com/btc/tx/792405e7a85a468d0cbfa99ac7fc7c4409942768a91d26eb13e8fb9efba46c95/

If the recipient and the owner of 14UdCugXpW3ukYgGPNM18v3VqVxyp3S3Ak did not sent that TX, the priv key of 14UdCugXpW3ukYgGPNM18v3VqVxyp3S3Ak is most likely got compromised and the funds were stolen. Sorry.


lcoin listens on port 19336 by default, however you can set another port by using the --http-port=<your port> flag when starting the node


Compile the code. Release the new client. Old and new version will disagree at some point in the future (block 10k in your case) et voila, you will have a forked chain.


If this happens, you are likely talking of the years following 2140.  If bitcoin survives, it is very possible that bitcoin will be worth millions of dollars.  If so, then perhaps single little satoshis will be worth cents or perhaps what we perceive of as dollars.  Especially if bitcoin is used to supercede as the most common method to use currency.  However america would have to lose a lot of value and do something mighty stupid to lose its number one slot as "the preferred method to hold and spend purchasing power"


Lightning Network: can I create a channel from a preexisting channel?

No, you cannot. This is because you could always revert the state of the channel to the one where you held all of the coins without Alice being able to have any recourse if you do so.


Who will verify any transaction when the upper bound to total number of bitcoins is reached?

Please see here https://en.bitcoin.it/wiki/Transaction_fees .

  It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.


How to create a simple lightweight wallet (without mining) for an Altcoin

you can probably modify https://github.com/OutCast3k/coinbin/ to your needs


Can a miner set the EXACT timestamp of a block?

Bitcoin miners can construct the block header, including the timestamp, however they want, as long as it adheres to the consensus rules. The shift you describe is well inside the 2 hour timerange, so it can be done when setting out to mine the block. It cannot however be done once the block is mined as the timestamp is part of the header, which is hashed into the PoW, hence changing the timestamp would invalidate the proof of work.

Most miners however prefer to increase/decrease the timestamp in order to have a simple way to alter the header, thus more hashes to compute. This is sometimes called time-rolling and is performed on top of the nonce-rolling.


Create a transaction from addresses A and B sending to address C

You are right in how your transaction should look like. However, you are getting confused since you are looking for the wrong concept.

You are not sending funds to a multisig address, that is an address shared by multiple users in which some of them need to sign a transaction or order to spend funds from the address. You are (if I've got it right) willing to spend funds from two different addresses (A and B) in order to send funds to a third address: C.

Therefore, what you should build is a transaction with inputs from both addresses A and B, in which each input may be sign by the corresponding address from the latter two.


Where can one convert their bitcoins to Liquid LBTC bitcoins on Blockstreams Liquid Network?

According to the documentation, anyone running a Liquid node can generate and fund a peg-in transaction. And anyone can run a Liquid node.

You'll need a participant, which can be an exchange, to peg-out and exchange your L-BTC for BTC though.

The peg-in is explained in more details here.


Why estimatesmart fee returning the same fee for diffeent blocks number?

The estimatesmartfee fee estimation algorithm maintains local historical records of two things:

Transaction fees (sat/B) of confirmed transactions
Target Intervals: Blocks between mempool acceptance and confirmation

Based on these records, the algorithm will be able to provide an estimation of the minimum fees required to obtain confirmation within your specified block interval target n.

Specifically, when you query estimatesmartfee(n), you are asking for a 95% historic probability that your transaction will be mined in n blocks.

There are two possibilities for why estimatesmartfee(n) will return equal fees for different targets.

It returns -1: The method doesn't have enough historical mempool records to perform the estimation.
For the mempool records on your local server, the fee rates for 95% confirmation probability within your indicated target values n fall within the same fee bucket range, resulting in the same sat/b values returned.

You may want to run the server a little longer and see if these values change.


Is there data on the geographic distribution of bitcoin users?

This shows bitcoin nodes based on IP address location.

http://www.weusecoins.com/globe-bitcoin/  (UPDATE: link is broken)


Can Multibit be set to use a SOCKS proxy on OSX?

Unfortunately there is a library used in MultiBit/ bitcoinj for networking (called netty) that does not support SOCKS proxies. Thus currently you cannot set up MultiBit to use Tor.

It is something we want to support so there are plans afoot to refactor the code and use a different networking library that does support SOCKS proxies.


Using blockchain to publish downloadable software verification codes

Okay, I will bite.

No, I don't think it would be useful to publish software hashes in the blockchain.

As you recognize, a hash of a software package is useless unless it is somehow authenticated.  Currently, the most popular way to do this is to make the hash available on a "well-known" website which uses HTTPS, and provides an X.509 certificate signed by a recognized authority.  This provides some level of confidence that the hash is claimed as authentic by the owners of the website, who are hopefully the same people as the authors of the software.

If you want to distribute the hash from any site that can't itself be authenticated, the hash will need to be self-authenticating; it should carry a signature that the user can have some confidence was made by the right people.  One way to do that would be with X.509 certificates again, but packaged explicitly with the hash rather than being provided implicitly by an HTTPS server.

Your proposal to use a NXT alias would have a similar effect, though I think as things stand it would provide rather less confidence.  As problematic as the current certificate authority system is, I think most people today would place more trust in a certificate for "Initech Corporation" signed by Verisign than in the owner of "nxt:initech".

Either way, the point is that if you're not going to distribute the hash from some "well-known" location, it has to have a self-contained signature, and at that point you can distribute it any way you want.  You certainly could put it in the blockchain, but what's the point?  It's of no use without the software package that it's supposed to authenticate.  (And you can't put the software itself in the blockchain, it's too big.)  Why not cut out the middleman and just distribute the signed hash together with the software?  In fact, why not just distribute a single signed file?

In fact, in many ways, distributing the hash in the blockchain is less secure than just putting it on a website.  Even if I just stick it on the plain old HTTP server for initech.com, an attacker still has to either compromise that server or intercept a user's traffic somehow, which is nontrivial to achieve.  If I put it in the blockchain, anyone with BTC 0.0001 to spare can post another hash that looks similar (perhaps signed by "inittech" instead), making it fairly likely that some confused user will pick the wrong one by mistake.


Can leased out nxt coins still be used or do you have to wait for it to expire?

According to https://nxtwiki.org/wiki/Account_Leasing:

  Your balance never leaves your account

  Your funds are still on your account after you lease them. They are    still available for use: you can spend them, receive more etc. The only thing given is your forging power, by consequence while your balance is leased, you will not be able to forge on your own.

Your can spend your coins, but when you do your leased forging power will diminish.


Is there an alternative to identify a lightning node without their IP or onion address?

Lightning network nodes are identified by their node_id which is a ECDSA pubkey. This key will not change if the network Adress (IP Adress or onion Adress) changes.
If you issue invoices you will see that neither IP nor onion Adresse are part of the invoice and necessary for routing. Only your node ID (which can be derived from yours signature) is part of the invoice. This means as long as your node is online, has open channels and is connected to its peers it will be able to send and receive money.
So the question is what happens to your node and its connections if the node changes its IP Adress? Well it will in the background open a new connection to its peers and channel partners so that they can talk to you again.
Of course for other peers to be able to connect to your node your node has to send out a new node announcment message via the gossip protocol in order to update its network adress. As gossip messages in lightning are not relayed in real time to protect against spam it can be tricky for other nodes to connect to you if your network address changes too often. However this will not be an issue for end users as their node can reestablish its necessary connections to its channel partners.
If course if all channel partners have the same problem peers could not find each other and conduct the reestablishing in real time. Thus for the routing part of the network somewhat stable network addresses are useful. In general toronions are considered more stable than dynamic IP addresses.
Of course lightning network could have relied on DNS as an alternative to solve that issue. While it does rely on DNS for node discovery as described in BOLT10 it does not use dns for your described problem. So to answer your question fully: no there is currently no alternative but that is most likely never a problem.