Accountability with Bitcoin transactions

I am no lawyer, but as far as I know there is no specific precedent for this, or none that I could find anyway. Due to this, if you could reasonably prove that you had no intent in supporting that illegal organisation or group I don't see a strong case for any prosecution. Obviously there is a huge amount of grey area here, so what is "reasonable" would be up to interpretation. Also each country would have its own individual laws, which makes this even harder to give a specific answer.

If you are worried, I would recommend that you do two things. 1) Cover your ass by keeping all emails or any correspondence relating to your BTC transactions in a secure place. 2) You can also use tools like PGP, Hushmail, Cryptocat, Zfone, TrueCrypt and Tor to help protect your online anonymity.


How do I use electrum on multiple computers?

As you have suggested, all you need to do is to restore the wallet from your seed on each computer and you'll have all your Electrum instances synced.

Labels can also be exported and imported on each PC in order to avoid having to re-write them; or you can use the plugin LabElectrum (Label Sync) to store them in the cloud and update them at your convenience.

Transactions will remain synced as they are received from the network.

Imported keys are not derived from your seed, so you'll need to manually import them on each computer. Or if you have many imported keys you can copy the electrum.dat file to each computer you'll use.


I'm not sure what daemons should be used in this script and ...

You first run two bitcoind daemons locally and then specify their ports as arguments to the command along with other information such as authentication credentials:
# Example usage:
#  multisigsync.py \
   --connect1=http://abc:123@127.0.0.1:9000 \
   --connect2=http://abc:123@127.0.0.1:9001 \
   2MsrtHjVXGdT7RuTEiUWzec87Cik1rPpmyD

In this example one bitcoind has been configured to listen on port 9000 the other is listening on port 9001
It looks like this should also work with remote bitcoind instances.

... how it all works.

It isn't clear what part you want help with.
The ServiceProxy stuff seems to be described at https://www.jsonrpc.org/archive_json-rpc.org/python-json-rpc.html


Why do keys need both X and Y coordinates, if X can be solved for Y using the curve equation?

A private key is just a number modulo the order of the curve.

A public key is the (X,Y) coordinate pair corresponding to that number (the private key) multiplied by the base point (which is a property of the curve used).

If you're talking about public keys: you're almost right. The Y coordinate can indeed be computed from the X coordinate, if you know the sign (given the formula y^2 = x^3 + 7, there are two solutions for Y for every X).

In fact, if you're using a recent version of several wallet clients (bitcoind/bitcoin-qt since 0.6.0 for example), this trick is used. It's called compressed public keys, and it means that when spending a transaction output, the public key stored in the spending script (and thus the block chain) only contains the X coordinate and a marker byte to denote which of both Y coordinates is used. This is slightly slower to validate, but saves space.

In practice, public keys are encoded in the following legal ways:

0x02 + [32-byte X coordinate] (if the Y coordinate is even)
0x03 + [32-byte X coordinate] (if the Y coordinate is odd)
0x04 + [32-byte X coordinate] + [32-byte Y coordinate]

