Bitcoin Core full node wallet - questions about security & recovery can you tell me pls,

1)  Which secure full node wallet implementations exist? Currently I just know of bitcoin core. Is there not any other one with a GUI?

2)  Can you use a Ledger device with those full node wallets?

3) Many wallet apps like "Ledger Live" use their own servers for transaction verification. What is the case if you use a full node wallet like Bitcoin Core? Whose servers are you pinging there during transactions?

4) Can the bitcoin core wallet censor in any way your transactions, hide them or simulate, prolong them?

5) In bitcoin core, how is the funds recovery mechanism? Is it "Hierarchical Deterministic", can you you always restore your funds with a 24word mnemonic (also by other HD wallets)?

6) If someone for example gets access to your computer where your bitcoin core  wallet is installed on, would this person be able to freely access the wallet and transact with it? What security mechanisms are in place for that scenario?

7) How can you restore funds with bitcoin core when you lost your computer where the wallet was installed on? Which different recovery options exist?
Is bitcoin core wallet compatible with this recovery mechanism listed in github:
https://github.com/iancoleman/bip39

Thanks everyone for educating me!

1) Which secure full node wallet implementations exist? Currently I just know of bitcoin core. Is there not any other one with a GUI?

I don't know of any others, apart from forks of Bitcoin Core like Knots. See https://bitcoin.org for an overview of various types of wallet software.

  2) Can you use a Ledger device with those full node wallets?

Yes, though it is a complex manual process using command-line tools for now.

  3) Many wallet apps like "Ledger Live" use their own servers for transaction verification. What is the case if you use a full node wallet like Bitcoin Core? Whose servers are you pinging there during transactions?

Bitcoin Core is a full node that does not rely on any trusted services. The built-in wallet in Bitcoin Core (or any other wallet you'd connect to it) is solely querying your own node.

The node of course needs peers to download blocks and transactions from, but all it needs is one honest peer. As all data is locally verified it does not matter if your peers are trying to mislead you.

  4) Can the bitcoin core wallet censor in any way your transactions, hide them or simulate, prolong them?

If the software you yourself use is malicious it can do anything, including censoring your transactions or stealing your coins. Bitcoin Core is open source, and many eyes review all changes in it, but you have to make sure to use the official Bitcoin Core binaries from https://bitcoincore.org (or https://bitcoin.org), and verify the signatures (see instructions on those sites for doing so), to prevent someone from giving you a modified version.

  5) In bitcoin core, how is the funds recovery mechanism? Is it "Hierarchical Deterministic", can you you always restore your funds with a 24word mnemonic (also by other HD wallets)?

It uses BIP32 derivation internally, so keys and addresses are deterministic. There is no seed phrase; you need to make a backup of its wallet.dat file.

  6) If someone for example gets access to your computer where your bitcoin core wallet is installed on, would this person be able to freely access the wallet and transact with it? What security mechanisms are in place for that scenario?

You can protect a Bitcoin Core wallet with an encryption passphrase. Nobody can send funds away without access to the passphrase. Note that there is no way to recover: if you lose the passphrase your coins are irrecoverably lost.

  7) How can you restore funds with bitcoin core when you lost your computer where the wallet was installed on? Which different recovery options exist?
  Is bitcoin core wallet compatible with this recovery mechanism listed in github: https://github.com/iancoleman/bip39

You restore the wallet.dat file from backup. No other options are supported.


Using mining pools, how do miners switch what coin to mine so quickly? Using mining pools, how do miners switch what coin to mine so quickly? Can someone explain?

Also do miners store a copy of the blockchain locally?

how do miners switch what coin to mine so quickly

This is called profit switching, and is usually implemented by the pool software. For example, NOMP explains this feature:

  Coin-switching ports using coin-networks and crypto-exchange APIs to
  detect profitability. Miner's connect to these ports with their public
  key which NOMP uses to derive an address for any coin needed to be
  paid out.

See https://github.com/zone117x/node-open-mining-portal

  Also do miners store a copy of the blockchain locally?

Typically, no. Miners focus their resources on the hashing algorithm and implement minimum necessary data transfer. Nodes store and validate the data and the miners will just get the latest block template from the node to mine, and then send solutions back.


Possible error in the white paper Calculations section? Section 11 presents calculations of the probability of double spending, P(z, q), given an attacker relative hash rate q and a block count z.

P(z, q) can only be understood by knowing exactly what z represents. From the Calculations section:

  The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value... [my emphasis]

Clearly, the transaction has one confirmation. The transaction "has been added to a block" and zero blocks have been linked after it. In other words, the transaction is hosted by the tip of the active chain.

Nevertheless, the probability of this transaction being double-spent is 100%, regardless of the attacker's hash power. In fact, the probability is 100% even with no active attacker.

This contradiction is reinforced by the equation Satoshi gives:

When z = 0, P = 1.0.

What am I missing?

There is at least one answer to this question that claims that z=0 means that the transaction is unconfirmed. That's inconsistent with the paragraph I quoted.

There appears to be an error somewhere in the Calculations section leading to a contradiction. I'm looking for an answer that either points the error out, or explains what I'm misinterpreting.

EDIT

One response offers the suggestion that Satoshi may have been talking about a Finney attack. In other words, the attacker has already pre-mined a block before attempting the double spend. Assuming the attacker can propagate blocks faster than the network, there would be a 100% chance of success. In this scenario, the attacker and network are tied at z=0, and given faster block propagation, the advantage goes to the attacker.

However, the Calculations section explicitly disallows a Finney attack. In particular, the attacker has mined no blocks prior to the attack:

  The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.

I believe at least part of the problem is mathematical. Specifically, Satoshi gives the value of λ as:

When z=0, λ=0.

Referring back to Satoshi's original derivation of double-spending probability P(z, q):

λ=0 means that every term is zero, independent of hash rate. In other words, the attacker can never double spend.

This contradicts the "rearranged" form of the equation, which gives a probability of 100% as noted above.

I'm no math specialist, but from what I can tell, the two forms of P(z, q) that Satoshi gives are not equivalent for z=0. In fact, they give the opposite answer:

in one case, the attacker always fails, P(z, q) = 0
in the other case, the attacker succeeds with 100% probability, P(z, q) = 1.

Either way, the attacker's relative hash rate doesn't factor into the analysis when z=0.

I realize that other treatments of this problem have appeared. For now, I'm just interested in fixing the apparent problem with the white paper's analysis for z=0.

Is this possible, and if so, how can I do that?

One way to interpret this is that there is, indeed, a mistake.

A more charitable interpretation is that there are two unstated assumptions:

The attacker is performing a Finney-like attack - that is, he has already pre-mined a block before even attempting the transaction. So while z=0 means the honest network has 1 block, so does the attacker.
The attacker wins propagation races. So if there is a leaf attacker block with the double-spending transaction, and a same-height leaf honest block with the original transaction, the attacker's transaction will be accepted.

Together, these give a 100% chance of success for the attacker if there is only 1 confirmation.

In my own paper on the subject, I have explicitly stated the assumption that the attacker already has one block (while removing a different simplifying assumption).


Is it possible to store data privately into the bitcoin blockchain? Given that Bitcoin is a public and permissionless blockchain, does this mean that any data stored in it will be free for anyone to see?

Is it possible to store documents such as screenshots etc.?

You can encrypt your data before you store it. However anyone would have access to the encrypted data and, if the encryption is broken (either now or in the future), the encrypted data will be revealed.


