How does your account get credited when you send bitcoins(ex. Coinbase)

There are no accounts as far as the block chain is conerned.  A transaction will show up in any wallet that contains a private key associated with one of the transaction outputs.  So if you create a wallet, export the private key and then import the private key into a different wallet, a transaction sending coins to the address associated with that private key will show up in both wallets.  Either wallet can spend the coins although this can lead to synchronization problems with the other wallet.

A wallet is responsible for scanning the block chain and recognizing relevant transactions.  If the wallet is online, it is notified when a new block is broadcast so that it can update its wallet transactions.  if the wallet is offline, it needs to scan the block chain when it comes online to pick up any blocks that it missed.

So the answer to your question is the private keys control which wallets contain a specified transaction.  In your case, you would need to create a different private key for each of your customers.


What are the minimum security expectations of an online wallet service?

It would be impractical to list every single expectation here, but the TradeHill exchange sets themselves up for PCI compliance. I think being PCI compliant is a great set of standards to keep your data safe and secure.

PCI compliance is basically security standards setup by the PCI Security Standards Concil for merchants who accept credit cards, online or offline. They have 4 sets of levels of PCI compliance, which I believe TradeHill to abide to the first level (at the bottom).

Common sense comes into play when storing Bitcoins. Keep a small percentage of them online for immediate usage, when your hot storage gets empty, fill it back up with funds stored offline. Keep multiple secure backups of your wallet files, so a 'bitomat' doesn't happen.

I don't think there is anything to protect a staff member from rubber hose attacks, but limiting the access of your staff members so that the information is accessed on a need-to-know basis through someone like you would help prevent sensitive data leaking. If they're attacking you, then you're fucked.


Why does Bitcoin use two rounds of SHA256?

From Zooko's answer provided in Crypto StackExchange:

  SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their
  excellent book "Practical Cryptography" (later updated by Ferguson,
  Schneier, and Kohno and renamed "Cryptography Engineering") as a way
  to make SHA-256 invulnerable to "length-extension" attack. They called
  it "SHA-256d".


This depends a lot on how you handle your wallet. If you are careful about it and make sure you have an off-site backup of your wallet (or use a deterministic or paper wallet, etc) then you can easily pass your wallet and all the coins it contains to anyone you choose in the same ways that you can pass on other property.

Of course if you're the only person with access to the wallet and have not planned anything then yes, your bitcoins will be "lost in the network."


What contributions have Chaincode developers made to Bitcoin?

Few things that were mentioned on Chaincode's website:

Chaincode engineers develop, review, test and maintain Bitcoin Core

Chaincode has contributed research and design for many of the recent improvements in the Bitcoin protocol, e.g. Erlay and Compact Blocks.

The Chaincode Residency is a program for engineers to develop experience with Bitcoin. Chaincode has hosted several residencies focused on the Bitcoin protocol, Bitcoin Core, Lightning Network applications and the Lightning protocol.

Bitcoin Optech helps Bitcoin users and businesses integrate scaling technologies through workshops, documentation, weekly newsletters, original research, case studies and announcements.

The Chaincode Podcast brings you interviews with the most influential Bitcoin engineers about Bitcoin protocol development.

https://chaincode.com/projects


Switching back and forth between Bitcoin ABC and Core nodes (Ubuntu)

While you can feed the Bitcoin Core blockchain to Bitcoin ABC, the blockchain will be changed by Bitcoin ABC.  So you will need two copies of the blockchain if you wish to also run Bitcoin Core.

Also, unfortunately, you can not easily run these two clients side-by-side.  If you try to install Bitcoin ABC it will install itself over Bitcoin Core and use the same config file.  The only solution is some kind of containerization.  You can do this by using a second computer.  I'm doing it by installing a second Ubuntu into a virtual machine.  I use KVM/QEMU with Virt-Manager.  Then I install Bitcoin ABC into that virtual machine.  I keep a second copy of the blockchain on my host machine and mount that via NFS.  Simply add to your /etc/fstab something like:

192.168.122.1:/home/User/BitcoinCash        /home/User/BitcoinCash   nfs     hard,timeo=14           0       0

Note that 192.168.122.1 is the default address at which your host machine can be reached.  See here.

So far this has worked and I have been able to sync up to the fork, but beyond that I am having some trouble which I am asking about here.  [I am now able to complete the sync.  See that link.  Be sure that when copying the .bitcoin directory for use with Bitcoin ABC, you delete the chainstate/ directory and the blocks/{blk,rev}*.dat that contain blocks beyond the fork, or the client will freeze.]

Note also that you should be careful about the wallet that you feed to Bitcoin ABC.  Do not feed it your Bitcoin wallet if you have anything left in it.  First, transfer everything out to a second wallet.  Then give Bitcoin ABC your first wallet.  Since that first wallet had BTC in it at the fork, those BTC will become BCC even though somewhere post-fork the wallet becomes empty.  The reason to transfer your BTC out of the wallet to a second one, is that you never want to trust a second piece of software, in this case Bitcoin ABC, with the keys that could give it access to your (classic) bitcoins.


How a SegWit transaction is accepted without witness?

How legacy node can verify them without the witness?

An example of a SegWit output is: scriptPubKey: 0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7. For legacy nodes, this output looks like an anyone can spend output as there are no opcodes or verification. Such outputs do not require any signatures to spend. Thus when a legacy node sees a transaction spending a SegWit output, it does not go looking for any signatures and considers the transaction to be perfectly valid.

  Block size of 1MB

With the SegWit soft-fork, block size got redefined to 4,000,000 Weight Units (WU). In the WU calculation, transaction data (excluding segregated signatures) are multiplied by 4 while segregated signature data are multiplied by just 1. For example, if transaction data (excluding signatures) is 200 bytes and the witness data is 144 bytes, then the transaction has a WU of (200*4) + (144*1) = 944 WU. Blocks cannot breach this 4M WU criteria without getting invalidated. If there is a block with 1MB of non-signature data then it's size is 4M WU (1MB*4). Adding signature data on top of that will breach that threshold.

For legacy nodes, the block size continues to remain at 1 MB as these nodes do not query for the witness data for a SegWit transaction. If a block size exceeded 1MB with transaction data excluding signatures, then it would also exceed the 4M WU criteria as well.


running regtest network, bitcoin.conf incorrectly configured?

just do this...

To use bitcoind and bitcoin-cli, you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work:

  rpcpassword=change_this_to_a_long_random_password

in the future I'll be sure to RTFM


in this case will the block be invalid as it hold a previous hash value which is not the latest block?

Yes. The miner will construct a new block template, that builds off the newest valid block, and continue to mine on the new template.

If they continued to mine on the old block, they would likely end up wasting resources, as the rest of the network will have begun following the new, longer (more work) chain.


How to generate a new extended public key (xpub)?

You can do that, but each HD seed needs to be inside its own wallet file which is loaded by the server. Running bitcoind with multiple -wallet arguments will achieve what you are aiming for. Currently it is not supported to dynamically load and unload wallets at runtime, but support for that is being added and will be available in a future release.


How do I get BTC out of my Multibit wallet?

You will need to move your coins to something like Electrum. Give these tutorials a try perhaps:

https://www.youtube.com/watch?v=E-KcY6KUVnY
https://www.youtube.com/watch?v=LaijbTcxsv8


How do I generate a paper wallet for Bitcoin Cash


Do any actual bitcoin credit / debit cards exist yet?

Bitcurex offers prepaid cards for Euro, Dollar, Pounds and PLNs.


My current real-time estimate using https://github.com/ayeowch/bitnodes is 8000 to 10000 nodes that are reachable at any one time with churn rate of 300 to 500 nodes every 5 minutes. The churn could be due to several factors, e.g.

Node went offline
Node reached max. allowed connections
Time of day, e.g. more nodes are online during US working hours
Network errors


Can't make successful call via remote JSON RPC

You're trying to send RPC queries to the P2P network port. You should use port 8332 instead of 8333.

Bitcoin Core:

interacts with other Bitcoin nodes on the network using the P2P protcol via port 8333 (or whatever you configure -port to be)
responds to RPC queries (JSON-RPC) via port 8332 (or whatever you configure -rpcport to be).


There are a lot of things that need to be considered when selecting coins. Just covering the amount that you want to send is not enough, you have not considered the transaction fees that you will be paying for your transaction. So even though you have UTXOs of 0.1 BTC in value, using just one of those means that you will not have enough value in the transaction to cover the transaction fee so your transaction won't be relayed or confirmed.

So if you have to go over the target value, now you need to have change outputs. But even here you have to be careful. If you choose just enough Bitcoin to cover the outgoing amount and the transaction fee, you may end up producing a very small change output that would be considered dust. Dust outputs are not good as they are uneconomical to spend, i.e. they cost more in transaction fees than they are worth.

Bitcoin Core uses two different coin selection algorithms for different cases, and they have different target values.

The first one (the one that you found), is known as Branch and Bound. It tries to exactly match the amount needed for the transaction (outgoing amount + transaction fees) and not produce change. There is a small buffer allowing the algorithm to select slightly more coins than necessary in order to have a better match and avoid producing change outputs.

The general idea for this buffer is that if you are willing to create a change output and have to consume the cost of spending that output in the future, then you are willing to take that cost now and simply not produce a change output. So long as the extra amount that was selected is less than the predicted cost of spending a change output in the future, it is worth it to burn that amount now as extra transaction fee rather than producing a change output. The cost to the user is at most the same, and more likely to be less.

In general, this will produce smaller transactions and thus pay less in fees due to avoiding change outputs. It also helps with privacy because there is no change to link back to your wallet.

If the Branch and Bound exact matcher fails and it must produce a change output, then Bitcoin Core falls back to its original algorithm. This original algorithm is largely also an exact matcher, it just has a bunch of random fixes and hacks that were put into it to fix various issues. At a high level, it randomly selects coins.