(the two solutions for Y always have different oddness, but as we're talking about a coordinate in a finite field rather than a real number, it does not actually have a 'sign')


Arbitrage in the Bitcoin / Bitcoin Cash fork

A coin on either fork is distinctly a coin on its respective fork. Sure you can send someone BTC and then send someone else BCC that spent the "same" input, but no one will care because that is entirely a different coin using a different blockchain. With the kind of fork that will be happening, no sort of fraud (outside of any normal fraud) can occur. The fork implements two way replay protection so receivers cannot replay transactions and get money on both forks, and double spending cannot happen because this will be a persistent chain split with no possibility of blockchain reorganizations.


Why isn't the block hash used to calculate accumulated work?

The answer is because among the set of acceptable hashes, every hash is equally likely. See https://bitcoin.stackexchange.com/a/939/60443

There really hasn't been more work done just because the value is greater, as long as it meets the current difficulty. Nickel and diming the work done by comparing block hashes would create many more forks, thus requiring more confirmations to be sure a transaction is final.


Javascript library to explore bitcoin blockchain data by connecting to a local running node

bitcoin tools library
https://github.com/bitpay/bitcore-lib

Unofficial Node.js client for blockexplorer.com API
https://github.com/barto-/blockexplorer

or you can install bitcore full node and use bitcore-lib with that full node


Is there an equivalent to the Xpub/Zpub for multisig wallets?

A multi-sig address is a hash of a script that combines multiple separate keys. In other words the purpose of it is to require multiple signatures from multiple keys that are stored (and usually generated) independently. For that reason it can not be generated from a single extended public key (xpub).
What you can do, is to have multiple extended keys, and for each address derive a public key from each xkey at the same path and combine those pubkeys to get your address.

For example a 2 of 2 scheme between Alice an Bob would work like this:

Alice generates a master private key, stores it in a safe and private place.
Bob generate a master private key, stores it in a safe and private place.
Alice gets her master public key for a specific path like: m/44'/0'/0'/0* and shares it with Bob.
Bob gets his master public key for a specific path like: m/44'/2'/1'/0* and shares it with Alice.
They both agree that Alice pubkeys have to come first** and start at index 0.
To get an address they each independently derive the same public keys from the two extended pubkeys they have, combine them (OP_2<AlicePubKey><BobPubKey><OP_2><OP_CheckMultiSig>) hash it and get the corresponding address.
Each time they want a new address, they get the next index and repeat step 6.

*. These paths are optional but the keys that are derived from these extended public keys can only have non-hardened paths.
**. Note that in step 5 the order is important and they have to agree on it first. Otherwise the address for OP_2<BobPubKey><AlicePubKey><OP_2><OP_CheckMultiSig> is different and mistakes like that could lead to losses.


Which crypto currency exchanges are using segwit (bc1) addresses for its users?

As of November 2017, only Electrum wallet and blockchain.info are major services which support bech32 address format. A number of services use P2SH wrapped segwit scripts which is easier for backwards compatibility for the moment. This is expected due to the bech32 BIP (BIP 173) not being formalised at this point in time.


Do サトシ (Satoshi) or ナカモト (Nakamoto) mean anything in Japanese?

Without knowing the intended kanji, it's unclear exactly what meaning "Satoshi" and "Nakamoto" have, because there are sometimes many homophones in Japanese (including homophonous names). The Japanese Wikipedia article on Satoshi Nakamoto does not give kanji (and also treats it, typographically, as a Western name), suggesting that the exact intended meaning is unknown. But, we can make educated guesses.

For "Satoshi", there are over a dozen possibilities listed on a Japanese name site, but many of them relate to virtue, wisdom, intelligence, and other intellectual traits.

For "Nakamoto", it's much easier to provide a solid guess. 中本 is a common family name, roughly meaning "middle-origin". 仲本 might also be plausible, with this "naka" meaning "relation, relationship". And, even if "moto" were written as 元, this still roughly means "origin".


Are Ethereum Tokens issued in an ICO similar to stocks on a stock market?

Tokens, in general, are not the same as shares in that they do not provide ownership stake or voting rights in the corporation. Typically, they are simply vehicles with which to conduct transactions for the goods or services within the corporate entity from which they are issued.  After the ICO where the company sets the price for the tokens, their value is based on supply and demand.  Demand is usually speculative and created by people's perception of what they think the particular corporation's importance will be in this new, rapidly evolving, yet very powerful world of blockchain technology. This speculative nature, as well as the fact that tokens provide no form of ownership, is what has led many established traditional Wall Street corporate investors to call this new investment vehicle dangerous, fraudulent, Ponzi-like, a big "bubble", etc.  There's no doubt that many of the companies issuing cryptocurrency tokens will disappear in time leaving their tokens worthless, but there is also good reason to believe the best ones will become large, powerful, and ubiquitous in our future. The tokens, which by the way are usually finite in number, of the surviving companies in this nascent cryto-world will have more value as the demand for their use increases. Some people will buy and hold the tokens as stores of value while others will actively use the tokens for the goods and/or services of the company. Usually tokens are traded on established exchanges such as Coinbase, Kraken, Poloniex, etc. that connect buyer and seller but every exchange decides with which coins they want to deal.  Due diligence of a company should be performed before deciding to which ICO's one should "contribute" (the term used to buy tokens in an ICO) just as one would when buying a traditional stock.

Think of tokens like concert tickets.  You don't buy ownership in the band, but need the ticket to consume (see) the band.  Tickets can be bought and sold and their value depends on the popularity of the band/demand to see the band.  There are exchanges, like StubHub, that facilitate buying and selling. There are limited numbers of tickets just like there are a finite number of tokens.  An ICO would be like prepurchasing tickets for future concerts at a very low cost.  The band may or may not be around in the future but if you can spot the diamond in the rough, your tickets could be very valuable in the future. If you prepurchase tickets to a band that goes nowhere, you lose everything.


Is there a historical timeseries of market depth & transactions available?

Current market depth available at

https://mtgox.com/api/0/data/getDepth.php?Currency=USD

All trades which happened in the last 24 hours available at

https://mtgox.com/code/data/getTrades.php

Retrieves 100 trades that happend after specified transaction

https://mtgox.com/code/data/getTrades.php?since="transaction tid"

A script is required to retrive all historical data, like the one posted by mizerydearia. The idea is to cycle download request while incrementing "transaction tid" aka "lasttrade" to download all data in steps.

#!/bin/bash
outputfile=data
lasttrade=0
while test -n "$lasttrade";do
    wget --quiet https://mtgox.com/code/data/getTrades.php?since=$lasttrade
    if test "`cat getTrades.php\?since\=$lasttrade`" != "[]";then
        cat getTrades.php\?since\=* >> $outputfile;
        echo >> $outputfile;
        lasttrade=`cat getTrades.php\?since\=$lasttrade|sed "s/,/\n/g"|grep tid|tail -n 1|cut -d ":" -f 2|cut -d "\"" -f 2`;
        lasttradets=`cat getTrades.php\?since\=*|sed "s/,/\n/g"|grep date|tail -n 1|cut -d ":" -f 2`;
        echo "$(date -d @$lasttradets)  tid $lasttrade"
    else
        echo Finished
    fi
    rm getTrades.php\?since\=*;
done

See MtGox - API for more http API calls.


How to check Bitcoind block chain download progress level

Do

cd /home/

then

nano block.sh

copy the code below and paste (right click if you use putty) to the script.

#!/bin/bash
while true ; do
    clear
    echo "Press enter to break loop. Script will loop every 3 seconds"
    echo "script by Nixsy 18th august 2013"
    echo "If loop freezes press CTRL+C"
    echo ""
    echo -e "    \033[31mdownloaded\e[0m/\033[32mavailable\e[0m"
    echo -e "    \033[31m"`bitcoin-cli getblockcount 2>&1`"\e[0m"/"\033[32m"`wget -O - http://blockchain.info/q/getblockcount 2>/dev/null`"\e[0m"
    read -t 3 -n 3 && break
done

When you have copied the text to nano hold CTRL+X and then press Y to save.

In terminal type or copy from below followed by the enter key.

chmod +x block.sh

to start the script type.

./block.sh

This is just a little edit of the script from Lohoris, It will clear the screen then loop the script every 3 seconds until a key press.

Credit to Lohoris for the original script.


What is a Project Fork?

A fork in software development refers to the event of an independent project spinning off from a software project. Such forks sometimes occur in the opensource sphere, when there are irreconcilable plans/goals within a project's community, then often leading to a split in the community and two distinct projects thereafter.  In practice this takes form in the sourcecode being copied and henceforth being developed in a different direction independently by the forkers. For example in this conventional sense of fork, Litecoin is a fork of Bitcoin: Litecoin started as a copy of Bitcoin's code-base, but developed into an independent project (although still closely related).

Softfork and Hardfork in Bitcoin terminology

The terms softfork and hardfork in Bitcoin describe compatibility breaking changes in the Bitcoin protocol: Should the community be irreconcilably divided about such an issue, the old version and the new version of Bitcoin could emerge as distinct projects thereafter. While both versions of the Bitcoin protocol are in use, the differences in acceptance may cause a lasting blockchain-fork, i.e. two distinct longest chains which are both considered valid by part of the network.

Softforks are forward compatible

Softforks restrict block acceptance rules in comparison to earlier versions.

The new rules allow a subset of the previous valid blocks, therefore  all blocks considered valid by the newer version are also valid in the old version. If at least 51% of the mining power shifts to the new version, the system self-corrects:
Blocks created by old versions of Bitcoin Core that are invalid under the new paradigm might commence a short-term "old-only blockchain-fork", but eventually, they would be overtaken by the chain fork created under the new paradigm, as the hashing power working on the old paradigm would be smaller ("only old versions") than on the new paradigm ("accepted by all versions").

However, if less than 51% of the hashing power switches to the new version,  the blockchain-fork will not mend automatically as the chain created under the old rules has more hashing power and is incompatible to the new rules. This can either be remedied by the adopters of the softfork giving up their chain, or more hashing power switching to the softfork chain. The latter would cause the softfork chain to eventually overtake and reorganize the other chaintip.

Hardforks are not forward compatible

Hardforks ease block acceptance rules making previously invalid blocks valid in the new version. Obviously, this is not forward compatible as older versions will not accept the new blocks, causing the users of the old paradigm to remain on their own blockchain-fork indefinitely. To implement a hardfork, without a blockchain-fork, all users must switch to the new protocol consensually.

HF != blockchain-forks

Lately, I've seen "hardfork" being used interchangeably with "chain split". They refer to different things. A chain split is the state of the network when mining is based on more than one chaintip at the same time. This can happen for various reasons, including hardforks, softforks, buggy node software, and simply two miners discovering a block at the same height.


How can I use message signing to prove that I have private keys for many different accounts?

You can sign a message or export the private key of all the addresses in your wallet, including change addresses.

If you want to have a single message signed by all your keys the only solution I see would be to sign a message with the first key, then sign the signed message with a second key, ad nauseam.

Strictly from an encryption point of view I don't believe it is possible with ECDSA to sign with multiple keys in the same signature, I might be wrong here though.

As you may already have guessed, the most practical solution would probably be to consolidate your funds into a single address and sign a message with its private key. But it has a privacy tradeoff.


How does Bitcoin work when someone opens a wallet and gets a private key? Who stores that data? How could you access it if your forgot it?

Usually your private keys are stored only on your computer, in an encrypted file. If you lose them, your bitcoins are lost. That is why it is important to take a backup of your seed words or wallet file. If you use a website wallet, the owner of that website stores your keys, which means you must trust them and risk that they will not be hacked, etc. which goes against bitcoin principles - don't trust, just verify. So it's important that you keep your private keys safe somewhere that you can access, don't let a website keep them from you.

  how is it verified when someone exchanges bitcoin and dollars? Because the owner of those bitcoins has to change but there is obviously no proof in the system he has done that transaction

Of course there is proof - every transaction is recorded in the blockchain forever. So every transaction can be seen by everyone else on the network, everyone knows the bitcoins have exchanged owners (technically they can't know whether they've exchanged owners or just moved to a new address though, of course)


Well it's not sure whether it's completely off the table, but they have indeed called it off for now:

"Segwit2x hardfork has been called off! Common sense prevails"

You can see some things in this article: https://www.coindesk.com/relief-disbelief-bitcoin-reacts-sudden-2x-suspension/

And this is the message they sent out: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html

Cheers,

David


Where can one find the Bitcoin core roadmap?

Refer to https://bitcoincore.org

It contains plans for releases, features (sometimes ) announced on the blog, IRC meeting notes and you can also subscribe to announcements here: https://bitcoincore.org/en/list/announcements/join/. Note that if you want to see which issues and PR's are scheduled for the next release, you can search by milestone. Eg. is:open is:pr milestone:0.17.0

Potentially the most up to date (and accurate) would be the Bitcoin Github Repository. Potential features and bugs can be found on the Issues page as well, and code that is proposed for merging on the Pull Requests page. It will usually also include comments from collaborators that can give an idea of when it might be implemented.


Is it possible to increase the transaction fee of a sent transaction not yet in a block?

Today? No.

There was a feature that was developed referred to as child pays for parent however few miners if any are using this patch.

There have been instances where mining pool operators have been offered a bounty to include a specific transactions, but there is no automated process for that and presumably would require a significant incentive.


You showed a directory listig using "ls". Maybe that is the first issue. Try using "ls -la", which would also show hidden folders, beginning with a dot.

Otherwise here is a tutorial:
https://bitcoin.org/en/developer-examples#regtest-mode
and
https://bitcoin.org/en/full-node#linux-instructions

difficult to say, what happened, but if you just create a ".bitcoin" directory, and go ahead to create the bitcoin.conf file, you should be ok.


Does Bisq somehow use the Bitcoin blockchain for recording trades?

When fulfilling a trade the BTC seller deposit the coins in a multisig script with 2 keys, one controlled by them and one by the buyer.
When the BTC seller acknowledge the reception of the fiat payment, they release the coin to a script only controlled by the buyer.
This mechanism, as well as a number of others (see the documentation for details), aims to disincentivize fraud.


How to find out as soon as possible about a transaction to my payment address?

Most people look up the receiving address in blockchain.info , but the site is having some trouble lately. They show the transaction about a second after broadcast, and show how many confirmations a transaction has in the address page.

If it doesen't work, try another block explorer, some are listed below:

blockexplorer.com

blockr.io

blockcypher.com


Hosted web wallet based on bitcoin core - approach to handling keys

The question is: after several thousands of users will create their wallets, the server's wallet.dat file is going to be really huge. Would that make the bitcoin server slow?

Yes, it is know that when the wallet.dat file is very large it noticeable slows down Bitcoin Core. However this only happens when there are millions of keys stored in the wallet.

Instead of having all of the private keys in one file, you can use Bitcoin Core's multiwallet feature. This feature allows you to have multiple wallet files loaded into Bitcoin Core so this should avoid the issue of having too large of a wallet file. It will also let each use have their own wallet file so only one user's coins are actually moved when spending any money. The only downside to this is that loading and unloading a wallet requires restarting. Once PR 10740 is merged, you will be able to dynamically load and unload wallets. Note that having many wallets loaded at the same time may also be problematic.


You could try connecting to various mining pools, fallback nodes or seed nodes. Those should be well connected.

The best option, however, would be to host your own Bitcoin node on a server and set it to connect to a lot of outbound peers. This would also ensure that you would be able to see most transactions quickly and also broadcast the transactions that interest you to more peers.

All in all, it is best not to rely on third-party nodes if you can set up your own well connected node. Also, you should also consider a pre-mined double spend attack that would be undetectable no matter how many nodes you are connected to.


Bitcoin-core how to get all transactions hashes?

Browse BlockChair to find the list of transactions: https://blockchair.com/bitcoin/transactions

Then uncheck every box other than TXID (hash):

https://blockchair.com/bitcoin/transactions#f=hash

Then use export, and pay them if needed.


How can the transaction history be checked when new addresses are generated?

One thing you might be missing is "there are no balances".  The network doesn't know about wallets or balances, it only knows about outputs.  These outputs are either spent or unspent. Once you have this concept it's easier to understand.

If your wallet says you have a balance of 1.2345 BTC that means it "thinks" there are X number of unspent outputs that you "control" that add up to 1.2345.  It's basing this on the keys it knows about and the transactions it has seen so far. There could be 1 output with a value of 1.2345 or 100 outputs with a sum of 1.2345, or any combination.

See any transaction on blockchain.info and you'll see the inputs on the left side.  These inputs are previously unspent outputs.

https://blockchain.info/tx/ad646bbac1e44e4db199420e12fec2966903a0e078da99fab97b3156455f252a

On the right side are the new unspent outputs.  Once an output is used it's now spent and carries no balance.  Since the outputs you are using probably don't add up to exactly what you want there is a concept of change.

https://en.bitcoin.it/wiki/Change

So what about new addresses? The network doesn't need to know anything about new addresses.  When a node sees a new transaction it only has to verify the outputs being spent are not spent already i.e. they haven't been used by any other transaction (along with other verification like signature, amounts etc..)

So all transactions are linked to previous ones in that way.


Proof of Work and Proof of Stake - Competitive advantage

but if we think the other way around if you have more money and buy more Ether tokens you are again have the competitive advantage at the Proof of Stake consensus mechanism. OR am I missing something?

You're not missing anything.

Instead of people investing money in hardware, it becomes people hoarding coins and investing money into buying more coins. All that serves to do is make the rich richer and is really no better than PoW in that regard. This sort of behavior can lead to stagnation of the coin's economy as people use it less and less for transacting and keep holding more for staking.

Furthermore, Proof of Stake has problems, specifically the Nothing At Stake problem. If someone wanted to fork the blockchain, they can do so without risking their money. They can then stake on both the fork and the original at no extra cost. This is not good for the coin. But with Proof of Work, if a miner forked the blockchain, they do have something at stake: they hashrate can only be used to mine the fork or the original, so they risk losing their money if they mine on the wrong fork. Thus there is an incentive to not fork.


I was able to get the POST working. The error you're getting back seems to indicate the key "addrs" is not in the POST payload. Just a guess, but maybe you don't need the quotes and spaces around the payload?

Screenshot here:


How are the assets locked and unlocked trustlessly using sidechains?

This is my conceptual understanding, which will hopefully be useful here, but I'm sure there are technical subtleties that I am not including, which some more experienced with the side-chains project would be able to give more insight into.

First, we need to have a clear definition of an SPV proof. I will use SPV proof to mean: A bit sequence that proves that a transaction has a substantial amount of work committing to it. It is desirable for this proof to be as small as possible.

Essentially, you start by sending some coins on the main chain to an output that has a scriptPubKey that says

OP_SPVPROOFVERIFY

Then wait until it has sufficient confirmations (1-days worth, I think), and you take this UTXO, represented by the pair (txid, n), and go over to a sidechain make a transaction that uses an SPV proof of the output being in the confirmed blockchain to issue new coins. This is essentially like moving coins from one blockchain to another.

Then when you're done using them on the side-chain, you make a new output with the same number of coins, maybe sending them to OP_RETURN. Thus, you've given up your coins on the side-chain, allowing them to be re-claimed on the main chain. Before you can re-claim them, though, you have to wait for 1-days worth of confirmations on the sidechain, and then construct an SPV proof that the coins have been destroyed in the sidechain. This SPV proof is what lets you unlock your coins from the OP_SPVPROOFVERIFY output that they were locked in before.

For more info on compact SPV proofs, see:

Appendix B of the Sidechains white paper.
This post on the bitcoin-dev mailing list
Is there a PoW system that shows cumulative work without an ever-increasing proof size?


Reasons Behind Finding an IP addresses of Miners

Ordinary Bitcoin users would not care about the IP addresses of miners. Every Bitcoin node simply tells its peers (the "neighbors" of the node) about any new transactions they hear about. This way, the transactions get relayed across the network until everyone has heard about them, including the miners.
The waiting period is independent of how quickly the transaction gets to miners. Miners are constantly trying to find a block and succeed at random intervals. Whenever they find a block, they include whatever transactions they know about that pay the most fees, so beside a transaction just missing to get into a block, the wait is independent—it's simply until the next block is found that they fit into.
It's not clear to me in what scenario people might be trying to find the IP addresses of miners. Two that come to mind would be researchers that are trying to map Bitcoin mining activity, and attackers that want to hijack hash power.


Why there's no bank or institution lending Bitcoins?

My co-founder and I just started a Bitbond.net where we connect borrowers and lenders and offer an online wallet. Our goal is to make banks obsolete by such a service.

You can borrow Bitcoins by issuing a Bitbond. Before that, we perfom a credit rating to assess the creditworthiness of the issuer. We also do an identity check so if a borrower is late on his or her payments this can hurt their credit score.

The good thing about it is that by connecting borrowers and lenders directly you match the maturities of bith sides. One big problem with banks is that they give out long term loans and refinance them with very short term money, i.e. their client's deposits or overnight loans from other banks. Since Bitcoin wants to be a better and more stable currency we believe that banking as such also needs to improve. That is why we built Bitbond.net


You can buy ARK for example on bittrex.com in exchange for bitcoins.
That means that to buy it, you'll have to purchase Bitcoin first and deposit it there.


What i'm wondering is how many PSU's would I will need and what kind is recommended?

I would recommend much higher PSU, at least 1000 Watt PSU for each two Radeon's R9 290x. This is based on some recommendations I found (here and here). I am 99.99% confident a single 750 Watt PSU will NOT be able to cover 6 GPUs of that power.

I also think the motherboard you selected can only take 3 cards, you need to double check. Even with 3 slots the cards may not have enough room between the slots, so you will need to use extension cables. The CPU is actually overpowered, I would select a low-power one. CPU will not be used for mining. Memory is not used as well. You will be covered with a 2-4GB stick to run the OS processes.

No one seem to be bothered with a case. For that much price of a hardware you don't want much dust to come in. Or any morning coffee spilt on your expensive hardware... I would advice to buy a large, solid, enclosure with good ventilation. This would cost you around $200. But it will protect the hardware much better then a milk or vegi plastic case.

Just thoughts, I am NOT a professional electrical engineer.


What prevents two miners from working on separate blocks which share transactions?

What prevents one miner (Miner A) from creating a block including transaction X which has a transaction fee associated with it, and Miner B working on a separate block which also has the same transaction X in it.

Nothing prevents that. That happens all the time.

  Clearly both of them cannot get the transaction fee.

Right.

  Does whoever solves it first get the bitcoins, and the loser gets nothing? Or are transactions "claimed" when you create a block, so others cannot also work on verifying them.

Whoever solves it and gets their block into the blockchain gets everything, and the loser gets nothing. This is not always the same as the person who solves it first.

  Is it possible for somebody to not have their transaction be verified in a long time? What if no miner picks up their transaction in their respective block they are working on? Or are the chances of that very low.

That happens all the time. The general advice on the site is to use a high transaction fee, rebroadcast your transaction if it isn't confirming, and to not depend on transactions confirming quickly.


Why are existing distributed database technologies not applicable to cryptocurrencies

The security model of MongoDB assumes that all MongoDB nodes are run by the same entity, and trusts the servers in the cluster to not tamper with the data they're given. There are checksums and such, but those are intended to detect and correct accidental corruption of data, not intentional changes.

  How does something like ethereum nodes actually store data?

Bitcoin uses LevelDB to store blockchain data, though this is not sharded for the reasons mentioned above.

I don't know what backend Ethereum uses.


Can I store all the keys from a multisig account on Ledger devices?

I am searching for an answer to the same question. From what I have read so far, the Ledger Nano S does not support multiple BIP44 HD accounts, but I have contacted Ledger for confirmation of this.

This feature would be very useful to distribute the backups of your ledger device (no single backup would be able to steal your funds) but maintain the convenience of being able to sign your own transactions without the need for a 3rd party.

I will update this answer when I receive a response from Ledger.

Update

Still no response from Ledger, but I did find another solution to the problem I was originally trying to solve, so I thought I'd share.

Ian Coleman has developed an implementation of Shamir's Secret Sharing Scheme for BIP39, allowing you to split a single BIP39 mnemonic into a number of parts, which are able to be restored similar to an m-of-n multi-sig wallet - ie You could generate 4 parts to the backup, and allow the full backup to be restored with only 3 of the 4 parts.

More info can be found in the GitHub link: https://github.com/iancoleman/shamir39


How do I securely store different CryptoCurrencies?

Short answer: Yes, it is possible. But depends on every coin. The majority of the top coins has his own wallet where your funds can't be stolen.

First of all, taking into account that cryptocurrencies are a developing technology I wouldn't use the word "securely". But if you want to minimize the risk, I recommend you to diversify your portfolio, for example:

50% BTC
20% ETH
10% LTC
10% XMR
5% IOTA
5% MAID

That would be pretty much my choice, you can make your own.

In any case, for a long-term investment I recommend you to research the core technology of each coin. And of course guard the funds on your own wallet.

If you want to invest on really new cryptocurrencies that doesn't have a wallet yet, you'll have to let the money on the exchange until a wallet is launched. There's no other way.


How to set up a private bitcoin network with mining on a single machine?

I've had to do this, so I'll try to describe exactly what you need to do to get mining on testnet to work in a local setup. For our purposes, we'll have 2 instances of bitcoind running, the first set up to be a miner, the second as a peer.

First, create two directories, one for the miner, the other for the peer:

$ mkdir 1
$ mkdir 2

Now create this file in the 1 directory:

$ <your favorite editor> 1/bitcoin.conf

Here are the contents of the file:

testnet=1
irc=0
dnsseed=0
upnp=0
listen=1
checkpoints=0
server=1
rpcuser=test
rpcpassword=test
rpcallowip=127.0.0.1
port=20000
rpcport=20001

Now go and make the same file for the 2 directory

$ <your favorite editor> 2/bitcoin.conf

Contents:

testnet=1
irc=0
dnsseed=0
upnp=0
listen=0
checkpoints=0
connect=127.0.0.1:20000
rpcuser=test
rpcpassword=test
port=20010
rpcport=20011

Run the first instance:

$ bitcoind -datadir=1 -daemon

Run the second instance:

$ bitcoind -datadir=2 -daemon

You can check to see if everything is up and running by using bitcoin-cli:

$ bitcoin-cli -datadir=1 getinfo

Blocks should be 0 until you mine something.

If you have mining hardware, you can now mine by connecting to 127.0.0.1:20001 with the user/pass of test/test. The actual command to connect will differ based on the mining software you use, but for bfgminer, it would be something like:

$ bfgminer -o http://127.0.0.1:20001 -O test:test --generate-to <a testnet address> --no-longpoll -S all

Note that CPU mining takes several hours to find a block from my experience.


Why do bitcoin: URLs not use "//", breaking "clickability"?

The Bitcoin URI scheme is defined in BIP21:

Bitcoin URIs follow the general format for URIs as set forth in RFC
3986. The path component consists of a bitcoin address, and the query component provides additional payment options.

You can read through the entire RFC document or the summary on Wikipedia which answers your question:

An optional authority component preceded by two slashes (//),
comprising:

An optional userinfo subcomponent that may consist of a user name and an optional password preceded by a colon (:), followed by an at
symbol (@). Use of the format username:password in the userinfo
subcomponent is deprecated for security reasons. Applications should
not render as clear text any data after the first colon (:) found
within a userinfo subcomponent unless the data after the colon is the
empty string (indicating no password).
A host subcomponent, consisting of either a registered name (including but not limited to a hostname), or an IP address. IPv4
addresses must be in dot-decimal notation, and IPv6 addresses must be
enclosed in brackets ([]).[24][c]
An optional port subcomponent preceded by a colon (:).

Conclusion: the Bitcoin URI scheme is RFC-compliant and does not require the optional "authority" component which is what the // deliniates.


Ethereum achieves consensus using Proof-of-Work. This was true in the initial "Olympic" testnet (0.9), in the first "Frontier" release (1.0) and in the second "Homestead" release (1.1).

The upcoming "Metropolis" release (1.2) will also keep the consensus to be achieved by Proof-of-Work. The used algorithm is called Ethash, and it was created specifically for Ethereum.

It's hard to speculate about how the roadmap after that will be, but it is announced that at some point a release called "Serenity" will introduce a hardfork which updates the network to find consensus by utilizing Proof-of-Stake.

The Proof-of-Stake algorithm is still being developed by Vlad Zamfir and is called Casper. which is a security-deposit based economic consensus protocol. This means that nodes, so called bonded validators, have to place a security deposit, an action called bonding, in order to serve the consensus by producing blocks.

In Casper style proof of stake anyone can participate in block production by posting a bond. After posting a bond you have an opportunity to bet on which block will be included next. The incentives are such that you make money by betting with the eventual consensus and lose money by betting against the consensus. Any cryptographically provable misbehavior results in the forfeit of the bond.

At the bottom line of this post, it's worth to note that the Ethereum network is poised with a difficulty bomb which increases the difficulty exponential after a certain time of mining and it will hit around the beginning of 2017. This will make the network basicly stop mining if no hardfork to Proof-of-Stake or any other solution will be scheduled before.


Privacy and security are important to Bitcoin users, so I would like to see more faucets that do not:

Use Flash
Use JavaScript
Contain any advertisements
Require the collection of any personal data to use the faucet


Script to import multiple priv keys in Electrum

First of all get rid of all that junk. One priv key per line is all you need. So use grep privkey filename|cut -d":" -f2 > clean-file.txt. Then call this  python script with that file as an argument:

import sys
from electrum import bitcoin
f = open(sys.argv[1], "r")
for privkey in f:
    privkey=privkey.strip()
    orig_format,secret,compressed=bitcoin.deserialize_privkey( privkey)
    formats = [ bitcoin.serialize_privkey( secret, False, "p2pkh"), bitcoin.serialize_privkey( secret, True, "p2pkh"), bitcoin.serialize_privkey( secret, True, "p2wpkh"), bitcoin.serialize_privkey( secret, True, "p2wpkh-p2sh") ]
    for thing in formats:
        print(thing)

It'll output all the private keys in the various formats.


How are bip44 coin identifiers assigned?

BIP44 is more like a standard which you are supposed to follow. The coin id's assigned are way to standardise the approach in case you are making a wallet and want better segregation of your coins.

For example, with the same seed, you can derive keys for different cryptocurrencies, just by changing the coin  id. Do note all those ids can be used to generate addresses for only one crypto as well.

Basically it is trying to maintain some nomenclature in this open source community. There is no code in the source code specifying this.
As a matter of fact , the address and private keys generated are backwards compatible to a node version not having the HD wallet implementation.

Address generation is something which the bitcoin core software provides, however anyone can write their own code for address generation as long as it follows the guidelines for address generation.


The problem was in count of characters encoded in tx. C++ code allocate memory depending of count variable in tx.
This commit solve the problem: https://github.com/stellar/js-xdr/pull/4/commits/119a8c26f71de8568d88cee1a94cb33074797859


Is there any way to tell if there is a miner (in a pool) on the network, from a network perspective?

Pool miners connect to the pool server, not to the P2P network. You may be able to find the pool server by tracing the origin of the blocks, but you can't find the individual pooled miners on the network, as they're not actually on the network.


Your scriptSig is too big! It is limited to 200 kbytes, and you've got 1400 inputs @ 0.2kbyte (best case scenario): 1400x 200 = 280kbyte.

Try using half the inputs (preferably newer inputs) to cut the scriptSig down in size.


Each full-node checks the validity of blocks. Checking the validity of a block is indeed done by repeating all steps of building that block and checking for adherence to all consensus rules. If a block infringes any rule, a full-node will consider the block invalid, ignore the block, and ban the node that sent it to him from his peers for 24h for sending invalid information.

As each miner should be running a full-node to stay abreast of the current blockchain-tip, either all miners or no miners should consider a block valid (as long as they are in agreement on the consensus rules that apply).


Is the scripting system an incalculable security risk?

New scripts could be added over time.

And how would you do that (without breaking old clients / getting all bitcoin clients to work the same way with the same scripts / etc) ?

I think the script language will let bitcoin evolve, without having to make any (fundamental) changes to the protocol. It's a futurewise smart decision (just like bitcoin has some protection against quantum computers, even though they ain't "dangerous" yet - and might never be). IMO it's one of the thing that make bitcoin 'better than the rest'.

Ofc having a less complex script language would minimize any potential attack vector, but I think the complexity of the language already is low enough for it not to be of any concern. At most we will probably see DoS attack (e.g. transactions which loops endless), but this should be easily fixable with an update (and the currently client already have lots of "anti-DoS" checks, to protect against this).


Does address-reuse make Bitcoin private keys vulnerable to quantum computing?

The simple explanation is that the attacks that quantum computing enables require information (the public key) that isn't available until after the first transaction is seen.

Until the first transaction spending an output, all that is known is the hashed version of the recipient key (aka the address) which isn't enough to mount the attack.  If fully developed quantum computers appear with no warning and somehow make it into the hands of a large miner they could potentially see an incoming transaction and race the transaction but the odds of this are vanishingly small.  Most likely, as QC becomes more of a danger, the algorithms in bitcoin will be swapped out for QC resistant ones.


Can Bitcoin scripting be used for double spending attacks?

What you're describing is a contradiction of terms. If a sum of money is deposited into an address, that means that only that address's private key can spend the money.

Maybe you could craft a non-standard transaction and tell people it's giving address B's owner permission to spend it, but if people look closely enough at the transaction, they'll be able to tell that it's really address C (and not B)'s owner that can spend it. There's no way around this: the transaction output is public, as is the implementation of how it works.

So if the question is: can you fool software X with a non-standard transaction? Perhaps, it would depend on finding a bug (or other less-than-ideal situation) in the software in question. (for example, if you craft a transaction that can be spent by address B or C, maybe the wallet owning B will say it has the balance, and if he doesn't transfer it again before you do, then you can "steal back" the money that way) However, I'd treat any non-standard transactions as highly suspect.


what are private keys (essentially) how can i make them using any given data?

Bitcoin private keys (secp256k1) are just a random 256bits "number" (256 random zero and ones), or say 32byte random data. The only constraints are, that the random number must be between 0x1 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD.

You can calculate the public key from your private key but not vice versa (it's not practical possible).

With "revealing a webaddress" you probably mean encryption. You can use Bitcoin private keys with available schemes (Ex. diffie hellman) to derive a symmetric encryption key (ex. AES256) and encrypt data for a particular receiver.


Adding instead of concatenating hashes in Merkle trees

There are a number of issues here, with different answers.
Can Merkle trees use a commutative operation in general to combine hashes?
Yes, but only if they aren't intended to commit to the order of the leaves.
Clearly when a commutative operation is used, [A,B,C,D] and [D,C,A,B] will hash to the same thing. This is not a problem if the Merkle root is intended to be a commitment to the (multi)set of leaves, but it is if it is intended to be a commitment to the list.
Could the Bitcoin transaction Merkle tree have used a commutative operation?
Maybe, it's hard to talk about hypotheticals.
The order of transactions in a block is relevant (transactions can spend outputs created by previous transactions in the same block), so you want to prevent a peer from reordering the transactions to invalidate it without breaking the commitment. Obviously alternative solutions could have been used here, either by encoding the order explicitly, or by performing a topological sort on the set of transactions before verification.
Obviously this cannot be changed anymore in the actual Bitcoin protocol without a very invasive hardfork.
Can you use addition or xor as commutative hash combination function?
Not without security reduction.
Imagine a 2-element Merkle tree with leaf elements A and B. Their hash is H = hash(leafhash(A) + leafhash(B)). An attacker who knows A and B can use a generalized birthday attack to find other leaves C and D such that leafhash(C) + leafhash(D) = leafhash(A) + leafhash(B). Perhaps surprisingly, this only needs ~2128 work if leafhash is a generic (and secure) 256-bit hash function. By doing so, the attacker has managed to perform a second preimage attack on the Merkle tree construction, in only the square root of the time that would normally be expected for second preimage security.
There may be reductions in other security properties too.
Are there other feasible commutative hash combination functions then?
Yes, but they don't shrink the data.
For example, if the hashes are treated as integers modulo a large prime, then combining child hashes x and y as (x+y,xy) works (because the sum and product uniquely identify the inputs, but not their order). When working in a large characteristic-2 finite field (e.g. GF(2256)), (x+y,x3+y3) also works.
Another much simpler possibility is simply sorting the elements: combining x and y as (min(x,y),max(x,y)) works fine.
If using secure commutative combination functions doesn't shrink the data, then is there any point?
It means that you can prove an element is in the Merkle tree without revealing its position.
This is a minor bandwidth gain (log2(n) bits for a tree with n elements), reduces some implementation complexity, and may be a slight privacy improvement if the positions are sensitive. In fact, this approach is used in the proposed Taproot script trees (concatenating the hashes after sorting), precisely for the reason above.
Disclaimer: I'm a co-author of that proposal.


Connect a mobile client to wallet on remote Bitcoin Core

Yes, you can use the node's RPC API method getnewaddress to create a new public-key pair and it will return the address.


Loading wallet crashes bitcoin core wallet

Check this file: ErrorFile=d:\btdata\db.log
Errors are logged in there. You are viewing the debug logs which will not print any error.


Is there any punishment for Having more than 50% of the mining power of the network

Quite the contrary. If a pool becomes too big it just earns more money. There is no punishment. Maybe some bad reputation, but not something the majority will even notice.

It has happened three times so far that pools reached hashpower majority or got too close to it: Deepbit, BTC Guild and GHash.

Only Eleuthria, operator of BTC Guild, handled this in a responsible way. He raised the pool fees which caused some miners to react, moving to other pools. This balanced out the pools.

GHash scammed a casino, but they could have done this without having so much hashpower as we are talking about zero-confirmation transactions. They later said it was done by a rogue employee who is no longer with them.

Deepbit and GHash acted irresponsible and so did the miners. It appears that the vast majority of miners are not keeping watch on whether a pool gets too much hashpower or they just don't care.

The fourth time this happens, maybe some very bad things will happen. Hopefully in that case miners will take note and act more responsibly. It is doubtful though, as almost noone reacted to the casino scam mentioned above.

Disappointing for sure, but it is what it is.


Latest versions of the reference Bitcoin implementation have the 'dumpwallet' RPC command, which dumps a human-readable list of all of your private keys.

The format is simple: just comment-lines (starting with #) or lines that are the private key (plus metadata about the key). So to combine keys from several wallets you would:

Re-run bitcoind/Bitcoin-Qt, giving the -wallet=/path/to/wallet option
dumpwallet the private keys to a file (walletpassphrase first if the wallet has a passphrase)
Shutdown
concatenate the files together
Re-run and importwallet the combined file

The last step will take a while as the blockchain is scanned for transactions to/from the imported private keys (concatenating several wallet keys together in step 3 saves time over repeatedly dumping/importing).

A php or python or bash script that did all of the starting/stopping/concatenating either using the JSON/RPC interface or bitcoin-cli would be spiffy. Extra credit if it noticed which wallets were locked and prompted for passphrases....


Authentificate myself as the sender of a bitcoin transaction

Some deep, technical bitcoin magic?
Would you care to elaborate on this more?

The problem is that to prove you are the owner of the originating bitcoin address, you need to sign something using the private key from that address. That's the only true bitcoin-like solution, as this key is the very thing that allows you to make transactions is your only technical proof of ownership.

Unfortunately, the way said key is stored is by being in your wallet (be it the wallet file of your bitcoin client or your brain wallet or whatever else you use). If you do not have this, then you lost that address, and with it access to any remaining bitcoins in that address, and the only purely technical way of authenticating yourself as the owner.

There may yet be a non-technical solution: Find someone whom the beneficiary of your transaction mishap trusts and who can vouch for the address being your address. Maybe someone has transferred bitcoin to that very address of yours and can assure the beneficiary that it is indeed yours?

Note that all this leaves another question: Does the beneficiary know what address he has been paid from? I may be wrong, but I suspect that each block in the blockchain describes only lumped inputs and lumped outputs, so the source(s) could(?) be any combination of the input addresses. So if I was the beneficiary, then without further educating myself about the technicalities of bitcoin transactions, I wouldn't be quite sure from which bitcoin address I'd need authentification from.


How to obtain your nodeID (QR code) in eclair-mobile?

Click the three dots in the top right corner, tap "Network Info".

Your NodeId is visible on this screen

Now, go to the URL ip.tyk.nu to find your IP address.

Now, in a Linux prompt (or WSL), install the PyPI qrcode package. On Ubuntu, it is available in the python3-qrcode package.

Now, execute this command (substitute the values you just learnt):

echo -n "<nodeID>@<IPaddress>:9735" | qr

The QR code is now visible in your terminal. If you want a real image, you can use zbarimg from the package zbar-tools.


The version is wrong:

I have 02000000

But the one that appears on the block is

Version 0x20000000

Doing the formatting:

00000020

Calculating the hash of the block:

from hashlib import sha256
import hashlib
header = "0000002066720b99e07d284bd4fe67ff8c49a5db1dd8514fcdab610000000000000000007829844f4c3a41a537b3131ca992643eaa9d093b2383e4cdc060ad7dc548118751eb505ac1910018de19b302".decode('hex')
print sha256(sha256(header).digest()).digest()[::-1].encode('hex')

And the answer is:

00000000000000000020cf2bdc6563fb25c424af588d5fb7223461e72715e4a9

That is the original hash in the block:

00000000000000000020cf2bdc6563fb25c424af588d5fb7223461e72715e4a9


Ardor Lightweight Contracts: (Almost) trustless way with new Phased Transaction type?

One idea how to solve it works like this:

The sender submits the contract trigger transaction as phased with a reveal secret approval model based on the hash of a secret it generates.
The contract activated by this trigger transaction, submits the response transaction(s) with a composite approval model composed of the same hash of the secret used by the trigger transaction and the trigger transaction full hash.

What happens next is the following:

If the sender approves the trigger transaction, it can also approve the contract transaction since they rely on the same secret.

If the sender does not approve the trigger transaction both the trigger transaction and the transaction submitted by the contract expire.

If the sender tries to approve the contract transaction but not approve his own transaction, the the contract transaction won't be approved since it also relies on the trigger transaction full hash which is not approved in the blockchain.

To implement this we need at least two changes to the existing design:
1. Trigger a contract by a phased transaction which is not approved yet, which is currently not supported.
2. Enhance the by transaction full hash approval model so it has an option to only become approved if the full hash represents a phased approved transaction and not just a transaction stored in the blockchain like it is now.


Is it possible to safely mine bitcoin at 13.5 TH/s with hardware with 10.5 TH/s?

You’re not going to get any solid answers for what is safe and possible. Mining hardware varies a lot in what the chips can actually perform at reliably, even between individual units of the same model.

Overclocking mining hardware in general is a fools errand, there’s a non linear relationship between the frequency and power usage. That is, by adding 20% more power you’re not going to get 20% more performance out, the efficiency is significantly degraded. When overclocking hardware runs out of specification for the cabling and voltage conversion, which significantly increases the risk of fire and damage.


What does the "Cost per Transaction" chart on BlockChain.info show?

On the chart overview page you find the description "Cost per Transaction: A chart showing miners revenue divided by the number of transactions.".

Meaning, it's the total value of the block reward of a block divided by the number of transactions confirmed on the network in that block.

Here is an example with made up numbers:

Block reward is 25 BTC + 0.1 BTC in transaction fees.
There are 502 transactions in the block.
Current exchange rate is 367.3 USD/BTC.

25.1 BTC / 502 transactions = 0.05 BTC per transaction

367.30 USD/BTC * 0.05 BTC per transaction = $18.37 per transaction

Concerning what will happen after the regular block reward is reduced/discontinued, check out:

Will Bitcoin suffer from a mining Tragedy of the Commons when mining fees drop to zero?
How much will transaction fees eventually be?
What happens once the mining reward gets cut in half?


Transaction with Multiple Inputs having Same Address

Inputs do not refer to addresses, but rather unspent transaction outputs (UTXOs).  If there are multiple UTXOs payable to the same address, then a transaction spending those UTXOs will have to list them individually, and cannot lump them together into a single input.  The fact that all the UTXOs are payable to the same address doesn't matter; they still need to be listed as inputs separately.


Has the Timestamp Server from the original whitepaper ever been developed?

The system called timestamp server in the original whitepaper is currently more often referred to as a "miner".

They timestamp blocks, which combine several transactions, imposing an authorative order on these transactions. This is necessary as the system cannot otherwise decide which of two conflicting but otherwise valid transactions should be accepted.

It's certainly not a general-purpose timestamping system, but that can be built on top of it. See for example ChronoBit or OpenTimestamps.


It is not true that individual bitcoins have an identifier. In fact, individual bitcoins do not exist.

What your wallet holds are addresses. These addresses can occur in the Bitcoin block chain, which can - at its simplest - be seen as a big database of balances for each Bitcoin address. Your wallet also holds a private key for each address, which can be seen as the password needed to spend the balance that is accredited to the corresponding address.

When you spend some bitcoins, you send them from one of your addresses to another address. Only the person that owns the private key corresponding to the address, can spend the bitcoins on its balance.

Now, that still not explains how bitcoins can be divided into smaller fractions. In fact, the Bitcoin protocol does not really work with the unit bitcoin, but with a smaller unit, called satoshi. 1 bitcoin equals 100,000,000 (= 10^8) satoshi. So 1 satoshi (=10^-8 BTC) is the smallest amount you can send.

This means that when you send 0.7 BTC, you actually send 70,000,000 satoshis.


You need the private key not the public key to do a sweep.

Actually it'll be easier if you simply copied the wallet file to the new system. If you have access to the electrum gui then you can create a copy via file > save copy. If you don't then find the wallet file and copy it over.


What is the actual reason for using boost:signals for few functions?

Signals in OO is a powerful concept that allows binding instances together on runtime.

The signals concept allows to keep code modular and bind multiple instances on one signal emitter.

Just calling a function can work (for the 1-to-n you would at least need another vector of instances, etc.), but would reduce the flexibility and modularity of the code.


How old should be my bitcoins to send them again without transaction fee?

As the coins "age" they will have a higher priority.

I don't know the algorithm, but believe it is roughly like a day or so and then the age of the coin no longer is a factor.

So if you are seeing minimum fees for coins more than a day after you've received them, it is because of other reasons, such as having outputs at amounts below 0.01 BTC.


Handwritten paperwallet or hardwarewallet to store Bitcoins?

True.
There is a standard algorithm for generating the keys from the seed words (BIP 39 / BIP 32).  Most hardware wallets follow this algorithm (check before you buy).  So even if the hardware device has failed or cannot be used, you can still use your written seed words with any other software or hardware device that implements the standard algorithm to recover your keys and spend your coins.
True.
True.  But if you are paranoid, you could generate your own seed words with some more trusted software, import them into your wallet, and check with some other software that the hardware wallet is correctly generating the keys from them.  That would guarantee that the keys are secure, though of course it wouldn't rule out the possibility that the hardware wallet is secretly sending them back to the manufacturer or another attacker.


iPhone App for Bitcoin trading / transfering?

You cannot buy Bitcoin with credit card as far as I know.

iOS apps are generally limited to either:

HTML5 client (Blockchain.info or GreenAddress.it)
a "pure" (ie no website integration) app like BreadWallet, Pheeva
A trading app (ANX), Coinbase

So buying BTC and managing or trading are very distinct functionalities, and you'll likely never find the former because of credit card fraud allowing for untraceable Bitcoins to be purchased. Also, most all purchases of Bitcoin (except OTC or cash LocalBitcoins.com transactions) require ID to allow fiat to BTC conversion.

The only exception I can think of is Coinjar.io which are rolling out a debit card in Australia which can be used like a normal credit card, but automatically debits a linked Coinjar BTC deposit.


How to generate transaction history from all addresses that are part of common xpub/ypub without having the xpub/ypub?

Create a watch-only wallet in bitcoin core

Add the addresses using importaddress or importmulti. I imported one address for testing: importaddres tb1qpax3dzmat0qffp3pgkmnmue4tps0xglru65crt "test1" false

Rescan blockchain. I did rescanblockchain 1810000 1896271 for testing

List Transactions for the addresses.

I get the below results:

[
  {
    "involvesWatchonly": true,
    "address": "tb1qpax3dzmat0qffp3pgkmnmue4tps0xglru65crt",
    "category": "receive",
    "amount": 0.01200000,
    "label": "test1",
    "vout": 1,
    "confirmations": 57879,
    "blockhash": "000000006ff7a6de9ddedfa8f3dec502e0740b4e19bf9d60091711f442a383fd",
    "blockheight": 1838397,
    "blockindex": 16,
    "blocktime": 1602028580,
    "txid": "98fe1985b800b87a5196c2d1d01980a9930532b0f9b8c5488bfde273cf9b1b01",
    "walletconflicts": [
    ],
    "time": 1602028580,
    "timereceived": 1607228610,
    "bip125-replaceable": "no"
  },
  {
    "involvesWatchonly": true,
    "address": "tb1qj5q83vcsldetj6krhv0jgwexff2vj6xfmd8az6",
    "category": "send",
    "amount": -0.01000000,
    "vout": 1,
    "fee": -0.00000282,
    "confirmations": 4,
    "blockhash": "0000000097539dce940bacac2da89704645862ab878bbb1aa832d5fd3b65c91f",
    "blockheight": 1896272,
    "blockindex": 69,
    "blocktime": 1607229053,
    "txid": "06ff26b56ac6636326cb2f25b6434243a755e2fd2574808271a88ca23fc05b54",
    "walletconflicts": [
    ],
    "time": 1607228776,
    "timereceived": 1607228776,
    "bip125-replaceable": "no",
    "abandoned": false
  },
  {
    "involvesWatchonly": true,
    "address": "tb1qjd4cnkp0zz4dhl2383tugl54dd9eryteya7yjv",
    "category": "send",
    "amount": -0.00199718,
    "vout": 0,
    "fee": -0.00000282,
    "confirmations": 4,
    "blockhash": "0000000097539dce940bacac2da89704645862ab878bbb1aa832d5fd3b65c91f",
    "blockheight": 1896272,
    "blockindex": 69,
    "blocktime": 1607229053,
    "txid": "06ff26b56ac6636326cb2f25b6434243a755e2fd2574808271a88ca23fc05b54",
    "walletconflicts": [
    ],
    "time": 1607228776,
    "timereceived": 1607228776,
    "bip125-replaceable": "no",
    "abandoned": false
  }
]

Results are in JSON format according to my understanding, you can convert them to CSV using one of the available options depending on OS or programming language you prefer to use. Related question: https://unix.stackexchange.com/questions/507615/parse-json-data-using-jq-and-convert-into-csv


There is something like this described on the wiki.

Update: As Meni wrote in a comment below, this is more flexible than you require, since you already know who should pay, and how much.

So we can create a single transaction with 2 inputs, one from Alice and one from Bob, and a single output to the recipient of the payment.

Alice and Bob need to both have an input in their wallet of the right size, so we don't worry about who gets the change.  Then Alice tells Bob what input she's going to use.  Bob makes a transaction including both Alice's and Bob's input, and signs his input with SIGHASH_ALL, meaning that his signature isn't valid unless Alice also signs her input.  He then sends the incomplete transaction to Alice for her to sign, she signs her input, and sends the result to the network.


What percentage of merchant Bitcoin receipts are immediately converted into fiat?

The last stats Bitpay published were in December, 2014, so it may be somewhat out of date. They said that 10% of the merchants keep settle entirely in Bitcoin, 41% of the merchants keep a part of their settlement in Bitcoin, and the remainder settle entirely in fiat.

That said, there are plenty of instances where BitPay merchants get settled in Bitcoin, and then use a local exchange to turn that into fiat. This is in instances where, for example, BitPay doesn't support fiat payouts in that country, or BitPay's fiat rate is lower than the local exchange's. I think it's safe to say that the actual percentage is much lower than 10%.

Of the 41% that partly settle in Bitcoin it's hard to know what the average percentage split looks like, and BitPay don't make that information available.


How could Schnorr signatures be aggregated across the whole transaction?

This is a feature of Schnorr digital signatures (ECSDSA) that did not exist in the digital signature scheme (ECDSA) that we are currently using. You should not compare the two multisig schemes together, the current design is a workaround.

Schnorr allows you to "aggregate" multiple signatures into only one signature by combining both private/public keys in the process of signing and produce a single signature (r,s) based on them. As a result you should only see one signature and one public key in your Schnorr transaction scriptSig and the output scripts (scriptPubkey) should also only use a single public key.

Take a look at this answer for a simplified collective signature scheme to get the general idea of how we only have one signature/pubkey, MuSig adds some additional steps to this process to prevent certain attacks.


How many IF/ELSE/ENDIF can be used in a script?

OP_IF
  OP_3
OP_ELSE
  OP_IF
    lock1 OP_CLTV OP_DROP OP_2
  OP_ELSE
    lock2 OP_CLTV OP_DROP OP_1
  OP_ENDIF
OP_ENDIF
pub1 pub2 pub3 OP_3 OP_CHECKMULTISIG

some pseudocode:

var x = stack.pop ( );  // take the last item from stack and remove it
if ( x != 0 )
{
  stack.push ( 3 );  // push the number '3' to the stack
}
else
{
  var y = stack.pop ( ); // take next item
  if ( y != 0 )
  {
    stack.push ( locktime1 ); // push value
    stack.compare_top_value_with_timestamp_and_abort_if_not_valid ( );
    stack.pop ( ); // remove locktime1 if passed
    stack.push ( 2 );
  }
  else
  {
    stack.push ( locktime2 ); // push value
    stack.compare_top_value_with_timestamp_and_abort_if_not_valid ( );
    stack.pop ( ); // remove locktime2 if passed
    stack.push ( 1 );
  }
}
stack.push ( pub1 );
stack.push ( pub2 );
stack.push ( pub3 );
stack.push ( 3 );
stack.check_multi_sig ( );


How to calculate Tapscript sigops budget?

The total size including the above Compact Size is 1049. In addition to this, do I need to add the number of bytes(1) of CompactSize for the number of elements(5)?

Indeed.
What matters is the total number of bytes of witness data for that input (i.e., all bytes subject to the witness discount). That also includes the encoding of the number of witness stack elements.


Is it possible to run out of nonce values?

Yes, it is possible to not find a valid block for all 2^32 possible nonces, and that is indeed the typical case. I believe only at the minimum difficulty level, sometimes still used as basis for finding shares in pooled mining, would you even average(!) one valid block out of all possible nonce values.

There is a timestamp field you can update, and there is an extra nonce that may not be so obvious because it goes into a hash calculation before being included, along nonce and timestamp, in the final double-SHA-256 hash.

Find more information here.


A thin client is a program which connects to the Bitcoin peer-to-peer (P2P) network but which doesn't fully validate transactions or blocks.  That is, it's a client to the full nodes on the network.
Most thin clients use the Simplified Payment Validation (SPV) method to verify that confirmed transactions are part of a block.  To do this, they connect to a full node on the P2P network and send it a filter (called a Bloom filter) that will match any transactions affecting the client's wallet.  When a new block is created, the client requests a special lightweight version of that block called a Merkle block.
The merkle block includes a block header, a relatively small number of hashes, a list of one-bit flags, and a transaction count.  Using this information---often less than 1 KB of data---the client can build a partial Merkle tree to the block header as illustrated below.  If the hash of the root node of the partial Merkle tree equals the hash of merkle root in the block header, the SPV client has cryptographic proof that the transaction was included in that block.  If that block then gets 6 confirmations at the current network difficulty, then the client has extremely strong proof that the transaction was valid and is accepted by the entire network.

(Image taken from MIT-licensed Bitcoin.org developer documentation.  I'm also the author of that image.)
The only major downside of the SPV method is that full nodes can simply not tell the thin clients about transactions, making it look like the client hasn't received bitcoins or that a transaction the client broadcast earlier hasn't confirmed.


I provided my XPUB and YPUB to Trezor support - should I continue to use my Trezor?

XPUB refers to an extended public key, and because it is only a public key, you have not compromised your private keys. Thus it is safe to continue using, yes. You have, on the other hand, compromised your privacy, as with that xpub Trezor support can derive all your addresses and know they are all yours. But it's likely they just want to look to see if you have any bitcoin gold balance on any of them, it's probably completely harmless


For a block to be added to the chain, it needs vote from majority of miners, is that correct? If yes, does that mean a single block gets worked upon by all of the miners?

There is no voting. Each miner works on their own version of blocks. Once they have found the hash of the block header which meets the difficulty target, they broadcast the block to the rest of the network. When the other full nodes and miners receive this block, they will first verify if the block meets all the protocol rules, and the transactions within the block are also valid. The bitcoin software is designed so as to accept the chain with the most proof of work. In most cases this is also same as the longest chain. So, when the new block is received by the nodes, they would add this block on top of the existing chain if the block is valid. When the block is received, the other miners would see that they have lost the 'race' for that particular block height. Now they will start working on the next block, by building on the top of the block that they just received.

  How does the 51 percent or 2/3 majority voting rule work?

I assume you are referring to 51% attack. 51% attack basically means that if a miner has more than 50% of the hash power of the total network, he has higher probability of mining blocks that is faster than the rest of the network combined. If that is the case, then the miner can double spend the bitcoins. If you want more clarity as to what 51% attack is, then you can refer here. Regarding 2/3rd voting, you might have read that as a part of Byzantine Fault Tolerance (BFT) threshold. However, bitcoin doesn't exist within the normal model of BFT consensus. Under conventional assumptions bitcoin will converge on a stable history if honest participants have a majority hashpower (>50%).


I believe the large threat of theft of Bitcoin or digital assets is through hacking into your account located on an exchange or possibly your wallet.  I do not believe you find theft at this point in time elsewhere.  In the future we may see qubits or quantum computing being able to conquer the blockchains security.  But as of now I believe it is through people hacking your accounts.


Is there a "MtGox Live" alternative which supports Euro?

MtGox Live now supports 17 currencies. Use this URL with the desired country code:

http://mtgoxlive.com/orders?currency=YOUR_DESIRED_CURRENCY_CODE

  BTC  // Bitcoin
  USD  // USA
  EUR  // Euro
  JPY  // Japan
  CAD  // Canada
  GBP  // Great Britain
  CHF  // Switzerland
  RUB  // Russia
  AUD  // Australia
  SEK  // Swedish
  DKK  // Denmark
  HKD  // Hong Kong
  PLN  // Poland
  CNY  // China
  SGD  // Singapore
  THB  // Thailand
  NZD  // New Zealand

Here is the Euro chart: http://mtgoxlive.com/orders?currency=EUR


Would this alternative to Proof of Work work?

I thought 3 random "validators" could be picked to do the hash-math. Only if all 3 get the same result, it is stored to a "temporary" blockchain. And only if say the next 3 blocks worked with that result, it will be placed in the actual Blockchain. If 1 of 3 gets a different hash, 3 other random people are selected to validate.

The devil is in the details! How does the network agree on three random validators? Unless all participants are agreeing on the same quorum, the  network will not converge. How do you ensure that each network participant becomes aware of the chosen quorum? What happens when one of the quorum participants just simply never responds. Is there a timeout? How do you ensure that a distributed system without a shared clock agrees when the timeout comes into effect?
I'm afraid you are back to the start: now you need a consensus system to bootstrap your consensus system.
Even worse, Bitcoin attempts to achieve consensus under adversarial conditions. E.g. someone could be flooding the network with numerous entities (a "sybil attack") giving them a greater chance at providing all members of the quorum, which gives them authorship of the next block. Or some participant could attempt to actively sabotage the process by disseminating contradictory information. So, not only do we need to achieve consensus, but the network must also be Byzantine fault tolerant.
Either way, it's not trivial to come up with a consensus system that is stable, much less with one that has more attractive trade-offs than Bitcoin's proof-of-work.
You may find these related questions interesting as well:

Why doesn't Bitcoin migrate to proof-of-stake?
Is there a way to set up proof-of-work systems so they would be even more useful?


Trying to send Bitcoins from testnet to my regtest node

The regtest system is completely isolated from testnet and only exists on your local machine by default, you won't see the transaction from TPs faucet because it isn't on the same network. Blocks in your regtest setup can be instantly created using bitcoin-cli setgenerate true <number of blocks> each of which will bring into existence 50 BTC in your local wallet for testing with.


With sendmany, how to specify the "subtractfeefrom" so that I pay the fee, but it's not subtracted from any of the "inner transactions"?

From the documentation:

The fee will be equally deducted from the amount of each selected
address.
Those recipients will receive less bitcoins than you enter in their
corresponding amount field.
If no addresses are specified here, the sender pays the fee.

So it seems like you simply don't specify any addresses in that field.


If I have only the private key from a multibit private key export, how can I use the bitcoin later elsewhere?

If I have some transactions after the export, more or new private keys will be created, which will mean that I can no longer depend on this set of private keys to regain access to the funds. Is this correct?

If you create a new address, you create a new private key, and (with MultiBit's model) you need to backup your private keys again, because there's a new private key added to the list. If you reuse the same address in new transactions (which is possible, but usually not recommended for privacy reasons), you don't need to rebackup your keys.

  My main question is, how exactly can I recover the funds for a particular address with only this private key (or set of private keys) (not specifically in multibit, but generally)? Do all clients and online wallets have an import private key option?

Most, if not all, clients/wallets have an ability to import private keys. However, there are a few different formats out there, so if the question is, "can Wallet X read this private key directly?", the answer's not as clear. But I think it is safe to say that you'll always be able to find something to read your MultiBit backup and send the money to a new address.

  What is done behind the scenes with this private key to find the public key and the address?

The private key (which is a 256-bit number) is multiplied by the base point, which is a point on Bitcoin's elliptic curve. This is done with some fairly complicated mathematical calculations. The result is the public key, which is another point on the elliptic curve. To calculate the address from the public key, you follow an algorithm with various hashings and a checksum. This is detailed at the Bitcoin wiki, which can be represented by this pseudocode:

160_hash = RIPEMD-160(SHA256(public key))
double_hash = SHA-256(SHA-256(0x00 + 160_hash))
address = base58(160_hash + double_hash[0:4])

To sum up, private key -> public key, and public key -> address are easy, while the reverse of each of this is (believed to be) practically impossible.

The most important part to take away from all this, is that one private key corresponds to one address. If you generate a new address, you have a new private key, and need to make sure it's backed up!


Since the "ownership" of bitcoins is essentially tied to having knowledge of the private key for the address they are stored against, it's very difficult to prove that nobody knows the private key.

However, it is possible to send bitcoins to an address with no private key, essentially destroying them. Details here: How to generate a valid bitcoin address for destroying bitcoins?

To answer your 3 questions:

There is no accepted definition of a lost bitcoin that I'm aware of, and it's unlikely there will be one because of the difficulty in providing proof.
The network doesn't know whether the private key for some bitcoins have been lost.
The value is based on market demand. From this perspective, bitcoins that aren't currently offered for sale are the same as lost coins until they are offered up for sale, at which point the price is affected. Though individuals do have the capability to prove they own bitcoins without offering them for sale, they rarely do so, so you'll probably never be able to find out much about which unspent bitcoins are still being quietly held and which are lost.


I don't think there is a command you can run, besides looking at Bitcoin's source code. (look for enum opcodetype)

Note that a lot of the opcodes listed there

are disabled to reduce complexity, (OP_CAT)
change meanings depending on which softforks are applied, (OP_CHECKLOCKTIMEVERIFY and OP_NOP2 have the same opcode) or
may have no meaning in a script. (OP_SMALLINTEGER)

To get a list of ones that can actually be used without making a script fail, you need to look at the code that actually evaluates scripts. (look for Bool EvalScript)

Here's a list of legal opcodes, as of time of writing:

(direct push, opcode 0x01-0x4b)
OP_PUSHDATA1
OP_PUSHDATA2
OP_PUSHDATA4
OP_0-16
OP_TRUE
OP_FALSE
OP_1NEGATE
OP_CHECKLOCKTIMEVERIFY
OP_CHECKSEQUENCEVERIFY
OP_NOP
OP_NOP1-10
OP_IF
OP_NOTIF
OP_ELSE
OP_ENDIF
OP_VERIFY
OP_RETURN
OP_TOALTSTACK
OP_FROMALTSTACK
OP_2DROP
OP_2DUP
OP_3DUP
OP_2OVER
OP_2ROT
OP_2SWAP
OP_IFDUP
OP_DEPTH
OP_DROP
OP_DUP
OP_NIP
OP_OVER
OP_PICK
OP_ROLL
OP_ROT
OP_SWAP
OP_TUCK
OP_SIZE
OP_EQUAL
OP_EQUALVERIFY
OP_NUMNOTEQUAL
OP_1ADD
OP_1SUB
OP_NEGATE
OP_ABS
OP_NOT
OP_0NOTEQUAL
OP_1ADD
OP_1SUB
OP_NEGATE
OP_ABS
OP_NOT
OP_0NOTEQUAL
OP_ADD
OP_SUB
OP_BOOLAND
OP_BOOLOR
OP_NUMEQUAL
OP_NUMEQUALVERIFY
OP_NUMNOTEQUAL
OP_LESSTHAN
OP_GREATERTHAN
OP_LESSTHANOREQUAL
OP_GREATERTHANOREQUAL
OP_MIN
OP_MAX
OP_ADD
OP_SUB
OP_BOOLAND
OP_BOOLOR
OP_NUMEQUAL
OP_NUMEQUALVERIFY
OP_NUMNOTEQUAL
OP_LESSTHAN
OP_GREATERTHAN
OP_LESSTHANOREQUAL
OP_GREATERTHANOREQUAL
OP_MIN
OP_MAX
OP_WITHIN
OP_RIPEMD160
OP_SHA1
OP_SHA256
OP_HASH160
OP_HASH256
OP_CODESEPARATOR
OP_CHECKSIG
OP_CHECKSIGVERIFY
OP_CHECKMULTISIG
OP_CHECKMULTISIGVERIFY

Bitcoin Wiki has an excellent page on this subject, if you're trying to figure out what is possible in Bitcoin script.


Why is a full sweep of a cold wallet more secure than a withdrawal?

That makes sense to me.

You see, you can generate a wallet completely offline. If so, the private key of that wallet would have never been on a internet-connected computer. That's a safe key.

However, you cannot (as far as I understand) send money without putting the private key of that wallet onto a computer that touches the internet.

Makes sense to completely empty that wallet and create a band new one offline again. Transfer partial money to where ever you want, then transfer the rest to the public key of a new wallet that has never had its private key on an internet-connected computer.


How do I show my wallet from the command line?

Direct command-line access via bitcoind is not available any more. You can get access from the command line via the RPC (Remote Procedure Call) API, e.g. with python. The API calls list is found here.

To give a specific example, you can access wallet information via the Python RPC API. Given that the client was booted with rpcuser=user and rpcpassword=pass, the sample python script illustrates how you can call the getbalance command:

  from jsonrpc import ServiceProxy

  access = ServiceProxy("http://user:pass:8332")
  access.getinfo()
  access.listreceivedbyaddress(6)
  print access.getbalance()


why not reduce the difficulty of PoW?

I'm going to assume you mean we decrease the block interval, so that blocks are found more often than the current 10 minute target. Manually altering the difficulty would indeed allow blocks to be found faster, but only until the difficulty adjustment resets it.
So really, to change the block interval, you'd need to change the difficulty adjustment algorithm, so that the target time interval is shorter.

If I understood correctly, this would speed up the mining of the blocks, so we could do more transactions for a still low cost and keep security, is that right ?

Bitcoin's proof-of-work allows miners to turn energy into security, so the amount of energy spent per time is equivalent to the amount of security attained per time.
So we could allow twice as many transactions per time, but assuming the amount of hashpower remains unchanged, we will still have the same amount of energy being spent per time to secure those transactions. This also means that at the moment of transaction confirmation, the "security per transaction" would be halved, since only half the time has passed. After two blocks, the transaction would have security equivalent to a single block's confirmation on the unaltered chain.
Related: this is why blockchains which claim to have 'faster finality than Bitcoin' are a farce: the Bitcoin network consumes more energy per time (and thus provides more security) than any other network. The number of blocks that have passed is meaningless as far as security is concerned, what really matters is the cost of rewriting those blocks. For example, rewriting 100 blocks of a low hashpower coin might be cheaper than 1 block on the Bitcoin network. So in this way the Bitcoin network's single block provides more security, more quickly.
So, why don't we do this, and lower the block interval?
With respect to the question you quoted, it is worth noting that halving the block time would be equivalent to doubling the block size, in terms of the computational, bandwidth, and storage (ignoring pruning) resources required. Doing so would put more strain on network nodes, as it would require more resources to run one. With an increase in required resources, we should expect that less nodes will exist, and that negatively impacts the degree of network decentralization. Having nodes remain as decentralized as possible is important for the bitcoin network, as the value proposition of the network largely depends on it.
As Pieter mentioned in the comments, another negative effect is increased block orphan rates. I'll copy the text from the link in Pieter's comment, which was written by Pieter, and is a great description of the issues with decreasing the block interval:

There are two issues that get worsened by this:

The shorter the inter-block interval is, the more advantage you're giving to an attacker. You see, blocks take time to propagate through the network to all miners, at the very least limited by the speed of light. Due to PoW resulting in a Poisson process for block generation time, there is a nontrivial chance for two blocks being found within a very short time of one another. If that period of time is so short that the first block has not had time to reach the miner producing the second, the second block will be a waste of power (both in terms of income and in security to the network). This wouldn't be a problem if it affected every miner equally, but it doesn't. More well-connected (geographically centralized) miners suffer less, as they're relatively closer to everyone. But most importantly, a 51% attacker does not suffer from this at all, as he only builds on top of his own blocks, and thus never needs to wait for propagation. For some numbers, at block interval 600s there is about a 0.83% chance that two blocks are produced within 5s of each other. With block interval 60s that goes up to around 8.0%. If block propagation takes 5s, that means giving a direct 8% cost reduction to a mining collusion attack.
Overall resource consumption for full nodes. If you have 10x more blocks of the same size, full nodes will need 10x more resources to verify history and maintain in sync (bandwidth, CPU, I/O, storage, ...).

In my opinion, considering these negative effects, the linear gains in scale achieved would not be worth the work and risks involved in pushing out a rule change like this.


You can force mempool synchronization by running a script which connects to the RPC ports, fetches transactions from one node's mempool, and sends it to the other nodes. Note that because this uses RPC, it will be fairly slow and will still result in some mempool desynchronization. You will probably want to run this script periodically. Here is an example in python using python-bitcoinrpc.

Note: I have not tested this

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# rpc_user and rpc_password are set in the bitcoin.conf file
nodes = []
NODE1_URL = "10.10.10.1:8332"
NODE2_URL = "10.10.10.2:8332"
NODE3_URL = "10.10.10.3:8332"
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE1_URL)))
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE2_URL)))
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE3_URL)))

