If you want a system with centralized trust, I suppose you could do a 100% pre-mine, and have some checkpoints to 'lock' this, and have all nodes verify against the checkpoint coming from a trusted set of nodes. Even with this, you could have some bad players trying to cheat, and it would involve constant 'supervision' and checkpointing as needed... Why would any outsider want to use such a system, is beyond me. If we assume centralized trust, there are probably more efficient ways to build a token exchange platform anyway.

PoS can't really work for the same reason perpetuum mobile is impossible or in other words - you can't pull yourself up by pulling on your own hair.

The problem boils down to the fact that, with PoS, what you're staking and what you're winning is one and the same thing, a digital token. So, you're staking something that doesn't physically exist, to win more of something that doesn't physically exist. And the more you have, the more you're able to win. Sure, because there's a market you can say you're staking something of 'value', but if you got it cheap in the first place and it appreciated 100x in the meantime, the cost for you to start foul play is not at the new price, but at the old price at which you got it. Also, if you're happy with 100x, you just dump it on the market, exit clean and let some other poor soul be exposed to the risk. There's no 'investment' you can lose, because it's all digital - both the prize and the stake.

With PoW, your stake is something physical. You used 'real' money which still stands for actual human work performed, invested into specialized hardware, and consumed hard, physical energy to win the prize. Why this is important? Because energy can't be created out of thin air - you can't cheat laws of physics. This means that the punishment for attempts at cheating will always cost you real-world resources and not some digital token which came into existence from thin air in the first place. Even if you sell all your winnings, it doesn't erase your investment/stake. You still have the hardware you invested in, and there is still incentive to keep it running as long as the market gives value to the token it creates. You can't get rid of it at 100x like in PoS, because only the token appreciates, while the mining gear depreciates.
See the difference?

There's good research on the subject: https://download.wpsoftware.net/bitcoin/pos.pdf

But why do we need PoW at all?

Problem is, in digital world, anything can be simulated. If we're trying to simulate gold, what's to stop us to change the color of this 'virtual gold'. If we can do it, then why it should have value? The most important property of a cryptocurrency is ensuring certainty of its properties, like emission, fungibility, immutability, security etc. We often hear the term 'voting' but I think it is misleading. When you vote, it's someone else performing some action. This is not the case with cryptocurrency. When you 'vote', you're really only saying "the crypto with xyz properties is the one I consider valid" and if someone sends you something with xyq properties, you ignore it as invalid. If there are many peers stating exactly the same xyz properties, then it becomes a currency among them, and anyone accepting xyz as properties is free to join and transact. The more peers accepting it, the more certain you are you will have peers to transact with who're accepting the xyz properties. So where's the vote making someone else do something? There's no such vote. You either accept xyz or you don't. That's the role of nodes. There's one property which the nodes simply aren't able to verify - chronological ordering of transactions and for that, we need miners. That's it.

With PoW, any attempt at rewriting history is expensive. With PoS, it's free. 'Solutions' to make PoS 'work' like checkpoints defeat the purpose because how can you tell which checkpoints are the 'right' ones? Someone said so? Some 'trusted' server? I thought we're building trustless decentralized systems here :)


onlynet only affects outbound connections.
If you only want inbound IPv4 connections (why?), you'll need to either:

Patch Bitcoin Core to bind to IPv6 addresses in IPV6_V6ONLY mode (see CConnman::BindListenPort in src/net.cpp)
Use some firewall rule on your system to prevent incoming IPv4 connections to it
Make sure you only have a publicly-reachable IPv6 address


Is there a service that can track how a coin flows from one wallet to another visually?

I think you're looking for something like https://www.bitcointracker.co


‘Batching’ generally refers to making payments to multiple addresses, all within a single bitcoin transaction. Put differently, this means you would craft a transaction with many outputs, each one paying out a different customer, for example.

In your case, you are trying to consolidate funds (UTXOs). The outcome is similar: a more efficient use of block space, and thus lower fees for you.

To consolidate all your UTXOs, you could simply send a transaction from BISQ to your bitcoin-core wallet, that empties the BISQ wallet entirely. This should spend all your current UTXOs as inputs, and create a singular output that will be spendable from your bitcoin-core wallet.

EDIT: I misread the question, so the lined-out text above isn't relevant to the answer OP is looking for. Lets try again:

Generally, batching transactions helps to save on transaction fees, by using block space more efficiently. In this case, the goal is to apparently also maintain some privacy, by not linking all of your previous addresses together through a single spend consuming all of your UTXOs, and sending the balance to a new address.

There is an often-cited 'common-input-ownership-heuristic' that seeks to identify users under the assumption that all inputs to a transaction are likely owned by the same user. So in the case of creating a batched transaction, someone viewing the ledger may infer that a single entity owns all of the input addresses.

By paying out to many addresses, you may gain some privacy against 3rd party observers (they may assume each output is owned by a separate user, for example), but the common-input-ownership-heuristic will still be working against you, to group all of your current UTXOs together.

It is worth mentioning that this heuristic is not always true! It is possible to craft transactions with inputs provided by several users in a trust-less manner, but these transactions are currently more rare on the network.

All of that said, most wallet software does not include functionality to craft multi-output transactions, so while I am not familiar with BISQ, my guess is what you are trying to do is not possible using that software. Bitcoin-core does include this functionality, so if you are motivated enough you could perhaps export your private keys (or seed phrase) from BISQ, import them into bitcoin-core, and then craft the transaction manually to move the funds to new addresses in the desired fashion.

It is perhaps worth watching the mempool to make this transaction during a time of low fees, for maximum savings.


I found the problem. Turns out the it was actually running as it should. The reason for the error message was that the program tried to decrypt the wallet, but I never encrypted it in the first place. After encrypting it, it works fine.


What is the reference algorithm for validating a Bitcoin address?

Please avoid code samples, as they are language-specific; what I'm asking for is a detailed description of the steps required for validation, so that it can be implemented in any language of choice.

You won't find any documentation other than the wiki which is generally out of date and incorrect, so code samples will have to do. Check the reference client Bitcoin Core, and some of the JavaScript implementations in BitcoinJS. It's not difficult, just base58 encoding with a version byte of 0x01 at the front and a truncated hash at the rear. P2SH transactions have a different version byte but are still valid in the same fashion.


I'm making an infographic on Bitcoin. How can I download all Bitcoin transactions to do some analysis?

A key element of the Bitcoin protocol is the block chain, which is a public transaction database. This contains most all transactions made in bitcoins and also includes information such as the sending and receiving addresses. You can find historical transaction data for the past 3 months by using a block chain explorer like ABE or Blockchain.info.

I would recommend ABE, only because it is written in Python, which will make it a lot easier to interface with for data analysis purposes.


It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks.

Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path.  As a result, overall propagation time depends mostly on the behavior of fastest paths and there are many optimizations in the Bitcoin network to make the fastest paths usually quite fast.

On the vast majority of blocks >99% of the transactions in the block are known in advance and already validated. With validation already cached the only further validation required are trivial tests such as preventing double-spends within a block and verifying that block time/height are consistent with transaction lock-times.

On blocks consisting of known transactions relay among BIP152 HB-mode peers occurs without most of the validation (only POW and the hash root are checked, which takes under 1ms on a typical fast host). Similarly, fibre forwarding doesn't need to wait for validation (or complete reception, for that matter) even when many transactions aren't known in advance.

As a result on average the amount of time used for validation in propagation in the network today is probably closer to 0% than to 1%. I would expect based on data from matt's relay network that the 99.9th percentile would have a couple percent in validation.