What does Bitcoin-Qt "Change Passphrase..." do to existing private keys and corresponding addresses? "Change Passphrase..." obviously lets me encrypt the wallet with a new string of text.  I think (correct me if I'm wrong) that this creates new private key(s) inside wallet.dat.

How are existing addresses affected when the passphrase is changed?

Are they still linked to the old private key (previous passphrase)?
If so, should I send those Bitcoin to myself (sending them to a new address that was generated after the change of passphrase)?

The wallet actually uses a randomly generated master key to encrypt the keys, and this master key is encrypted using your passphrase.

When you change the passphrase, all that changes is the encrypted master key. The actually encrypted wallet keys aren't touched at all.


bitcoind and rollntime support According to this page: https://en.bitcoin.it/wiki/Poolservers bitcoind's rollntime support is 'Supported, but not advertised'.  I am taking that to mean that it doesn't provide the X-Roll-NTime header that would advertise this support, but you can increment the ntime value to get extra nonce space and still submit found blocks after doing this.

Is this correct?  If so, what would be the max amount that a mining client can increment the ntime value?

If so, what would be the max amount that a mining client can increment the ntime value?

bitcoind will accept a block and push it out to the network as long as it is valid. Because of that, it's incredibly lenient. Quoting from bitcoin wiki:

  A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours

It almost never matters. Because bitcoind is a single-user mining program, it's almost always on the same computer as the mining agent. If the mining agent needs to get more work units, it doesn't use up extra bandwidth.


Difference between "time" and "mediantime" in getblock? For bitcoin-cli getblock, what's the difference between "time" and "mediantime"?

If i'm looking for a strictly increasing series of timestamps, is one better to choose than the other?

mediantime is better for your purpose. The timestamp is chosen by the miners, and has some restrictions on it such as it can't be too far in the future/past (no more than 2 hours into the future), but it is not strictly increasing. Mediantime, on the other hand, is. Mediantime is the median time of the past 11 block timestamps, and a block must have a timestamp greater than that median time, so the mediantime always increases.


What are some of the GitHub alternatives that you consider for Bitcoin Core and other Bitcoin related projects? Time for Bitcoin Core and other bitcoin related projects to look for GitHub alternatives?
Some of the issues:
https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/
https://twitter.com/lrvick/status/1320246266270519297
https://twitter.com/jonatack/status/1315623229747322880

A list of some GitHub alternatives is here.

GitLab
BitBucket
SourceForge
Launchpad
Google Cloud Source Repositories
AWS CodeCommit
Phabricator
Gogs (Self-Hosted)
Gitea (Self-Hosted)
Apache Allura (Self-Hosted)

This GitHub Repo Full Downloader written by Andrew Chow may also be of interest.
Discussion on whether to move from GitHub and where to move to should be had on IRC and GitHub rather than here. StackExchange isn't set up for discussions and conversations and it will get very noisy if everyone expresses a view here.


How could a bot purchase bitcoins without paying for them? An article titled "Researchers find that one person caused bitcoin to spike from $150 to $1,000 in 2013" (here) at CNBC discusses a paper titled "Price Manipulation in the Bitcoin Ecosystem" (here).

This article says about the paper that

  They found that a majority of the price manipulation happened due to
  two bots with "??" listed as the name of the user country. They named
  these bots "Markus" and "Willy."

  Markus bought and sold bitcoin at seemingly random prices and did not pay transaction fees. Upon further review, they found reason to
  believe that Markus was not actually paying for the bitcoins he was
  receiving. Markus acquired a total of 335,898 bitcoins and was
  active from February 14th, 2013 until September 27th, 2013.

On p.7 of that paper the authors wrote that

  In the end, we have concluded that Markus did not actually pay for the
  bitcoins he acquired; rather, his account was fraudulently credited
  with claimed bitcoins that almost certainly were not backed by real
  coins. Furthermore, because transactions were duplicated, no
  legitimate Mt. Gox customer received the at currency Markus supposedly
  paid to acquire the coins.

  Markus began buying bitcoin on 2013-02-14 and was active until
  2013-09-27. He did not pay for the bitcoins he acquired nor did he pay
  fees for the transactions.

I am mainly interested in how a duplication of transaction would lead to the seller not getting paid.

This is not explained in the paper as it mainly focuses on how the activity by the bots drove up the price of BTC at Mt. Gox and elsewhere.

Questions:

Isn't the purpose of the blockchain to avoid issues with transaction
integrity, such as duplicate transactions?
How would duplication of a transaction lead to the seller not
getting paid?

Isn't the purpose of the blockchain to avoid issues with transaction integrity, such as duplicate transactions?

Trades on an exchange do not happen on the blockchain. Those transactions are not Bitcoin transactions; they are internal to the exchange and are just updates to the exchange's internal database. Because of this, duplicate transactions could happen without anyone really knowing.

  How would duplication of a transaction lead to the seller not getting paid?

The balance in an exchange account is just a number in a database and is not necessarily backed by that amount of actual currency. I believe what the authors are saying here is that the buyers and sellers would have their balances updated to say that they had X amount of money, but if they tried to withdraw, the funds wouldn't actually be there so that they could withdraw.


What can be the reason to change transaction ID? I always thought that when my wallet create a transaction, it's transaction id is fixed (it is the SHA256 of the transaction message). Yes, the transaction might not be included in the next block (and can even be dropped completely) but if it will be included the transaction ID is fixed. Apparently this is not correct:

  Transaction IDs are not authoritative until a transaction has been
  confirmed. Absence of a transaction hash in the blockchain does not
  mean the transaction was not processed. This is known as "transaction
  malleability," because transaction hashes can be modified prior to
  confirmation in a block. After confirmation, the txid is immutable and
  authoritative.

Can anyone explain

the reasons why transaction ID can be changed?
Who can change this ID (I assume a miner who mined a block)?
What field in the transaction message can be changed to warrant the change of txId?

I think What is transaction malleability will answer most of it. But to summarize it in terms of your actual questions:

  the reasons why transaction ID can be changed?

Because someone can create another transaction (= different transaction message) that accomplishes the same thing as yours, while reusing your signatures.

The reason the signatures can be reused in a different message is because the signatures don't sign themselves. They don't sign themselves because that would require a dependency loop (the transaction message depends on the signature, and the signature signs the transaction message), which would be impossible to sign for.

The question is then what can be changed in a signature that doesn't invalidate it. The known ways for doing so are listed in BIP62 (which aimed to prevent some of them, but was retracted - it still gives a good overview).

  Who can change this ID (I assume a miner who mined a block)?

Anyone who relays your transaction (including miners), as they see your transaction but have the ability to produce a modified version and relay that one faster than someone else.

  What field in the transaction message can be changed to warrant the change of txId?

The scriptSig field in the transactions' inputs. It contains the ECDSA signatures, but also redeemscripts, public keys, and various other information needed to prove a spend was authorized.

With BIP141 (Segregated Witness), these issues are avoided by making the signatures not affect the txid anymore. Instead, they are stored in a separate field (called the witness) which is only necessary to prove a transaction's validity, and does not contribute to its effect.


Tracking incoming transactions using nodejs and own node I need to verify that user from my database has sent btc to my wallet.

Ideally I want to generate a unique address for each user transaction and then track all those addresses but I suppose it will be difficult to implement due to address gap limit, so I decided to just ask users for their bitcoin address and then expecting tx with funds transfer from that address to my wallet so I can verify funds were sent by them.

I have own bitcoin node which I want to use for tracking all the transactions to my wallet.

So let's say I want to track all txs just to my wallet address.

I was following the guide how to implement this with ZEROMQ. I've updated bitcoind config file with to can listen for raw txs via zeromq.
There are my nodejs code:

const bitcoin = require('bitcoinjs-lib');
const zmq = require('zeromq');

const sock = zmq.socket('sub');
const addr = 'tcp://127.0.0.1:3000';

module.exports = function (app) {

    sock.connect(addr);
    sock.subscribe('rawtx');

    sock.on('message', function (topic, message) {
        if (topic.toString() === 'rawtx') {
            let rawTx = message.toString('hex');
            let tx = bitcoin.Transaction.fromHex(rawTx);
            let txid = tx.getId();

            const address = bitcoin.address.fromOutputScript(tx.outs[0].script, bitcoin.networks.testnet);

            console.log("address ", address)
            console.log('received transaction', txid, tx);
        }
    });
}

As I understand, when I connect to node in live network from this code, I'll be notified about all txs that are happening in the network?

How can I validate transactions with transferring funds only to my wallet and decode address from which funds were transferred?

Are there some easy ways to implement this and maybe some code/project examples?

I was doing almost the same thing you need, to accomplish that I created a database with the addresses I wanted to monitor and keep track of them on the mempool of my fullnode which I could read the transactions and check each one of them if any of my addresses is there if it is I record the txid for further checking.
If the transfer gets confirmed before it is in my mempool (never happened to me) but the logic would simply be to check the block sent by ZMQ scraping all transactions and looking for any of the addresses.


settxfee: formula for fixed fee I want to set fixed fee rate for transaction. I calculated tx size which is 222( here is this tx), called rpc settxfee
$o->settxfee(sprintf('%f', (0.00001/222)*1000));

and sent to the network. I supposed fee would set for tx to 0.00001 but set to 0.00000662 TBTC instead. Here is wallet info  "paytxfee": 0.00004500,, seems  settxfee worked as expected. What do I do wrong?

Big disclaimer: you really shouldn't do this. Transaction prioritization works based on fee per size, so that's what you should be configuring.
As for an explanation of what you're seeing: the block explorer you're using is showing the wrong size. For fee computations what you need is the vsize, not the serialized size. This is the size that takes the discount for witness data introduced by BIP141 (segwit) into account.
The vsize of your transaction is 141, not 222.


Does miner's reward get added to blockchain Whenever someone makes a transaction it gets verified by the miners & after that it becomes the part of the ledger. So as a reward miners get a small amount of bitcoin. Now my doubt is the reward that a miner is getting for successful validation, it should also be added to ledger and needs to be verified by someone say 'new miner'. The new miner's reward should also be verified by someone else. And this process of verifying rewards will continue forever.

Is my understanding right or am I missing something?

The miner's reward is verified by every node (you referred to "someone else"). It gets rejected if invalid conditions are contained. The keyword here is "coinbase transaction", and it needs to follow the rules mentioned in the book. This coinbase tx goes into the ledger, if it follows the rules.

Source


Is wallet.dat transferable between OS? Am I able to transfer my wallet.dat from Ubuntu QT to Windows QT by backing up the file and pasting in the other operating system?

Yes. There is nothing OS-specific in wallet.dat file.


0 active connection to bitcoin network (testnet) I am working with the testnet. I downloaded the bitcoin-core application on Linux and I am running the version Bitcoin Core version v0.12.1.0-g9779e1e (64-bit) I was able to download the bitcoin block, recently its no longer syncing with the bitcoin network. Its showing 3 days behind and 0 active connection to the bitcoin network. How can I fix the issue. I want to connect to the testnet. I tried to change the network settings in the application. Still its not working.

This worked for me:

addnode 185.28.76.179:18333

This "well connected testnet node" was suggested to me here.


OP_CHECKLOCKTIMEVERIFY / OP_HODL script Can someone please explain how I can use OP_CHECKLOCKTIMEVERIFY or OP_HODL to lock funds until block 600000? I have been searching for a newb friendly script but the only ones I have come across is for nLocktime

I took this from Andreas' book "Mastering Bitcoin" (2nd edition, page 158ff):

  To lock it to a time, say 3 months from now, the transaction would be
  a P2SH trans‐ action with a redeem script like this:

[now + 3 months] CHECKLOCKTIMEVERIFY DROP
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

  where  is a block height or time value estimated 3
  months from the time the transaction is mined:
  current block height + 12,960 (blocks) or current Unix epoch time +
  7,760,000 (seconds).

The problem is that we are currently at ~506000 blocks, so if this should be a block height, and not a time range, it must be ~94000 blocks in the future.

  CLTV and nLocktime use the same format to describe timelocks, either a
  block height or the time elapsed in seconds since Unix epoch.
  Critically, when used together, the format of nLocktime must match
  that of CLTV in the inputs—they must both reference either block
  height or time in seconds.

  If nLocktime is nonzero and below 500 million, it is interpreted as a
  block height, meaning the transaction is not valid and is not relayed
  or included in the blockchain prior to the specified block height.

So in your case it must be:

94000 CHECKLOCKTIMEVERIFY DROP
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

You could achieve the delay also with nLocktime, then the tx is not put into the blockchain before the block appears (I think the tx stays in mempool), but with the CLTV it goes directly into the blockchain (is visible in the blockchain), and can only be retrieved after block height  is reached.


No information available about transaction I transferred all of my 0.0105 BTC in one address to “1Px92t3MBmZcMfomZmt2BKqaaWHRp2y7fQ” through Bitcoin Core. There are two transaction records as following:

Details are:

  Status: 9 confirmations

> Date: 2016/12/3 19:30

> Debit: -0.01036619 BTC

> Net amount: -0.01036619 BTC

> Transaction ID:
  e71a265559886a784b242a77d952f58821deada04c547d26b61032ee4f8f5360

> Output index: 0

  Status: 10 confirmations, broadcast through 6 node(s)

> Date: 2016/12/3 19:19

> To: huobi 1Px92t3MBmZcMfomZmt2BKqaaWHRp2y7fQ (watch-only)

> Debit: -0.01036619 BTC

> Credit: 0.01036619 BTC

> Total debit: -0.01036619 BTC

> Total credit: 0.01036619 BTC

> Transaction fee: -0.00013381 BTC

> Net amount: -0.00013381 BTC

> Transaction ID:
  9ff577cea7b86667eaea93084b4fb7ed75a5ed6d14bdc6e0557ca8fdc55efb82

> Output index: 0

Two questions:

FIRST
Why there two transaction records and one of them with type “Payment to yourself”? My balance is 0 now.

SECOND
getrawtransaction

  9ff577cea7b86667eaea93084b4fb7ed75a5ed6d14bdc6e0557ca8fdc55efb82 1

results: No information available about transaction (code -5)

  What does the transaction
  9ff577cea7b86667eaea93084b4fb7ed75a5ed6d14bdc6e0557ca8fdc55efb82
  represented?

looking at blockchain.info, your first spent to this address was done at 2016-DEC-03 11:19:29 CET, amount was 0.01036619 BTC. This is what is shown in your picture above. You can look at the raw TX here: 9ff577ce...c55efb82
Later on there was a second TX: e71a26555...f8f5360
Both TX are confirmed. All good.
Not sure if I got your question right, on the payment to yourself. Usually if you spend bitcoins, they come from UTXOs, and if a value doesn't exist, the wallet will try to combine several UTXOs to near the desired value. The remainings go back into your wallet. It is like buying something for 9 Euros, you pay with a ten Euro bill, and get 1 Euro back to your wallet.


How to create more ripples? What is the exact procedure for creating more Ripple currency units (XRP) in excess of the default 100 billion that already exist?

There is no such procedure. While OpenCoin could accomplish it today by changing the code to create such a thing, in the future, the procedure would be as follows:

Propose some kind of change that would create more XRP.
Assign it a 256-bit ID. (It can be arbitrary.)
Release patches that support this change, and announce their support for this ID.
Get 80% of validators to run your patches.
Wait out the two week waiting period for new feature enablement (to give a chance for review and vetoing).
If 80% of validators (weighted by trust) still run your patch, the feature will enable itself and then you can create more XRP. Alternatively, you could try to convince about 50% of validators (weighted by trust) that your patch is so urgently needed that the normal supermajority delay process can be bypassed.


What came first, transaction or mining? I have been thinking for a while and can't really figure this out..

From my understanding, in Bitcoin network, 'bitcoins' are created when a miner successfully mines a transaction. So this means in order for the network to create a bitcoin, there has to be something to be mined and that something is transaction.

But what I also read, the first transaction was from Satoshi to Hal where Satoshi transferred 10 BTC to Hal. How is the possible since to create 10 BTC, they had to do mining previously which can only be done on previous transaction which makes this transaction not first.. Circular.

Or is it the genesis bitcoin was created without mining? Could be the case, but I am not able to find a reference to that.

Mining was first, as you say, there had to be bitcoins to transact which must have come from mining blocks. The key is, that blocks can be empty. Most early blocks were. And even some blocks now are mined empty, e.g. this one: https://blockchain.info/block/0000000000000000005afd87cdbb34e8126674766c261619044c4c213286d72b

Blocks always contain a Coinbase transaction which pays the reward to the miner regardless of whether there are any other transactions to mine or not.

The incentive for miners to include other transactions in blocks rather than leave them empty is the transaction fees.


How do transactions get to miners? How operations from exchange and other ways of transferring bitcoins goes into 'system' (mining people)?

Computers running the Bitcoin software pass transactions from one to the other to rapidly distribute new transactions throughout the network. Miners accumulate transactions from the network to put into blocks that they mine.

If you go to blockchain.info you can see new unconfirmed transactions scroll by on the bottom left.


How does Bitcoin Core know the progress of blockchain without connecting to peers? I restarted my Bitcoin Core node after a gap of about a day and when seeing the console log, I noticed that it calculated the progress of my blockchain even before  connecting to peers. The log information is pasted below. If you look at the last line, it says the progress=0.999577.

2020-02-03T09:02:15Z init message: Loading banlist...
2020-02-03T09:02:15Z Cache configuration:
2020-02-03T09:02:15Z * Using 2.0 MiB for block index database
2020-02-03T09:02:15Z * Using 8.0 MiB for chain state database
2020-02-03T09:02:15Z * Using 390.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2020-02-03T09:02:15Z init message: Loading block index...
2020-02-03T09:02:15Z Opening LevelDB in C:\Users\ugamk\AppData\Roaming\Bitcoin\blocks\index
2020-02-03T09:02:15Z Opened LevelDB successfully
2020-02-03T09:02:15Z Using obfuscation key for C:\Users\ugamk\AppData\Roaming\Bitcoin\blocks\index: 0000000000000000
2020-02-03T09:02:21Z LoadBlockIndexDB: last block file = 1951
2020-02-03T09:02:21Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=79, size=71688771, heights=615600...615678, time=2020-02-02...2020-02-02)
2020-02-03T09:02:21Z Checking all blk files are present...
2020-02-03T09:02:21Z LoadBlockIndexDB(): Block files have previously been pruned
2020-02-03T09:02:21Z Opening LevelDB in C:\Users\ugamk\AppData\Roaming\Bitcoin\chainstate
2020-02-03T09:02:22Z Opened LevelDB successfully
2020-02-03T09:02:22Z Using obfuscation key for C:\Users\ugamk\AppData\Roaming\Bitcoin\chainstate: f5c820df867e2ff2
2020-02-03T09:02:22Z Loaded best chain: hashBestChain=000000000000000000034ff79a0c7ec61ea44e59514172d2a8d83033aaf9416b height=615678 date=2020-02-02T17:29:57Z progress=0.999577