for node in nodes:
    txs = node.getrawmempool()
    for tx in txs:
        rawtx = node.getrawtransaction(tx)
        for b_node in nodes:
            b_node.sendrawtransaction(rawtx)

What this does is it fetches a list of transaction ids in a node's mempool. Then it fetches each transaction and broadcasts them through the other nodes. It does this for each node. This, in theory, ensures that all of the nodes will have the same transactions in their mempool.


Create BitCoin address for each registered user

You will want to look into this implementation of bitcoin.

https://bitcoinj.github.io/

The documentation will provide all required information for generating bitcoin addresses.

It is generally unwise to reuse addresses, also very expensive to be constantly moving small amounts on the main chain. You may want to consider other implementation options rather than one address per user.


Mining pool hashrate effect on a miner's income

The size of a pool, its total hashrate and the distribution of hashrate between bigger and smaller miners, have no effect on the rewards you, mining with a specific hashrate, will obtain on average.

The total block rewards collected by the pool are proportional to the number of blocks it finds per time unit, which is proportional on average to its total hashrate. In every fair pool reward method, the rewards you get on average are exactly proportional to your part in the total work done by the pool. If you mine in a pool twice as large, the pool will collect twice as much rewards but your share in them will be cut by half, meaning you get the same on average.

More specifically, all fair reward methods give miners on average (1-f)pB per share they submit, with f being the fee, p the probability that a share will be a block, and B the block reward. This amount does not depend on anything else, in particular not on the pool size.