An important part of this fallback algorithm is that, because it must create a change output, it chooses to target a minimum change amount to avoid the dust issue I mentioned earlier. Bitcoin Core defaults a minimum change amount of 0.01 Bitcoin. Of course there are exceptions to this when there are not enough coins in the wallet.

So what happened here is that you did not have coins of the correct values to exactly match 0.01 BTC + transaction fees, so the Branch and Bound algorithm fails. It falls back to the fallback algorithm and now targets 0.01 BTC (outgoing) + 0.01 (minimum change) + transaction fees. The fallback algorithm is able to select coins for this target value and thus you get the transaction that you have.


Can I use one graphics card for games and one for Bitcoin mining, without losing performance?

With the advent of ASICs, Bitcoin GPU mining is no longer profitable. I would recommend mining a Scrypt coin such as Dogecoin or Litecoin. (You can then trade it in for Bitcoin on an exchange, if you prefer.)

To answer your original question, yes, you can use one card for mining and the other for actually running the computer.


How to reset node information in Bitcoin Core?

To reset the peer database to the initial state, stop Bitcoin Core, delete the peers.dat file, and start Bitcoin Core again.


How much trust is placed on Satoshi Nakamoto?

Is the safety of bitcoin dependent on the creator of it being a trustworthy person?

No, the safety of Bitcoin is not at all dependent on the identity of its creator.

The source code is public. The paper is public.

  Or would it be safe to use even if it turned out the creator's day job was working at the NSA?

Again, the genesis of Bitcoin is unrelated to its current state or future state, except through the data of the blockchain.


Can failed Transactions figure out which Channel is exhausted?

As far as I understand (but I did not double check the code) the answer is yes. The error messages in the onion seem to be encrypted in a way so that only the origanal sender of the onion can decrypt it. Since the error also had to be padded to keep the error onion of constant length the key derivation scheme for sending onions is kind of reused. In that sense the receiver of the error message unwraps all the envelopes and thus should know from which node the error arose.


I can’t really offer much insight into the reliability of the website you’ve linked, but if you’re really keen to verify what is posted there, you could run your own node, and then find/write some code to index and organize all addresses by their balance. More generally, questions asking about the reliability of a certain website or service are off-topic here.

That said, it’s important to understand what the list actually represents. Namely: this is not a list of how much BTC the top 100 BTC holders own. It is a list of how much BTC is stored in the 100 richest addresses.

This difference is important, as bitcoin users do not map 1:1 onto bitcoin addresses. Many of the addresses on that list are likely the cold storage wallets of bitcoin exchanges, meaning the balance of the address is in fact owned by a great number of users (customers of that exchange). Likewise, some very wealthy users may store their coins spread out across a great number of addresses (in order to maintain better financial privacy, for example).

So while it may be interesting to see what addresses hold the most bitcoin, this metric does not tell us much in terms of who (or how many people) actually own those coins.


Decreasing Energy Consumption of Bitcoin's PoW with paired mining rounds

I think that implementing the protocol described in this paper wouldn't do much to diminish the total energy spent mining, but it would increase network instability and the potential for malicious miners to game the network to their advantage.
This protocol creates a condition where every other block actually requires that the miner to find 2 valid blocks in a row (the election block, and then the second round block), with a fall-back timeout of x minutes coming into effect after the first election block is found. Before x minutes has passed, the election winning miner(s) will have much less competition in trying to find the new block, so it seems to me that it is in their best interest to not publish their election block, until they also find a second round block! This way, the timeout condition will never be hit, but this also means that all other miners on the network will be working to mine their own election-blocks (and second round blocks), with little incentive to stop the search.
With this in mind, it is unclear if any rational miner would turn off their mining hardware ('mining-save-mode'), especially when considering that a miner will have many costs, including overhead (rent), staff, electricity, etc. Turning off their mining hardware will mean completely forgoing their chance of any revenue (the block reward), while only dropping their electrical consumption (and not any of their other costs). This only serves to put a high opportunity cost on any time spent not-mining.
Other issues I can see:

the bitcoin network has no mechanism for registering/identifying individual miners over time, so it is unclear how the protocol could restrict the eligibility of miners participating in the second round in each mining epoch.

The paper claims that the miner which wins the first round of the epoch would not
be allowed to participate in the second round, but it is unclear how
such a thing would be enforced. What is to stop the first-round winner from also attempting to find a 'runner-up' block and compete in the second round? Even if miners were somehow made to register an identity with the network (how such a thing would be possible is a big question in itself), what is to stop a miner from registering many identities, and switching between them?

There is no way to reliably enforce the time-out process for the second round. The network is asynchronous, it is not possible to accurately define '10 minutes after the election-block was found' as a starting point for the fallback process of allowing all miners to participate in the round to help guarantee network liveness. This creates instability at the chain-tip, as the validity of blocks created by the fallback process may be unclear to network participants.
This protocol may create incentives for miners to coordinate externally. For example: if I am a miner and I find a valid election-block, then I may want to sell the ability to participate in the second-round block to other miners! Doing so could help normalize my expected returns, while allowing other miners to reduce their opportunity cost of otherwise not mining in the second round.
Supposing the miners do not perform the election-block-withholding attack described above, in the event a single miner finds an election block, they may be further incentivized to perform a block withholding attack using their round 2 block as well! With little competition for the round 2 block, the miner would enjoy a much higher chance of having the withholding attack succeed, and they could begin searching for the round-1 block of the next epoch while withholding the round-2 block of the current epoch.

These are just some of my initial thoughts, I'm open to criticism of them, and there may be further issues I haven't seen. But at this time, I'm seeing a lot of problems that make this proposal somewhat uninteresting and untenable.

Perhaps also worth mentioning, I think that the premise of the paper is erroneous in the first place. The energy spent by bitcoin miners provides a mechanism by which the network is secured. Valuable things require security, and security cannot be gained for free. The openness of the bitcoin network simply allows a rather objective quantification of the energy (ie the opportunity cost) used to secure it, compared to other systems which have a more obfuscated or social form of security, that comes at a higher relative opportunity cost!


How can i emulate two or more recipient address?

fe709089a2a2142b82f9f57745452eff0f5feb9d6e02a6ad87b8faf4750c8a16 is not paying out to a P2SH multisig address. It is paying out to a bare multisig address.

With your commands, you are creating a multisig address wrapped inside a P2SH address. What you have is a HASH160(redeeemScript). What you want is just an output going to n <pub1> <pub2> .... m OP_CHECKMULTISIG.

Do note that bare multisigs are rarely used these days, and nodes may reject the transaction (although it is still valid if mined). You should be using a P2SH address.


How would tax and government revenue be enforced in a bitcoin run society?

It is a PUBLIC LEDGER - anyone can follow an address trail, and the governments of the world already know how to do that - and that is why so many are looking to adopt Bitcoin and make their own digital currencies.  See especially https://secure.caseyresearch.com/chain?cid=MKT336710&eid=MKT337276&encryptedSnaid=&snaid=&step=start


ASIC Miner Block Erupter & bfgminer: "no devices found"

Try following the ASIC instructions provided with BFGMiner

  These will autodetect if supported by the device; otherwise, you need to use
  the '--scan-serial erupter:' option to tell BFGMiner what device to
  probe; if you know you have no other serial devices, or only ones that can
  tolerate garbage, you can use '--scan-serial erupter:all' to probe all serial
  ports. They communicate with the Icarus protocol, which has some additional
  options in README.FPGA

Try adding --scan-serial-erupter:all to the command for starting BFGMiner.


Bandwidth required for Bitcoin going global?

This is a possible issue.

Currently we have a block limit in size of 1Mb although many pools send out 250Kb to make their block propagate faster to avoid orphaned blocks.

This gives us a cap of 7 transactions per second, data usage of 6Mb per hour or 144Mb a day, almost negligible amount of bandwidth.

Visa on average handles 2000 per second.

So looking at 285 times the amount of transaction is using 40Gb per day in bandwidth.

Most home ADSL2 lines can handle this now.


Create a new receiving address in the behalf of another wallet?

Yes, you can use bitcoin-cli for address generation.

To learn more try:

  bitcoin-cli help getnewaddress

Also consider using some RESTful service running on your Bitcoind host.

For Node I can recommend https://www.npmjs.com/package/bitcoin-core


How to limit the debug.log file while running bitcoind?

You can use logrotate.
Create a file named bitcoin-debug in /etc/logrotate.d.

This is the contents:

/home/bitcoin/.bitcoin/debug.log
{
        rotate 36
        monthly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                kill -HUP `cat /home/bitcoin/.bitcoin/bitcoind.pid`
        endscript
}

Replace /home/bitcoin/.bitcoin with the actual path to your bitcoin directory.

The full logrotate manpage is here: http://manpages.ubuntu.com/manpages/jaunty/man8/logrotate.8.html

In ubuntu the logrotate daemon manages many different log files.  In the /etc/logrotate.d folder, each file contains instructions for the logrotate deamon.  Adding this file tells logrotate that you want to start a new log file once a month. The other options tell it to compress the old logs after a day and to keep only 36 months worth (3 years) of logs.

I originally found out about logrotate from this thread: https://bitcointalk.org/index.php?topic=130533.0

Another thing to bear in mind is that given this sends the SIGHUP signal to the bitcoin server, if you happen to be running bitcoin within gdb, it becomes necessary to tell gdb to ignore the SIGHUP signal, so far example, bitcoind can be run using: gdb $HOME/.bitcoin/bitcoin-qt -ex 'handle SIGHUP nostop' -ex run


What exaclty does owning cryptocurrency mean?

Ownership is a difficult concept and, in some contexts, irrelevant.
The answer you get from a lawyer or tax-adviser may differ from the one you get from a software developer.
Knowledge of a number gives you the power to spend money denominated in Bitcoin. Anyone else who knows that number has the same power. The Bitcoin network doesn't care who knew it first. It doesn't adjudicate ownership between multiple people who know a number.
I'm not sure you can own a number. If I know 12 do I own the number 12? Does that mean other people can't legally use 12 without my permission?. If I know that 12 is the number that opens a combination lock to a safe in my office is that a different sort of knowledge that confers ownership of 12 in some context?  Does it confer ownership of the contents of the safe? Or is the legal ownership of the contents of the safe determined completely independently of knowledge of the combination? These are legal and philosophical questions. I think it may be best to avoid worrying about ownership and concentrate on keeping private keys secure.