I was appalled because my node hadn't connected to any peers until this point of time. The only reasonable explanation in my opinion is that Bitcoin Core calculates the "estimated" progress assuming 10 minute block time and when it last received the block. Is my assumption correct, or is there something else that allows Bitcoin Core to know the progress.

The progress number is the ratio between the total number of transactions in the active (validated) chain, and the expected total number of transactions at the current point in time. The latter is estimated based on statistics that are hardcoded in the Bitcoin Core source code, and updated every major release.

For example in version v0.19.0, the source code, you find:

chainTxData = ChainTxData{
    // Data from RPC: getchaintxstats 4096 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf
    /* nTime    */ 1569926786,
    /* nTxCount */ 460596047,
    /* dTxRate  */ 3.77848885073875,
};

Which implies that at timestamp 1569926786 (Tue Oct  1 10:46:26 UTC 2019), the total number of transactions in the chain was 460596047. After that point in time, 3.7785 transactions per second are expected.

The total number of transactions at present is then estimated as:

If last_block_time < nTime, (current_time - nTime) * dTxRate + nTxCount
If last_block_time > nTime, (current_time - last_block_time) * dTxRate + last_block_total_tx_count


Where do I get my username and password for solo mining? I downloaded Bitcoin-Qt and synched.  I downloaded pyminer to help me understand the mining process.  But I need a username and password.  Where do I get them for solo mining?

You just make them up. They just need to match on both ends (the bitcoin program and the mining program).


So I closed my wallet in MultiBit and there isn't a trace of my wallet I've looked through every file imaginable and I can't find the Wallet I had all my bitcoin in. I'm about to faint, you have no idea how much money I just lost. I'm trying my best not to curse up a storm in here, but I don't see the wallet anywhere, i'm beyond angry right now. Can anyone help? Please?

See here first,
https://multibit.org/en/help/v0.5/help_troubleshooting.html,
Then here,
https://multibit.org/en/help/v0.5/help_support_missingWallets.html

Also, has been asked previously,
Closed wallet in MultiBit, is it gone for good??


Who made the weusecoins intro video? I really like the weusecoins.com introduction video. Who made the video?

It explains very clearly what bitcoins are, how it is different from other money, and how you can buy and sell bitcoins. They did a great job.

If you would pause the video a couple seconds from the end, you could see that the voice is done by Chris Rice, motion graphics by Fabian Rühle, music and sound design by Christian Barth, and production by Stefan Thomas.

Also, if you check the Active Bounties page on Bitcoin Wiki, you will see that they made 13622.05 BTC doing it (although it was back when Bitcoins were quite cheap in comparison to what they are now).


How do I find out the miners fee for my transaction using Blockchain.info API? Blockchain.info gives you the options of 'frugal', 'normal' and 'generous' for setting miners fees and leave it slightly vague as to what the transaction fee will ultimately be.

I want to use their Make Outgoing Payments API to send payments but how can I know what they choose as a transaction fee?

What if I have 0.01 BTC in my wallet and want to send it all to an address. There won't be enough BTC left over for a fee. What happens then?