What does differ according to the size of the pool is the variance in the rewards (how much they vary from the average due to randomness) and the maturity time (how long it takes to obtain the rewards). It is always the case that a bigger pool will have less variance and maturity time, and thus for a miner of any size it is better to mine for a pool as large as possible (however, it is better yet to mine for multiple pools simultaneously).

One point where a miner needs to optimize based on his own size is the share difficulty; smaller miners will want easier shares, so they should make sure their pool offers it. While bigger miners should work on more difficult shares to make sure the pool server isn't overloaded.


Is a peer connection maintained for the life of the node, or is it recreated on every request?

Or is the connection persisted for the life time of the application?

Persistent. Subsequent messages will be transmitted across the same connection.

  If it is persisted, what prevents a well known public node from being swarmed with peer requests?

The Core implementation has a Connection Manager that increments the ban score for a peer if the peer behaves erroneously (e.g. spamming peer requests). Once a ban score of 100 has been accrued, the peer will be disconnected and banned from connecting until ban time window has been served.


What happens to the transaction using the coinbase transaction output of a block later considered stale?

Found the answer on Bitcoin Wiki short after.

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

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


Can I use Bitcoin so that my non-bitcoin friend finally receives CNY?

There are services that allow you to withdraw bitcoins to a third person's bank account. In that case your friend will not need to convert bitcoin to cash. I believe it will be quite easier - there also are bitcoin to bank/cash exchanges in China, but due to their regulations, such exchanges are operating using personal accounts or some schemes that are rather risky and hard to understand for the newbie.