Correct Citation Format for a Bitcoin Transaction

There is none that I'm aware of, but technically speaking, the blockchain and the transaction hash would suffice to find it. It might be nice to add the block height number as well.

Something like:

Tx 35779d11b2c5aedc1ada50aaa33aafb53ccc07dae71e6d18a35a0ccb872a0efa, Bitcoin Block 342508

Would work as a citation.


How to get fee in a transaction with unconfirmed inputs in bitcoinj?

In case of a SPV node you don't have the values of the inputs of a transaction, as you don't have the full blockchain and thus all the UTXOs.

The transaction itself has no values of the inputs!

You have the following options:

Query a trusted server for the UTXOs (e.g. electrum servers)
Query a webservice (e.g. blockcypher)
of course have a full copy of the blockchain, you could use java bindings to query a local bitcoind


Yes, you can do that, but it may be difficult to do. This process is called arbitrage and is something that occurs in other markets, not just in cryptocurrency trading.

Keep in mind that if you do this, the price difference might be gone by the time that the other exchange accepts the deposit.

Alternatively, if you have enough capital, you can keep money on multiple exchanges and make same sized trades (e.g. buy 1 BTC on one exchange and sell 1 BTC on the other). However you will still need to rebalance by making transactions, and during that time, you will not be able to perform arbitrage.


What values are legal for the transaction's version field?

In the transaction's version field, what values are legal?

The version field is a 32 bit unsigned integer, any value is valid. Version 0, or version numbers above the nodes CURRENT_VERSION constant are considered non-standard and are not relayed, though they can appear in blocks.

  What values have actually been seen in the blockchain?

1 is the only number to have been in use at this point in time. BIP62 proposes bumping the version to 3 (skipping 2 entirely) to match the block version and avoid confusion, however this was withdrawn. BIP68 specifies that transactions spending a CSV output must have version 2 or higher.


Why was BIP34 (Block v2, Height in Coinbase) not implemented via the coinbase tx's locktime or nSequence?

That would have made perfect sense, and I see no reason why that wouldn't have been the superior way of doing it.

However, as far as I remember, nobody suggested this at the time.


Will the Liquid sidechain be open to any user?

Liquid wallets are open and accessible to anyone. This could either be SPV wallets such as Blockstream Green or the Elements Liquid node.

With these wallets you can verify transactions (your own transactions with Green, all transactions with the node). However, you can't produce blocks. To do that, you need to be one of the Liquid members. To become such a member, you need to go through Blockstream. At the time of writing, there are 33 members full list available here.


How to keep Bitcions when reinstalling OS from fresh

(I suppose you have the Bitcoin-Qt client.)

Taking a backup of the Bitcoin folder will do it.

Copy the folder to an external hard drive of a different partition.
Reinstall your system.
Install Bitcoin-Qt again.
Move the folder back.

Note that to keep your bitcoins, only the wallet.dat file is required. But when you copy the whole folder, you will probably not need to sync with the network again.


Set the number of keys/addresses in a wallet

Finally found it:

# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
#keypool=100


What kind of privacy does Taproot give bitcoin?

Taproot allows inputs to hide the fact that there is a script specifying a contract. If sufficient parties involved in that contract agree and cooperatively spend the Bitcoin, that input looks just like any other input, including ones that do not have contracts and have only one person.

This helps privacy as the conditions of a contract are hidden. This also makes such transactions smaller which will save on fees.


Would signature aggregation reduce the largest feasible blocksize

SegWit blocks aren't limited in bytes anymore but rather in weight. The maximum weight for a block is 4M. The weight of non-witness data is 4x its number of bytes.

So, yes, decreasing the amount of signature-data frees up some weight which can then be filled by more transactions. Yet those new transactions also contain some non-witness data which is more costly. An average full block will still be 4M in weight, but reduced in size (bytes) while containing more transactions. Both are good news.


in the form of them giving me the key for getting access to the wallet.

Something I associate with scams.
If this is an online wallet (custodial) this sort of thing is normally explicitly forbidden in the terms and conditions. And for good reasons.
If it is a more normal wallet, it is an idiotic way of donating money. That by itself is suspicious.

Is it possible, that I'll run into trouble here?

It is possible, but there's insufficient information to guess how unlikely it is.
Suppose that the wallet (key) is stolen or that money that is the proceeds of crime will be routed through it. It is possible that, having accessed or used the wallet you will be traced and held responsible for money laundering, handling stolen money or accused of complicity in crime.
Maybe they're hoping you don't know that changing the password won't lock them out of the wallet and that sometime in the future you'll add money to that wallet that they will then steal.
Maybe they're grooming you and will later ask you to perform some sort of favour for them involving the use of that wallet in a way that helps them but lands you with debt or a day in a police interview room?
Or it may be the donor is just appallingly inept. Or thinks you are?
In the end it doesn't matter, you don't have to work out the exact way they are trying to trick you. If it seems at all suspicious, keep well clear and don't get involved at all.
The only relatively safe way to accept Bitcoin as a gift is to download a popular respected wallet to a clean PC or phone, don't give anyone else any details at all about your wallet apart from a single-use bitcoin address they can transfer some amount of Bitcoin to. Never accept wallets or keys from other people.


Make sure That you have, in your bitcoin.conf file located in ~/Library/Application Support/Bitcoin at least the following:

server=1
rpcuser=<username>
rpcpassword=<your_password>

Restart Bitcoin client, enjoy Bitcoin solo mining. ;)


Transactions are chained in a way that when Alice spend funds, she has to provide two pieces of information, the first one is a proof that the money was sent to her  and the other is a challenge for whomever wants to spend the coins she is sending, so when Alice received her coins she provided an Address, I.E the challenge, or a hash of the challenge to be more precise.

When Bobs gives his address he is doing the same, he is providing the challenge that needs to be solved in order to spend the coins.

When Bob generates an address what he is doing is generating a key pair, the private key he keeps secret to use when he wants to spend funds, and the public key is hashed twice and encoded in a special format, (Base58Check), and is that encoded hashed value what he shares with Alice.

So when Alice pays to Bob, she creates a new transaction, that refers to the old transaction from which she is spending, that old transaction has the hash of Alice's PublicKey, it pays to whomever can demonstrate that owns the ECDSA private key that generated Alice address. That is easy to check, because Alice provides the public key that hashes to that address and she signs the spending transaction with the private key and adds the signature to the transaction that spends the funds.

It means that she needs not only to prove that she has the private key, but she must also prove that having the private key she approves the spending by signing the transaction that spends her funds.


Sending P2SH transaction with non-standard script

Before the redeem script is executed, the stack looks like this (from top to bottom): TRUE, Data3, Data2, Data1, Sig. The TRUE on top of the stack comes from OP_EQUAL.

Now the redeem script runs and you drop the top three elements from the stack and then add PubKey, leaving you with PubKey, Data1, Sig. When OP_CHECKSIG runs now it uses Data1 as Signature instead of Sig which makes it fail. At the end the stack is FALSE, Sig. The top element of the stack is FALSE which makes the transaction fail.


Why don't developers switch from bitcoin-qt to a cleaner implementation?

(disclaimer: I work on Bitcoin Core)

As Luca already mentioned, you have to distinguish wallet implementations and the fully verifying nodes on the network.

Because of how Satoshi wrote his code (a node and a wallet in the same program), the two are often confused, but this is considered a bad idea now. They can perfectly function independently. The reference client's wallet is only one of multiple wallets now, and certainly not the most used or in any privileged position.

When we're talking about validation on the network, things are more complex. Bitcoin is a consensus system, where every node in the network must be able to independently judge the validity of blocks, and come to the exact same conclusion as everyone else. If two nodes disagree about the validity of blocks, they will ignore the other (considering each other's blocks as attacks). If two groups of nodes with different rules both have mining power, a fork will appear, where both groups believe they're the only ones around. This is a disaster, as it means every coin that existed before the fork can be spent once on each side.

Thus, the actual rules of the network are those that full nodes implement. We can try do describe the behaviour, but can't prescribe it. If the rules would be written down in some unambiguous formal document, and a difference would be found between the rules and the implementation, we might say the implementation has a bug... but new nodes on the network would have to copy that bug nonetheless.

Unfortunately, reimplementing those rules is far from trivial. Many people who have tried doing so have actually discovered weirdnesses in what is considered valid by the reference client, and weren't previously known. For example, Bitcoin relies on OpenSSL for signature verification, and early versions just passed whatever was found in transactions to OpenSSL. Turns out that OpenSSL actually accepts incorrectly-encoded signatures to some degree. Without knowing it, several wallet implementation had appeared over time that created such signatures (they're accepted, they must be valid, right?). This means that any new fully validating node implementation must either use OpenSSL too, or mimick it exactly by accepting the exact same set of invalid encodings. There's been progress towards making these signatures invalid (since 0.8 they're not relayed anymore), but making them actually invalid will require a coordinated soft-fork of the consensus rules (EDIT: this has happened on july 4th 2015 with BIP66 being activated).

Examples such as that make me very uncertain about whether exact reimplementation is possible with the current state of the art. That's certainly partly due to implementation details in the reference client, but also because of how hard consensus systems are. There are unit tests for several parts of the logic, and a network interaction test that simulates several weird edge cases to see how a node responds, but they are far from complete (especially because maybe not all edge cases are even perfectly understood). Differences are unlikely to be things found through random testing.

In my opinion, we should aim at modularizing the reference client code, and abstracting the consensus-critical part out into a library, so that it can be reused by several clients without these risks. That will inevitably take time, though.