In the worst case, however, no transactions would be known or already validated and, also in the worst case, a block could require minutes of processing to validate.  Fibre would still forward fairly quickly though still several times slower than typical due to the additional data needed.  In such a worst case situation the vast majority of the propagation time would be spent on validation, even where Fibre propagation is used (which doesn't need to wait for validation even when the data is unknown), just due the final receiving node's own validation.

This other answer may be of interest to you: https://bitcoin.stackexchange.com/a/80928/52021

The community has spent a fair amount of effort optimizing the non-malicious block case both because it was clear what needed to be done there and because providing equitable access to very fast propagation is essential to avoiding creating an advantage for larger miners.  Arguably, however, for many concerns the worst case performance is more critical.  Fibre makes some advance on the non-validation related worst case performance, and not making the worst case worse was a major design goal in segwit but the worst case remains a more difficult and somewhat less well addressed problem.


Do the all coins/tokens have the corresponding network exploring sites/tools?

All open source cryptocurrency project should have a community which voluntarily elects to support its ecosystem. At the beginning, block explorers for said cryptocurrency project are run on a voluntary basis, but as it gains traction, there will eventually be an economic incentive to provide said service.


There's talk of increasing the blocksize - if this can be achieved - does this mean that the 21m btc limit can also be changed?

Flat-out increasing the blocksize is a hardfork. Hardforks require the overwhelming support of all parts of the Bitcoin sphere to be adopted, otherwise they will create a forkcoin. 51% would be unlikely to suffice to implement a hardfork.

Changing the reward schedule and thus the Bitcoin supply would also require a hardfork. From a technical perspective, changing the reward schedule would probably require a similar level of changes in Bitcoin software to be rolled out.
However, getting support for a change in the Bitcoin supply would be much more difficult as it's a key precept of what Bitcoin is, while the blocksize is "merely" an operational value that has implications for the network's security and how the Bitcoin project develops. I therefore consider it extremely unlikely that the Bitcoin supply will change in the future, while a blocksize increase is almost certain.


Bitcoin RawTransaction Json - what do all the variables mean

the transaction has inputs and outputs. the inputs describe the previous bitcoins being spent in this transaction and the outputs describe the address(es) to send these bitcoins to. you can view transactions for any block using blockexplorer.com. for example, here is the simplified data for block 728, and here is the data for this same block converted from the blockchain into json format.

for a good explanation of what each of these elements inside the transaction means, i recommend this article.


I believe it stands for vector input size and vector output size.

vin_sz is the number of inputs and vout_sz is the number of outputs.


What is cs_main? Why is it called cs_main?

What is cs_main?

cs_main is a recursive mutex which is used to ensure that validation is carried out in an atomic way. It guards access to validation specific variables (such as CChainState and CNode) or mempool variables (in net_processing). The lock of cs_main is in validation.cpp.

Why is it called cs_main?

cs_main was the mutex ("critical section") that protected data in Satoshi's original main.cpp. In theory it could be renamed today as main.cpp has since been refactored into smaller files but every time you rename something in a header file, everyone needs to recompile any file that includes that header.
A long-term goal is to separate out those different bits of data that are protected by cs_main, so that eventually cs_main only protects the data inside validation.
These were answered by John Newbery and other participants of the May 12th 2021 Bitcoin Core PR review club.


How to make totally secure Bitcoin transactions?

The primary concern with Bitcoin security is where your private keys are stored.

In your scenario the private keys are stored on a Linux laptop which is not unreasonable if you follow good internet hygiene and security practices.

The next best approach is to purchase a hardware wallet from the likes of Trezor or Ledger. These wallets have High Security Module (HSM) chips inside them that are highly resistant to being compromised. By highly resistant it means the private keys are stored on a tamper-proof chip and NEVER leave it. The HSM chip in the Ledger Blue is ST31. Google for ways to compromise the ST31 versus ways to compromise Linux and you'll get the idea.

With a hardware wallet it works in conjunction with a client on your PC but the crucial factor is the transaction (tx) is signed in the HSM chip and the only thing an attacker could do is try and replace the Bitcoin address in your tx. Most hardware wallets safeguard against this by displaying the recipient address on the screen when requesting verification of the signature operation.

And finally you could write your private key down on a piece of paper and hand-sign all your Bitcoin tx's. No electronic compromises to worry about.


Mining pools communicating outside of network

This is definitely being done. One such network is FIBRE.

Obviously, miners want other miners to build on top of blocks they've mined as quickly as possible to increase the odds that their blocks will not be orphaned. And miners also want to get new blocks and start building on them as quickly as possible for the same reason.

So miners have every incentive to send and receive their blocks as quickly and as widely as possible. The bitcoin network is built to exchange blocks, but it's not its top design priority. So large scale miners use purpose built networks optimized for just that task.


Well it depends on the contract, usually they promise you a fixed hash rate working for you for a fixed time (as 200Mhs for 2 months) and you will get whatever that miner gets.
This can be done hiring full machines and then you can just tell the operator the pool and client configuration so you get the coins directly on your account.

Or the can sell you just some part of the machine hash power, in that case you will not have the option of changing the pool settings but instead you are given a way to get the hash rate and result of your machine and then the operator gives you the percentage of it's earnings that you paid for.

Currently there is a new kind of mining contracts, that is the cloud mining, it is just the same as the percentage system but instead you get a contol panel where you can increase or decrease the MHs you want and the operator usually runs a whole datacenter of miners.

The contract's price almost always are more expensive than the expected returns of that hashing power by the end of the contract but if they are paid in fiat could be an instrument to invest if you are confidant in the rise of the coin.
Also they are a good way to mine without having to worry about electricity, noise, temperature...


How to use blockstream's REST api to retrieve JSON output on an address?

As others have said you can use https://blockstream.info/api/address/bc1qgsmfaz22lzy08wqjspd8xtm43hal5tgz4hyac6 for the JSON - the doc is in reference to running a local instance - the exact endpoint is depending on deployment, the default deployment we use has nginx forward /api/ requests to electrs without the api bit https://github.com/Blockstream/esplora/blob/master/contrib/nginx.conf.in#L32 but it depends on how people want to deploy it.

We should probably mention this in the API.md file to avoid confusion


Check this out:
https://www.youtube.com/watch?v=yO-W_GDwZrg&t=497s

This video will walk you through the different aspects of Cryptowatch and how to use them for profitable trading.


How does Bitcoin Core estimate the transaction fee?

Your client [1] will make use of transactions it relays to build an estimation : by caching it (and the block height) when it first sees it. It will later be able to tell how much time (# of blocks) it took for it to be confirmed.
To build a reliable estimation, it will fill "buckets" (basically, a pack of transactions sharing a common characteristic) according to the feerate paid by each transaction it relays.
When comes the time to estimate the feerate for a transaction to be included in block before a specified number of blocks, your client will check the percentage of transactions confirmed in each bucket (so, with transactions paying that much on average) during this period of time. It will return the feerate of the first bucket with a success (confirmed transaction) rate higher to the threshold [2].
This probability threshold is set by the second argument to estimatesmartfee (CONSERVATIVE | ECONOMICAL).
To quote the documentation by Alex Morcos (who coded most of the fee estimator) :

/** \class CBlockPolicyEstimator
The BlockPolicyEstimator is used for estimating the feerate needed
for a transaction to be included in a block within a certain number of
blocks.
At a high level the algorithm works by grouping transactions into buckets
based on having similar feerates and then tracking how long it
takes transactions in the various buckets to be mined.  It operates under
the assumption that in general transactions of higher feerate will be
included in blocks before transactions of lower feerate.   So for
example if you wanted to know what feerate you should put on a transaction to
be included in a block within the next 5 blocks, you would start by looking
at the bucket with the highest feerate transactions and verifying that a
sufficiently high percentage of them were confirmed within 5 blocks and
then you would look at the next highest feerate bucket, and so on, stopping at
the last bucket to pass the test.
The average feerate of transactions in this
bucket will give you an indication of the lowest feerate you can put on a
transaction and still have a sufficiently high chance of being confirmed
within your desired 5 blocks.

[1]: Talking about each node, it goes without saying that all nodes on the network don't share the same estimation (as there is no consensus on the mempools).
[2]: this is simplified, the CONSERVATIVE and ECONOMICAL parameters have technically an influence across buckets (target / 2, target, target * 2) but it's conceptually the same logic.

Going further, this is the best (without using easily malleable data) we can do with the information we have at broadcast time but it's clearly not enough from a UX perspective as you'll never be able to predict the feerate.
For example if multiple megabytes of transactions are broadcast at the same time you broadcast yours, fee estimation won't help you.
This is why replace by fee.


What's the probability of vanity pools causing RIPEMD-160 (public key hash) collisions?

Bitcoin addresses are 160-bit numbers. Hence, randomly finding a private key corresponding to an address takes on average 2^160 attempts.

If 4 billion computers work on cracking a key doing 1 billion calculations per second for 15 billion years, they will find a total of 1.8*10^36 keys, so their chance to hit a right one is

(1.8*10^36)/(2^160) = 1.23 * 10^(-12)

which is one in a trillion. And this is only if they intentionally try to crack keys. If they just run normal vanity calculations, it doesn't matter how many keys they go over, as they'll eventually report just one key.

In the future (when the above figures may be slightly less ridicuolous), we might move on to longer key hashes.

So no, there's no risk.


How to deserialize the Transaction Count in a raw block?

This number is encoded as a variable-length integer, see the txn_count in the block protocol message.
The idea is the following:

Read the first byte as marker
If marker < 0xFD

marker is the number

If marker == 0xFD

read the next 2 bytes as the number

If marker == 0xFE

read the next 4 bytes as the number

If marker == 0xFF

read the next 8 bytes as the number

Or, in Python:
def read_varint(byte_array):
    marker = byte_array[0]
    if marker < 0xfd:
        return marker
    elif marker == 0xfd:
        return int.from_bytes(byte_array[1:3], 'little')
    elif marker == 0xfe:
        return int.from_bytes(byte_array[1:5], 'little')
    else:
        return int.from_bytes(byte_array[1:9], 'little')

See also the implementation in Bitcoin Core here.


I think your worry is that the hacker will change the public key in the database to be the public key for one of their addresses, and get access to the private key that you own, which means they will have the ability to make 2/3 signatures, which is all that they need.

This will only be a risk if you can't detect it and alert those who are funding the addresses to stop. As Matthieu said, the signatures on the old multisig address won't be valid anymore. If your service is queried for an address to send coins to, however, and it returns the new maliciously created address, then your users might be funding an address which can be spent by the hacker.

So, I think your best bet would be to make sure that you can put your service into safe-mode if someone has hacked in.


Why hasn't cold storage (offline signing) been supported by Bitcoin Core (GUI) up till now (0.19.0.1)?

Prior to segwit doing this securely required carrying around enormous prior transactions.

Prior to PBST there wasn't a standard serialization that covered all the interesting use-cases.

It's been possible to offline sign for years using the CLI and many people have been doing so.

More recently this PR adds a GUI for doing this using PSBT: https://github.com/bitcoin/bitcoin/pull/16944


Significance of the "hash" field reported by the 'bitcoin-cli getblock' command

Is the "hash" field something that the 'bitcoin-cli' calculates and inserts in situ into the json for informational purpouses

This is correct. The block contains all of the info necessary to compute the hash, so as you mentioned, including it would be unnecessary and self-referential.

As one of the steps taken to confirm the block as being valid, bitcoind will calculate the hash and check it against the network difficulty. Using the getblock command returns this hash, among other info (not all of which is explicitly included in the block, but can be calculated locally with the available info).


How to secure a blockchain based on PoW against 51% attack?

I couldn't find a satisfying answer to this 51% attack issue, so for a new blockchain with only 300 mined blocks

I am not sure about "blockchains" but below is the best answer I have read about 51% attacks related to Bitcoin by Greg Maxwell:
I think questions like this are ultimately the result of a fundamental lack of understanding about what Bitcoin is doing.
The problem Bitcoin is attempting to solve is getting everyone everywhere to agree on the same stable history of transactions.  This is necessary because in order to prevent users from printing money from nothing the system must have a rule that you can't spend a given coin more than once-- like I have a dollar then pay both alice and bob that dollar, creating a dollar out of nothing.
The intuitive way to prevent that excessive spending is to decide that first transaction that spends a coin is valid and any additional spends are invalid.   However,  in a truly decentralized system "first" is actually logically meaningless!   As an inescapable result of relativity the order which different parties will perceive events depends on their relative positions, no matter how good or fast your communication system is.
So any system that needs to prevent duplication has to have a way to artificially assign "firstness".  Centralized systems like ripple, eos, iota, blockstream liquid, etc. just have a single party (or a virtual single party) use its idea of whatever came first and everyone else just has to accept its decision.
A decentralized system like Bitcoin uses a public election.  But you can't just have a vote of 'people' in a decentralized system because that would require a centralized party to authorize people to vote.  Instead, Bitcoin uses a vote of computing power because it's possible to verify computing power without the help of any centralized third party.
If we didn't have the constraint that this system needed to work online, then you could imagine an alternative where consensus could be determined by people presenting large amounts of some rare element. ... but you can't prove you control osmium online, it appears that computing power is the only thing that can work for this purpose online.
When people talk about "51%" all they're really talking about is people rigging that election, so that they can override what everyone previously thought was the accepted order of transactions with a new order that changes some of their payments from one party to another.
With this understanding maybe you can see that the concern doesn't even depend on a single person having too much of the hash-power.  The attack would work just as well if there were 100 people each with an equal amount and a majority of them colluded to dishonestly override the result.
Also, any mechanism that would let you prevent one party (much less a secret collusion) from having too much authority would almost certainly let you just replace mining entirely. The only known way to do that is to introduce centralization and if you're willing to do that it's trivial, if you're not it appears impossible.  People have cooked up 1001 complicated schemes that claim to do it without introducing centralization, but careful analysis finds again and again that these fixes centralize the system but just hide the centralization.
I think people obsess far too much about "51%"-- it has some kind of attractive mystery to it that distracts people.  If you're worried that someone might reorder history using a high hash-power collusion-- just wait longer before you consider your transactions final.
A far bigger risk to Bitcoin is that the public using it won't understand, won't care, and won't protect the decentralization properties that make it valuable over centralized alternatives in the first place. ... a risk we can see playing out constantly in the billion dollar market caps of totally centralized systems.  The ability demonstrated by system with fake decentralization to arbitrarily change the rules out from under users is far more concerning than the risk that an expensive attack could allow some theft in the case of over-eagerly finalized transactions.
Source: https://www.reddit.com/r/Bitcoin/comments/ddddfl/question_on_the_vulnerability_of_bitcoin/f2g9e7b


Why does P2Pool show up on BitcoinWatch.com if it's P2P?

All miners in P2Pool mine "solo" but distributing the reward between all its peers, hence having both advantages of solo mining and pooled mining. The reward distribution is build into the block itself, you can't mine such a block to change it later to give yourself all the reward, nor will the P2Pool accept shares that don't contain reward redistribution.

If it doesn't show as a pool it's encased into "other known".


Is Bitcoin's Economic Majority those who already own coins or those who will buy or keep coins?

Each entity's weight in the economic majority is closely related to its ability to devalue the coins in the protocol version they are against.

People (and their proxies) who are willing to offer goods or services (including traditional currencies) for Bitcoin can refuse to accept coins of the "wrong" protocol, while people who hold bitcoins can sell coins of the wrong protocol.

A detailed analysis might reveal the impact each of these groups has, though I suspect the former group has an advantage.

(Personal note: It's been said that I coined the term "economic majority" in this context. When I originally used it I meant the former group.)


Is there a cold storage option for altcoins?

Each Altcoin will have their own respective wallet software. For example, Bitcoin has bitcoin-qt and SYS coin for example has blockmarket-qt. Each coin will have to have it's own wallet. Some wallets support multiple types of coins (Electrum).


createrawtransaction, multiple outputs, single input?

ok, i figured it out. the correct answer to the following example will look this way:

# get your unspent transactions
listunspent
# select the ones you want to pour BTC from, please also note their 'vout', it is an output of a transaction you own a private key to and therefore able to spend.
createrawtransaction '[{"txid":"aaaa...","vout":0},{"txid":"bbbb...","vout":0}]' '{"1mainaddr...":0.02}'
# explained: you are using two outputs, of total 0.0205 BTC. you give away 0.0005 fee and you keep 0.02 at your 1mainaddr...
# you can dump the resulting transaction draft to see how it'll look like
decoderawtransaction <...result_from_createrawtransaction...>
# sign it with your private keys
signrawtransaction <...result_from_createrawtransaction...>
# if it returns you a hex with "complete" : true, you can now send it off to network
# if it returns "complete" : false, you either don't have a private key for signing, or you might have specified invalid 'vout'. google for more possible problems, those were two i experienced.
sendrawtransaction <...result_from_signrawtransaction_hex...>

references:

people.xiph.org/~greg/signdemo.txt
bitcointalk.org/index.php?topic=101525.0

thanks:

@Murch

this is a manual for original satoshi client.


Gifting Bitcoin to novice users is difficult. First, your gift is tied to an obligation. In order to make use of it, they need to invest time to understand it and how to access it. This causes such gifts often to not properly connect. Secondly, the Bitcoin gift is often forgotten about because the recipient doesn't have an immediate use for it. Often Bitcoin gifts are somewhat impersonal (e.g. a paperwallet similar to a gift voucher), so they tend to get displaced. Optimally, the gift is personal and unique enough to be kept track of as well as hardy enough to survive until the recipients interest is piqued.
This brings us to another issue. The instructions how to use the Bitcoin gift must be sufficiently accessible and longlasting that a novice users can follow them now or in two decades. And they must be stored with the gift! On the other hand, it should be safe against being stolen through casual observation, like e.g. cleaning helpers. Even using some service is hit-and-miss: the space is only 11 years old, nobody knows which services will still be around in 12–16 years when your god sons get interested?
I surmise that you might have the best chances of success by investing significant effort to make your gift very personal (ensuring that it is treasured) and find a way to integrate instructions with the gift so they don't get separated.
You will want to keep a backup in case it does get lost.


Where is the AES-256 key/ IV pair stored in wallet.dat file?

I imagine the Bitcoin-core source code may be a good guide to the layout of a wallet.dat file. You may need to find the source of the specific version of Bitcoin core that created (or last wrote) the wallet.dat file.

There is also https://en.bitcoin.it/wiki/Wallet which points you to various resources.

  The format of this file is Berkeley DB. Tools that can manipulate wallet files include pywallet.


If Bitcoin is not controlled by the state, how come in some countries it is illegal?

A party can send a hexadecimal string to another party and nobody in the world can prove bitcoin or any form of money was sent. Governments can ban bitcoin usage but the bitcoin protocol is indistinguishable and can be implemented using plain speech, so it would be a matter of banning freedom of speech.


How to protect the latest block in block chain be tampered?

Recall that in order to be a valid block, it has to have a valid proof of work: the hash of the header has to be below the current target value (i.e. start with a sufficient number of zeros).  If you just alter something in the block (e.g. the destination of the coinbase transaction), its hash will change and almost certainly will no longer meet the proof-of-work target.  So you'll have to also find a nonce value which does result in a hash that meets the target.  This is just as much work as mining a new block from scratch and carries no particular benefit compared to regular mining.

If you succeed in doing so, then there will simply be two candidate blocks for the head of the block chain: the original one, and your new "tampered" version (whose hash will necessarily be different from that of the original one).  Miners will be free to choose either one to build their blocks on top of.  Soon, a consensus will be reached as to which one is part of the block chain and which one is an orphan.


which private key use to Sign this transaction?

When you have a transaction with multiple inputs, each input must be signed. The general format for a transaction is:

Transaction

{version} {flag (optional)} {input counter} {inputs} {output counter} {outputs} {witnesses (optional)} {lock time}

version (4 Bytes) - Transaction format version
flag (2 Byte Array) - Optional flag, if present, must be 0001, which indicates there is witness data in this transaction
input counter (Variable Length) - Number of inputs in the transaction represented by a Variable Length Integer.
inputs (based on Input Counter) - List of all transaction inputs which will be spent and which reference unspent transaction outputs from previous transactions.
output counter (Variable Length) - Number of outputs in the transaction represented by a Variable Length Integer.
outputs (based on Output Counter) - List of all transaction outputs where the coins will be sent and which will become unspent transaction outputs to be spent in future transactions.
witnesses (variable) - Optional list of all witnesses only if Flag is present, which are used in transaction validation according to specifications for Segregated Witness.
locktime (4 Bytes) - If non-zero and sequence numbers are < ffffffff: it represents either the block height or timestamp when transaction is final.

Inputs

And the general format for each input is:

{previous tx hash} {previous utxo index} {scriptSig length} {scriptSig} {sequence number}

previous tx hash (32 Bytes) - Hash of the previous transaction. This is used to lookup the transaction in order to validate that this input can be spent.
previous utxo index (4 Bytes) - Previous Unspent Transaction Output (UTXO) index. Since transactions can have multiple outputs, in order to specify which output, you can provide a zero-based index.
scriptSig length (Variable Length) - Length in bytes of the scriptSig.
scriptSig (based on scriptSig length)- The first part of the script that is executed before the scriptPubKey from the UTXO. When they are both executed in order, the result must be true in order to be considered a valid spend.
sequence number (4 Bytes) - Used as a relative lock time if transaction version is >= 2. See BIP68.

You can see that each input requires a scriptSig, which is where the signature is (unless it is a segwit tx, then it is in the witnesses field in the transaction above)


How transaction fees are calculated when buying from exchange and transferring to wallet?

Whenever ownership of bitcoins is transferred by means of a transaction on the blockchain, this transaction takes up space in a block and therefore incurs a transaction fee. Essentially, each sender that requests confirmation of their transaction attaches a bid for blockchain space to their transaction which a miner can collect when they include the transaction in their block.

Since the Bitcoin exchange controls the funds when you withdraw to your own wallet, the Bitcoin exchange is the sender of the transaction and decides what fee to attach to the transaction. Additionally, a withdrawal from an exchange may incur a withdrawal fee depending on the specific exchange's policy. Please check the corresponding exchange's FAQ or user guidance for more information on their fee policies.


Compressed keys default for brainwallet?

The compressed keys are better for use.
Because the redeem transaction size will be smaller, so one can save a fee.
Unfortunately, the original design of brainwallets created uncompressed keys.
And now this setting is default.
It is too late to change the default behavior of this.
Let us say that "uncompressed" keys are standard de-facto.


What's the difference? Why does only one Web wallet (Coin.Space) give you full control, why not others?

Click the question mark icon next to each field and it will give you a more detailed explanation of what that qualifier means. For example, "Shared Control over your money" says this:

  This wallet requires every transaction to be authorized both by you and this third party. Under normal circumstances, you can regain full control over your bitcoins using your initial backup or pre-signed transactions sent by email.

"Full Control" says this:

  This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds. You are however still responsible for securing and backing up your wallet.

  Why are these wallets not listed on bitcoin.org/en/choose-your-wallet: StrongCoin, Blockchain.info, Jaxx

Bitcoin.org has a listing policy for wallets. Wallets must meet certain criteria for security, usability, and privacy in order to be listed on the website. The full criteria is available here: https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/managing-wallets.md. Wallets which do not meet those criteria are either not added or are de-listed (as in the case with blockchain.info).

  Why are these not listed on bitcoin.com/choose-your-wallet: Coin.Space, Xapo

AFAIK bitcoin.com does not have any criteria for a wallet to be listed. Presumably wallets are not listed there because no one has bothered to ask them to list a wallet.

  Some web wallets (e.g. Coin.Space, Coinbase) say "Vulnerable environment" while others do not (e.g. BitGo, BTC.com). Some like Jaxx list "Secure environment". What is the difference?

Again, clicking the question mark icon will tell you. For "Vulnerable Environment", it says:

  This wallet can be loaded on computers which are vulnerable to malware. Securing your computer, using a strong passphrase, moving most of your funds to cold storage, or enabling two-factor authentication can make it harder to steal your bitcoins.

For "Secure Environment":

  This wallet is loaded on mobiles where apps are usually isolated. This provides a good protection against malware, although mobiles are usually easier to steal or lose. Encrypting your mobile and backing up your wallet can reduce that risk.

  Some says "Remote app", some do not. What is the difference?

For "Remote App":

  This wallet is loaded from a remote location. This means that whenever you use your wallet, you need to trust the developers not to steal or lose your bitcoins in an incident on their site. Using a browser extension or mobile app, if available, can reduce that risk.

  It appears that their recovery would be more troublesome compared to a mnemonic phrase method. Especially, the mention of "nLocktime" by GA was lost on me.

It can be more secure because in order for someone to steal your Bitcoin, they would need to compromise more than just your mnemonic, they would also need to compromise whatever two factor authentication you have set up in order to spend your coins.

The nLockTime thing is a special transaction which cannot be confirmed until after a certain date or block height. This transaction is for the possibility that GreenAddress becomes unavailable for some reason but still allows you to access your money.

  About your comment: "can easily be stolen by the wallet provider". Is it because they know the mnemonic phrase? Is it that they generate it so they know it?

No, it is because you are using whatever web wallet software they serve to you at the time you visit their website. You have absolutely no control over what software you are actually using (as in what the code is). So that software could be malicious, and there would be nothing you could do about it. For example, suppose blockchain.info has been legally obligated to confiscate your coins. They could simply just serve you and only you a modified version of their software which sends all of your private keys back to them in an unencrypted form and all transactions that that software makes just sends the coins back to blockchain.info. This does not even have to be blockchain.info being malicious; it could be a man-in-the-middle attacker who has hijacked your connection to blockchain.info and served you the bad software.


There are bitcoin mining proxies, some code is available on github (use the search).
For example https://github.com/cdhowie/Bitcoin-mining-proxy
(*pls make your own security evaluations on opensource code)

Im not aware of a "intermediate pool", of course proxies are popular for mining.


If you are not one of them what are other options except just asking for donations?

You could post on the ripple forums or on a ripple thread at bitcointalk. However, instead of asking/begging for a donation you should offer something, e.g. some small number of bitcents, cash, a favour, a promise to pay back the XRP with interest, etc.

  Will this be something all new users have to face in the future too?

I'm sure by the time Ripple.com is out of beta there will be an easier way to get started. Possibly gateways will offer a one time funding of a Ripple accounts either for free of via whatever other currencies the gateways use.


That's correct, a private key is not required to use createrawtransaction. The private key is only required during the signing process of signrawtransaction just as you stated in your question.

If you are looking for a web service that will allow you to create a raw transaction online, I suggest you check out http://coinb.in it does exactly this, as well as broadcast the transaction, and allow you to save a local copy to sign the transaction offline.


"always spend all balance of paper wallets" - Then why am I using my paper-wallet for multiple transactions without any problem?

Most clients will return change to a newly-generated change address, which is not the same as the address on the paper wallet.  So if you spend a partial amount, the rest of the coins will go to a change address in your client and the wallet will be empty.

You mentioned using Blockchain.info as your wallet.  The Blockchain.info wallet behaves differently than most wallets.  When you spend coins from a Blockchain address, the change goes back into the same address that you spent from.  That's why your change remains in the paper wallet.  But as far as I know, Blockchain.info is the only wallet software that works that way.  If you were using any other client, you would have run into the change address problem by now.

It's generally not good practice to reuse addresses, because it makes your financial activity easier to track.  And it's not a good idea to reuse a paper wallet.  Once the private key has touched an Internet-connected machine, it's not necessarily safe anymore.  It's possible that some malware on your phone might steal the key and empty your wallet.  The whole point of a paper wallet is to keep your private key from touching the Internet.  Once you've spent coins from a paper wallet, you really shouldn't reuse it.  You should move the rest of the coins to a new paper wallet.


I ran out of space while synchronizing, how do I get my private keys & find my balance?

If you know what bitcoin address your bitcoins are coming to (and you should know if you expect to get your bitcoins), you can lookup balance on blockchain.info like this:

http://blockchain.info/address/your-address

replace your-address with your actual bitcoin address, for example here some random address i found:

http://blockchain.info/address/1LNx3azmdKyH43UsJ6DK9oUrTbkPUr6UJg


https://Blockchain.info shows the transaction has a fee of 0.00063014 BTC, or about $7.77* CAD.  This seems to indicate the ATM took around $1.50 for the transaction, and the fee sent in the transaction by the ATM was set to 155 satoshis per byte.  Since the transaction is 404 bytes, that makes for a total fee of 0.0006262 BTC for the transaction.

https://bitcoinfees.earn.com/ shows that 155 satoshis per byte is a reasonable transaction cost that will result in the transaction being processed in around 5 to 15 minutes.  If the ATM provides the ability to specify the fee per byte, you might be inclined to set it to a lower amount knowing that the transaction will take a longer time to be processed, allowing you to retain more of your dollars.

*as of 2017-11-28 3:08 UTC.


Does every miner verify blocks that are already in the Blockchain

I'd advise you to use the search function a bit more, as you are asking a lot of questions which have already been answered.

When it is broadcast, other full nodes will ignore it as spam, and typically disconnect from the node that sent it. A bad block is unlikely to propagate very far on the network.
When other miners see it, they will also ignore it. If they mine on top of it, they will be wasting their hashing power. This also means that the miner who did the proof of work on the invalid block has wasted their own hashing power. This is why it's important that miners validate the transactions they include in blocks.

What happens if a miner publishes a block which contains an invalid transaction?


Migrate old Bitcoin Core wallet to Trezor

Do I have such a recovery seed?

No. Bitcoin Core does not use mnemonics nor is the seed exportable.

Is there any other way I can migrate my wallet to the trezor? (Other than creating a new wallet and transferring funds from the existing one to this new one)

No. The only way to migrate is to send a transaction that transfers your Bitcoin to your Trezor.

Can a Trezor hold several bitcoin wallets simultaneously? (Suppose I created a new one, and later discovered I can also access the old one through it)

No.


You are describing, the new cottage industry -- that of The Bitcoin Specialist.

There are a lot of skills that can be combined to become self employed providing Bitcoin-related services.

There is profit that can be made when trading bitcoins in-person.  There are hundreds of individuals who are signed up with LocalBitcoins and offer this personal buying and/or selling service.  Adding a fee or offering an exchange rate in your favor from five to fifteen percent versus the market rate is not uncommon, though that is temporary as competition will bring the rates more in line with market prices over the long run.

http://www.LocalBitcoins.com

There is the need for IT security assistance.  It could be as simple as helping a person understand two-factor authentication and setting up Google Authenticator to secure access to the user's exchange account.

Individuals who don't know what an "air gap" is might be willing to pay to be shown how to create an offline paper wallet using a LiveOS on a system that has no network connectivity -- purposely disabled for security purposes.  Or set up an Armory offline wallet and demonstrate how it is used:

http://www.BitAddress.org
http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

More and more Bitcoin-related services, including #bitcoin-otc marketplace, MPEx, and FastCash4Bitcoins.com for example, require GPG. Setting that up for people (and showing how to back up the GPG private key) is a needed support service.

Online there are people who simply want to move their funds from their own wallet to an EWallet and can't be bothered with updating the software and/or waiting for the blockchain to finish downloading.   But they might be willing to attach their wallet.dat (if encrypted) or upload it (via https) to someone offering wallet transfer services.

There are people locally who might be interested in speculative trading who would pay for the education -- not just market-timing trading on the exchanges but perhaps investing on MPEX, or ICBit.se (futures) as well.

There may be individuals who would love to play BitLotto, bitZino and SatoshiDICE but don't know what "provably fair" means.  So being able to demonstrate why these can be considered "provably fair" and explain how they can be used is a service that gamblers might pay for.

Bitcoin is just one of the components in the tool chest.  Just as knowing Bitcoin very well opens some doors, knowing other privacy-enhancing technologies can be valuable as well.   Tor and to a lesser extent mesh networking are two other skills a Bitcoin technology consultant will want to have expertise in.

There may be people willing to transact on the dark net but they don't already have the technical ability to do so.  Having someone local who is familiar with the steps (e.g., install Tor, install GPG, coin mixing, etc.) and can perform assistance in getting set up, in-person, is a valued service.  [Though be careful, and don't offer this service unless you really know your stuff.]  Consider joining or starting a CryptoParty:

http://www.CryptoParty.org

Local escrow is another service.  A person might not trust an online escrow but if they already know who you are, in real life, they might be more willing to use you as escrow for a trade.

Somewhat related to escrow is to act as a buyer's agent.  For instance, someone is buying something from a seller in your town and wishes to ensure a good transaction.   So you accept the buyer's payment and then you meet the seller to inspect the goods before shipment. If the items are in working order you settle up (paying cash to the seller), and the shipment goes out.

Additionally, now that ASICs are just about to ship, a person can provide tech services to non-technical people.  The BFL equipment will still need a host, whether it is a Raspberry Pi or a desktop computer.  Unlike GPU and to a lesser extent FPGAs, the ASIC equipment does not require strong technical skills.  A miner can be set up in minutes, with only periodic maintenance.  Because there is not much heat produced nor any extraordinary connectivity requirements, ASIC mining is once again putting mining back in the range of capabilities of a typical slightly ambitious person.

Just look at all the ways bitcoins are used and there are unmet needs all over the place.


Bitcoin Core V 0.10.0: Is there a way to force send when not synchronized?

No, you can not force a transaction.

Your bitcoin core wallet will only trust receiving and sending transactions once you are synchronised. Your wallet is currently doing something similar to time travelling. It is synchronising all transaction from the genenis block to the current block.

The blockchain is a numerical sequence of the proof of existance of every transaction recorded on Bitcoins world wide ledger. Your Tx will be propagated as soon as you have downloaded this chain of truth.

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


Cache the Bitcoin Datadir to Improve Performance? Increase Bitcoin DB Cache Size?

The very recently released bitcoin v0.6.0 has modified bdb cache settings (25 megabytes by default), and provides a way to change this via the command-line option -dbcache=N, with N a number in megabytes.

This change caused a very significant speedup for synchronizing the block chain indeed.


Is there a way to transfer money from Dwolla to MtGox without paying BitInstant a 3.99% transaction fee?

Im not aware of a method other then BitInstant with the 3.99% fee.  This can be confirmed at...

https://bitcointalk.org/index.php?topic=160604.0

However, there are other ways to buy bitcoins besides USD deposits to Mt.Gox which may have lower fees.


See

https://support.exodus.io/article/37-how-do-i-get-started-with-exodus

Backup your wallet to keep it safe
Once you have had a look around the Exodus wallet and you like it, it is time to go through the backup. During the backup process you will receive your (randomly generated) secret phrase of your wallet. This is a secret phrase that functions as a master key to all of your assets, if you would like to know more about your secret phrase then please check out this article: 12-word secret “recovery phrase”

If the password to the wallet doesn't work and you haven't transferred money to the wallet then you can probably just start again.


Any service a miner offers which is not related to or benefited by their being a miner should be ignored, because this is external and unrelated to mining: anyone can run such a service, and likewise a miner could choose to; or not.

There are some services that a miner could run that are miner-specific, but note that since such services are economic transactions which generally occur in private (ie between the miner and the customer), it is difficult to say how much revenue they may bring in. As an example, a miner could offer a service to mine transactions that are not broadcast to the network before they are included in a block. It would be difficult, if not impossible, to prove that any transaction in a block was such included via such a paid service, unless you were the miner or the customer.

So anyways, the thing we can be most sure about, is the block reward and the transaction fees. This is because that information is necessarily public: the first transaction in each block is called the coinbase transaction, and it includes all of that information.

So you can find this information for yourself, just by looking at the reward and transaction fees included in each block through history.

The block reward is halved every 210,000 blocks, currently it is 12.5 BTC. The transaction fees vary depending on how much users are paying to have their transactions included in new blocks (generally, more transactions means high fees), but right now (and for a good portion of bitcoin's history) transaction fees are a small part of the total mining reward.

As an example of a busy time on the network: in block 500,439 the transaction fees (~13.01 BTC) exceeded the block reward (12.5 BTC), and many blocks in that range have very high fees as well. To my knowledge that block is the only time the block reward has been less than the transaction fees, but maybe somebody else here knows better (I'm excluding blocks with 'erroneous' transactions which included unnecessarily large amounts of BTC as their transaction fee, at least).


It's a scam. Do NOT click. Will be a virus your take your passwords


Read this:
https://github.com/ckolivas/cgminer/blob/3.7/SCRYPT-README
In particular:

--intensity XX (-I XX)
Just like in bitcoin mining, scrypt mining takes an intensity, however the
scale goes from 0 to 20 to mimic the "Aggression" used in mtrlt's reaper. The
reason this is crucial is that too high an intensity can actually be
disastrous with scrypt because it CAN run out of ram. High intensities
start writing over the same ram and it is highly dependent on the GPU, but they
can start actually DECREASING your hashrate, or even worse, start producing
garbage with HW errors skyrocketing. Note that if you do NOT specify an
intensity, cgminer uses dynamic mode which is designed to minimise the harm
to a running desktop and performance WILL be poor. The lower limit to intensity
with scrypt is usually 8 and cgminer will prevent it going too low.
SUMMARY: Setting this for reasonable hashrates is mandatory.

The author of the above is also the author of cgminer, so it is worth reading.  My results immediately improved with this:

./cgminer --scrypt --intensity 20 --auto-fan --gpu-powertune -10
-u hnaparst.1 -p password -o stratum+tcp://pool1.us.multipool.us:7777


I've forgotten the password to my wallet but can still access it, can I get my Bitcoins out?

Sorry but there is no way to spend the coins without the password.  However if your password was of poor quality you may be able to use hacking tools to brute-force it.

Importing the coins to another wallet won't help... it would have the same password.


I had a similar problem with the Android Wallet which is also based on bitcoinj. I wanted to transfer my backed up wallet from my old phone to my new phone. The problem I had was that I wanted to take advantage of the new wallet words, as well as have my old addresses with me.

The only thing I could come up with is just sending the funds to my new wallet and deleting the old one.

I figured that no one would need to send me money to the old addresses. And, if they did, I would have to tell them that the addresses were compromised or that I didn't have access to them anymore. Moreover, because of the bug on Android, my old wallet made an automatic transaction flagging some old addresses as compromised.

The new wallets (and Bitcoin core itself) encourage the use of only one address per transaction. So, I think that transferring funds to the new wallet is the easiest way to go.

Hope this helps.


Blockchain vs. Banks: which one has more affordable transaction fees?

Bitcoin's blockchain transaction fees are market-based, so they fluctuate based on what fees miners are willing to mine:

Currently, they are around $0.75.

First of all, one major difference is that Bitcoin's fees are flat (not based on the transaction amount) and Visa or Mastercard's interchange fees are percentage-based. This means that the fee for larger transactions on the Bitcoin network are the same for very small transactions. You can find Visa's fees, for example on their website: Visa Interchange Rates, which depend on the type of transaction, but they generally are over 1%. Based on that, any transaction above $75 will be cheaper on the Bitcoin blockchain.

Now, there is a secondary layer network on Bitcoin called the Lightning Network, where you can do microtransactions, which are not all immediately posted to the blockchain, but can have drastically lower fees because nodes have to compete to route payment channels, see Bitcoin Lightning Network Creators: Fees Will Be Effectively Zero. The only time you pay the blockchain tx fee is when the channel is created or closed.


Create a transaction spendable in a specific block height

You have to add the absolute time/blockheight before OP_CHECKLOCKTIMEVERIFY in the script to depict how long you want to lock the transaction. Also you are using 150 as the CLTV parameter. Anything that is below 500M is dubbed as block height. Given you are using 150, that means that transaction is not spendable until 150 blocks, which should mean it is spendable immediately.


List of exchanges that seem to be trading Super Bitcoin are listed here https://www.coingecko.com/en/coins/super-bitcoin/trading_exchanges

Gate offers the best liquidity at this time. Good luck


how to monitor +20,000 addresses for new received transactions?

I am basically doing the same thing for bitcoinmonitor.net. I have a database of addresses to monitor and get notifications from bitcoind for any incoming transaction.

I maintain a patchset for bitcoind which allows setting an url which will be called with any incoming unconfirmed transaction, including transaction details in a json object. Also for any new accepted block a (different) url can be set up to be called with details on the new block.

So you will get a notification for any incoming unconfirmed transaction, then you can match this with the monitored addresses in your database.
If you want to trigger actions after a certain number of confirmations you need to hook up to the new block event.

Check https://github.com/TripleSpeeder/bitcoin for my bitcoind fork. I try to keep it more or less in sync with the current stable official client. This is running stable with bitcoinmonitor.net for around 10 months now.


How are a private key and a seed phrase related?

It's the same relationship between the branches of a tree and the seed you put in the earth that grows into that tree.
We have a seed that can be used to derive child branches and child keys which makes the relationship is one directional (you can always derive the child key by having the seed but you can't compute the seed from the child key).
Take a look at the following picture from BIP32:


Why iota coin do not support smart-contracts?

IOTA is very different from Bitcoin. Consensus formation and transactions are not separate. In Bitcoin you have miners that realize consensus on the order of transactions, that are separate from the transactions done. In IOTA every transaction has to validate two earlier transactions. This leads to another data structure than a blockchain, they call the Tangle:

A "blockchainless blockchain".

Now, to implement a virtual machine that can execute a smart contract it needs to have consensus on order of transactions (let's say, the order of "0"s and "0"s). With the Tangle every node has a different view of when transactions happened. This makes it impossible to have consensus on smart contracts.

Facilitating smart contracts is on the roadmap of IOTA. The idea is to do this with timestamp oracles that provide a mechanism for order of transactions. See [http://iota.org/timestamps.pdf](On the timestamps in the tangle).


Why does Bitcoin support both compressed and uncompressed keys/addresses?

The reason they exist both, is because Satoshi didn't know about compressed public keys, and it was only recently discovered that they would be possible to use without compatibility problems (support only exists as of version 0.6 of the reference client).

The advantage is clear: their public keys are smaller, resulting in smaller transactions on the network, saving block chain size for everyone.

Update: inside SegWit spends, only compressed keys can be used.


Where in a bitcoin transaction can I store some data?

createrawtransaction can be used to store data:

createrawtransaction [{"txid":"id","vout":n},...] {"address":amount,"data":"hex",...} ( locktime ) ( replaceable )

Create a transaction spending the given inputs and creating new outputs.
Outputs can be addresses or data.
Returns hex-encoded raw transaction.
Note that the transaction's inputs are not signed, and
it is not stored in the wallet or transmitted to the network.

Arguments:
1. "inputs"                (array, required) A json array of json objects
     [
       {
         "txid":"id",    (string, required) The transaction id
         "vout":n,         (numeric, required) The output number
         "sequence":n      (numeric, optional) The sequence number
       }
       ,...
     ]
2. "outputs"               (object, required) a json object with outputs
    {
      "address": x.xxx,    (numeric or string, required) The key is the bitcoin address, the numeric value (can be string) is the BTC amount
      "data": "hex"      (string, required) The key is "data", the value is hex encoded data
      ,...
    }
3. locktime                  (numeric, optional, default=0) Raw locktime. Non-0 value also locktime-activates inputs
4. replaceable               (boolean, optional, default=false) Marks this transaction as BIP125 replaceable.
                             Allows this transaction to be replaced by a transaction with higher fees. If provided, it is an error if explicit sequence numbers are incompatible.

Result:
"transaction"              (string) hex string of the transaction

Examples:
> bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "{\"address\":0.01}"
> bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "{\"data\":\"00010203\"}"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": ["[{\"txid\":\"myid\",\"vout\":0}]", "{\"address\":0.01}"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": ["[{\"txid\":\"myid\",\"vout\":0}]", "{\"data\":\"00010203\"}"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


Does difficulty adjustment apply when you mine in secret?

Yes. The difficulty adjustment is part of the consensus rules. In order to create a valid chain that you intend to use to replace the current main chain, you must follow all of the consensus rules. That means adjusting the difficulty in the same way any verifier would be when they validate your chain.


It does not have one.

Bitcoin Core uses hardened derivation, so there is no way to compute the addresses it will use externally.

Support for that will likely be added in upcoming versions, but likely won't be the default (there are security risks when using non-hardened derivation).


What would happen if you send Bitcoin (BTC) to a Bitcoin Cash (BCH, aka BCC) address?

As of what happens if someone send BTC from a BTC wallet to BCC wallet address, the transactions go through.
But you can only see that transaction in the Bitcoin Blockchain rather than Bitcoin cash blockchain.
I will explain with an example.

Say there is an address named "abc" in BTC and another address named "def" in BCC.

abc has 1 BTC (Bitcoin Network)
def has 0 BCC (Bitcoin Cash Network)

If a person by mistake (or for fun) sends 1 BTC from abc to def. Then the balance changes as follows:

abc has 0 BTC (Bitcoin Network)
def has 1 BTC (Bitcoin Network) [Assuming there was no transaction fees]
def has 0 BCC (Bitcoin Cash Network)

So, if the owner of def in BCC has the private key of that address, he can access the BTC in def as well.

But if he unfortunately does not hold the private key of that BCC address (like it can be of an exchange where you don't have access to the private key), then the BTC cannot be accessed by the owner of the BCC address.

Hope this answers your query well.


What is the secure, self-hosted wallet to redeem BTG (Bitcoin Gold)?

Ideally self-hosted and open source.

State of the blockchain, crypto, whole ecosystem - early days - no ideal solutions - skilled developers are in extremely high demand and (to be honest) I didn't expect to find such tool.

With that said - first I moved actual BTC to another address.

Then - using the seed I was able to follow instructions here: https://coinsutra.com/claim-bitcoin-gold-btg/ (very good write up, THANKS)

In essence:

install Coinomi app (currently Android only)
restore wallet
put your phrase (don't tick BIP39)
add BTC (optionally, I first added BTC so that I could easily verify that balance is recognised)
add BTG - advanced - M/44H/0H/0H (important, defaults are not smart)
profit

I happened to keep BTC at blockchain.info (not anymore) so I had access to the 12 words seed - that was easy. There is a number of questions about claiming BTG from other type of the wallets - my first thought are leading towards bounty-smart-contract-fication - put some money in the pot and hire developers - so that whales can get their 5% dividend without risking much.

In my case - I enjoy playing, educating, experimenting. It was time well spent - I believe so.


Cryptocurrency Exchange Technical architecture? How to build it? (Developer Point of View)

There is opensource asset exchange called Peatio written in ruby. You can look into its source code to see what happens with assets during their lifetime there.

Mainly there are 3 steps for exchange:

Deposit - put real coins to exchange's accounts
Exchange - change coins, by changing just values of accounts' balances
Withdraw - send real coins from exchange's accounts to end user

When user sends deposit request, exchange generates new address (sends rpc request to btc node), and assigns it to deposit entity in db. User have to send sufficient amount of btc, to fulfill deposit. When special daemon watcher finds incoming transaction to the address assigned to some deposit entity, it compares incoming amount with required one and waits for confirmations. If there are enough btcs and confirmations - daemon increases amount of user's account balance.

Then, during user's exchanges, exchange engine just changes numbers in db, so no real transactions are provided. This allows very fast fast and network fee free exchanges.

When user decides to spend bitcoins from account, he sends withdrawal request to exchange. Exchange checks user's balance and if there are enough coins, sends them from its wallet to user's address and decreases user's balance

In such system security of the main server is critical. All coins are stored on wallets of the system and can be spent by it. So cold wallet is usually used in such exchanges. Nearly 90% of total amount of all coins are sent to some secured wallet: hardware wallet or at least wallet, that is stored on a system that doesn't have internet connection. When there is not enough coins on hot wallet to create withdrawal, alert is sent to admin, and he manually sends some coins from cold wallet to hot.

If you don't want to allow trading, and just want exchange, you can remove Exchange step, and create withdrawal just after deposit fulfillment. But then you have to determine price of the pair.

This is not the only approach to asset exchanges. There are also approaches when users control their wallets on exchange, and approaches when decisions to change user's balance are taken by several nodes together.


Successfully compile bitcoin without errors, but get 'Abort trap: 6' when I run /.bitcoind on Mac OSX

I solve it by updating OSX and XCode to latest version, but still get 1 fail when running 'make check'(see issue: https://github.com/bitcoin/bitcoin/issues/11731#issuecomment-345811656).


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


Satoshi made many design decisions that are now criticized (like signatures in transactions, 2-week difficulty period, halvings, etc..). He also made some maths error in the whitepaper. Satoshi wasn't a perfect designer and his C++ code was not up to the highest standards.

We will maybe never know for sure why he chose what he chose, but I'd personally argue it was for simplicity sake.

On a more tangent note: while SegWit looks simple on paper (just put the signatures on the side), in practice, it's quite a complex change to implement. It took months for the most experienced developers to review it.


Why my bitcoind cannot query all the blocks?

That's because although the Bitcoin blockchain has a current height of 574080, your full node has synced until 195807 (the output "blocks": 195807 after running getblockchaininfo command). Block 195876, the one that you are querying, has not synced yet on your node. As you said, you have just installed Bitcoin Core. It take  many hours (or sometimes days depending on your machine) for the node to reach the tip of the blockchain. It is not the size of the blockchain that makes it take so long time, but because your full node will go through every transaction since the genesis block and make sure that they confine by the consensus protocol.


How spending same coins both at BCC and BTC blockchains prevented?

This is from their FAQ.

Bitcoin Cash transactions use a new flag SIGHASH_FORKID, which is non standard to the legacy blockchain.  This prevents Bitcoin Cash transactions from being replayed on the Bitcoin blockchain and vice versa.


How sign the first transaction's signature?

See Bitcoin Wiki.
Above image illustrates a byte-map of transaction with each type of TxIn and TxOut.

We should attention at "Coinbase/Generation" (Coinbase means the first transaction in a block).
Codebase's script is a arbitary data.
Yep, it is random.

Therefore the signature of first transaction of a block is not used.


Why is mining necessary for the Bitcoin network/system?

You should start here: http://www.youtube.com/watch?v=GmOzih6I1zs

As the video mentions, mining is needed to ensure fairness and for keeping th network stable, safe and secure.

Now, let's see what that means. But first a very brief explanation of the principle of mining.

Mining

The Bitcoin network consists of nodes that all store a database with all transactions, called the block chain. This database consists of a long chain of blocks, each holding one or more transactions. What miners basically do is bundling all unconfirmed transaction into a block. The form of the block must satisfy certain conditions before the block is considered valid. This condition is called proof of work and is not trivial to understand. When a miner finds a block that is valid, it can send its block to the network and others will verify it. When it is indeed valid, all clients will add it to their block chain. Every time a miner finds a valid block, it has the right to assign a certain amount of bitcoins to himself, called the block reward. They also get all transaction fees of all transactions included in his block. This way, new bitcoins are added to the network and it can be ensured that transactions can be confirmed.

Fairness

Since Bitcoin is peer-to-peer and there is no central authority to control it, every one can send any kind of transaction to the network, whether or not it is valid. You could simply send a transaction that sends someone else's coins to yourself.

Luckily no one in the network will accept your transaction. When you want to spend bitcoins from a certain address, you will need to sign the transaction with the private key of that address. Other clients in the network can verify that you own that private key because they have the public key. This method is based on public-key cryptography.

So when miners try to bundle unconfirmed transactions into a block, they first need to confirm every transaction to make sure that all transactions in its block are valid. When they are not, other clients will not accept the block they mined when they send it to the network.

This way, miners ensure that people can only spend bitcoins they own.

Stability

This is the least difficult one to understand. The Bitcoin protocol sets the difficulty of the mining problem so that averagely every 10 minutes a new block can be found by some miner. This way, a transaction takes 10 minutes to be confirmed on average.

However, after a transaction has been included in a block, it still is not irreversible. This is not easy to understand, but when a miners try to mine a new block, they include in that block the number and the ID of the previous one. So let's say someone mined block 100, which follows number 99. It can happen that someone else didn't notice that someone found a valid block to follow on 99 and makes a valid number 100 itself as well, let's call it 100'. In this case, most clients will only accept the first block they received. But it can happen that another miner received 100' first and will find a block following on 100' and not on 100. Then we have following situation:

98 - 99 - 100
      \ _ 100' - 101'

When clients notice such a situation, they will always choose the longest existing chain (that only consists of block they think are valid). This means that block 100 will be discarded and that 100' and 101' or now the two last block of the main chain. This means that a transaction that was confirmed by block 100 is now possibly no longer confirmed. Luckily, the miners who found block 100' or 101' probably also knew of the transaction and most probably they also included it in one of those blocks. But it can happen that they did not and so a transaction can be undone.

For this reason, most clients and merchants require a transaction to be confirmed by at least 6 blocks. This means it must be included in a block that has at least 5 blocks after it.

The fact that a transaction will be able to be considered confirmed after averagely 1 hour, makes it a stable situation. It happens rarely that transactions confirmed for more than 1 hour will ever be reversed again.

Safety and security

The previous part about stability already included some security aspects of mining. It is clear that miners make the Bitcoin block chain trustworthy. When a transaction is included in a block and 5 or more other blocks have passed, you can be sure it is irreversible and safe to accept it as a payment.

It is also clear that the safety and security of Bitcoin as a payment system is in the hands of the miners and that every time one of them solves a block, he has the power to decide what transactions he accepted to the block chain.

Mostly, all miners are fair and they will include as much valid transactions as possible. Whenever a miner is not fair and it selectively excludes some transactions, some other miner will likely include it in the next block.

There is however one flaw. When a miner has more computation power than all other miners combined, it can always create new blocks at a faster rate than the others. This gives him much power over the block chain, and that is to be avoided at all cost. This flaw is named a 51% attack. This answer sums up the consequences of what could happen if someone would have 51% of the network computation power.

But this is a security flaw, what has this to do with why miners should mine? Well, as more people mine, the total computation power rises and it will be much much harder for someone to perform such a 51% attack. Currently, to own hardware capable of performing such an attack would be so enormously expensive that it is economically unfeasible to do, if not completely impossible. So, every miner who contributes his power to the network ensures that only fair miners will find blocks and that the network will be safe for people to trust upon.


Faster way to sync my new Bitcoin wallet?

The blockchain is available via Torrent now. You can download bootstrap.dat (14GB) this way and then process it locally, which in my case was much faster than syncing with network using Bitcoin-Qt.

Have a look at the announcement and you can grab torrent file from sourceforge.


segwit compatilibity bc1 and 3 bitcoin wallet?

there are two type of segwit as P2SH starting with 3 and Native SegWit (bech32) starting with bc1, but don't know which of the two segwit one, is better and is compatible to transfer and receive from a legacy one?

Generally speaking the "bc1" native SegWit address is better. It's completely redesigned comparing to the classical/legacy Base58 encoding invented by Satoshi.
Alphabets in a "bc1" address can be either all upper-case or all lower-case, the former fits QR code better, resulting in a more compact QR code. Without mixed-case alphabets, "bc1" address is also easier to be read orally.
"bc1" (P2WPKH) addresses take the least bytes in transactions comparing to "3" (P2SH-P2WPKH) addresses or "1" (P2PKH) addresses, therefore its miner fee is the cheapest among three address types.
Bitcoins can be freely transferred among all three address types.
However, when you are receiving bitcoins, there's a compatibility issue around "bc1" addresses, that some (old) wallets (including the withdrawal interface of some exchanges) simply don't recognize it.
When you are sending bitcoins from SegWit addresses, there's nothing to worry about, except a minor issue that a 0-conf SegWit transaction may not show up in the payee's view, if the payee is using an old wallet which is not SegWit-aware. In that situation, it will finally show up in the payee's view when it gets included into the blockchain.
By the way, SegWit addresses, including both "3" and "bc1", currently doesn't support the "sign/verify message" feature in Bitcoin Core. Some developers also worried about abuses of this function IIRC. Trezor and Electrum had implemented this feature in ways which were not compatible with each other. In the future, maybe we could see this standardized by BIP322.

a segwit wallet helps to reduce the size of the tx, and reduce fee

Currenty SegWit doesn't really reduce the size of the transaction. The "bc1" native SegWit address only reduce the size by several bytes. The "3" P2SH SegWit address on the contrary cosumes more bytes in the block, because P2SH wrapping itself requires a 20-byte hash.
Mostly it's just a discount, that the "witness" part (mostly digital signatures and pubkeys) would be counted as 1/4 of its actual size (aka. "virtual byte", or vB for short). Obviously, only transactions spending coins from SegWit addresses enjoy that discount.
However, SegWit has other benefits, like Signing of input values, which simplifies unsigned transaction format, especially PSBT, which could benefit offline/cold/hardware wallets and transactions involving multiple parties (related).  Update: it turns out that this improvement doesn't really work: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd


Creating multiple clients inside a single lnd node

Yes absolutely. Many users can use / share one lightning node. You might have to create some accounting sodtware if you want every user to have their own funds. This is a classical custodial wallet solution. I am not aware of open source solutions but I build one on top of the clightning api. This solution should work in a. Very similar way for lnd.

Start by looking at the grpc api and macaroons so that you can create such a software on top of your lightning node


Why are the results of the Coinish Bitcoin calculate so grim?

I started around March with 2 GPU's. My electricity is free and bitcoin price has tripled since then. I still haven't come close breakeven.

Back then I knew it would take a long time, and I knew the ASICs were coming. I did it purely out of interest and fun.

There really is no other reason to start GPU mining now. Even with everything free, it's just wear and tear on the hardware.

So the answer is: that calculator is probably right. Math doesn't lie, I guess.


Can I export my funds from blockchain.info with the backup phrase?

If you mean by "backup phrase" the Mnemonic phrase which is 12 word for blockchain so the answer is yes, you can export your funds.

Assume you want to import your mnemonic phrase to electrm

you have to choose that your mnemonic phrase is bip39 seed, not electrum seed.

Then they will ask about derivation path you leave it 44 (default) for blockchain.


Input and Output of all funds in the same block?

There are two transactions associated with the address: 1CRTSXJXa3LsaHwjTA5yTbqbyi6QituztX
Tx 1: e53cfb481ea8c2e2ff2827c7148393fbd617d7fc545c4a1a475221839344ca48
Fee: 0.00009072BTC
Fee rate: 3.02 satoshi/vByte
Tx 2: 9fa21b4ed7b242f0ddf1962c8f942109ae8f48ec5b03fff8e00a03e116c6bd44
Fee: 0.00002724BTC
Fee rate: 12.16 satoshi/vByte
Both were included in block 598408
This is possible and you can always spend unconfirmed UTXO. Child tx will use higher fee rate, this is dependent on parent tx so both are included in same block. If the fee rate for both transactions combined is higher than most of the transactions in mempool, miners will prioritize such transactions.
Child pays for parent: How would you create child pay for parent in bitcoind-cli


What is it about a Trezor that means it can't be infected by malware?

Trezor is a relatively simple, specialized hardware device. It does not run any OS, just a small program specifically developed for signing Bitcoin transactions and managing the keys. Thus, the attack surface is very small compared to conventional general-purpose computers. You can say it's practically impossible to infect it.

Security is a much more complicated area though and I wouldn't say it's impossible unless I can formally prove it. It is however the safest device I know of (but this is subjective).


What does validation cover conceptually in the Bitcoin Core codebase?

John Newbery answered this at the Bitcoin Core PR review club session.

Conceptually validation stores and maintains our best view of the blockchain and associated UTXO set. It also includes an interface to submit unconfirmed transactions to the mempool.

In addition, James O'Beirne's slides from a presentation on Bitcoin Core architecture at Bitcoin Edge Dev++ stated:

Validation handles modifying in-memory data structures for chainstate and transactions (mempool) on the basis of certain acceptance rules.
It both defines some of these data structures (CChainState, mapBlockIndex) as well as procedures for validating them, e.g. CheckBlock().
Oddly, it also contains some utility functions for marshalling data to and from disk, e.g. ReadBlockFromDisk(), FlushStateToDisk(), {Dump,Load}Mempool(). This is probably because validation.{h,cpp} is the result of refactoring main.{h,cpp} into smaller pieces.

Here is a diagram from James' presentation showing how validation relates to other regions of the codebase.


Can Darkcoin's Darksend be implemented on top of Bitcoin?

Yes, DarkSend is one specific implementation of CoinJoin, and CoinJoin can implemented directly on top of Bitcoin without a modification of the protocol. So no fork is necessary.

The Darkcoin Whitepaper does not
mention anything that would deviate from the CoinJoin idea and thus require a modification of Bitcoin. (However, the paper is not very detailed and I did not look at the source code, so I cannot provide an answer with 100% certainty.)

CoinJoin has been originally proposed by Gregory Maxwell. The main advantage of CoinJoin to avoid that coins can be stolen while mixing them with other users. It does not change Bitcoin, it runs on top of it, i.e., it only provides a special way to create perfectly valid Bitcoin transactions that can be submitted to the network. Of course, users need a special client to participate in the protocol. For users with normal clients, the created transaction is just a normal Bitcoin transaction that appears in the blockchain.


Formula for calculating bitcoin transaction size doesn't always work out but why

What am I missing?

Public keys can be compressed or uncompressed
Signature can has slightly different size

And yes, Murch is right in his comment. The formula works only for p2pkh inputs and p2pkh outputs. No p2sh, no segwit, no anything except p2pkh


After restarting a node, are missed transactions recovered in mempool? (v0.14.1)

Bitcoin Core (v0.14+) does not actively try to learn about transactions it missed.

Historically, this was not done because it would unnecessarily and unintentionally extend the lifetime of transactions in the mempool. This is no longer an issue because the mempool is limited, and deals correct with expiration and eviction.

However, no efficient protocol exists to accomplish mempool syncing. We could ask for all txids from all peers, but this would amount to several hundred MB of data, most of which is redundant (as it'd be identical across peers). Some research has been done on set reconciliation protocols, which efficiently find differences between the mempools and just transfer the differences. None of that is close to deployment, however.


Do US based exchanges need to file as an MSB with FinCen?

Yes - FinCen released details about this within the past month stating that Bitcoin "exchanger" must comply with regulations. Note that this may apply not just to exchange "houses", but also to individuals who exchange Bitcoin for USD. From the FinCen summary:

  A user of virtual currency is not an MSB (money services business) under FinCEN's regulations and therefore is not subject to MSB registration, reporting, and recordkeeping regulations. However, an administrator or exchanger is an MSB under FinCEN's regulations, specifically, a money transmitter, unless a limitation to or exemption from the definition applies to the person. An administrator or exchanger is not a provider or seller of prepaid access, or a dealer in foreign exchange, under FinCEN's regulations.

FinCen statement
ArsTechnica article


why is the blockchain necessary if bitcoins utilize cryptography

Problems:

1) Sybil attack (this is actually a huge one and has been for decades and decades in all kinds of applications). Other answers already mentioned this too. What is a majority if one attacker can easily pretend to be 10 million nodes?

Bitcoin makes (mining) nodes do Proof of Work and it's the amount of (unfakeable) work done that counts, not the number of (easily fakeable) nodes.

2) Timestamp? There is no such thing as an "earliest timestamped trade". Transactions arrive at different nodes at different times. Do you trust the timestamp that the attached put inside the transaction or do you listen to the majority (see 1).

Note that Bitcoin decides what is "earliest" by constructing a global clock that beats very irregularly, but on average every 10 minutes.

3) Initial download. Where in your system is a brand new node going to get the current ledger? From the majority? (See 1) Bitcoin solves this by keeping the history so as long as you start with the initial genesis block, you'll arrive at the current ledger without having to trust anyone.

4) Keeping balances is actually not more efficient at all if you care anything for the pseudonymous nature of Bitcoin. Every address is supposed to be unique so if you keep a balance for every address it's still going to be big. Sure you can drop zero balances but Bitcoin does that too in the UTXO set. Once validated old blocks don't matter anymore at all. They get archived on disk or even deleted (pruned). So the 50GB of blocks don't matter anymore anyway.


Is it possible to send bitcoins without paying a fee?

It is possible to send Bitcoins without paying any fee. The easiest way is if your transaction meets the following requirements:

The transaction only sends coins to one address, plus the return of change. (No more than two 'out' scripts.)
The transaction doesn't need to gather a large number of small transaction outputs. (You are spending funds you received in a sensible way, not as a large number of micro-transactions.)
The funds are stable. That is, you aren't spending funds you recently received.

Otherwise, the transaction fee goes to the miner who includes your transaction in a block.

Currently, it is possible to get any valid, standard transaction into a block without paying a fee if you are willing to be sufficiently patient. You may need to specifically configure your client to connect to a client known to accept such transactions and known to relay them to miners. (Luke Dash Jr. runs one such node, with IP address 173.242.112.53.)


Is bitcoin just one long block chain or are there multiple chains?

The Bitcoin blockchain converges to a single-file chain because each block references exactly one predecessor, and thus there can only be one block at every height in the chain connecting the genesis block and the chain-tip.

However, at times more than one block will be found at the same height. This happens either due to the mere happenstance of two miners discovering a valid block in the same instant, which is benign and will rectify by itself when one of the two sires a successor block and thus creates a new longest valid chain, or it could happen if a faction in Bitcoin adopts an incompatible protocol rule change (hardfork). Since network participants that don't accept the rule change will not accept these blocks as valid, two chain-tips may persist henceforth.

Recently, the hardfork plans of Bitcoin Unlimited have been a major topic in Bitcoin, which frequently includes discussion of possible scenarios with two incompatible chain-tips. I assume that you seeing a discussion of that sort gave you the idea that there could be more than one chain.


(How) can I run standard clients on a "toy" block chain?

This seemed to be a newbie question. There is what is called a "testnet", and there is more info on the Wiki at: https://en.bitcoin.it/wiki/Testnet

This site has a specific tag for it, as well: https://bitcoin.stackexchange.com/questions/tagged/testnet


Why do transaction/blockchain based gambling sites use such complicated methods for proving fairness?

Obviously many gambling websites cheat. Most of them are not transparent.

An important thing is that most gambling websites that use a government-backed currency are subject to gambling laws in the country of that government.

Bitcoin isn't. Bitcoin is currently not subject to any gambling law and so it would be easier for gambling site owners to be unfair. For this reason, it can be very important for a Bitcoin business to be transparent if they want to gain traction in the masses.

Another reason, Bitcoin offers a unique way to prove fairness of such applications from within it's own workings. Why wouldn't you use it if you plan to offer a fair service after all??


In a mining pool, can there be any two or more nodes mining a block using the same nonce?

As I understand this. The nonce is the response to the mining hardware. Nodes process transactions AND this is not mining. The mining produces the nonce the core adds transactions and distributes them (according to block level).
This is an artifact of early bitcoin development from pre-2010 release of "theory technology". You would have a hard time finding any information on this now a days. Good luck @ the onion.


How to debug a failed restore of a Namecoin wallet?

The best thing to do is wait for the blockchain to download.  With most wallet backups/new installations of bitcoin or namecoin blockchain downloading is usually the issue.  Many people seem to get a little impatient and think the program is broken when it's really just the download taking a while.


i can not calculate gflops  but...

some easy thoughts:

if sha2 is not safe anymore you can not easily steal bitcoin from an existing address by calculating the private key from any address because to generate the address ripemd160 is also used. and you did not assume that ripemd160 is also not safe anymore.

if everyone would know sha2 is not safe anymore then bitcoin will be worthless because everybody can mine without doing any work of the proof-of-work-process.

if only the attacker knows how to calculate the input of an sha2 function, an intelligent attacker would not attack the system. he would use the system:
the easiest way to make money when you can calculate nearly arbitrary sha2-hashs with nearly arbitrary input: mining. you can mine blocks and so you can earn 12.5btc several times every hour (furthermore you earn the transactionfees) without paying many money for electricity because you don't need to "work" in the sense of proof of work anymore. the advantage: you do not destroying the system because no one can really realize that you can "hack" the system and so you could theoretically earn many bitcoins.