Is Wuala (LaCie) the largest company to accept Bitcoins?

It is fantastic to see companies accept Bitcoin, even if it is just an "alpha / trial" like the method Wuala provides.

While Lacie (Wuala) is likely the largest company to accept bitcoins directly as payment, that is a specialized product of interest to a smaller subset of the bitcoin community.  Their volume of bitcoin commerce probably is a fraction of that for other bitcoin businesses which are needed by a wider customer base.  The larger dollar amounts where bitcoins are used directly for purchases might be in categories such as web hosting, dedicated servers, anonymous VPN, etc.

The largest companies to benefit from Bitcoin commerce though are the companies that offer vouchers or e-gift codes that can be used for payment.  These include NewEgg Vouchers (purchased on BTCBuy.info) and Amazon Credit and eBay Gift Codes (purchased on SpendBitcoins.com).   Those are, by far, where the largest amount of Bitcoin commerce is occurring.  Some day these companies will simply cut out the middle man and start accepting bitcoins directly (or through a payment intermediary such as Bit-Pay).


Is Bitcoin database cross platform compatible?

It should be compatible if your running one instance at a time, BUT I think that the datadir is being locked.
Try to find more details in the logs, it should tell you the reason of the error which could be anything.
if you are running any bitcoin software on windows stop it and try to restart bitcoind from your linux box.