There really isn't a standard fee value. Various clients implement different amounts. For example on my MultiBit installation it's currently set to 0.0001 BTC per 1000 bytes of transaction size.

You must include a fee otherwise miners won't confirm your transaction.

For Blockchain.info's case, using their API, if you don't have the $fee parameter, Blockchain.info will automatically add 0.0005 BTC in fee, which is the default value.

  All transactions include a 0.0005 BTC miners fee.

So if you send 0.01 BTC with their API, and don't specify the $fee parameter, it will add a 0.0005 fee to your transaction.

EDIT This means you actually need at least 0.0105 BTC (0.01 + 0.0005) in your wallet to make the transaction. If you want to send all of the 0.01 BTC, you have to actually send 0.0095, otherwise the transaction won't go through.


How to determine if a remote node prunes? Is there a way to determine if a remote full-node prunes its blocks (i.e., if it doesn't store the entire Bitcoin blockchain)?

Yes. The client unsets the service bit NODE_NETWORK when pruning.

You could also try to request a block.


how fast does a Sapphire R9 280X Varpor-X Tri-X can and how can i calculate the bitcoin i can have pers day? as above i'm wondering that how fast (mh/s) can a R9 280X can and how can i calculate the bitcoin i can have per days because i'm newb to this mining

Hashrate for the Saphire can be found here:

https://litecoin.info/Mining_hardware_comparison

Don't bother GPU mining, especially for SHA-256 (bitcoin). You can blow one of those out of the water with a $20 used USB ASIC on ebay. The days of casual mining are over, you will be operating at a loss unless you have some of the cheapest electricity in the world and a large mining setup.


Is it possible for some one with huge computing power to disrupt Block Chain? Is it plausible for some kind of anonymous organization having huge computational resources to attack on block chain by re-building entire block chain within the time frame of next block to be published and gain control over the currency.

I don't think the premise of the attack (rebuilding the entire blockchain within the time of one block) is necessary. If someone wanted to rebuild the entire blockchain, they could take, say, a year to do it, which would considerably reduce the computational requirements. Of course more blocks would be created during that time, so they would need to catch up at the end, but that would be much easier than re-creating the whole blockchain in 10 minutes.

The other thing they could do is start in the middle of the blockchain (unless you have a good reason for redoing the entire thing), which would also reduce the computational requirements. Or is the idea of rebuilding the entire chain that they would control all the bitcoins?

I think it would be reasonable for a three letter agency to build enough ASICs to have well over 51% and take over mining. (They could have enough capacity right now hidden in pools, waiting until they need to take control and nobody would know. And the hardware would pay for itself.) But rebuilding the entire blockchain would require an implausible amount of hardware for little benefit.


bip 32 wallet with openssl i want to use a hierarchical deterministic (bip32) wallet but i'm a bit put off by a lot of the libraries which use different ecdsa libraries to the core bitcoind client. for example pycoin uses a natively implemented elliptic curve library, bip32utils uses python's ecdsa library (i think).

while i'm sure these implementations work extremely well, i'm worried that there may be some rare edge cases where they diverge from openssl's ecdsa implementation.

are there plans to implement a deterministic wallet in bitcoind?
are there any bip32 wallets which call already-existing-functions in bitcoind wherever possible?
if not then what level of risk is involved in using bip32 wallets which rely on non-openssl ecdsa libraries?

p.s. i get that openssl's implementation of ecdsa is also not perfect, but it seems to me that consistency (even to the point of reproducing a bug) is crucial with bitcoin.

You would be best off using something that links to libsecp256k1 than openssl, which is in the process of being dropped in Bitcoin Core due to endless security concerns anyway. I'm not aware of any that do, but I will update this answer if I find any.

  are there plans to implement a deterministic wallet in bitcoind?

Possibly, there's currently some planning going on with this, its at least likely that the current wallet will be deprecated and replaced with something more separate from the actual daemon. The current wallet is very heavily tied into the client in a lot of places, and has some massive dependencies like BerkeleyDB which are completely overkill for a key value store.

The current train of thought and some code is partly mixed into the bitcoin-dev logs and also on github. You shouldn't be using any of this with real money though, it is likely to be unstable for a long time.

  are there any bip32 wallets which call already-existing-functions in bitcoind wherever possible?

None I am aware of, most wallet software currently developed is either built on BitcoinJ (which numerous privacy and security considerations), querying some remote service (privacy and massive security issues), or something home brewed. Generally key management through JSON-RPC is pretty awful so that is somewhat understandable.

  if not then what level of risk is involved in using bip32 wallets which rely on non-openssl ecdsa libraries?

It's good you're thinking about this sort of thing to begin with.

Depends on the library, but the worst possible outcome is that a software implementation bug causes all of your money to be lost or stolen. This isn't unreasonable to suggest, and it happens almost constantly through the history of Bitcoin. Blockchain.info rolled their own RNG and has lost funds on a number of occasions due to it, Mt Gox wrote their own wallet and lost a pile of money when a function errored out and they sent their money to the pubkeyhash null, Bitcoin Armory found the ECDSA code they used leaked private keys through the signature. There's bound to have been more mistakes but these are the ones that have been made public.

Pretty high levels of risk, really.


Blockchain.info - generated addresses & the blockchain I am generating new addresses with the blockchain api and sending funds to them from a primary blockchain.info address. Just wanted to know if those transactions will appear in the blockchain or are they internal to blockchain.info?

Thanks

Yes, all transactions to and from blockchain.info wallets will be recorded in the blockchain.  blockchain.info does not control their customers' private keys, making it impossible for them to perform offchain transactions.  In contrast, Coinbase uses internal accounting for transfers between Coinbase accounts.


Is it possible to shorten the blockchain? I've been doing some research into Bitcoin and the blockchain in general, and I've come upon a question that I can't find much of an answer to.

With my current understanding of the blockchain, I wonder if it would possible to create a "summary" block, and start the chain over? reducing its size while still maintaining continuity.

The summary would have the hash of the last block in the old chain.
For length calculation, it would be considered an extension of the old chain, and therefore its length calculated by adding its length to that of the old chain.
I'm thinking that it would need to contain a summary of all accounts at the time of the summarization; essentially it would be the net of the old chain.

I found this question from five years ago, which helped a little bit.

This article states that the current size of the blockchain is over 100GB, and thats from 6 months back.

I'm just trying to learn, and this question has been bugging me for a little while. Is something like this possible?

it is not possible, because there is no consensus rule who, how and when should do it and how sould others accept "new genesis" block


Why does Bitcoin Core not let met change the label for "requested payments"? I created a receive address, entered "fdjdsgudhsgudfhgfhdgf" without thinking about it (I was going to describe it properly later) and sent coins to it from a different wallet.
Then I later changed it to "Accurate description blabla" in the "Transactions" tab, which it allowed me to do. Then I looked in the "Receive" tab and saw that it still had the stupid gibberish label there. So I went to change the label... only to realize to my horror that there is no way to change the label there, once created... ?!
Please tell me I'm hallucinating or missing something. I'll forever be annoyed by this if I'm somehow forced to keep that "fdjdsgudhsgudfhgfhdgf" label. Especially as it's now renamed in the "Transactions" tab...

I think what you are looking for may be:
In version 0.21 Open the Windows menu and choose Receiving Addresses

In older versions you had to open the File menu and choose Receiving Addresses

then right-click on any unwanted label and choose Edit.


How balances are calculated? Is it the case that the blockchain has information on the balance associated with each public key-address, such that the client on my PC, say, will look at every public/private keys pair in wallet.dat, find all public keys in the blockchain for each of my private keys, sum up the balances for each, and show me the overall balance?

The Bitcoin-Qt/bitcoind client computes the balance as you describe, by summing up all the transactions for all the Bitcoin addresses in the wallet.dat.

The blockchain contains all transactions since the genesis block (block 0).  So the balances are simply all the unspent transaction outputs (UTXOs).

There are third party services which will monitor the blockchain to provide balance info for a specified address or addresses.  BTCBalance.net is one.


How can the segwit witness data be "off-chain"? What does it really mean? I have several questions regarding the segwit witness data. My current understanding is as follows.
Before segwit, the witness data was part of the input that the user had to provide so that they could spend an UTXO. The witness data is the digital signature or any other solution that allows an UTXO to be spent. The input was not comprised only of the witness data, but the witness data could be a large part of the input.
Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-chain". This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.
My questions are:

Is my understanding above correct?

What do we mean when we say that the witness data is "off-chain"? If it's not part of the blockchain, where does it reside? Does it mean that nodes process witness data differently from the rest of the input data?

While I understand that the input itself is now lighter, the user still has to provide the witness data in order to spend the UTXO. Wouldn't the witness data need to be relayed alongside the rest of the input so that nodes can make sure that the transactions are valid? How can there be a gain of efficiency?

No, that's not accurate. Witness data is on-chain, inputs have a similar byte length as before (they are just weighed differently), and the transaction throughput is increased because segwit is a defacto blocksize increase.

Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-chain". This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.

This is a common misunderstanding perpetuated by an abundance of (sometimes deliberately) confusing descriptions of how segwit works.
A transaction is not complete without the proof that it was authorized by the owner of the spent funds. As such, the witness is explicitly part of a "complete transaction". What segwit did was to segregate the witness (read "signature") out of the input script and move it to the "witness section" of the transaction. The witness section is at the same hierarchical level as the inputs and outputs.
The witness section is excluded when calculating the transaction id (txid), but it is part of the transaction, and used to calculate the witness transaction id (wtxid). While the merkle root in the blockheader commits to the txids of the included transactions, each segwit block additionally commits to a merkle tree of the transactions' wtxids. In conclusion, the witnesses are a) part of the transaction, b) part of the blockchain, c) necessary to fully validate the blockchain.
Segwit replaced the blocksize limit with a blockweight limit. The blocksize was based on the raw byte length of transactions and capped at 1,000,000 bytes. The blockweight limit is capped at 4,000,000 weight units, where weight is calculated by counting witness bytes with a factor of one, and non-witness bytes with a factor of 4. This happens to result in an equivalent limit if a block only includes transactions without witness data.
The actual transaction data of a segwit input compared to a non-segwit input is only marginally smaller. It is the discount of witness data that allows blocks to exceed the previous blocksize limit, making segwit an effective blocksize increase with the biggest block to date having 2,422,858 bytes (but 3,993,379 weight units).
Segwit transactions and blocks are made forward compatible to pre-segwit nodes. Segwit nodes will strip the witness data before relaying the data to pre-segwit nodes. The stripped transactions and blocks are non-standard but valid according to the pre-segwit protocol rules, and thus pre-segwit nodes can follow the blockchain and converge on the same UTXO set.
Note that pre-segwit nodes have not been "fully validating nodes" since segwit was activated on August 24th 2017 as they do not unilaterally enforce all consensus rules of the Bitcoin protocol.


How does Sentinel check Blockchain? I've been very happy to hodl my Bitcoin on a paper wallet (coinglacier.org) and using Sentinel to view the balance of my addresses (using extended public key).

Sentinel is an awesome app, it provides just what I need and is very user friendly!

However, recently I was wondering, whether Sentinel was a privacy leak for me or not. So how is Sentinel scanning the Blockchain for incoming transactions? Is it using SPV, or is it just connecting to a server from Samourai, in a way that Samourai can tell which addresses I am looking after?

“Sentinel” is just an interface to an API owned by Samourai Wallet. It therefor leaks the fact that you own the outputs you’re watching are probably offline storage (and links them together into one wallet) when you watched them, and your connection details like your IP address and probable physical location.


Why is my new altcoin trying to connect to peers and sees almost 200k blocks remaining? I downloaded and forked the Blackcoin source code. I changed all of the references to BlackCoin, changed the pszTimestamp string along with the current Unix timestamp. Then, I successfully mined the genesis block and put it, along with the merkle hash and the nNonce into the source code and recompiled.

My wallet loads up just fine. The problem is, it says it ha 16 active connections to the network and sees 193k blocks it needs to download. In the debug.log file, theses are all orphan blocks. Also in the debug.log file, it is showing that it is trying to connect to what I assume are built in nodes somewhere in the BlackCoin source code. I cannot find these for the life of me.

How can I change this so that my coin knows the correct blockchain?

Thanks.

Every coin has some defined set of seed servers it can to connect to in order to build up the initial list of peers.

See:

static const char *strDNSSeed

in

https://github.com/ralphtheninja/blackcoin/blob/master/src/net.cpp


mtgox max bid higher than min ask caling getDepth.php I stumbled on some data that contains bids that are higher than asks. That can be seen in orderbook data with the following unix timestamps (for getting human readable date use $date -d@[unixtime]):
1325249854
1325249914
1325249975
1325319825
1325441984
1325545019
1325595982
1325597938
1325625735
1325645568
1325660473
1326656827
1328089365
1328089676
1328089737

So does MtGox stream "orders as arrived" without any processing or is this some kind of anomaly? From 6. 2011 till 9. 2012 with about 3min resolution I counted around 300 instances of such anomalies. Any thoughts on what could be going on? Is this common for other exchanges?

I would say that the depth feed you are reading is of the orders coming in, before they are matched.

Those orders would feed into the matching engine which would make fair trades off those orders.

It is not possible to or desirable to make an optimal trade at any given instant. this can be due to network latency (etc)  and because someone might think it would be better to make a trade, that was slightly less than optimal, than to miss out on making a trade (but still not too much up or down);

For example:
What you will probably find is that if you put in an order to buy 10 btc at $100 but someone else has put in a sell order for 10 at  $99 you order will convert to a trade of $99. The buyer and the seller both get what they wanted.

Like wise if one seller was willing to sell 5 btc at $95 and someone else was willing 5 btc at $100 you would end up with 2 partial fills to complete the trade.

Back in the day on stock markets (i.e., not btc) the exchange (or broker) would just pocket the difference. However this doesn't really happen much now (in my understanding) as the markets are more efficient (fast traded data feeds & order placement + high liquidity)

At the end of the day both buyers and sellers get what they want, and because there is reasonable liquidity, speed and fast access to market information, people will not be making trades which are too different from what would be optimal.


How to return Bitcoins to sender through Bitcoin API? I want to get information about the creator of a given transaction through Bitcoin API. More specifically, any or all addresses they sent their Bitcoins from, so I can return some of the money back. Is it possible to do using just the JSON RPC, or do I have to rely on external sources (such as the Block Explorer)?

If the address is in your wallet, gettransaction includes the input addresses:

http://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

If this is done by an agent where the addresses might not be in the wallet, v0.7 getrawtransaction gives you access to those transactions.

http://en.bitcoin.it/wiki/Raw_Transactions

There are other tools that you can use to build this capability as well.

libBitcoin
Armory (see Extras)
Bitcoin ABE


How to file bitcoin income to the IRS as a nonresident alien I am a Chinese student in US right now, and my taxation status is Nonresident Alien.

Since IRS has announced bitcoin as "property", I just wonder how to define my gains from my sell of bitcoin in US. My husband bought bitcoin on Chinese website by RMB and I sold them on coinbase to get USD.

According to IRS's explanation, is the money I gained from coinbase "US source property gains"? If so, how to calculate the gains? Does IRS accept transaction records from Chinese websites? Some of the websites even went bankrupt already.

It's my first time to file my taxes in US, I really don't want to cause any trouble. Thanks!

The analysis is the same as for other property.

You only need to report income that is effectively connected to the US or that is fixed, determinable, annual, or periodic (FDAP).  So while you would need to report a US-sourced scholarship grant or wages from working in the US, you do not need to report a foreign transaction.

If the transaction was a foreign person abroad (your husband) buying and then selling from foreign people, and the property was not located in the US (this is mostly about real estate), then you should be quite safe not reporting it.  The fact that he sold it for USD does not make it reportable or taxable in the US.

Please review Publication 54 if you have further questions.


Current blockchain hot topics in research I'm looking for a research project for my master thesis in software engineering and computer science and i'm willing to research the blockchain technology. What are the current open issues and/or hot topics regard blockchains?

EDIT: I can see my question is way too generic, i just wanted to specify i read about 20 papers on the topic and i'm more concerned about the dencentralization aspect of it.

I think it's scalability. The cost to generate a block is getting more and more expensive. Couple months ago, CryptoKitties caused Ethereum network congestion due to the surge of transactions. For real world application, I think blockchain must be able to handle high volume of transaction. This can be achieved by reducing the cost to generate a block. AFAIK, some blockchains are developing proof-of-stake algorithms replace the old proof-of-work one.

You may interested in Ouroboros proof-of-stake algorithm, which is implemented by Cardano. Ethereum is also working on their own implementation - Casper


Lost/forgotten/locked Bitcoins There are currently ~16 million bitcoins in circulation at this moment. There will only ever be 21 million coins. What about all the coins that have been locked in wallets due to loss of keys, owners of wallets dying, etc...?

The number of lost coins is probably fairly small now but if Bitcoin is going to be relevant for who knows 100, 200 or 300+ years, this number will increase. I guess the reduction of "usable" coins will increase the price per coin and the majority of coins won't ever be lost so this not a significant issue.

Are there any solutions to lost coins or is this just a feature of the decentralized network?

What about all the coins that have been locked in wallets due to loss of keys, owners of wallets dying, etc...?

There is no way someone can tell you the exact amount of "locked" bitcoins. Even after looking into blockchain and building the system of how often bitcoins move from one wallet to another. There are many people who have bitcoins and sitting on them for many years, but still have the access and can use them anytime they want (it can be considered as lost bitcoins, but it's not). So it will be impossible to track how many bitcoins are lost "forever" by users.

Are there any solutions to lost coins or is this just a feature of the decentralized network?

There is no current solution and I'm not sure there will be one. Bitcoin wallets/storage services improve their security and adding more and more features to recover your keys, passwords, etc., but it has nothing to do with those people who lost it long time ago.


How does the bitcoin core protect against initial DNS seed changes? While the bitcoin network is essentially P2P, one still needs to identify an initial node to connect to. I understand that a method for such initial connections is connecting to known DNS seeds, e.g seed.bitcoin.sipa.be. If a malicious actor were to, hypothetically, redirect this "link" to a seed that points to a different network, where, for example, he has 51% majority, could any damage be caused by this ?

Generally there's some discussion about attacks against the bootstrapping of Bitcoin Core, but there's not a whole lot in terms of being able to defend against it. Fortunately the DNS seeds are only really used on the first launch of the software, the rumoring of peers within the network is used for all subsequent connections.
There's not a whole lot that could be done with gaining this sort of access without a lot of cost beyond just subverting DNS seeds. The clients have an idea of the total amount of work needed for the chain to be valid, so won't be fooled by an entirely new blockchain that has no connection to the real one. Mining with a low hashrate at the tip of the real blockchain is not possible either due to there being a maximum amount the difficulty can drop in each period; you can't simply mine 2 weeks worth of blocks and have the difficulty drop to nearly zero.
Ideally we'd now have the DNS seeds, but the risks they introduce are manageable, the bootstrapping issue isn't unique to Bitcoin, it's something that all P2P networks need to contend with to some degree.


Why is the witness data fee discounted by a factor of four? I've read that it encourages users to consolidate UTXO sets. How would it be doing that?

Witnesses do not need to be stored once they have been verified and can be discarded. This effectively reduces the size of the UTXO. The discount is supposed to account for the reduced storage requirements and to encourage users to switch to segwit, benefiting the network as a whole.


Who takes the decisions of "hard-forks" in the Bitcoin community? I understand that there is no central authority on Bitcoin, but I can't understand who takes decisions on "forking" the blockchain.

Here it was mentioned that the "Bitcoin community voted"—how did that happen? Who is the community? I assume anyone? If so, how can one vote?

I was reading about a hard-fork coming on 16th of November and I don't really understand how that works.

No-one decides literally for everyone. Miners make the decision to exploit one proposal rather than another one, so whenever miners disagree and don't follow one protocol to around 100% then a fork happens.

In this case (of B2X) it is the proposal of Segwit2x that will or will not be followed.


Does the nonce have to be a number? Since we're just trying to produce a specific hash output, couldn't the nonce also include letters or otherwise random bits?

The nonce is an arbitrary string of bits with no particular meaning. Typically they are converted into an unsigned integer for convenience. Every possible set of nonce bits has a corresponding integer in this representation.

To get letter in a nonce, you'd have to present the bits in the nonce in some encoding scheme that had some way to encode letters. There is no such scheme in common use.


How to turn off "change" address in bitcoind? I would like to keep backup of my wallet on paper, but that's impossible or at least impractical when the bitcoind keeps creating new addresses for "change". I know it is possible in theory to do it by sending the change back to the sending address. And I know there are privacy implications when doing this. But I care more about security than anonymity in my case.

Is there an option to turn off "change" addresses in bitcoind (the original Satoshi client)?

Bitcoind isn't designed for that. There isn't option for that and probably won't be. If you are interested in keeping paper backup, you should look at clients such as Electrum.


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

What values have actually been seen in the blockchain?

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

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

  What values have actually been seen in the blockchain?

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


Some newbie questions about bitcoin transactions and anonymity I am totally new to the Bitcoin thing and have installed Electrum yesterday after having read a lot of reviews on different local wallet options. I am not really planning to use it yet, but I want to learn the thechnology.

I am still a little confused regarding some things. The questions are below.

1) After having installed Electrum I go to the Recieving tab in the GUI. There I can see some different addresses. Can I publish them all to the public to get payments?

2) Are these addresses static? That is, will I have these addresses forever to receive payments and I guess multiple people can insert bitcoins multiple times to the same address?