What is the btc.to address shortening algorithm?

The results are specific to the website and the order in which the addresses were input.

This can be easily determined by experiment. I took a random address from BE and it gave me http://btc.to/2z7. I took another address and it gave me http://btc.to/2z8.

So clearly, it stores all given addresses in a database, and the URL is the address ID encoded in base 36 (experiment also shows that it's case insensitive).

Also, it only accepts valid Bitcoin addresses.

More generally, it's impossible for any algorithm to take an arbitrary long, high-entropy string and give a short string which can be uniquely mapped back to the input.


Why does this transaction results in more than 1 unspent output?

This is an exchange withdrawal, and presumably they are batching multiple user withdrawals into one transaction to reduce the overhead cost. In particular, 17A16QmavnUfCW11DAApiJxp7ARnxN5pGX belongs to Poloniex.

This is not uncommon, and many companies that must make frequent payments to multiple people will batch the payouts to reduce fees.

Most wallet software will not let you set multiple change addresses for a single transaction, but nothing prevents you from creating such a transaction manually at a protocol level.


How can I specify transaction fee size when creating a raw transaction?

The fee is the difference between the inputs and outputs, so you can specify the fee by leaving that amount unaccounted for in your transaction.

Be careful though, this has lead to 200BTC transaction fees in the past when someone forgot to include a change address: http://www.reddit.com/r/Bitcoin/comments/1lb5my/asicminer_refunds_the_accidental_200_btc/


How to test if a transaction can spend an existing output?

If you build Bitcoin Core from master, you can use the new testmempoolaccept rpc method to check if your tx would have made it into the mempool. This will include checking the signature, and ensuring that your inputs are actually unspent. It does not add broadcast the tx into the mempool, but simply checks if it would have been accepted.


What strategies can an e-wallet use in order to reduce transaction fees?

First, transfer out older coins, gathering as few inputs as possible. The client does this automatically, and exchanges will typically have a vast supply of old outputs they can claim.

Second, combine transactions (using 'sendmany'), sending funds to more than one destination at a time. If you have a single, large, old transaction output you can claim, use it to make payments to three or four destinations at once. This will keep your transaction just inside the free relay limit.

Third, configure your client appropriately. Set it to never pay a transaction fee. Set it to specifically connect to other clients known to relay transactions with no fees and known to be linked to miners who are willing to include transactions with no fees. And trade off anonymity for convenience and speed by modifying your client to send new, local transactions to all connected clients immediately.

Note that not all of these strategies will always be appropriate. For example, if fast transactions are important to your customers, it may be worth paying the occasional transaction fee even if you have to eat the cost.


What is a good resource to learn about bitcoin

I would recommend bitcoin book and bitcointalk forum as starting points. The book is very technical, but has everything you need to know. After 2nd+ reading things will get much easier. Forum has huge amount of useful information, but keep an eye on outdated material. It is also good to know whats going on with current BIPs to have some vision about upcoming protocol changes, etc.


How can I participate in a mining pool that is mining Litecoins?

Litecoin doesn't use the same algorithm as Bitcoin. Bitcoin hashes are SHA-256 based.
Litecoin hashes are Scrypt based. You must use a miner capable of understanding scrypt.  Early in Litecoin history there were no GPU capable miners as the performance of GPU relative to CPU was very poor.  In time GPU performance increased and today most mining software supports both SHA-256 and Scrypt.  Part of the reason that GPU mining is possible is that the Scrypt parameters used in Litecoin (and other clones) have been selected to reduce the "memory hardness" of the algorithm.  The default parameters for scrypt are n=2^20, r=8, p=1.  The Scrypt used by Litecoin uses the parameters n=2^10, r=1, p=1 making it roughly 100x less memory hard and allowing GPUs to out perform CPUs while they are unable at n=2^20, r=8, p=1.


Is there any service/api for deriving HD wallet addresses from a master public key?

I ended up writing my own command-line tool to perform wallet discovery and print out a report.

It supports single xpub derivation as well as multisig m-of-n wallets, specifically CoPay wallets.

It determines if each address has been used or not by querying blockchain.info or also toshi or insight servers (the latter two can be run locally.)

Anyone interested can check it out at:
https://github.com/dan-da/hd-wallet-addrs

I plan to add a web frontend soon.  Update: Web frontend is here.

Also, blockonomics is pretty good and very fast.  They don't seem to support CoPay/multisig yet though.


Is one blockchain of one exchange place the same blockchain used in other exchange places?

As long as your Bitcoins are in Kraken and you haven't withdrawn them, then the Bitcoins aren't actually recorded on the blockchain -- Kraken just has a line in their database saying they owe you a certain number of Bitcoins. You wouldn't find this on the blockchain until you actually initiate a withdrawal of your Bitcoins from Kraken.
Every Bitcoin exchange, and every Bitcoin user in the world, when they do publish to the Bitcoin blockchain, publish to the same blockchain though.


On quering the blockchain, can someone read what transaction took place?

We're implementing bitcoin-blockchain smart contracts in OpenBazaar.

OpenBazaar smart contracts are not part of the blockchain. The blockchain stores the multisig contract only; it serves as a depository for the money to stay before a product is delivered.

However, smart contracts are viewable at a later time, and either party can prove that the contract was in fact signed by their counter-party. Whether a public entity is able to view these contracts depends on how the contract was transferred between the two parties. Contracts are general means of exchange, so they can be transferred privately (e.g. via GPG-encrypted email), or publicly (e.g. by publishing plaintext on reddit).

In all cases, contracts are typically GPG triple-signed with public keys, and this signature is verifiable by anyone. If the physical identity of the person holding a GPG key corresponding to an OpenBazaar identity is known, they can be hold liable in traditional law court.

Of course, one of the points of OpenBazaar is pseudonymous transactions between merchants and buyers whose physical identity is not known. In that case, the contract may be displayed in a traditional court, but the court will be powerless. On the contrary, we employ arbiters and mediators that are able to resolve such conflicts of interest between pseudonymous parties, and who can themselves be also pseudonymous if they so desire.


OP_CHECKSIG: reasoning behind construction of message to be signed

I think, since with some sighash types, the scriptPubKey is not part of the txid. So it is not automatically taken into consideration when the txid is already part of the hash.


old wallet.dat with only incoming tx from mining, now shows 0 coins even after rescan and all the transactions are there

If you found an old wallet (prior to Core 0.13 which was released in August 2016), it wasn't using BIP32 HD. So there is very very likely no master private key,... instead, there are a large number of private keys.

You can use dumpwallet <filename> in the GUI console or via RPC to extract your private keys to a text file and import them into a different application.

But if you see transactions in Bitcoin Core and your balance is zero, this mostly means that there must be one or multiple spending transactions that have spent your mined bitcoins.


Your transaction should be confirming shrtly(within 1 day)You did not send the appropriate miner fee which is why the transaction is slower to confirm. Do not worry tho it will confirm at some point tody:)


How could a large owner of Bitcoin give back to the Bitcoin community in an equal way?

By destroying his coins ( sending them to an address noone has the private key for, like 1nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn )


So far as I know, those two are the most advanced, and your best bet is going to be placing an order and waiting for it to ship.  Sadly, as I have one on order and am waiting impatiently.


Can Litecoin & Bitcoin have overlapping Transaction Ids (txid)

Litecoin uses Scrypt as its mining algorithm, but transaction identifiers (txids) are still produced using SHA256d. Litecoin started with a different genesis block, so there is no overlapping history in the blockchains.
It is extremely unlikely for any transactions to ever collide in their txids, simply because 2256 is such an extremely large digest space, whether that is within Bitcoin or across Bitcoin and Litecoin.


The Makefile in that directory appears to be a perfectly good makefile. Perhaps the build instructions are out of date. So try:

make namecoind

(without the -f option, the make program automatically reads the file named Makefile).


How can I calculate network hashrate for a given range of blocks where difficulty changes somewhere within the range?

Start by computing the total amount of work. Work is defined as the expected number of hashes that were necessary for a particular block. If a block's target is Target, its amount of work is Work = 2**256 / (Target + 1) (follows from the fact that Target + 1 in 2**256 hashes have a value lower or equal to Target). As the difficulty Diff is defined as MaxTarget / Target with MaxTarget = 65535 * 2**208, it follows that Work = Diff * 2**48 / 65535 = Diff * 4295032833.

So, for each block, look at its difficulty, and compute Diff * 4295032833. Compute the sum of all those values for all blocks in your time range.

Now divide that sum-work by the number of seconds your interval lasted. The result is your average number of hashes per second during that interval.

For very short intervals (less than a few hours), it is possible for block timestamp inaccuracy to be relevant. One way to avoid this problem is by starting off not with a range of blocks, but a range of timestamps, and choosing all blocks within that range, rather than estimating the time range from the range blocks.


How do I send bitcoin to multiple recipients at once?

You can "send to many" addresses in the same transaction, most of the wallets have options to create a transaction with multiple output addresses.

Also, I would like to know if the reason I see people do this is for privacy reasons?

There can be lot of reasons. Batching is normally done by exchanges and businesses to use bitcoin in a better way and pay less fees. I am not sure if there is any benefit related to privacy in batching except if the outputs are of similar amounts or amounts are hidden in the case of L-BTC(Liquid) confidential transactions.
Batching can save upto 80% fees by David Harding: https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb
Electrum:

Bitcoin Core:


how to see bitcoin blockchain and addressess for testnet

Blockchain.info does appear to support testnet blocks and transactions by simply using the "testnet" subdomain.

For example:

txid: 4200cea53a075f3081156a9d664fe05cfe108a09e26e8f20ee65e7ebe141060b

block: 1443900

address: mum6KQEwAHGDRr7HRXx7hufcsyqiGPUCtN

So in your case simply use this:

https://testnet.blockchain.info/tx/#{txid}

https://testnet.blockchain.info/address/#{address}


Details are in BIP 146:

We require that the S value inside ECDSA signatures is at most the curve order divided by 2...
...
A high S value in signature could be trivially replaced by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.

Signatures encode two important values for verification r and S. If (r, S) is a valid signature, then so is (r, -S), which is equivalent to (r, curver_order -S).


How this is possible to generate blocks with no transactions?

How this can be possible and what for?

A miner is under no obligation to include transactions in a block, but there are incentives for them to do so:

the miner will make more revenue, since they will collect transaction fees
miners are invested in their operations, and thus want to see bitcoin succeed. If no miners processed transactions, bitcoin would not be functional (and thus miners may lose money on their investment)

There are some times that it makes sense for a miner to make a block with no transactions in it, for example when a miner hears about a new block on the network, they may first validate the header, and then afterwards validate the entire block. The miner wants to begin mining on top of the new block ASAP (mining on an old block would be a waste of money), but they have a small problem in that it takes a tiny bit of time to download and validate the entire block's contents. During this time, the miner will be unsure of which transactions are in the new block, so in order to guarantee they do not accidentally re-use an already-confirmed transaction, they will attempt to mine an empty block while waiting for the validation of the previous block to finish.

Even though this only happens for a very short amount of time, given enough blocks, probability says that eventually, a miner may find a valid, empty block in the seconds following the last block.

  Additional question: If this is so easy to generate such blocks, what stops miners to generate these (lightweight) blocks as many as possible to earn new bitcoins?

The number of transactions in block does not affect how easy it is to mine a block. Finding a valid empty block is no easier than finding a valid full block.

Some related questions that may be of interest:

How often does a block have only 1 transaction?
Why does antpool mine so many empty blocks?
Creating empty blocks vs full blocks


How to make a Bitcoin address your main one in Blockchain.info?

I've played around with the blockchain.info wallet, and here's what it looks like is happening:

Blockchain.info shows the "This Is Your Bitcoin Address" by date the address was added to your wallet (not the date of the oldest transaction on the blockchain)

To determine blockchain.info's "sort order" for your addresses, export a paper wallet (from the button on the "Wallet Home" tab)

The order of addresses on that pdf is the order Blockchain.info will use when choosing your Default Address. You need to archive/remove all of the addresses above your DESIRED address for it to be your default.

So if you want to change the default address you have two options:

If you don't need the 'old' address anymore

Simply transfer the BTC out of the previous address into a new one (either one you already have, or click on the 'create new address' button).

Archive the 'old' address. It's still available in your wallet under the Receive Money / Archived tab.

Archived addresses won't be shown as your main address.

If you want to keep the 'old' address in your wallet

A little bit trickier, you'll be DELETING the address & private key, then re-adding it.

Generate your paper wallet backup, and have it open. Make SURE you have the private key of the address(es) in front of you.
Archive the address(es) above your desired address
Go to the 'Archive' tab and find those archived addresses. Check the box next to them and select DELETE. (blockchain.info will ask you if you're sure. Then they triple check. It's a good idea to make sure that yes - you still have the private keys saved from step 1 above)
Re-import the private keys taken from your paper wallet) for your addresses. It's under the "Import / Export" tab. When importing, select IMPORT KEYS DIRECTLY (instead of SWEEP KEYS) if you want to keep the same address in your wallet.


The question is a little confusing, but:
1 and 2 are more to do with your own personal security practices. Of course, your own bitcoins are only as safe as the measures you take to secure them.
#3 - It is recommended to stick to wallet software that is open source, such that its code can be audited and verified to be safe. If you can read code, you are encouraged to read through the code of the wallet software you use and compile it yourself.
#4 - Traffic on the Bitcoin network isn't encrypted at all. If you run a Bitcoin node, your ISP will be able to see that you're running a Bitcoin node, and if you relay transactions from your node, your ISP will be able to assume those are your transactions. However, they won't be able to modify them, as any modification would require a new signature with your private key.
#5 - At worst, a miner launching a 51% attack can prevent your transactions from confirming. While harmful, they won't be able to actually manipulate your transaction, as your transaction still must have a valid signature from your private key.


What legal items should I know about if I am piggy-backing off of another bitcoin exchange?

If you're worried about regulation, you should be contacting a lawyer to help you remain compliant.


Would it be possible to change the p2p protocol used by the bitcoin-clients without a hard-fork?

Yes, the p2p protocol itself is not consensus-critical. Of course there can not be two completely seperate networks, so you will have to take care to create bridges between the two. But other than that you could make a sneakernet p2p network where people exchange USB sticks if you like.


Would it really be this easy to steal peoples bitcoins?

Yes, of course this would work.

What do you expect? It's the digital equivalent of walking into a random building with a storefront that vaguely looks like a bank with lots of dollar signs, and then asking "hey i want a bank account, where do I send money?".

Don't install random wallet software. Do research.


Who decides that the new block is ready to hash?

A new block is ready to hash as soon as the last block has been solved. Miners immediately start to try solving the next block. As soon as one of them succeeds, that block is published and all the miners move to work on the following one.

The difficulty is adjusted so that a solution is found by somebody, out of all the active miners, on average about once every 10 minutes.


How do I remove hard coded seeds from the bitcoin source code?

There are a few ways to do it, I personally went into src/net.cpp and commented out the if condition that triggers the lookup starting at line 1266.

// if (addrman.size() == 0 && (GetTime() - nStart > 60)) {
//     static bool done = false;
//     if (!done) {
//         LogPrintf("Adding fixed seed nodes as DNS doesn't seem to be available.\n");
//         addrman.Add(Params().FixedSeeds(), CNetAddr("127.0.0.1"));
//         done = true;
//     }
// }

Another effective fix was to remove all the encoded seed nodes from the two arrays located in src/chainparamsseeds.cpp


How do I buy bitcoins with South African Rands?

https://www.luno.com (previously known as BitX) trades BTC for ZAR via EFT to South African banks. They have accounts at FNB and Standard Bank. If you have an account at one of those, it will clear faster.


Trying to import Bitcoin ATM wallet into Armory

I'm very curious why does Armory scan the private key I have imported takes for a long time.

However, sweeping a bitcoin from a paper wallet should be very simple.
Install and use a Mycelium wallet app on your phone. Scan the QR private key on the paper wallet and send it to the Armory's QR receiving address.

In this case, you are using the Mycelium wallet as a bridge and nothing is compromised. You can also just throw away the paper wallet.

Just maybe the problem is with pycoin. I'm trying to use an offline bitaddress.org to import my private key to Armory.


Bitcoin Blockchain Parser to get all block headers

I share a small Python script that can parse off-line the data which is stored in blk*.dat files.

You can try it here.

If you want, you can turn-off the strings savings that you does not need.


Is there a way to use My Wallet account with bitcoin-qt client?

Yes, export the private key(s) of the addresses that have funds on blockchain.info using the settings/advanced section and then import them into the bitcoin-qt software. You will then have full access to the address(es) in both wallets.

in the bitcoin-qt debug console..

importprivkey "keyhere"

Edit:  Don't forget change from transactions may not go back into the original address - so once you've made a transaction it may be that you have to repeat the export & import private key process to have the funds available on both wallets.


With the strongest hardware today, how long does it take to brute force or generate 10^18 bitcoin address as fast as possible?

My laptop, running an i7-4XXX can hit about 1 millions keys per second using a vanity address generator at its peak. This usually slows down as it heats up, and it is certainly possible to go faster with GPUs.

Assuming the strongest hardware today is 10000x faster, or can generate 10 billion keys per second, you will reach 10^18 in 10^18/10^10 seconds, which is 1157 days.