EDIT: Did you install bitcoind and run it as root? if not, can you try to chown -R  ~/.bitcoin as root, not the db folder itself, it still can be a permission issue,


bundler configuration to accept 1 ms currency to 1 account (Ardor)

With Ardor 2.1.0e you can start a bundler which bundles only transactions with certain currency. Use CurrencyBundler filter with parameter the currency ID.

If you want to additionally filter only transactions sent to your account, you'll have to either write a new filter for that like

public class RecipientBundler implements Bundler.Filter {

    @Override
    public boolean ok(Bundler bundler, ChildTransaction childTransaction) {
        return bundler.getAccountId() == childTransaction.getRecipientId();
    }

    @Override
    public String getName() {
        return "RecipientBundler";
    }

    @Override
    public String getDescription() {
        return "Only bundle the transactions sent to the bundler account";
    }

}

...or alternatively you can create the currency as controllable.

With 2.0.14 you'll have to write a filter like the one from above which checks both conditions - that the transaction is transferring your currency and that the transaction is transferring it to your account.

EDIT:
More details about the bundling in Ardor 2.1 can be found in nxtwiki


The app wrote incorrectly adress of bitcoin

Put in the correct address, and try again.


I do not know of a definitive list of provable solvency implementations. Some of the current implementations however do show signs of similarity even if you cannot call that standardization.