3) Actually, from an anonymity perspective, what is the difference between having several receiving addresses in one wallet to get payments and multiple wallets with one address each?

4) If one would be totally anonymous when getting and making payments (let´s say person A will get payment from B and then A will pay C), is this a correct way to do it and still become anonymous:

   a) install a local wallet with `tor` support (Electrum for instance)
   b) connect to the `tor` network and give one of the receiving addresses to person B
      so he or she can make the payment
   c) Go to the Send tab and send to person C.
   When the transactions are done, close the wallet and disconnect from tor

1) After having installed Electrum I go to the Recieving tab in the GUI. There I can see some different addresses. Can I publish them all to the public to get payments?

Yes, these addresses are meant to be "published" to other parties who will send you payments

  2) Are these addresses static? That is, will I have these addresses forever to receive payments and I guess multiple people can insert bitcoins multiple times to the same address?

Electrum is an HD wallet which means it generated its addresses in a deterministic way so as long as you keep your seed phrase in a safe place you will be the owner of these addresses. Reusing addresses without a good reason is generally discouraged.

  3) Actually, from an anonymity perspective, what is the difference between having several receiving addresses in one wallet to get payments and multiple wallets with one address each?

Having multiple wallets with one address each is a huge overkill and improves nothing in terms of anonymity, it will only make it easier for you to get lost amongst your wallets, not being able to use the bitcoin network the way it is supposed to be used and eventually lose some funds.

  4) If one would be totally anonymous when getting and making payments (let´s say person A will get payment from B and then A will pay C), is this a correct way to do it and still become anonymous:
     a) install a local wallet with tor support (Electrum for instance)
     b) connect to the tor network and give one of the receiving addresses to person B
        so he or she can make the payment
     c) Go to the Send tab and send to person C.
     When the transactions are done, close the wallet and disconnect from tor