Note that the Bitcoin keyspace is much larger, about 2^256 (although I believe you "only" need to crack 2^128 to start breaking into stuff with high probability, but I can't find that reference right now). For 2^256 keys, even at 10 billion per second, it would take you 3.672×10^59 years, which is 2.7×10^49 times the age of the universe.

Edit:

You would only need to go through 2^160 combinations to break a p2pkh address, since you only need to beat the HASH160. This reduces your time to only 4.631×10^30 years.


Complete definition of 'tx_witness' data structure used in 'tx' data structure

In Bitcoin Core, the scriptWitness property (for the CTxIn class) is serialized from a CTransaction as a std::vector<std::vector<unsigned char> >, so I would imagine the serialized version would look something like:

TxWitness:

+------------+-------------------------+------------------------+
| Field Size |        Description      |       Data Type        |
+------------+-------------------------+------------------------+
| 0+         | witness_component count | var_int                |
| ?          | witness_components      | witness_component[]    |
+------------+-------------------------+------------------------+

WitnessComponent:

+------------+------------------+-----------+
| Field Size |   Description    | Data Type |
+------------+------------------+-----------+
| 0+         | component length | var_int   |
| ?          | component        | uchar[]   |
+------------+------------------+-----------+

References:

https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L67
https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L254
https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h#L676


Lightning bumpfee completes but doesnt create a new transaction. Instead it waits in "pending sweeps"

My bitcoind didn't have the parent txn so the bumpfee never completed.
I restarted my bitcoind, lnd, rebroadcasted a raw txn that I got from another node's mempool and issued a bumpfee again.
A new txn was confirmed shortly after


Problems with deterministic ECDSA based on RFC6979 in Bitcoin

Not any serious efficiency concerns. Signing is done fairly infrequently for any particular client (only a few signatures per transaction usually). While possible that the signing might take slightly longer to generate the k value, it would not be noticeable, especially considering how infrequently it is used by any one particular client. It's the verification of all the signatures that is the CPU bottleneck for block verification in bitcoin, because all full nodes have to verify the signatures of all the transactions on the network, and this takes the same time regardless of how the k parameter was chosen.

Gregory Maxwell made a comment about the use of deterministic k values here:

  The primary arguments in most spaces against derandomizing DSA are
  FIPS conformance (irrelevant for us) and reasonable concerns about the
  risks of using a (less) reviewed cryptographic construct. With
  widespread motion towards derandomized DSA this latter concern is less
  of an issue.

The new libsecp256k1 library by Pieter Wuille actually uses deterministic generation of k.

Also note that one of the key benefits of using this construction is that you need not worry about a weakness in your PRNG being exploited in the signing process. For example, signing different pieces of data with the same k value instantly leaks your private key. A similar attack can also be exploited if the PRNG is weak enough to determine the relationship between different k values used when signing the same piece of data. Since the k is deterministically generated from the data you are signing (and the private key), these concerns about the PRNG are no longer as relevant, as you will always produce the same signature for the same piece of data. This also makes writing ECDSA unit tests easier.


Traditional VC investment vs. bitcoin IPO

This is ultimately a question where you may have to choose between liquidity and control.  Traditional VC investments are a lot more liquid, in other words, they likely have a lot more money to offer, than any bitcoin stock market.  At the current exchange rate, the amount you'd like to raise is equivalent to roughly 15,000 bitcoins (on the 1.5 million end of the the range, anyway).

Localbitcoins - you're a popular enough exchange that you may very well be able to raise that much in a bitcoin IPO.

I imagine it'd be a lot easier with a traditional VC to make that kind of money though, and that would be in fiat already for the marketing efforts that you're planning.  But the catch is that the money the VC provides will likely have strings attached, they'll want some control of your business in return for that kind of money, or as you said, the 4 - 5 year exit plan.

The other issue that you have to consider here is this: what are you looking for in return for this money?  Are you just thinking of the money going towards shares of stock, as in a bitcoin exchange?  Or do you want business advice for your business as well?  A bitcoin exchange can definitely provide liquidity, how much, I don't know.  But if you want business advice, then you are likely better off with a traditional VC since they will be able to provide that for you.


HD wallets are not special when it comes to transactions. Transactions don't care whether the keys involved were derived deterministically or generated randomly.

Think of a wallet split into two parts: the first part (which we will call the key handler) handles the private/public keypairs and creating digital signatures. The second part (which we will call the transaction handler) handles transaction receiving and transaction creation. Suppose the first part has some functions getnewpubkey (returns a new address) and signdatawithpubkey (receives a public key and some piece of data to sign, returns a digital signature).

So there are two different types of key handlers - ones which randomly generate keys and ones which generate them deterministically (aka HD wallets). These two can be used interchangeable with the transaction handler; the transaction handler does the exact same thing and it doesn't care about how the keys are generated. All it needs is to get keys when it needs them, and for the key handler to sign transactions when the transaction handler asks it to.

In your scenario, regardless of whether a HD wallet was used, the transaction handler knows of two transactions that it can spend from. These two transactions were sent to the addresses that correspond to two keys that the transaction handler asked the key handler to provide (i.e. it called getnewpubkey twice).

Now when you want to send, the transaction handler constructs a transaction that has your two received transactions as the inputs. Once it creates the transaction, it sends it to the key handler to sign (so it will call signwithpubkey twice and pass in the same transaction on both calls but one pubkey for the first call and the other pubkey for the second call). Then it takes those signatures and the unsigned transaction, combines them, and produces a final transaction which is then broadcast to the network.

Notice how the transaction handler which actually receives and creates the transaction does not know nor does it care about how the keys were derived. You could have used a key handler that randomly generates keys or one which deterministically generates them; it makes no difference.

  what should be done by the user. Thus, would appreciate it if anyone can explain the above by highlighting some steps in bitcoin-core for example.

The user does not need to do anything. The user clicks the buttons to get a new address when he wants a new address and clicks the buttons to send Bitcoin when he wants to send. Everything (choosing which transactions to use as inputs, creating the transaction, signing the transaction, etc.) is handled by the software. What the user does with transactions does not change whether the keys were randomly or deterministically generated.


Recovering ECDSA public key from the signature

when looking at a signed (P2PKH) tx, the signature looks like this:

483045022100A428348FF55B2B59BC55DDACB1A00F4ECDABE282707BA5185D39FE9CDF05D7F0022074232DAE76965B6311CEA2D9E5708A0F137F4EA2B0E36D0818450C67C9BA259D0121025F95E8A33556E9D7311FA748E9434B333A4ECFB590C773480A196DEAB0DEDEE1

This can be further split into two parts:

signature:
483045022100A428348FF55B2B59BC55DDACB1A00F4ECDABE282707BA5185D39FE9CDF05D7F0022074232DAE76965B6311CEA2D9E5708A0F137F4EA2B0E36D0818450C67C9BA259D01

pubkey:
21025F95E8A33556E9D7311FA748E9434B333A4ECFB590C773480A196DEAB0DEDEE1

and further looks like this in detail (with address for pubkey at the end):

  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        00A428348FF55B2B:59BC55DDACB1A00F
        4ECDABE282707BA5:185D39FE9CDF05D7
        F0
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        74232DAE76965B63:11CEA2D9E5708A0F
        137F4EA2B0E36D08:18450C67C9BA259D
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
    #########################################################
    21: OP_DATA_0x21:     type tag indicating LENGTH
    02: OP_INT_0x02:      type tag indicating INTEGER
        5F95E8A33556E9D7:311FA748E9434B33
        3A4ECFB590C77348:0A196DEAB0DEDEE1

    * This terminates the Public Key (X9.63 COMPRESSED form)
    * corresponding bitcoin address is:
   1HTNtayFkoBV28wqDygMbW33qSnRjxAuNR


Is there a point on the secp256k1 curve for any given X coordinate?

The size of secp256k1's coordinate field is 2256 - 232 - 977.

That means there are only 232 + 977 (about 4 billion) possible 32-byte combinations that are not a valid coordinate.

Only slightly less than half (around 2255 - 1.17 * 2127) of those are the X coordinate of a point on the curve (in fact, for every valid X coordinate, there are either exactly 0 or exactly 2 points on the curve).


There isn't really a notion of "withdrawing" from cold storage.  Bitcoin isn't a bank and you don't make deposits and withdrawals.  You have some coins in an address, that's all, and you can spend them any time you like.  The only difference with cold storage is that you are storing your private key on a piece of paper / USB stick / offline computer / etc, so you will have to do a little more work to spend the coins.

Spending coins from cold storage just requires a transaction, and every transaction requires a transaction fee.  But this would be the same fee no matter whether you were keeping your keys in cold storage or in a web wallet or on your smartphone.

(You might find older resources suggesting that coins which have stayed in the same address for a long time can be spent without fee, due to the transactions being higher "priority".  This is not true anymore due to the current shortage of block space.)


cgminer doesn't detect GPU in ssh session

The reason for this is that the X-Server that is handling the GPUs is not available in the SSH session. Try prefixing all commands with DISPLAY=:0. This tells cgminer which X-Server instance to use. The cgminer command then simply becomes:

DISPLAY=:0 ./cgminer -u ...

You can also fix this for the current session with the following

export DISPLAY=:0

this defines the variable in a bash shell (see your shell's documentation for details if you're using another shell). Putting this into your .bashrc file might be a good idea if you intend to use it only over SSH .


Send bitcoin raw transaction to network via webserver?

If you have a local bitcoin node (i.e. bitcoind running on the webserver), you can use the RPC command sendrawtransaction in order to send a transaction through your node to the network. Alternatively you can use a third party transaction broadcasting service like those offered by blockchain.info and blockcypher.com. Lastly, you could attempt to speak the Bitcoin P2P protocol and send the transaction directly to nodes on the network.


Total Bitcoins in circulation on any given day?

From command line the piping to date command needs a 2nd eye.  Bit late for me here, but it's a unix timestamp conversion to whatever format you want.

You can find out by:

getting the hash of each block at height X using the RPC or bitcoin-cli getblockhash X
using the blockhash to get information about that block using RPC or bitcoin-cli getblock <HASH>
get the timestamp of that block
convert timestamp into the date format you want
get the first transaction of the block (coinbase transaction) for the amount of newly mined coins using RPC or bitcoin-cli gettransaction <TX>

And run it through every block in a loop.

e.g.

bitcoin-cli getblockhash 1
00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048

 bitcoin-cli getblock 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 | jq '.time' | date
Mon Jun  3 18:54:45 UTC 2019

bitcoin-cli getrawtransaction `bitcoin-cli getblock 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 | jq -r '.tx[0]'` true | jq '.vout[0].value'
50

Here is block #1 on a btc explorer showing the same data, 50 new coins.

You can loop like that on command line but probably better to do with RPC and a real programming language.


can blocks remain capped to 1MB forever?

The blocksize topic correlates directly with the current 7 transaction per second (TPS) ceiling Bitcoin has that was recently brought to light before US Congressional Testimony. https://en.bitcoin.it/wiki/Scalability describes the 7 TPS ceilings under "Current bottlenecks".  Ignore block framing data fields, the 7 TPS limit implies that ~4200 transaction (10*60*7) with each being ~238 bytes in size fitting nicely into the 1MB block brown bag. A careful examination of the top of blockchain-dot-info will indicate the real world is a little more complex, and the 7 TPS ceiling is extremely optimistic, most transactions will be significantly larger than 238 bytes size! My mining Payouts alone are ~4K in size.

The tweaking of the blocksize a very hot/political topic. Remember the March 12, 2013 Bitcoin forked Blockchain issue??? (http://bitcoin.org/en/alert/2013-03-11-chain-fork) It is too early for me to tell what the trade space pros & cons [system's engineering truth concerning the trade space analysis of alternative (AoA) results for backward compatibility, scalability, security, sustained decentralization... measures of effectiveness (MOE) and measures of performance (MOP)] is for increasing the current 1MB block size in the Blockchain.

Ignoring state politics, in the end, the dynamics between stability of developer solutions, hardware engine solutions, miners and pools will ultimately determine the block size(s) supported in the future.

See:

http://keepbitcoinfree.org/
https://bitcoin.stackexchange.com/tags/blockchain-fork/hot
http://www.reddit.com/r/Bitcoin/comments/1owbpn/is_there_a_consensus_on_the_blocksize_limit_issue/
http://www.reddit.com/r/Bitcoin/comments/ioeob/an_alternative_to_supernodes/


Is it possible to run more than one client instance on a machine?

You need both a different RPC port (-rpcport), a different P2P port (-port), and a different working directory (-datadir).  You will also need to use the daemon (bitcoind) for everything after the first instance, since only one GUI can be running at the same time.


You can change the data directory

https://bitcoin.org/en/full-node#linux-instructions


It would depend on what the bankruptcy laws are in Japan and if the exchange has any assets or Bitcoins left.

Then it depends on how much the legal fees are involved it finding and converting all these into cash.

You should make sure you are included in the list of creditors or you will have no chance for a recovery of anything. And if you do recover, it will usually be pennies on the dollar.


i found bitcoin wallet I need qr private key where i can get that code?

I need qr private key

QR codes are a 2D barcode typically used by cryptocurrency wallets to present a payment-address which someone else uses to send you payment. They are also sometimes used when printing a private-key as a paper wallet.

where i can get that code?

Non-custodial wallets generally provide a means to extract the private-key. For example with Bitcoin-core you can use the CLI command dumpprivkey
Most wallets are protected by a pass-phrase. If you don't know the pass-phrase, and can't guess it, you cannot extract the private-key.

If you believe the private-key was printed in QR-barcode form as a paper-wallet it will obviously be wherever the owner put it - we can't really help with that.

Found wallet
You have no access to the Bitcoins associated with a wallet if you don't have the wallet's passphrase and dont have the private-key and don't know where it is in printed form and don't know a seed-phrase used to generate the private keys.

Converting a private-key from text to QR-code
If you have full-access to the wallet you found and want to convert it to a paper wallet in QR-code form - you'll need the wallet to support that or export the private key in other form (e.g. WIF) and then import it into software (perhaps a different wallet) that has the features you need.
For those comfortable with programming, I've seen people suggest downloading the HTML from, say, https://www.bitaddress.org and running that on a disconnected PC. It looks like client-side Javascript and can generate QR-codes from a known private-key with some modification. The Javascript libraries used appear to be open-source so can be obtained from the usual repositories.


How do on-line wallet or bitcoin exchanges usually secure their private keys?

To support timely settlement services outside an exchange's platform, around 1/12 to 1/16 value of an exchange's cryptocurrency value will probably need to be placed in hot storage. The rest will be in cold storage. Conceptually, fractional hot to cold storage ratios are analogous to fractional reserve banking and PBX trunk sizing.

The cybersecurity ante for the "state-of-the-practice" for exchanges and payment processors business as usual needs to be upped.  Don't even think about just a bunch of keys (JBOK) management. Hierarchical Deterministic (HD) technology is really the only viable approach to minimize key management complexity that can eat you alive. Insider threats will be one of the largest attack surfaces for exchanges. Employee background checks will be inadequate. Multisig support is critical to ensure internal separation of duties to prevent conflicts of interests.

For concise Dash examples about how to apply BIP 32/38/44 to altcoin key synthesis, and address generation (for both public and private extended keys) see answer URLs reference by BIP 38 Implementions for Altcoins?, in particular see this recent Wiki Posting.

Supporting multisig signature capability will be critical for minimizing the exposure of an exchange's cold and hot wallet assets. Suspect the libbitcoin multisig transaction composition interface will work for numerous altcoins, since I've tested it for BTC and TEST coins a few months back. However, still need to validate that bx multisig interface works with the newly supported altcoin "version" interface.  Extra validation work is required to ascertain which altcoins bx can successfully create version 1 text formatted multisignature transactions, and which altcoin network consensus mechanisms no kidding truly support multisig blockchain capabilities.

Multisig technologies alone do not prevent out-of-band multisig workflow spoofing attacks... ask BitP++. Suspect exchanges and payment services practicing "due diligence" and "due care" will eventually learn they must also deploy expensive to design/deploy/sustain controlled interface CDS technologies.


What keeps mining pools from creating wallets that send transactions only to pool members?

What is the point? The service you get as a user is worse, with 1/5th of the hashpower, I as a user have to wait longer to get my tx into the chain.

Now something similar is already happening, and has been for a long time. I can pay a pool to get my transaction a higher priority. Instead of replacing my transaction with a higher fee, i pay the miner directly so they will include it in their next block.

I get it you are thinking allong the lines of ''well if this pool has a part of the mempool that is only exlusive to themselves, they will get that money, but others wont'', yet from a user perspective, it makes no sense to do this. It takes more time, i see no reason why it would be cheaper.

Remember, the systems functions under ''I as a user am indifferent as to who includes my TX into a block, as long as it happens'' & ''I as a miner am indifferent as to what TX's I am including, as long as it has sufficient fee's''.


Ledger Nano S supported path is: m/49'|84'/0'/0'.
Source: https://walletsrecovery.org/


Blockchain.info is an alternative to blockexplorer that has additional statistics regarding market prices, mining costs and bitcoins in general. There is some information there about transactions that might interest you.

Here is a chart with data from last year:

A chart with Bitcoin Days Destroyed is also available at the website. This might be a better way to represent Bitcoin's usage. See this question and the wiki for more information about Bitcoin Days Destroyed.


All transactions would be replayable on both chains even after one was confirmed in a block on one chain, because since both chains start with the same UTXO set, the transactions spending those UTXOs are valid on both chains. The only exception is coins mined on each chain after the fork, because those coins will not be valid on the other chain. So that is how you can split your coins, you would need to mix your coins in transactions which use coins mined after the fork, so they are only valid on one chain. In the case of such a split I assume there would be some sort of service launched by the miners on both chains to start mixing people's coins and splitting them

EDIT: Ledger have announced they'll offer a tool to do that, its likely others will too: https://twitter.com/LedgerHQ/status/921730827117096960


Is the current number of confirmations visible somewhere in the raw block?

The number of confirmations is (height of most recent block - height of the block containing the transaction + 1). The contents of the specific block containing the transaction are fixed, while the number of confirmations keeps increasing, so the number of confirmations cannot be in the raw block data.


SegWit Version - is there a proposal for new versions?

BIP-114 which was published a while ago comes to mind :
https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki


Can I synchronize the blockchain on one computer then transfer the files to another?

Yes. Simplify go into the Bitcoin folder and copy every thing to the new computer. (Make sure you keep wallet.dat safe)


How to figure out the coordinates of a compressed G point?

Actually the compressed form in hex is 02 + X_coordinate if Y coordinate is even, or 03 + X_coordinate if Y coordinate is odd; comparing to the uncompressed form is 04 + X_coordinate + Y_coordinate.

So to retrieve the coordinates from the compressed form, just calculate the Y coordinate by curve equation Y^2 = X^3 + a*X + b, there will be two Y values, then choose the correct one by the prefix which is 02 or 03.

You will get the actual coordinates of the point.


How do I reconfigure Abe to work with Litecoin?

I used this configuration to work with Litecoin

{
  "chain": "Litecoin",
  "code3": "LTC",
  "address_version": "\x00",
  "magic": "\xfb\xc0\xb6\xdb",
  "policy": "Sha256Chain"
}

Its now hitting block 1201593 without any crashes. But still observing.


Are there RPC calls for correct RBF calculations in Bitcoin Core?

If your transaction is from Bitcoin Core's wallet, you can use the bumpfee command. It should do the same thing that the GUI does in order to create a replacement transaction with a higher fee.


This is 'service bit filtering.'

You can run nslookup seed.bitcoin.sipa.be, and get a list of bitcoin nodes.

You can also run nslookup x1.seed.bitcoin.sipa.be, and get a list of nodes with NODE_NETWORK set.

(source 1. source 2.)


How to find top 100 richest bitcoin wallet addresses on given date?

You can use blockchair.com. It allows to easily search and analyse the Bitcoin blockchain (also Bitcoin Cash and Ethereum).

In your case, you can sort the transaction outputs (addresses) descending
 by value and optionally specify the time in the time field so you get the top richest addresses at that time.


Lost my BTC, though my wallet is still available

Are you also sure that you've let Bitcoin qt fully synchronise with the network? Very recently I moved across my wallet.dat to a new installation with no issues.


What IDE to use for Bitcoin development?

Bitcoin Core uses the autotools build system, but CLion only supports projects using CMake, so you can't use Core with CLion. You should be able to use Core with Eclipse CDT and NetBeans as those support Autotools. You may need to do some special configuring for it to work properly. Most people who work on Core just use text editors, command line build commands, and gdb instead of an actual IDE (at least that is what I use, and I have heard some others do too).

If you want to add debugging print statements to the code, just add lines like this:

fprintf(stderr, "some text here\n");

and that will print some text here to the terminal if you are running it from the terminal. fprintf is a standard C function so you can look up how to use it to include more information in the output.


There are memory intensive mining algorithms, but usually the "memory" being discussed is not of the DDR3 variety. That 64 GB of DDR3 RAM you have is an excellent resource for many computing tasks (and enough to make me jealous), but is also dramatically slower than the L1 and L2 cache physically on the chip with your CPU. This is the memory we're talking about.

Memory intensive mining algorithms came about in reaction to GPU (and later FPGA and ASIC) acceleration. Because GPUs have so many cores, each core has access to only a miniscule amount of RAM, often an amount measured in kilobytes. Because Bitcoin's SHA256 mining algorithm has a tiny memory footprint, it runs quite nicely on such hardware. Some say this is a problem, others disagree.

CPUs, on the other hand, have relatively few cores sharing access to, on average, 64 to 128 kB of L1 cache and 2 to 4 MB of L2 cache. By virtue of being on the same die as the CPU cores, this RAM is extraordinarily fast and has amazingly low latency. This, it turns out, is an exploitable difference that memory intensive algorithms take advantage of.

An ideal implementation of one of these "memory intensive" algorithms (for mining) will be tuned such that the RAM footprint required is higher than the few kilobytes available to GPU cores, but lower than the few megabytes typically available in L1/L2. In this way, the mining algorithm can be run at high efficiency on standard CPUs, thus maximizing the hashrate available to secure the network, but is still resistant to GPU/FPGA/ASIC acceleration. The CryptoNote algorithm used by Monero is a good example.

Sadly, few altcoins take such care with their implementation. Most either use so little memory that they are freely accelerated with GPUs or use so much that all mining processes eat into your good old DDR3 and lose efficiency. In short, there is almost certainly a coin out there that can make use of such an obscene amount of system memory, but that's almost certainly a sign that they did it wrong since the goal of such an algorithm should be to maximize hashrate on the target device (CPUs) for the sake of network security while preventing acceleration from non-target devices (GPUs, FPGAs, ASICs).

In any event, all proof-of-work systems currently in use are mathematical in nature. This makes the memory requirements somewhat secondary in nature - you will still require a lot of computing power to mine and it is this computing power that will largely determine your results. In a few cases the extra RAM may help, but your CPU will still be doing the heavy lifting.

Special note: In certain non-mining implementations of such memory intensive algorithms (like the scrypt implementation used in BIP38 encrypted keys) the poor efficiency caused by exceeding available on-chip cache can actually be a positive effect and is often used intentionally. By forcing the process to use slower memory we can throttle the number of decryption attempts an attacker is able to make in a given timeframe, which dramatically reduces the effectiveness of brute force attacks. This is why decrypting your BIP38 key on a phone often takes 30+ seconds - it's a feature, not a bug.


1) When i send transaction who validate it ? Here I think, who can check and found that I haven't got enough money in my wallet. Example; I send 100 BTC but I have only 50.

All full nodes validate every single block and transaction they receive. Once a node validates each block and transaction, the block or transaction is forwarded to the nodes that it is connected.

A number of things are checked to ensure that a transaction is legitimate. One of the things checked is the sum of the outputs being spent (i.e. the inputs) is greater than or equal to the sum of the outputs being created. It does this by looking up the outputs that are being spent. Presumably the transactions that those outputs were a part of has already been validated and the node remembers that it determined that transaction to be valid. So when it sees your invalid transaction, it will immediately see that the sum of the outputs being created is greater than the sum of the outputs being spent, which means it is invalid. Your transaction will then be marked invalid and rejected.

  2) Can one transaction go by mistake in two blocks, and who prevent this ?