For example, tether.to ( https://tether.to/ ) backs every tether with a US dollar. That's 100% backing. This is not unlike the discarded gold standard where treasuries formerly backed a currency one to one. This was a provable solvency standard accepted by the international community for decades.

Bitfinex ( https://www.bitfinex.com ) keeps a balance of tether - and publishes exact numbers within its website - in line with its user obligations. Other players similarly strive to exhibit transparency in their financial transactions.

Some altcoins link the value of their coin to a tangible asset, such as marijuana. At the same time most people might agree that even an altcoin backed by a high value tangible asset is still not a provable solvency.

Transparency does not prove solvency. Maintaining a 100% reserve of capital assets versus capital liabilities does not prove solvency. Unless you have unfettered access to a Balance Sheet created with industry recognized fundamental accounting principles, with clear asset, liabilities and equity statements, and that these statements are truthful and complete, then there is no 100% verifiable method to ascertain whether a company is solvent, or not.

With privately held companies it is not likely you will see a publicly available Balance Sheet. So with private companies, as most bitcoin and cryptocurrency companies are, you will ultimately not be capable of proving solvency, notwithstanding capital asset and liability measures, or transparency.

If you cannot see the whole picture, then you cannot verify its authenticity.


Electrum exchange rates. Where do they come from and why are they incorrect?

As of this writing, Electrum retrieves its exchange rate from Intersango. The last sale there must have been abnormally low for the current exchange rate.


Is there some way to estimate the proper value of one Bitcoin?

Unlike stocks or precious metals, Bitcoin has no inherent value; it is only worth what people are willing to pay for it, and the only way to determine that is through trading activity on an exchange.
You can try to use the same technical analyses that are used on the stock and forex markets to predict the future price, but it's incorrect to call that its "proper value".