I suggest you take a look at these wiki entries: Anonymity, Protect your privacy.


Did the FIBRE protocol reduce the occurrence of chain forks? I've just learned that Fibre protocol is used for really fast block propagation. My understanding is that if blocks are propagated faster, miners can more quickly continue to work on (what seems to them) the head of the chain, there is a lower chance for temporary forks to happen and even if they occur, they are likely to be short (small length). Please correct me if I got that wrong. That leads me to two questions:

Is the Fibre protocol the reason for rare temporary forking?
Is the Fibre protocol also the reason why mining difficulty is pretty much the same across the network (I assume it's the same, otherwise it would be problematic, right)? If difficulty changes after 2016 blocks on average and block propagation is fast, everyone can adjust their mining difficulty pretty easy and there wont be much difference inside the network (most of the nodes will up to date)?

Is Fibre protocol deserved for rare temporary forking? If blocks are propagate that fast, there are less chances for temporary fork to happen and even if it do, they are short (small length)? Miner can fast continue to work on (what it seems to him) block head of the chain?

Well the point is that a miner can more quickly switch to a new block that has been found on the network. The time a miner spends on building on top of block A, while a block B has already been found by someone else, is very likely a waste of money and energy.
Note that this is not just in the interest of the miner, but of the entire network: a hypothetical 51% attacker is not subject to these losses, as they only build on top of their own blocks. Thus, faster propagation of blocks on the network means that this advantage 51% attackers have over honest miners is reduced.

Is Fibre protocol deserved why mining difficulty is pretty much the same across the network (I assume it's the same, otherwise it would be problematic, right)? If difficulty changes after 2016 blocks on average and block propagation is fast, everyone can adjust their mining difficulty pretty easy and there wont be much difference inside the network (most of the nodes will up to date)?

No, difficulty is not a function of time, but of the previous blocks. So regardless of which block a miner is working on, they always know exactly what the difficulty of that block needs to be (as they have the block's ancestors).
Better block propagation means they can switch to the next block faster, along with the difficulty change that that entails, however.
PS: Note that as of September 2020 the public FIBRE network is no longer operational, and I don't know if any private deployments exist.


What's the relationship between SLIP39 and BIP39? Trezor's SLIP39 makes it possible to apply Shamir's secret sharing to a Bitcoin wallet seed.

How do SLIP39 and BIP39 relate to each other?

I.e. it seems possible to derive SLIP39 from BIP39 words but this is messy, and deriving BIP39 from SLIP39 is not possible at all?

Or in Tony's words, what are the the details of calculating the BIP32 master seed from entropy using both schemas?

I want to know this because I was first under the impression that the relationship was quite strong and it would be possible to derive BIP39 words that can be used to recreate a wallet, but this does not actually seem to be the case.

There's some useful information here but it's not very concise answer: https://github.com/iancoleman/slip39/issues/1

BIP39 (Bitcoin Improvement Proposal) describes the implementation of a mnemonic sentence (set of easy to remember words from a predefined wordlist of 2048 words) that can be mapped to a binary seed from which you get a master key which in turn is used as per BIP32 for the generation of deterministic wallets.

SLIP39 (Satoshi Labs Improvement Proposal) has to do with the Shamir Secret Sharing Scheme (SSSS). This is a way to break up any secret into N parts so that any M of the N parts can reproduce the original secret. It is not limited to, but in the context of bitcoin it is mostly used for breaking up a mnemonic sentence from BIP39 or the seed of an HD wallet and giving each piece to a different party so that reconstruction of the secret would require collaboration/collusion of at least M parties. You still get with SLIP39 a mnemonic word sentence like you do with BIP39, only the words originate from a different wordlist. So if you see a mnemonic sentence, you can lookup its words against the online published wordlists of BIP39 and SLIP39 and recognize where it comes from.

SLIP39 is actually pretty neat, in that it allows for a two-level scheme where you have group-shares and within each group you define member-shares where you define an overall group threshold and within each group a separate member threshold.

For example I can split a master secret across four groups like:

Group-share 1: 1-of-1 for myself = single member-share and the threshold to fulfill this group-share is one i.e. I can do it by myself since I have the single member-share
Group-share 2: 1-of-1 same as Group-share 1
Group-share 3: 2-of-5 for my family = five member-shares (mom, dad, brother, sister, wife) and the threshold to fulfill this group-share is two i.e. any two family members together can reproduce it
Group-share 4: 3-of-6 for friends = six member-shares (alice, bob, charlie, david, eva, frank) and the threshold to fulfill this group-share is three i.e any three of my friends together can reproduce it

And finally you set a group-threshold of two i.e. to recover the master secret the goal is to reconstruct any two of the four group-shares.

Now, to recover the master secret here are a couple of possible recovery scenarios.

Scenario 1: I can do it all by myself since I have two member-shares from two of the four group-shares (Group-1 and Group-2) that both require a single member-share.

Scenario 2: alternatively my family members and friends can come together. In particular any two family members (to fulfill Group-3) and additionally any three friends (to fulfill Group-4). This way again two (the group threshold) of the four group-shares can be fulfilled.


Regular Expressions for DER signature hex (also req, address, TxIDs)? I'm using Python (2.7) and its re module for recognition of various Bitcoin data, namely:

  addresses, DER sigs, OP Return hexdata, TxIDs

I've been using re.compile: for example, for a valid Tx hash (TxID):

RE_TXHASH = re.compile('^[0-9a-fA-F]{64}$')
if bool(re.match(RE_TXHASH, 'f'*64)):    # 'f'*63 would fail
    print 'valid tx hash!'
else:
    raise Exception("invalid tx hash!")

I'm looking for regex patterns for the following (or input on my current best attempt):

DER signatures: General format "30[sig_size]02[r_size]02[s_size][sighash]"
Bitcoin addresses:  re.compile('^[123mn]{1}[a-km-zA-HJ-NP-Z0-9]{26,33}$')
OP Return hex strings: re.compile('^(6a){1}[a-fA-F0-9]{0,80}$')
TxIDs: re.compile('^[0-9a-fA-F]{64}$')

EDIT: to clarify, can someone help with a regex pattern for this? "30[sig_size]02[r_size]02[s_size][sighash]"

For DER sigs, it's possible for R or S to be very small.

DER sigs: re.compile('^30[0-9a-fA-F]{72,136}02[0-9a-fA-F]{0,64}02[0-9a-fA-F]{0,64}[0-9a-fA-F]{8}')

Bitcoin addresses cannot have a 0. Also the {1} is superfluous

Bitcoin addresses: re.compile('^[123mn][a-km-zA-HJ-NP-Z1-9]{26,33}$')

Again, {1} is superfluous for OP_RETURN. Also, the a might be capitalized.

OP Return hex strings: re.compile('^6[aA][a-fA-F0-9]{0,80}$')

TXIDs are fine


bitcoind and bitcoin-cli 'unrecognized', how can I access them from command line? I have downloaded and installed the precompiled Bitcoin Core OS-X (also successfully synchronized).  Every tutorial I have seen then directs one to begin using the executables bitcoind and bitcoin-cli. Unfortunately, these are unrecognized.

I've found this on the stack exchange as using Help->Debug Window which is incredibly helpful but I'm thinking it would be more advantageous to be able to run processes from command line...

Is it as simple as a missing symlink or something?  Or do I need to install from source in order to access these executables?

Bitcoin Core does not include bitcoind or bitcoin-cli. You can use the "debug" window to input the same commands there, or use  Homebrew to install bitcoind and its related tools bitcoin-cli and bitcoin-tx directly.

brew tap WyseNynja/homebrew-bitcoin
brew update
brew install bitcoind

This will download, compile, and install the most recent version of the daemon and the tools. The homebrew script used to do that is viewable on github. To keep up with new versions of Bitcoin Core that are released every few months, brew update && brew upgrade will check for new releases and rebuild if necessary.


Bitcoin value vs. Supercomputing What protects the stability of Bitcoin's value if supercomputers or some other technological breakthrough allows them to be mined at rates we have not anticipated?

The system is protected by an incentive mechanism. As Satoshi said in the paper itself:

  He ought to find it more profitable to play by the rules, such rules
  that favour him with more new coins than everyone else combined, than
  to undermine the system and the validity of his own wealth.

This means that if someone has access to a supercomputer, more powerful than the entire network combined, it would make more sense for them to use such computer to mine in a honest way and earn more reward than any other miner. Rather than actually use the power to do dishonest things, like to double-spend or to invalidate transactions, which would diminish the network's validity and therefore the value of the attacker's mining reward.

Also, if such computers are ever built, many people would want them, which would eventually redistribute the power. In that sense, ASICs could be considered tiny supercomputers.


Disabling GreenAddress 2FA ∵ Google Authenticator doesn't generate the correct OTPs for it According to the section "I lost my two-factor/mobile/etc (email/OTP|Authenticator/etc), what can I do?" of the GreenAddress FAQ page,

  You should always have at least two two-factor options enabled.

Unfortunately, I did not. I only kept the Google Authenticator one enabled.

  Additionally for OTP/Authenticator you should back up the initial seed number and/or QR code displayed. Provided you keep these backups you can maintain access to your coins even if you lose access to one method for any reason.

I did keep a backup of the Google Authenticator QR code (is this the same as the "initial seed number"?), but when I use the Google Authenticator or Authy apps to generate a OTP, GreenAddress / GreenBits doesn't recognize it.

Why would this be?

Is there a way to disable GreenAdress 2FA using the mnemonic and/or PIN?

The only reason I can think of that would result in the above with a valid OTP seed is invalid OTP settings (but default should work for Google Auth) OR incorrect time on the device OR invalid time (drifted) on the GreenAddress service clock.

I checked for the last one personally and the services clock is fine: in my experience most of the time is time/synchronization on the device.

There is no way of disabling GreenAddress 2FA without 2FA however users that created 2of3 subaccounts can use their two keys to spend/recover and users that enabled email notification with nlocktime can bypass the 2FA after a period of time (by default 90 days, min 1 day, or maximum nlocktime allows)

Thanks


Can a Bitcoin server have a .onion ToR address? Is it possible for a Bitcoin server to have a .onion ToR address?

If so, are there any in existence today?

(Note: this is an alternative to hiding addresses via the Azure Service Bus)

Yes, since version 0.7 this is possible with the reference client.

See the documentation about tor: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md

EDIT: also see https://en.bitcoin.it/wiki/Fallback_Nodes#Tor_nodes for a list of published onion nodes. The explanation on that site should be updated to reflected the built-in support for onion addresses since 0.7.0, though.


Cashaddr (bech32) to legacy address format convertor for Bitcoin Cash Several days ago our bitcoin cash core wallet started to generate addresses using the new format: bitcoincash:q...... . That's nice and differs from the bitcoin blockchain generated addresses, but some of our users have problems with the new address formats: not all the online exchangers supports the new format and mark it as invalid.
Is there an ability to show the user his OLD format address alongside with new one? So that we need some kind of convertor between cashaddr/legacy address format standards (maybe that's silly, sorry), or do it via wallet RPC API?

I've found this project:
https://github.com/oskyk/cashaddress , checked the accounts generated by it using validateaddress of my wallet, seems working fine!


Seed recovery strategy I got locked out of my Ledger Nano S. When setting up the device I was given a 24 words seed passphrase, which I wrote down. The device asked me to verify 3 of the 24 words and my input was valid.

It now turned out that I made a mistake when writing the seed passphrase down since the checksum doesn't validate and I can't recover my wallets. All words that I wrote down are words that are in the BIP32 spec words list.

What strategy would you use (involving coding or not coding) to try and fix the seed passphrase?

You most likely mistyped one or several words.
Manually trying different combinations can be a tedius process.
If I were you, I would be using seed recovery tool like btcrecover.

Are you familiar with the Levenshtein distance? The word(s) you misstyped are most probably the one(s) with shortest Levenshtein distance to the BIP32 spec words.

Example:

  staff can easily be mistaken for stuff or vice versa, since both are BIP32
  words.


How do I get a full transaction index with Bitcoin Core? How can I sync bitcoin full node so that I can access all details of transactions occurring on other nodes and other wallets also, like blockchain.info.

I have synced a full node using below commands, but that's giving details of node wallet account details.

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoins

The commands you have used are not for syncing to the bitcoin blockchain but to install a bitcoin, now with this client you can sync if you want, you will need days or weeks depending on your computer bandwidth and performance and 250+ giga of hard drive, you can start syncing by locating your bitcoin directoryand simply running:

  ./bitcoind

You can find more information about using and running properly a bitcoin full node here: https://bitcoin.org/en/full-node


How can I get the uncompressed public key from the compressed public key in openssl? Given a private key, I can get the uncompressed or compressed version of the public key like so.

EC_KEY* pKey = EC_KEY_new_by_curve_name(NID_secp256k1);

std::vector<unsigned char> getPubKey(EC_KEY* pKey, bool compressed) const {
    if (compressed)
        EC_KEY_set_conv_form(pKey, POINT_CONVERSION_COMPRESSED);
    else
        EC_KEY_set_conv_form(pKey, POINT_CONVERSION_UNCOMPRESSED);

    int nSize = i2o_ECPublicKey(pKey, NULL);
    std::vector<unsigned char> pubKey(nSize, 0)
    unsigned char* pBegin = &pubKey[0];
    i2o_ECPublicKey(pKey, &pBegin)
    return pubKey;
}

But how can I get the uncompressed public key from the compressed public key without knowing the private key?

If you have a compressed octet pubkey, use octet to point, then point to octet.

EC_POINT_oct2point(group, point, data, size, ctx);
EC_POINT_point2oct(group, point, POINT_CONVERSION_UNCOMPRESSED, data, len, ctx);


No inputs found when using Electrum to sweep private key from Bitcoin Core I'm trying to move my bitcoins from Bitcoin Core to Electrum in order to not have to store the blockchain. My starting position is a fully synced Bitcoin Core and a newly created standard Electrum wallet (without any imports).

I'm using the debug console in Bitcoin Core to execute walletpassphrase to unlock my wallet, and dumpprivkey together with the address obtained from File > Receiving addresses...

Once Bitcoin Core spits out a private key I'm following the instructions here http://docs.electrum.org/en/latest/faq.html#can-i-sweep-private-keys-from-other-bitcoin-clients and pasting into the sweep input box and leaving the default address intact.

The exact error message I receive is:

No inputs found. (Note that inputs need to be confirmed)

Am I doing something stupid here? Is this even the best migration procedure?

Your coins are likely in a change address. You could do a dumpwallet in bitcoin core and then sweep all the private keys. But this is going to be slow going in electrum and you're going to have to do it in batches. Instead I suggest extracting the addresses which have unspent outputs in them by using the listunspent command in bitcoin core and then sweeping only those addresses' private keys. You can also do this via the cli and then use standard text processing commands to extract the addresses (jq, grep). To get it via the cli run bitcoind -daemon and then use bitcoin-cli listunspent


Problem of colored-coins/assets and other coins with a parent/child relationship of paying for fees with only the parent currency I've looked into building out my own coin, but it was best to just piggy back on top of an existing blockchain like how colored coins and counterparty is doing it. But when going on this route, I run into the problem of having to pay the fees of using the blockchain in the native currency.

Say if I was to create a game token based off of the bitcoin blockchain on top of counterparty, I still have to pay the fees in Bitcoin. Which my users will not have even if I distributed my game tokens to them. Now they will be stuck with the game token without being able to send it anywhere.

One solution was to monitor these addresses, and just fund them a small amount of btc just for them to pay for the fees. Is there a service out there that does this?

This issue is also apparent in other coins like ethereum and nxt. They give the ability to create your own child coins within their blockchain but you are stuck with the coin unless the holder has the native currency.

How are others solving this problem?

It's definitely a common problem found in a lot of those platforms that make it easy to create your own colored coin/token. Asking users to acquire the native token, such as Bitcoin with Counterparty and NXT with the Nxt blockchain, is usually not a good way to start off your relationship with that customer. Some people may be fine with it, but it greatly hinders mainstream use.

Ardor solves this problem with child chains that allow child chain creators to have the users on their child chain pay transaction fees in the child chain token. A bundler (could be the child chain creator) would collect these fees and pay the Ardor main chain for transaction processing. So, ARDR tokens would still be needed, but your users wouldn't need to touch it at all.

You would still need to re-distribute your acquired child chain tokens though, but the Asset Exchange that will be on Ardor will be a great way for you to sell them back to your users. If a USD child chain exists (kinda like Tether and USDT), then they could purchase those child chain tokens directly with those USD tokens, much like getting game tokens at the old arcade.


What is the expected time until the next block is found? https://bitcoin.stackexchange.com/a/3908/659 says:

  Luckily, you'll only have to wait five minutes on average for a block to be found (blocks are one every ten minutes, so the expected delay until the next block is five minutes).

Upon reading it, I instantly felt that this was incorrect, and that the expected time until the next block is always 10 minutes (assuming the network hash rate matches the current difficulty).

If the blocks were generated exactly every 10 minutes, than it would be true that the expected time would be 5 minutes, but they're not.

So what's the real expected time?  Please make a plausible argument for why it is so.

10 minutes. Assuming, as you say, that the current network hashrate matches the difficulty - otherwise it is proportionally higher or lower.

Block finding is a Poisson process. The rate parameter λ is chosen so that 2016 blocks on average are found every 2 weeks, and since in such a process the expected number of events is proportional to the time span, it means λ is 1/(10 minutes).

The time until the next event (the next block found in our case) follows the exponential distribution with mean 1/λ, which is 10 minutes. This distribution is memoryless - the amount of time spent waiting for a block has no effect on the amount of time left to wait. When a block is found the expected time until the next block is 10 minutes (which is intuitive), and it is also 10 minutes at any other time.

If blocks arrived once every 10 minutes like clockwork, the expected time until the next block at a random point would be indeed 5 minutes - but then we wouldn't have to worry about expectations, we'd know exactly when the next block will be found.

In the future, the decreased generation reward might cause the total hashrate to fluctuate as transaction fees accumulate, causing reduced variability in block finding times, and reduced expected waiting time.


Ledger Nano S - Do you use the same key to send & receive Bitcoin? I have a just bought a Ledger Nano S and have put my Bitcoin onto it using one of the keys it generated. It actually generated 19 of them so I used the first one. My question is, if I want to load further crypto onto it, do I use the same key or one of the others? Thanks.

The string of characters you sent your btc to is called a bitcoin address. You should use a new one every time you receive funds.
This is important for your privacy, and the privacy of those you transact with. The blockchains is a public database, if you just used one address repeatedly, then every person that paid you would be effectively able to see your entire financial history. Obviously this is not ideal, but using a new address for each transaction can help a lot with this issue.
There are some small security considerations as well, but they are more theoretical in nature. Privacy is the main reason.
For more info see: https://en.bitcoin.it/wiki/Address_reuse


Adversarial Question: Why not fork LND Loop and provide the service freely/cheaply? Adversarial Question: Now that LND Loop is paid product, what stops someone from forking the software and selling the product themselves, or integrating it freely?

The only reason I can think of is that Loop is still maturing as a product, and that it is LND who will bring  it to maturity, so it makes sense to stay with the proprietors. But that's not even relevant when the service becomes mature.

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

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

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


Copyright claim to Bitcoin Whitepaper As you might know Craig W.(rong) is currently trying to «get» ownership over the BTC Whitepaper. I know this venture might seem ridiculous and harmless, but I believe it can be dangerous because of it's populistic nature. Alongside with the possible lack of understanding and/or caring of legal institutions it might have a considerable damaging effect. This is why I try to understand some more:

As I understand it the Software has been published under an MIT public license - Doesn't this affect the copyright situation of the Whitepaper as well?
The Original Whitepaper lists «Bitcoin.org» on it's first page - Doesn't this mean who ever runs this domain, owns the copyright alongside with »Satoshi Nakamoto« (if there is a copyright at all)?
Why does C.W. pursues his claims in England?
Doesn't mean the fact that the Whitepaper was published online and for free under a Pseudonym, that whoever published it, clearly has no intention of any copyright claim?
Do Satoshis E-Mails contain any clue about his/her/their intentions regarding the whitepaper?

I am aware these are a lot of questions and I will research them myself as well, but maybe someone has an answer to one or more of them at hand.
Thank you in advance!

Disclaimer: IANAL, this is not legal advice, the following are some lines of thought that I've seen on the matter that seem plausible to me:

The original client was published under MIT License. The whitepaper was packaged with the original client. The license statement explicitly covers the "included documentation". It seems plausible that the whitepaper therefore was published under MIT license.
Just mentioning bitcoin.org on the whitepaper does not transfer the copyright. Transferring copyrights is a rather involved procedure, and generally copyrights always remain exclusively with the actual creator. The inclusion of the URL in the document's header could potentially be interpreted as consent to be published there. I would expect 1. and 2. to be subject of the lawsuit.
I don't have any special insights why the copyright claim would be pursued in England. Potentially, the laws are favorable to the endeavor, or it's simply due to the claimant residing there.
If someone were to establish themselves as the copyright holder, they could potentially deny some parties from publishing it or use the copyright to legally pursue some parties. More likely, it would be used as evidence to cast the claimant as the creator of Bitcoin in the eye of the public, or as means to enforce patent claims.
I'm not aware of any special statements by Satoshi Nakamoto regarding the status of the Whitepaper.

Earlier, a cease-and-desist notice was sent to Square (among others) on behalf of Craig Wright for hosting a copy of the Bitcoin whitepaper. The Crypto Open Patent Alliance (COPA) responded in February 2021 on behalf of Square, requesting that the copyright claimant substantiate the basis of the claim. After no response was received, COPA announced filing a lawsuit alleging that CW in fact does not hold the copyright in April. I am optimistic that this lawsuit will clear up the matter.


Proper way of using a Mixing Service I want to use a mixing service and I was wondering what is the right way of using it.

I have some funds in my wallet (associated with a Bitcoin Address).

Should I generate a new address in my bitcoin client (this address would be picked up from my keypool itself right now). And after generating the address, I provide this address as the receiving address (for withdraw) to the mixing service?

Second case. Let's say I want to purchase something online using my bitcoins, like dedicated hosting service or something similar. The merchant wants me to send them the Bitcoins to their bitcoin address, but if I go through the mixing service for this purpose, it would take a very long time and transactions with merchants have to be completed fast.

In cases of mixing services like bitcoinfog, the minimum time interval is 6 hours after which the withdraw process starts.

So, what is the right way of using the mixing service?

Either of these solutions would work.

If you mix it first to a previously unused address or send it directly to the merchant via the service (ignoring the issue of timeouts on a merchant terminal if they have such a feature) the effect is the same.

The only thing to make sure is any change does not go back into an address which has not been via a coin sharing service. This will cause a link-back to your previous transactions.

The easiest way to avoid this is to have two separate wallets, one which is only been mixed and one which has not.


Double spending from "green addresses" & mitigation Suppose a user pays for a service (service1) using a "green address" (0 confirmations required) and service1 needs to immediately respend it using it's own green address

How many blocks should the service wait before respending that money to a normal Bitcoin-QT user?  (assuming the QT client doesn't recognize Green addresses)

Suppose the service sends the funds to another service  (service2) that recognizes it's coming from a green address.  There are still zero confirmations.

What would the block chain look like?  (Specifically can the multiple transactions appear in the same block?)
Can the multiple zero confirmations appear out of order?  (I know the answer is "no", but I'd like to know how & why)

If service1 trusts service0's green address implicitly, it can send the coins immediately; there is no advantage to waiting. The recipient can then decide how many blocks to wait for before treating the payment as confirmed.

If service0's green address isn't trusted, service1 needs to take into account that if service0 double-spends, service1 will be liable for the reversed transaction to service2. He can remedy it by resending with different coins, but it still won't look good.
The inputs of a transaction can reference outputs of transactions in the same block. So the block will include (interspersed with other transactions) a sequence of transactions where each one references the previous one.
As far as I know, no. An input can only reference the output of a previous transaction, where "previous" is either in a previous block or an earlier (in listing order) transaction in the same block. I couldn't find a definite confirmation for this, however.

Why - it makes sense and it makes sure there can be no cycles.

How - I suppose that when a client builds the list of transactions to include in a block, it puts aside any transactions which reference a transaction which was not yet included. Afterwards it can go back to add these transactions (multiple passes may be needed if there is a chain of multiple consecutive transactions).


Is every bitcoin transaction (eventualy) validated by every miner? I can see that my bitcoin transfers becomes real when my exchange detects 2 or more confirmations.

I believe each confirmation is a validation. Am I correct? If so, How many confirmations will have my transaction? As many as miners does exist? If not, how many?

Welcome to Bitcoin.SE!

Each node validates all transactions in every block and, every block in its entirety.

The confirmation count is how many blocks are mined on top of the block that includes your transaction. A new block is mined every ten minutes on average.


How does the signature verification feature in bitcoin-qt work without a public key? bitcoin-qt has a "signature verification" feature where you can verify a signed message.  All it needs is the bitcoin address of the signer, the message and a short signature.  From what I understand about digital signatures, you would need the public key in order to verify a signature.  A bitcoin address is just a hash of the public key.  The public key may be in the blockchain but that would only be the case if the address had already claimed at least one output.  If they haven't claimed any outputs, how can the signature be verified?

The ECDSA public key can be recovered from the signature.

See this bitcointalk thread and the linked pdf for details.