No, a transaction cannot go in two blocks. This is prevented by full nodes which validate every single block and transaction they receive.


Can an attacker with 51% of hash power change old blocks?

An attacker has a hard time changing the past

An attacker has very limited influence to change old blocks, because he has to replace all blocks that confirm the event he wants to change and keep up with the new ones that the network is still creating.

Example:
Say, Eve achieved to control 51% of the hash rate and wants to unconfirm a transaction from 6 blocks in the past.

To succeed, she has to provide 6 + X + 1 blocks, while the rest of the network finds X blocks.

With a hash rate distribution of 51:49 solving for X:

Eve would have to sustain control of 51% of the network's hashrate for an average of 172 blocks in order to unconfirm a transaction confirmed by six blocks.

That would be approximately 28 hours and 40 minutes. My calculation is simplifying the process by expecting a fixed block interval, as in reality, mining is a random process, it could take much longer or shorter.

Change a week of history?

For a week back, X would solve to 24,720 blocks, i.e. roughly 171 days.

How much could be changed with a week of 51% hash power?

With a week of 51% hash power, one would be able to catch up roughly 40 blocks, i.e. about 6 hours and 40 minutes.

But really?

Well, 50% of the hashing power doesn't just drop off the grid for long times without anyone noticing. If suddenly all blocks took twice as long people would start to catch on, after a few hours. I'm not sure everyone would just accept a rewrite of a significant portion of the history. As when both chain forks are public, it is easy to find out what was changed in the history, there might be broad support for declaring the attacking fork invalid, or at least somebody might be able to find out who got conned, and sue in meatspace.


Has the Bitcoin network surpassed the total computing capacity of all the general purpose computers in the world?

The comparison doesn't make sense. You can't use Bitcoin ASICs to do general computation, and using CPUs to mine Bitcoin is incredibly inefficient.

It also isn't meaningful in terms of security: no one would try to attack Bitcoin by taking over all of the CPUs in the world. Instead, they would fabricate or buy mining ASICs. (Or, more likely, try to hack into the pool servers that miners get their work from.)


Adversarial Question: Why not fork LND Loop and provide the service freely/cheaply?

LND Loop is an open-source solution with MIT Licence. So, you are free to fork the code and create your own solution without any restrictions. In fact, there are a number of submarine swap companies out there that offer you a solution to import/export liquidity from your channel. LND Loop will just be one amongst a sea of such solutions. Market share winners and losers would be differentiated from their customer service and how they are going to tailor the solution to the customer needs.

A classic example to consider is Docker. Its code is completely open source (Apache 2.0 license) for Linux distributions and you can fork it if you want. However, Docker has raised $307.9M in funding to date and has a valuation in billions. They make money through their enterprise editions, docker hub and other professional services.

In my opinion, a similar analogy can be drawn for lightning. In the future, the company that will be able to handle huge requests of loop-ins and loop-outs without sacrificing time will grab a majority market share. They will have to tailor their solution to their customers and provide the best service possible. This will require considering multiple factors including good backend technology to handle the load, good professional services and if the company is able to handle enterprise implementations for their Lightning payment needs. They will also need to figure out liquidity and fluctuations in market price of Bitcoin to handle such operations. Offering all the services at a low cost is what is going to differentiate the competition. Forking off the code is just the first small step.


What constitutes a project to be a Bitcoin Sidechain?

A sidechain requires one or more blockchains, aside from the parent chain. This is different from off-chain, which is what would be the case in some types of Coinbase transactions. Since you didn't mention the presence of an additional blockchain in your other reference to a 3rd party which provides tokens in exchange for a payment, I would assume (albeit subjectively) that it would probably be an off-chain type of transaction in that example, too.

Rootstock, on the other hand, has its own blockchain, to create a 2-way peg with Bitcoin to facilitate smart contracts and other potential features, like near-instant payments.

Here's more information about sidechains in case you'd like to read about them in more detail. There are additional technical components beyond the presence of one or more blockchains:

Enabling Blockchain Innovations with Pegged Sidechains
A Simple Explanation of Bitcoin "Sidechains"


Is BIP 32 Technology Cryptographic Curve Agnostic?

Any Elliptic Curve could work in the BIP32 scheme. The only property of a Curve that BIP32 relies on is that a * G + b *G = (a + b mod N) * G, which is true for any Elliptic Curve.

Secp256k1 is a 'Koblitz' curve, which just means its choice of parameters enables very fast scalar multiplication (computing a multiple of the Generator point).

With that said, if a vulnerability was discovered in secp256k1, it's not like everyone could just switch over easily. That would require a major change to the Bitcoin consensus system, and require coordination of many software systems.


Someone is using a bitcoin account to blackmail me

Blackmail should be reported to your local police.

This is a question and answer website where ordinary people like you and I share helpful information on a voluntary basis. We don't run bitcoin (no one does).

The number is not an account number, it is a bitcoin address. Those are not really traceable to any specific person, computer or place. People like the FBI may be able to eventually track down criminals using bitcoin on a large scale but we can't.


Mutibit HD - Maintain a wallet on 2 devices

Yes with an HD wallet you can use as many devices as you like.

However you may want to ask yourself why you are doing this. More devices = more possible attack surfaces.

Using different HD wallets has the benefit of the losing one (to a keylogger, etc) not causing loss to your Bitcoin in the others.

Why not keep a small amount of BTC in your mobile HD wallet for everyday use and have a little more in a seperate laptop HD wallet and the majority in a seperate cold storage HD wallet?


If you are purely out to learn, consider mining on the bitcoin testnet (the alternate bitcoin network that is identical except for running on a different port and allowing non-standard transactions). There you can even easily mine without needing any pool.

If you do insist on working on the Bitcoin port, really just about any pool should still allow you to participate. The question might be, though, what mining software is appropriate. If your choice involves downloading the blockchain, then its sheer size (>7 GB) may constitute a hardware constraint. But if you mine in a pool anyways, there is no reason for your miner to need access to the blockchain, unless you want it to verify that you do not unwittingly participate in a 50% attack.


What is the current state of BIP 38 (encrypted paper wallet) integration with cell phone wallets?

Blockchain.info works well, exactly as you describe for BIP38 encrypted keys.

I switched to Mycelium in late 2014 and have had good experiences since then.

  what's the state of BIP-38 integration with wallets in general?

It is actually quite good now.
Only obviously missing wallet is Armory: https://github.com/etotheipi/BitcoinArmory/issues/131

(Armory pioneered many of these ideas with its own implementations, but it is not yet using standards like BIP32 and BIP38 which came later)

One can also use Bippy to work with BIP38 encrypted keys offline.

PS: I just added recommendations here for creating a paper wallet:
How to download bitaddress.org to use offline?


The traditional way to store data is via an OP_RETURN. On Bitcoin, this is limited to 40 bytes of data. Bitcoin Cash increased this limit to 220 bytes just yesterday.

You can also store arbitrary data (more or less) on ethereum via a smart contract.

Traditionally, for this kind of use case, people opt to store the hash of the data instead of the raw data itself. They can then provide the raw data to someone, who can hash it and verify that it matches the hash that was stored on the blockchain.


Unconfirmed/pending transaction in MultiBit no longer exists, but my coin is still gone!

Use your backup to restore your wallet. Re-import your private keys and re-scan the block chain for your incoming transactions. If you can't find the outgoing transaction, then it was never sent and the coins are still in your private address.

If you have Multibit HD, then keep pressing 'receive' to generate a new address until it gets to the address that you received the coins on. Then it should show in your balance. I think you are using Multibit Classic though, so it only generated random addresses each time, and you would need your private keys for each address.