How do you determine which position a block is in the blockchain? I want to create a difficulty calculator and need to know when each 2016th block has been created and how many blocks were created in the previous two weeks.

Do I have to count and label each block from the genesis block up manually or is there an easier way without having to download and parse the entire blockchain or use an external service?

To find the height of a block with only the raw blockchain (or block header) data, you need to follow through the sequence of references all the way to the genesis block.

Of course, there are external services offering this information in their API.

As for your premise, to calculate difficulty you don't need to know how many blocks were created in two weeks, only how much time passed for 2016 blocks (or actually 2015 blocks due to an off-by-one bug).


Sign a tx with "low s" value using OpenSSL I currently try to sign a tx using OpenSSL. After some tinkering I think I got most of the tx right but Electrum complains with mandatory-script-verify-flag-failed (Non-canonical signature: S value is unnecessarily high) which is probably because of BIP62.

Is there a way to create proper signatures with OpenSSL except trying and hoping to get a small s value?

The rest of my code is in Golang and I couldn't find a proper packages for the used ECDSA curve and so wrapped around OpenSSL.

Alternatively, you could use libsecp256k1. This is the code used by Bitcoin Core for signing, and will automatically create low-S signatures (disclaimer: I'm the main author of that library).
Perhaps a Go wrapper exists.

If you stick to OpenSSL, it is possible to manually adjust the S value after signing. This is what Bitcoin Core used to do before v0.10. Here is what it used to do: https://github.com/bitcoin/bitcoin/blob/v0.9.0/src/key.cpp#L204L224


How to run a full node: Am I already doing so? I've succesfully installed bitcoind and bitcoin-cli. I got some questions about it:

I run bitcoind in the background by typing: bitcoind -daemon and the blockchain begins to download:

By typing getinfo  I can see how many blocks are known to my client on the line “blocks”… that´s ok for me.

But what happens at the end? I don´t see that bitcoind reports me anything back on the shell.

I see by typing getinfo that the blockchain is already on my computer. Then I turn off or hibernate computer for few hours.

I run bitcoind -daemon everytime I turn on my computer and it downloads the latest blocks that, of course, are missing because my computer was turned off.  Is that all?

Am I already running a full node?

Do I have to wait for the full download of blockchain for sending or receiving BTC with blitcoin-cli?

Does bitcoin-cli  work without this large file?

Yes, congratulations you are running a full node.

Note that you're mostly running a full node so that you can fully validate everything so you can now send and receive money without trusting anyone. However you are trusting your PC itself, malware might steal your money or cause you to lose money (both would happen with non-full nodes too of course).

You might want to check how many connections you have (after bitcoind has been running for at least an hour or so) use getpeerinfo. If you only see 8 outgoing connections then other nodes can probably not reach you. If you would like to enable them to do so you might need to configure your router to do portforwarding.

For receiving bitcoins you don't even need to be online at all. For sending them you don't need to have finished downloading as long as it has downloaded far enough to know that you received any.


Handling negative "s" values for signatures? In comparing these test vectors to my own results, for tests #2 and #5, I end up with negative s values.  My results show that for test #2, test_s = my_s * -1, as an integer, yet the hexadecimal representation matches up correctly with the test, while for test #5, test_s = my_s + curve_order.  What is the proper way to handle a negative s value, or possibly, should I not be getting negative s values for these tests?

Let us denote curve_order by q. When computing a signature (r,s) it is important to remember that r and s are meant to represent elements of Fq (the field of integers modulo q). The formula s = k^(-1)(e + rx) is an algebraic expression in Fq. So r an s are not really integers, they are integers modulo q (so for example two integers u and u + q represent the same elements of Fq). When implementing a function returning (r,s) there is nothing wrong with internally representing these quantities as integers. But when it comes to returning values, you have to decide how you wish to encode the values r and s. If s represents your implementation specific integer, do you simply want to return s? or s + q? or s - 3q? All these answers are the same (simply different encodings) but there is little chance you will match a test-vector unless you have a common encoding with it. When returning an integer s modulo q it is customary to encode s as the unique integer s' with 0 <= s' < q equal to s mod q.

So for example, when you say that test_s = my_s + curve_order, you effectively agree with the test, but have not enforced the usual encoding. When you say that test_s = my_s * -1, you genuinely disagree with the test but this is explained by 'standardization' (so make sure that you have 0 <= s < q and if s > q/2 replace it by -s, but make sure you encode -s as an integer within [0,q), which means s should in fact be replaced by q - s).


Does one of these exchanges have a sandbox to test? I want to test some trading. Does Binance, Bittrex, Poloniex, Kraken or Gemini have a sandbox to trade fake crypto to test systems?

I work for an exchange, I don't know if I am allowed to say which, but have something called a test net, which is similar to what you are describing and which many people use to test trading strategies.


Double SHA256 giving me an incorrect value with this code VB.net I'm trying to build a bitcoin miner. I have generated the message successfully, but I can't get the double SHA256 correctly. The value I'm getting is incorrect. What is wrong with this code?

 Private Sub Button9_Click(sender As Object, e As EventArgs) Handles Button9.Click

    Dim message_combined as string = "02000000671D0E2FF45DD1E927A51219D1CA1065C93B0C4E8840290A00000000000000002CD900FC3513260DF5BD2EABFD456CD2B3D2BACE30CC078215A907C045F4992E3E5F4A5E747B1B1843F740C0"

    Dim sha256 As SHA256 = SHA256Managed.Create()
    Dim bytes As Byte() = Encoding.UTF8.GetBytes(message_combined)
    Dim hash As Byte() = sha256.ComputeHash(bytes)
    Dim stringBuilder1 As New StringBuilder()

    For i As Integer = 0 To hash.Length - 1
        stringBuilder1.Append(hash(i).ToString("X2"))
    Next

    '  Dim sha256 As SHA256 = SHA256Managed.Create()
    Dim sha256_2 As SHA256 = SHA256Managed.Create()
    Dim bytes2 As Byte() = Encoding.UTF8.GetBytes(stringBuilder1.ToString())
    Dim hash2 As Byte() = sha256_2.ComputeHash(bytes2)
    'bytes2 = Encoding.UTF8.GetBytes(bytes)
    'hash2 = sha256_2.ComputeHash(bytes2)
    Dim stringBuilder2 As New StringBuilder()

    For i As Integer = 0 To hash2.Length - 1
        stringBuilder2.Append(hash2(i).ToString("X2"))
    Next

    final_hash = stringBuilder2.ToString()

    TextBox9.Text = final_hash
End Sub

After double hashing, the end hash should be: 920F0D3EF835E723DBDA8AE0E1EA0705FAF53AC784A8116639BCB215F3BC9D8B

You seem to be interpreting the hex encoded data as a UTF-8 string. Instead, you should be decoding it as a byte dump.

To illustrate, decoding 12 as a UTF-8 string will give you:

0x3132

while decoding it as a hex dump will give you:

0x12

In bitcoin, all hashing it done on the byte values, which are often printed as hex strings for convenience - you must decode them back into a byte array as hex strings, not as actual strings.


What happens when a request expires in Electrum, then I am paid? I just bought bitcoin from the bitcoin website, and it is taking a lot longer than I expected to process my information and my request and actually send BTC to my wallet.  I set the "expire" setting to 1 day when I was requesting in my BTC wallet.  What happens if I am paid after the request expires?  Is the address no longer used by my wallet?  Does the BTC go somewhere else?  Or does it go no where at all?

Your wallet will receive the Bitcoin. Your wallet is still watching for transactions to that address and will be able to receive Bitcoin at that address at any point in time.
The expiration is only used as a hint to the sender if you give them the payment request or the Bitcoin URI. It is not part of the blockchain nor part of the address. So if you just gave the address, then the sender wouldn't even know that there is an expiration. The expiration is only used by the client software but is not a hard limit.


If miners are creating their own mining algorithms or using something standard From this:

  the arrival of a new block has special significance for a mining node. The competition among miners effectively ends with the propagation of a new block that acts as an announcement of a winner. To miners, receiving a valid new block means someone else won the competition and they lost. However, the end of one round of a competition is also the beginning of the next round. The new block is not just a checkered flag, marking the end of the race; it is also the starting pistol in the race for the next block.

So I just wanted to clarify because I don't think I've seen it written down anywhere, that it's in a miners best interest to create their own algorithms to solve the computational challenges involved in mining. It's not as if every miner gets a standard algorithm and runs that. Please correct me if I'm wrong.

The double-SHA256 is the mining algorithm. Miners merely decide which transactions they wish to include in a block, and they an adjust the random nonce field in the block header. Additionally, they create the coinbase transaction (the first transaction in the block), which pays them out for the block reward. There is some additional information they can include in the coinbase transaction which makes no difference to the result, but merely allows them to attach some metadata (such as the name of their mining pool, to indicate they mined it).

The choice of transactions to include can be arbitrary, but the obvious approach is to include them prioritized by highest paying fee, because this maximizes the revenue the miner takes if they are successful.

Everything else is simply random numbers in order to try and find a hash which is below the target. The miners can choose how they generate those random numbers, or how they might partition the range of numbers to attempt between members of a mining pool to prevent duplication of work among the members of the pool.


Bitcoin-QT: which external memory (connected via USB2.0 + TrueCrypt) would work? Background
I have Bitcoin-QT 0.9.3 (zip version). bitcoin-qt.exe sits on the internal HDD of my laptop. All of the other stuff (blockchain, wallet,...) on a 128GB USB drive, fully encrypted with TrueCrypt (AES encryption), connected via USB2.0 port. I have bootstrap.dat (21GB copy of blockchain) on the USB drive, too.
Problem
everything is slow via USB2.0 flashdrive. Import of bootstrap.dat  file is barely making progress. It's been 7 days and I'm getting older. The progress bar shows it's 1/3 ready. No other application reads/writes to the USB drive.
Question
I'm considering swapping my flash drive for an external hard drive, but keeping TrueCrypt. Would this help, or would the fact that I have no USB3.0 ports be more important? I'm looking for satisfactory speed results that other people are getting by using bootstrap.dat. As slow as it's going, I'll import the blockchain slower than it's generated.
I would prefer your experience over suggestions like "try this..." becase I don't have free HDD space to "experiment", I just want to buy some HDD and hook it up to USB, but I'm worried that USB2.0 port itself is a bottleneck and I would just waste money. Thus I'm here for clues.
I'd prefer an HDD instead of an SSD, but I will hear out both options. I'm not interested in thin clients.
(basically I'm looking for cheapest external memory that would work, because flash drives don't work with Bitcoin-QT).

The cheapest external memory that would work fast enough to be acceptable is SATA3 HDD via usb2.0 adapter. (I didn't tested SATA1 or 2 nor old IDE drives, if you have them with over 500GB capacity you can probably use them too. I couldn't find them for my test).
For comparison, here's the time was needed to import 21GB blockchain:

2.0 USB flashdrive: never finished. took 7 days non-stop for progress bar to reach 1/3. and then speed slowed down to the point that there was no noticeable progress.
SATA3 HDD via USB2.0 adapter: about 20 hours non-stop.


Would an optimization proof-of-work problem where the entity with the lowest hash wins have any security weakness or other disadvantage? I am wondering if there would be any security deficiencies if cryptocurrencies such as Bitcoin were to change their proof-of-work problems to optimization contests. For example, suppose Bitcoin were to change its proof-of-work problem to an optimization problem. In this scenario, the goal each instance of the proof-of-work problem would be to minimize the output of the hash function, and the winner of each block is the entity who finds the input with the lowest hash after 10 minutes. Would an optimization proof-of-work problem cause any security weaknesses, other deficiencies, or complications for the cryptocurrency? Are there any cryptocurrencies which use an optimization proof-of-work problem instead of a search problem as a proof-of-work?

You're not thinking like an attacker yet. ;)

Beside this incentivizing selfish mining, a miner can do the following attack:
Mallory sends all her funds to herself every block.
As soon as she finds a block with a very low hash, she can execute the following attack: Make a payment to someone that accepts first confirmation with a substantial fee ensuring it will be in the next block. Wait for the next block. Receive the counterside of the deal (e.g. coins on another chain). Publish their block and laugh.


bitcoind has 0 connections I'm running bitcoind on a remote server (so I can only use the "headless" version). However, the client is not connecting to the bitcoin network. The "getinfo" command shows "connections: 0". I have also been keeping an eye on the blocks folder and there is no change there (when running bitcoin on the local machine, I can see files being created and updated there).

Here's what my bitcoin.conf looks like:

daemon=1
server=1
rpcuser=<redacted>
rpcpassword=<redacted>
rpcport=<redacted>
rpctimeout=60

Port 8333 is open for UDP traffic in my firewall and I have used an external port scanner to verify that it is open. However, I understand that that's not actually necessary for outgoing connections. I've also checked that my date / time is synchronized (this was suggested in some of the threads that I found on this topic).

What are other possibilities?

Bitcoin uses TCP. Configure your firewall to open TCP port 8333.


Do you sign only the previous output of transaction? I need to confirm that I understand how transactions work in the Bitcoin network. Ok, so:

Alice is a network node. Alice wants to send bitcoins to someone in the network. Alice is creating a transaction using her wallet.
Every transaction has inputs and outputs. The inputs of every transaction are just references to some previous outputs of some other, older transactions that previously sent funds to Alice addresses.
To send bitcoins Alice needs to resolve the puzzle given in the scriptPubKey of a previous transaction's output by using her scriptSig which her wallet generates upon making a transaction. Basically Alice just needs to prove that she is in control of private key (related to address previous bitcoins were sent to) by signing the new transaction.

Did I get these steps right?
My confusion started when I was exploring the hash type because I saw many sentences that said the Output of a transaction is signed correctly. With my understanding (from above) I assume that the previous output is signed correctly? And therefor, an input of a new transaction is considered valid. But I couldn't find confirmation for this. Am I missing something? Thank you!

The sighash type conditions what is part of the digest which is eventually signed for the transaction to be valid.
Some sighash types allow to either include (commit to) part --or none-- of the outputs of the transaction in the digest. Using these far less common sighash types introduce some malleability for a transaction, which usually allow more flexibility when different parties create a single transaction.
You almost always want to use SIGHASH_ALL and you anyway should append a SIGHASH_ALL signature to an input before broadcasting a transaction.
Regarding your question and to sum up, you always sign the current transaction and append this signature to the witness or the scriptSig. This signature can be conditioned using different sighash types.
For reference, you can see the wiki page on OP_CHECKSIG (it only covers the legacy transaction format, though).


Does bitcoind store timestamp at which private key was imported? If we import a private key using bitcoin-cli importprivkey <key>, is there anyway to find out when the import was done?

I am hoping a timestamp is included.

No, bitcoind does not. bitcoind does store a timestamp for keys however this timestamp is used to determine when to start rescanning. importprivkey does not allow you to specify this timestamp, so in order to be sure to not miss any transactions, the timestamp is set to 1 indicating that the entire blockchain will be rescanned.

The importmulti command allows you to specify the timestamp which by default is the time at which you imported the key. However, as mentioned earlier, since the timestamp is needed for rescanning, if it is not set to be early enough, the automatic rescan done at import time will not catch all of the transactions the key is involved in.

If you want to see the timestamps, you can use getaddressinfo to get the information for the address corresponding to the private key you imported. getaddressinfo will give you the timestamp in unix time.


using blockchain.info api_code I make a JSON call to

https://blockchain.info/tobtc?currency=USD&value=1

This is a free api with a request limit.

I have just received my api_code via email. This is blockchain.info's example of how to use it

  Once approved the API Code can be passed to all requests in the "api_code" parameter e.g. https://blockchain.info?api_code=$your_code

I am guessing that they mean with PHP (because of the dollar sign) as when I type into my address bar

https://blockchain.info/tobtc?api_code=000my0-api00-code-0000-000000000&currency=USD&value=1

The data does not any look different when I use the api code with the dollar

https://blockchain.info/tobtc?api_code=$000my0-api00-code-0000-000000000&currency=USD&value=1

Though I am unsure of how to tell what is the correct way as I can access this free api with and without an api code (with a request limit). How do I tell if I am adding it correctly?

The first one is correct.
https://blockchain.info/tobtc?api_code=000my0-api00-code-0000-000000000&currency=USD&value=1

However, the particular call you are using (/tobtc) is public and thus needs no api_code attached.

https://blockchain.info/tobtc?currency=USD&value=1


BIP0016 pay-to-scripthash transaction detection BIP0016 acknowledges it works by "recognizing one 'special' form of scriptPubKey", so P2SH transactions are actually special cases.

What are the exact rules to detect these special cases?

The document you linked to provides all the information you need.

Specifically, for an output to be recognized as pay-to-scripthash, its scriptPubKey must match the format

OP_HASH160 [20-byte-hash-value] OP_EQUAL

The scriptSig of the redeeming input is validated using different rules:

  Validation fails if there are any operations other than "push data" operations in the scriptSig.
  Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
  {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.

Older clients would accept such inputs, but they would not validate the included script. Therefore, the addition of these rules is a soft fork.


Get a JavaScript notification when Bitcoin transaction arrives to a certain address I'd like to implement a very simple address monitoring feature on a site I'm working on. I'd like to just be able to say "Listen to this address on the testnet for money to come in", and update the HTML on the page when BTC comes in. I realize Blockchain.info provides a websocket for precisely this, but doesn't provide it for use on testnet3.

I'm sure I'm overlooking something obvious. Any help is greatly appreciated.

Usually you do this on the wallet service you are using. They provide server-to-server notification callbacks when the address receives transactions. Then you parse this transaction  and let your on server to notify JavaScript clients.

EDIT: SoChain offers no-authentication, WebSockets, API to monitor Bitcoin addresses in real-time. You can use this on cliet-side JavaScript directly:

https://chain.so/api#realtime-balance-updates

I don't know if any pure client-side JavaScript APIs exist with notification feature - you always need to set up webhooks to some server, or be directly connected to bitcoind.

Also there is the issue of confirmation level - when you consider the transaction to be received, how many confirmations you demand for it. You'll usually end up getting several notifications per each new confirmation.

I have done this in my open source project Liberty Music Store using blockchain.info.

For inspiration, see the relevant blockchain.info webhook code which then forwards this information to JavaScript through Redis pub-sub listener pattern (though in this case it does using HTTP long poll instead of WebSockets for Android 2.3 compatibility):

https://github.com/miohtama/LibertyMusicStore/blob/master/tatianastore/blockchain.py#L110

https://github.com/miohtama/LibertyMusicStore/blob/master/tatianastore/static/main.js#L102

https://github.com/miohtama/LibertyMusicStore/blob/master/tatianastore/signals.py#L28

https://github.com/miohtama/LibertyMusicStore/blob/master/tatianastore/storefront.py#L253


Is there any way to send an output to a script which can then only be sent to one of two addresses? Is the following scenario possible?

I want to send money to a script. This script will require knowing a private key to spend, as usual, but the script is only valid if the money is being sent to one of two addresses. That is, if the transaction has more than one output, it is invalid. If the transaction's output is a standard script to address A or to address B then it is valid. If the transaction output value is any less than x, it is invalid.

In other words, it seems the scripts serve to validate that you can spend the output, but then the output can be spent however the claimant wants. Is there any way to limit how the outputs are spent? All this without requiring a trusted oracle of course.

There's no way for an input script to control the output script, so it can't be encoded into the script itself. However, you can get the same effect with more than one partially-signed transaction. Make a P2SH 2-of-2 multisig address, where you hold one key and the claimant holds the other. Send it some Bitcoin. Then part-sign two transactions from that address, one to A and the other to B. Send the claimant both transactions.

The claimant will only be able to spend exactly the amount you sign for, so if you really want a lower limit you'll need to create more transactions with different outputs.


Restore encrypted wallet I need to restore a wallet created with bitcoin-qt which was encrypted.  I have the encrypted wallet.dat file only.  Do I restore this simply by replacing the current wallet.dat with my backup wallet.dat file?

Yes.  However, you will lose any new private keys in the current wallet.dat.  Even if you didn't create any new addresses, bitcoin-qt creates change addresses if you send any money.  So, to be safe, you should dump the private keys for your current wallet.dat and the stop bitcoin-qt.  Replace the current wallet.dat with the saved wallet.dat.  Restart bitcoin-qt and then dump the private keys again.  If you have the same set, all is well.  Otherwise, you will need to import any missing private keys.

To dump the private keys using the bitcoin-qt debug console:

listaddressgroupings
walletpassphrase your-passphrase 300
dumpprivkey bitcoin-address
walletlock

Step 1 will list the bitcoin addresses in your wallet.  Steps 2 and 4 are only needed if the wallet is encrypted and unlocks your wallet for a maximum of 300 seconds.  Repeat Step 3 for each bitcoin address.

To import a private key using the bitcoin-qt debug console:

walletpassphrase your-passphrase 300
importprivkey private-key "key-label"
walletlock

Steps 1 and 3 are only needed if the wallet is encrypted.  Repeat Step 2 for each private key you are importing.  The key-label is whatever you want to identify the key.


Storing private key in apps and softwares that are local Im new to butcoin. I installed an app in my phone called Bread. And another in my computer called Electrum.

Both of them generated a seed(12 words) for me and it seems that seeed is my private key in the bitcoin network.

My question is: these softwares has my private key and i dont know if they stored it in remote servers. This means someone other has my private key and can access my money? This is a safe way in bitcoin culture? They are really local?

I want to use safest way to work with bitcoin and i dont want store my info in any website or app that can access my account, delete my account or any other intervention.

For safest way should i have my own copy of public ledger in a personal server? What is the safest way?

BreadWallet & Seed: the seed is not your private key, it is used to generate the private key, and it is stored locally on your phone. However, the level of trust in me (or anyone else) is not sufficient, when saying this. You might want to do a source code review by yourself to be 100% sure. In general I use Bread as well, for daily usage, not for big amounts. It is a fairly well working wallet, and the value in it is comparable to the wallet with FIAT money. There are privacy issues with such wallets like BREAD (they are called SPV wallet), and the risk with these SPV wallets is, you trust someone else that they verify the bitcoin blockchain correctly. E.g. there was the risk to fall victim of the segwit2x fork, and then you would think you are on the original bitcoin, but in fact the provider (and all SPV wallets) would be on a new blockchain, which has changed parameters. So with SPV wallets, only use small amounts of money.

Electrum: this is similiar, the seed is used to generate the privkeys. Electrum is also an SPV type of wallet, and you trust the provider's blockchain. I am not sure about the possibility of code review though.

Wanting to be 100% secure and safe, you need to run a full node (aka bitcoin core client or similiar), and get used to the idea of cold storage. There is lots of links to cold storage here in the forum.


Is this an incoming or outgoing transaction I recently looked at this bitcoin transaction:

transaction: 3b0e8fae9640e1d043cfef14815c6885e58d71e7ee31cfa53f9c9d5acb138a4d

For those who do not want to look at the transaction, I will give a simplified example of it:

There are 3 inputs:

X pays 0.5BTC
Y pays 2BTC
Z pays 3 BTC

There are 2 outputs:

A which gets 2.5BTC
X which gets 3 BTC

As you can see, the "balance" from Y and Z went to X, but X also paid out.

Would this be classed as a incoming or outgoing transaction?

The wallet balance would probably not change as they "may" own all of the addresses.

I would like to assume that they do not.

Should I class them as separate transactions?

It depends on your perspective and which addresses you control.

If you are Y or Z, it's an outgoing transaction.

If you are A, then it's incoming,

If you are X, it could be both. If X also controls Y or Z, then it's outgoing as he is sending money to A and the output that sends to X is just a change output. If X does not also control Y or Z, it would be both as Y and Z are simultaneously paying him and A while X is simultaneously paying A and receiving money from Y and Z.


Anyway I can track the guy behind the bitcoin address? I have just got a mail from someone called Mike Demarinis  blackmailing me to ask me to send him money. I know it's a joke, because i have got various passwords for different things. The guy simply don't know me.

But is there anyway that i can track the guy, like IP or location and call the police?

I want to find out where this address is from: bc1qz5ufptmvfkm4cjegwrfhqypvzum56phznm5raf

The mail is pretty nasty and frightening

No, there's no way for an individual to tie an arbitrary address to a specific person. However, it is sometimes possible for companies or governments to do so if the person went through a KYC/AML or identity verification flow on a centralized exchange site (i.e. Coinbase).

This is how the IRS was able to track people with large returns down for tax purposes (https://tokentax.co/blog/does-coinbase-report-to-the-irs/).

All bitcoin transactions are entirely public, just pseudonymous. So, if a company is able to tie an individual to any address, they can easily track where that address sent coins and go from there. So while you might not have any course of action yourself, it could still be worth reporting any information you do have to authorities.


Can you send amounts that would typically be considered 'dust' through the Lightning Network? Reading through the Lightning Network Paper, it seems that amounts sent through an intermediate node use the Hash Timelocked Output construction. The thing I'm concerned about with HTLCs is that they actually require their own output. Simultaneously, the transactions they are in must also be broadcast-able if the other party goes offline or become uncooperative.

So, let's look at a scenario where Alice wants to send 1 satoshi to Carol, through Bob, with whom Alice and Carol both already have payment channels open. Alice sends bob a new commitment transaction with 1 satoshi deducted from her balance and a new HTLC output for 1 satoshi. Bob sends the same type of channel update transactions to Carol. The problem is, though, that HLTC output would be considered dust if it ever did actually need to be broadcasted! So this cannot be considered a valid guarantee of payment, since the transaction would not even propagate on the network.

Is that a problem? Part of the excitement over the LN is that you can send really small amounts, but it seems to me that you can't actually send smaller amounts than you could in a real bitcoin transaction, because you have to be able to broadcast the transactions if the other party doesn't cooperate or goes offline.

You are correct that small payments would be a liability in the case of uncooperative nodes in a channel.  I also believe you are correct that when the values get small enough, the trust-less nature of a channel breaks down.  Although a 1 satoshi transaction is possible, at some point the cost of the transaction that closes the channel is higher than the value transmitted over the channel.  You couldn't open and close a channel just to send a single satoshi, even if both nodes were cooperative.

What the LN really does is create a network similar to the existing network of correspondent banks in the legacy financial infrastructure.  With every correspondent banking relationship (payment channel, in the LN), there are risks and liabilities involved.  These risks are mitigated by charging fees to use the channels, which is exactly what the Lightning Network will do.

I don't see this as a show stopper for the implementation of the Lightning Network, but it will be a factor in what drives the fees for using a channel.  This dynamic may also play a role in how the nodes split the money that is originally locked to create the channel.  Less established nodes may have to contribute a higher percentage than those nodes that have been deemed trustworthy.  I'm speculating here, but this is one potential way to mitigate risks.

Just like with Bitcoin, the system should work so long as there are more honest nodes than dishonest nodes.  In this case, however, dishonest nodes must attain enough money to disrupt the network as opposed to hashing power.


How to query bitcoin database created by Toshi? I want to query Toshi's(https://github.com/coinbase/toshi) database but can't figure it out how to connect to it. It seems like it runs inside a docker container.
Appreciate any help.

docker exec -it toshi_db_1 psql -U postgres -d toshi_development

Got the answer on a github issue https://github.com/coinbase/toshi/issues/198


Can you check if a node is pruning? Is it possible to check if a specific node is running the full blockchain or a pruned one?

Also if you can, is it possible to check exactly how many (or roughly) how many blocks they are distributing.

Bitcoin nodes advertise their services with the nServices bitmap. The first bit is NODE_NETWORK which indicates whether a node will be able to serve all blocks to other network participants.

Pruning nodes do not signal NODE_NETWORK, because they do not have a complete copy of the blockchain. They will however return any requested blocks they have in storage. As the minimum pruning size is 550 MB, they will be able to serve at least the last three days worth of blocks.


Does the private key of Bitcoin change everytime the address changes? I have read from many sites that an address should change every time a Bitcoin transaction is made. Does the private key change along with the Bitcoin address. How is the address obtained from the public key? Is it the same method of deriving the public key from the private key?

If you are posting different questions I suggest, posting them up in different threads. But I'll try to answer all of them.

1) It doesn't work like that. Every address is a pair (private key, public key), the address is made after hashing the public key twice.

So, each address has one private key and private keys are not shared.

So if in one address you have 1 btc, and you want to send 0.5 btc to some other address, usually the wallet software creates a new address that receives the difference minus the tx fee, that's your change address and any further transaction that spends the funds will spend from that address (the change address).

To clarify, address A has 1 btc. You want to send 0.5 btc to some address B.

What happens is, the balance of address A is fully spent into

B          (0.5)    <--- amount you want to spend
C          (0.4999) <--- amount you are left with after spending
fee        (0.0001) <--- transaction fee on spending B
A (total)  (1)      <--- original balance. fully spent

C is your change address, and when you spend your coins again you will spend from C and not from A.

2) The Public Key is obtained with one method related to how the way ECDSA works and the address is obtained by another method, mainly it is double hash of the public key that is encoded in a format called base58check as it includes a checksum to ensure that you didn't type the wrong address, also base 58 is designed to eliminate similarly looking characters, like 0 and O or l and I.

3) For the last question I'd like to refer you to How are bitcoins reassigned


How many Watts can I safely draw from a typical US home circuit for Bitcoin mining? Suppose I have a mining rig that draws 1,200 Watts.  How many of those mining rigs can I run on a standard US home circuit?

Do I need a special outlet?

What is the risk of an electrical fire?

What other safety precautions should I take?

There isn't a single "standard" for residential circuits in the U.S. but there might be a typical circuit, such as 20 amps.

As far as plug connections, don't use light-duty extension cords; make sure they are rated for high amperage, say 20amps.  Generally if you are plugging directly into an outlet then the total power drawn can be done safely up to 80% (rule of thumb) of the level the wiring is rated for.

If the circuit breaker is 20 amps and the circuit is using the proper gauge wiring for that and was wired properly, then you should be able to draw 16 amps safely from it.

16 amps * 120V = 1,920 watts.

So you could add a smaller capacity rig on the same circuit but you cannot have more than one of those 1.2 kWh rigs on what might be a "typical" residential circuit.

[Disclaimer: I'm not an electrical engineer nor an electrician but I play one on Bitcoin stackexchange.]


Is the difficulty target always truncated for practical purposes? The current value of bits in the block header is: 18034379. In target form, this is equal to:

0x0000000000000000034379000000000000000000000000000000000000000000

However, if you calculate the target using the difficulty:

target = maxtarget / difficulty
target = 0x00000000ffff0000000000000000000000000000000000000000000000000000 / 336899932795.8077
target = 0x0000000000000000034379000000004000000000000000000000000000000000

As you can just about see, this calculated value is more accurate than the  truncated target you get using bits.

My question is:

When mining, is the truncated target used (the one you get from bits), as opposed to the more accurate target you get by dividing the maxtarget by the difficulty?
Therefore, for all practical purposes, you should truncate the target you get when you divide the maxtarget by the difficulty?

When mining, is the truncated target used (the one you get from bits), as opposed to the more accurate target you get by dividing the maxtarget by the difficulty?

Yes. The bits value actually stored in headers is what matters, as this allows validation of standalone headers without context. Due to headers-first sync this is no longer strictly needed, but there is no reason to change the rules now.

  Therefore, for all practical purposes, you should truncate the target you get when you divide the maxtarget by the difficulty?

Yes.

There is at most a 0.0015% difference between the two, though (1 in 2**16).


What is the difference between secp256k1_ecmult_gen and secp256k1_ecmult? libsecp256k1 has two implementations, secp256k1_ecmult in ecmult.h and secp256k1_ecmult_gen in ecmult_gen.h, to multiply the points of an elliptic curve.
secp256k1_ecmult_gen supports simple multiplication such as a*G and secp256k1_ecmult supports multiplication involving addition such as a*P + bG. However, secp256k1_ecmult can be used for simple multiplication by setting b=0, actually, it is used as such in eckey_impl.h#secp256k1_eckey_pubkey_tweak_mul.
How should these two functions be used properly? Is there any difference in the performance?

How should these two functions be used properly?

A simple answer is "not at all". Those functions are not exposed in the public API of libsecp256k1, and that's the reason why they don't have user-targeted documentation. Instead, they're used as internal subroutines, mostly for the implementation of ECDSA and Schnorr signatures.
Be advised that cryptography should be implemented by experts. It's very easy to shoot yourself in the foot if you don't know what you're doing (and in fact, even if you know what you're doing).
Having said this, here's a high-level overview:

secp256k1_ecmult_gen gets as input a scalar a and computes the multiplication aG with the standard generator G. This function is constant-time in the scalar a, i.e., it ensures that the timing of the computation does not leak information about a. That's why it is used whenever the scalar is a secret, e.g., for key generation when computing the public key xG from the secret key x, or for signing when computing the nonce rG from the secret scalar r. In general, the requirement for a constant-time implementation makes makes code slower (for example, you can't have early returns).
secp256k1_ecmult gets as input two scalars a, b and a point P, and it computes aP + bG. This function does not ensure constant-time computations. This computation is exactly what is necessary for signature verification, and the function is suitable because no secret values are involved in verification.
There's also secp256k1_ecmult_const. It gets as input a scalar a and point P, and it computes aP in constant-time. (So in terms of functionality and security, it is a more general variant of secp256k1_ecmult_gen that works with arbitrary points P. As such it is less efficient because it cannot rely on some precomputation techniques that require to know P upfront.) This is used as a subroutine in the ECDH (Diffie-Hellman) module for computing the shared secret in the key exchange.


How can Blackcoin get 1st confirmation in 10 seconds? According to it's official page, Blackcoin used scrypt as its Proof-of-Work during the phase of initial coins' creation. But now it's purely Proof-of-Stake, and they claim to have a speed of just 10 seconds for first confirmation (and only needing 10 confirmations to get an almost guaranteed transaction).

How does their pure PoS model serve to verify transactions, without the risk of double spends?
How can they create blocks as often as 10 seconds without having massive amounts of orphans?

Blackcoin is a fork of Novacoin which is a fork of Peercoin which is a fork of Bitcoin.
In your own answer on how PoS mining functions is the answer to this question:

For Peercoin specifically, PoW and PoS blocks are independent. Just as you're betting your consumed electricity and CPU-time vs. the possible PoW-blok's reward, in the PoS blocks you're betting your coin-age: the amount oF PPC you own multiplied by the number of days they've sitted idly at your wallet. It must be a minimum of 30 and a maximum of 90 days for your coins to start generating tickets for the PoS raffle.
Should your ticket win, you earn 1% interest and lose all your coin-age, so your coins are, from the network POV, as though you had just received them. I.e. you'll need to wait another 30 days for them to be able to pay you interest again. Over time, though, you're just supposed to earn about 1% annually.

Honest nodes will only attempt to generate blocks if their stake is below the limit.  This cuts down on traffic immensely.  Looking out for violators cuts down on DoS as well which has only strangely been recently implemented in some coins.
I could find no major deviations from NovaCoin except for a decreased block spacing which may or may not apply to the PoS portion, faster coin maturity, and a few additions to net.cpp communications.
I have found no posts complaining about orphan blocks or any remarking that there are few except for this question.
I have found a few posts claiming that PoS will create extra traffic but nothing to substantiate it.
In short, BlackCoin appears to be the PoS Fastcoin, and throttled PoS will produce no more bandwidth consumption than PoW.
Throttling mechanisms
NXT
NXT is much more controlled than the other PoS coins:

What does this transparency mean? It means that anyone can predict (with very high probability) who and when will generate next block(s). And this gives us superior advantages:

Transactions can be sent directly to the miner who will mine the next block (if he decides to reveal his location on the Internet), thus saving traffic and coming much closer to VISA/MasterCard processing volumes.
Blocks can be generated in advance and sent to most of the miners before they become valid (timestamp validation), thus greatly reducing rate of orphaned blocks.
Due to ability to predict timestamps of future blocks (rate of blocks) it becomes possible to set appropriate fees to assure quick confirmations for important transactions (without paying too much for inclusion into a block).

NovaCoin
This will seem more familiar:

Novacoin uses the mixed Coin-Age/CoinDayWeight approach to provide proofs of the stake. The proof-of-stake difficulty is adjusted so as to limit the rate at which new blocks can be generated by the network to 10 minutes target spacing rate. Due to the very low probability of successful proof generation, this makes it unpredictable which computer in the network will be able to generate the next solution.
It's performed through scanning all available inputs in order to find lucky one that satisfies following condition:
SHA256(SHA256(KERNEL)) < CoinDayWeight *  NetworkTarget
Miner has to find a SHA256 hash that is under the target value.

In NovaCoin's case, it's still a little PoWish, but traffic is cut down because those who cannot mine because of insufficient stake either don't or are blacklisted for violating the rules.
Once a node has a conforming block, it stops working on that block index and moves to the next.  Eventually, no one is left working on the wrong chain.
BlackCoin
Based upon the above inspection of the code which is a fork of NovaCoin, BlackCoin works in an almost identical way except the spacing is tuned way down, and there are a few network enhancements to make the network a little stricter.
As a side note, based upon bitinfocharts's calculations, the 10 second advertisement is never met on average and is more like a lower bound; however, the intended spacing is one minute, so either the spacing formula is wrong, or PoS is actually so performant that it has busted the formula.
Ophan management
NXT is the extreme case.  My guess is that it rarely has any orphan blocks because the subsequent miner is selected, so an orphan is generated from a network malfunction rather than by design.
NovaCoin's first line of defense is PoS which limits the number of potential miners.  Since the longest conforming chain is accepted just as with PoW, hashpower dedicated to a losing chain is reduced for each now block index.


Can the Government step in, to ban bitcoins? The price of bitcoins increase with demand. Demand increases because people can spend the bitcoins. I think the price of bitcoins started as a drug money. The main advantage of bitcoins is that the sender or buyer is anonymous.
However that does not cause the increase in demand to what it is now.
I believe the current demand is increasing as more people are accepting bitcoins, and seeing this, more people are buying it.

If the government makes bitcoins illegal, people would loose trust in the bitcoins and the prices will go down.
Cant this cause the prices to go down?

I think that banning bitcoins and enforcing the ban would be a huge endeavor. It would be expensive and probably politically unpopular. See this question: How much would it cost for a government to undermine Bitcoins? Also see What methods could a government use to shutdown Bitcoin?


Does BIP148 (UASF) offer any replay attack protection? Is there any protection against replay attacks in BIP148?

Despite the popular name (UASF), it's effectively a hard fork (in the sense users with old nodes will be on a different chain), is there any protection against taking the transaction from the longer chain and putting it on "UASFCoin" chain, or vice versa?

Something like Ethereum with EIP155 / chain ID.

No. BIP 148 is a soft fork as the BIP 148 chain is valid to all non-BIP148 nodes and can wipe out the non-BIP 148 chain if it were to be longer than it. Because it is a soft fork, there cannot be any replay protection otherwise it would become a hard fork.


Is This a Bitcoin Scam? Is this a bitcoin scam? He is not asking for my username and is having me change my password before sending him the link to my mining wallet.

A bitcoin miner on LinkedIn wants to mine for me.

He asked me to set up a blockchain account and follow these instructions.

Click on REQUEST, you will see your mining wallet address there, Copy it and paste here or screenshot it and send here.
Change the Default password.
Click on Security Centre, then Click on Advance, you will see Change Password. then use any password of your choice. You are to change only the first change password you will see.
Follow the above steps and complete them and notify me when done so we can determine your mining hash power rate so that mining can start immediately.

Login using the Default password below.
Password: @miningserver2

Next, in that the same email you received from blockchain, open the message, under it you will see your Wallet I'd there (its a long combination of number and alphabet). Click on the wallet ID link, it will redirect you to blockchain login page.

Check your email, you will see a message from Blockchain , open the message and verify the message you got from blockchain by clicking on the verification link

Your details has been successfully registered

Always be watchful for any promise that you will receive bitcoins by creating an account or any other thing. Bitcoin is money and like real money, it is not easily given. In the crypto world, unfortunately, there are a lot of scammers, be aware.


Normal hashrate but no accepted shares in For the moment I'm trying to mine altcoins using an AMD HD6850.
The version of cgminer is 3.7.2. The pool I'm using is prohashing.com.
It's a scrypt-mining pool which mines the most profitable coins at the moment. When I'm connecting to the pool, I get decent hashrates for my GPU (200Mh/s), but I get no accepted shares... When I look on the prohashing profile page I see that next to my worker there's following message:

"This miner is not responding to work restart testing, so a suboptimal default value was chosen. Use the r= password argument to manually set a default value."

My main screen is looking like this:

My configuration file is as following:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer.exe -o stratum+tcp://prohashing.com:3333 -u CoinHunter -p "" -I 13 -w 256 --thread-concurrency 6144

Changing the difficulty or mining a specific coin didn't do the job...
Someone who has an idea?

200Mh/s is impossibly high for an HD6850 mining scrypt. My bet is that you're mining SHA256d, not scrypt. I don't see a -scrypt in your configuration file.


It is said that never reuse an address, but the news is stating biggest bitcoin addresses are buying? It is said that we should never reuse addresses, so I think one time into the address, and one time out, and that address should be abandoned.
So the top holders of bitcoins should know that too, but the news is having headlines:

Top 100 richest Bitcoin addresses bought 17x more BTC than sold in last 30 days
Top 100 Bitcoin addresses accumulated $11B more BTC in the past 30 days

So why aren't they following this simple rule?

This is mostly about privacy

Because they don't care about their privacy

Because they don't care about their clients/customers/friends' privacy

Because they want to keep their code simple

Because they don't want to keep a database of their addresses

Because their identity is already obvious: This is the case for exchange wallets

Because multisig addresses whose transactions require mulitple private keys to be signed are one each and I'm not aware of a "multisig hierarchical deterministic wallet" system. Multisig addresses are intended for reuse, at least until someone finds a way to solve this


Security risks with running bitcoin core, and how to protect yourself I'm new to bitcoin and want to help the network by running a full node. I plan to download bitcoin core from the bitcoin.org website, and run it on a spare laptop, by my concern is how do I protect my machine from attack? As I understand it, my IP address will be visible to see. Do I install specific security software or are there other practical steps for me to take?
I would appreciate it if answers can be made in simple, and if possible not overtly technical terms as I'm new to all of this.
Many thanks.

How do I protect my machine from attack?

The most important thing is to download Bitcoin Core from the correct destination. You can download it from bitcoincore.org or the source code can be found on the Bitcoin Core GitHub repo. If you download it from a malicious party's destination you could have serious problems. Luke Dashjr has a blog post on the extra precautions you could follow to make sure you are installing the correct software but this may be a challenge for you if you aren't technical.

Do I install specific security software?

No there is no specific security software to install. Depending on your operating system some may recommend an antivirus software but that is general security hygiene not specific to Bitcoin.

As I understand it, my IP address will be visible to see.

Yes your IP address will be visible to peers that you connect to unless you use Tor. (Tor is recommended if privacy is especially important to you.) However, if you choose to use a clearnet node and you don't want your IP address to show up on sites like bitnodes.io you can run a non-listening node by disabling listening. You do this by configuring with the -listen=0 flag or putting listen=0 in your config file. This way you can't be contacted by nodes you aren't directly connected to. The downside to this is that you aren't helping the network as much and you will typically have fewer connections.


The "01" byte at the end is the sighash type byte (specifically, 01 means SIGHASH_ALL, indicating that all inputs and outputs are signed). Such a byte is required for all signatures in Bitcoin scripts (both in legacy and segwit signatures). However, that byte is part of the DER-encoded signature; it's appended to it.
Presumably your hardware wallet produces the DER signature without the sighash type, and whatever software you use to construct the actual transaction is responsible for adding it.


How can I keep my wallet secure? The standard Bitcoin client does not encrypt wallet files, so any malicious user that gains access to this file will be able to transfer all the coins to their own wallet.  Furthermore, if I lose the wallet file then I lose access to those coins.  What steps must I take to prevent loss of coins like this?

One method commonly in use is an "offline wallet."

To generate an offline wallet, launch a bitcoin client on a known clean computer, virtual machine, or use a bootable Linux distribution like LinuxCoin. Make sure this system is NOT connected to the internet for this process. When the bitcoin client is first launched, it generates a brand new wallet.dat file with one address. Save that wallet.dat file to a thumb drive along with a text file containing your new bitcoin address. Delete the wallet.dat from the machine once you've copied it.

Any coins sent to that address are only accessible to someone holding the wallet.dat file on your thumb drive and since the computer which generated that thumb drive has never seen the internet so it's a pretty fair bet that your copy is the only copy. Send any coins you want to secure to your "offline" wallet's address and use your thumb drive to recover the coins when needed. Remember that once you've used the wallet on the thumb drive, it is now "burned" and a new one must be generated.

Edit: There is an excellent resource for wallet-securing techniques available on the Bitcoin wiki which also covers backup methods, encryption and many other topics at far too great a length to cover in a single answer.


Selling copies of blockchain database on disc Is it ethical / legal / at all possible to burn a copy of the Bitcoin (or any cryptocurrency) blockchain to a disc, and then sell the disc? Would there be any additional issues if we included a copy of the client (and associated source code)?

The idea is to make it easy for people to get started using Bitcoin without having to download 6 or more years' worth of blockchain data. The content would essentially be the Bitcoin data directory (minus the wallet.dat of course), and, if possible, the client. Users could insert the disc, install the client, and have the entire blockchain as of the date the disc was published.

Is this legal under the terms of the MIT license? Is there another license covering the blockchain data itself? Would anyone actually be interested in something like this?

I was thinking that perhaps something like this could be published annually, with the profits going to support the Bitcoin developers.

Is this legal under the terms of the GPL?

Bitcoin Core is distributed under the MIT license which explicitly allows this.

The content would essentially be the Bitcoin data directory (minus the wallet.dat of course), and, if possible, the client. Users could insert the CD, install the client, and have the entire blockchain as of the date the CD was published.

This is not recommended. Beyond modifications to the software (which can be caught with signatures) distributing a raw synchronized database is very vulnerable to tampering. The unspent outputs database can be silently modified to include non-existing outputs which the user would be likely to discover until it is too late. With knowledge of the people running a corrupted database an attacker can fork those users off the network very at their leisure, or if they accept zero confirmation transactions the victim can be directly defrauded at nearly no cost.
When a bootstrap.dat was distributed as a faster way for users to sync with the network it was always completely verified to avoid this type of attack.

Users could insert the CD, install the client, and have the entire blockchain as of the date the CD was published.

From a feasibility perspective this would actually be 60 CDs, or 7 DVDs at the time of writing.


Bitcoin transactions validation process I have a general understanding of building blocks. But am hoping someone can fill in the details/gaps. Also, can you correct if something is not right? Thanks.

Scenario:

Bitcoin transactions are broadcast to the bitcoin network.
Nodes receive the transactions.
Each node puts the transactions into their own internal mempool - or is it a network mempool that all nodes draw transactions from?
At some point, some nodes begin mining (hashing to find correct hash with leading zeros). When does this begin? I assume as soon as possible since it is a race. So then, it does not necessarily use the data in a fully built block, right?
At some point, the mining nodes fill up a block with transactions from mempool (they pull the ones with highest fees). Each node validates each transaction it puts into its block against the entire blockchain.
When a node finds a winning hash, it announces the winning parameters to the network.
The network can easily check the hash using the parameters (dataset, nonce
value, etc.) that the winning node sends out.

So here's where I am a bit unclear. How/when do the transactions in the winning block get verified by the rest of the network? Is it during the time when they verify the winning hash? Do they also verify that all transactions are good at that time?

How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?

Thanks.

Everything MCCCS wrote is good, but just to clarify on your last question:

  How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?

This question is slightly misguided: there is no 'accepting a block into the bitcoin network', because this assumes there is some network-wide threshold of acceptance that must be reached, or some sort of central yes/no switch for a block's acceptance.

The reality is that the network is made up of independently acting nodes. Each node decides for itself whether or not a block is valid, and it is by these 'consensus rules' that the network happens to come to agree on what the longest (most work) blockchain is. Once a valid block is broadcast, each node will independently work to verify that it is valid, and then add it to their local copy of the blockchain if it passes all the tests. The network is designed such that we expect all nodes that follow these consensus rules will remain in consensus, even though they are acting independently.


What are some good resources for understanding Bitcoin? I've tried to read about what a Bitcoin is, how to mine, etc.  I find them to be confusing in that I don't understand the underlying factors driving Bitcoin.  Everything I've read seems to assume the reader has some knowledge of Bitcoin (even the wiki).  Where should I start?

I wrote the "New to Bitcoin? Start here!" post at bitcointalk.org.

OrigamiRobot, I highly recommend that you read that introduction before proceeding on to anything else, especially the original whitepaper, which is incredibly unapproachable for the average person.  After you finish it, come here and ask about the things that still confuse you--Bitcoin is very complicated, and it can take a while to wrap your head around it!


how does bitcoin's 6 confirmation really help? I've read the following:

transaction is “confirmed” once it is buried 6 blocks into the
blockchain. This is taken to be a sufficient proof of work such that
reversing 6 blocks to double spend coins in a specific transaction is
infeasible. As we mentioned

Let's say Alice's blocks(honest node) is A->B->C and I included my transaction into that node which transforms 1BTC to starbucks to buy some coffee. (I am a malicious node), so my local chain is A->B->C' (note: It's C' and not C, and C' doesn't include my starbucks transaction, since i am trying to use 51% attack and double spend).
Now, Alice and other nodes do append blocks to their chain. Let's say A->B->C->D->E->F->G->H->I->J. That's great C block is already more than 6 deep into the blockchain. While Alice and others were building this chain, I am also building my chain(I have 51% hash rate power). and My local chain now looks like this A->B->C'->D'->E'->F'->G'->H'->I'->J' . Now, I solved one more and now after J', I also got K'...
If I now broadcast this, Alice is gonna accept this(longest) and I still double-spent it...
So, how does 6 confirmation really help at all? if someone has 51% power, 6 confirmation really doesn't matter. Any easy and good explanations about this?
My observation and answer IMHO:  I think 6 confirmation doesn't solve double spend or 51% attack. It's for the situation when blocks get mined at the same time. If that's the case,it's possible that someone's transaction might get slashed since other longest chain will appear after blocks don't get mined anymore at any given point. So 6 confirmation means that blocks don't get mined at the same time for 6 times sequentially. Correct ?
UPDATE: @murch This is what you're saying:

Generally, requiring more confirmations before considering a
transaction reliable makes reorganization attacks more expensive

And This is the only thing I don't understand.
If a malicious user has 51% attack power, why would more confirmations make it harder for him to attack ?

HN(honest Node) - A->B->C
AN(Attacker Node) - A-B-C

Attacker makes a transaction to HN (sending 5BTC to some merchant). but not in his own node, since it's local and doesn't broadcast. So we have the following:

HN(honest Node) - A->B->C->D(includes 5btc transaction)
AN(Attacker Node) - A-B-C->D' (note D' , it's different from D - because it doesn't include the 5BTC transaction).

Scenario 1)  HN just mines nodes, and AN also mines nodes.  Let's say they mined E and E' respectively. Now the 5BTC transaction has the confirmation of 2 block. Attacker mined one more block F' and broadcasted it. HN will reorganize chain. and 5BTC is not in AN's chain anymore... So attack successfully happened.
Scenario 2) While AN mines nodes, HN also mines nodes. attacker is faster, so AN mined 10 blocks starting at D'. HN mined 5 blocks starting at D. Now even though HN's D block has 6 confirmations, AN now broadcasts its longer chain and reorganization will happen on HN (removing D block, which consists of 5BTC transaction). so attack succeded.
So, we have 2 scenarios, one with 2 confirmations, one with 6 confirmations. How did 6 help at all in these cases, or at least cease the danger ?

Generally, all confirmations are relativistic: any chaintip could still be replaced with a heavier chain! However, reorganizations become increasingly costly and unlikely the more proof of work is piled on a block.
You are right, an attacker exerting a majority-attack can censor or rollback any transactions, and thus perform a doublespend-attack to return a payment they previously made to another party to themselves (also see What can an attacker with 51% of hash power do?).
If you are receiving payments that are orders of magnitudes larger than block rewards, you should consider additional precautions (e.g. KYC, collateral, waiting for more confirmations). The occurrence of a sustained majority attack on Bitcoin could be considered a fatal scenario for Bitcoin: no transaction could be trusted anymore at any number of confirmations.
You may have read that Bitcoin requires the majority of the hashrate to be "honest" to work. Honest in this context means "not collaborating to attack the network" or "independently creating good-faith blocks". Fortunately, it is rather expensive to control the majority of the hashrate. Each block reward is currently worth about $70,000, so a six block majority attack would likely cost $350,000+ in electricity cost alone. Additionally, it would require access to a majority of highly coveted and expensive hardware. Industrial Bitcoin miners have made enormous investments into application specific integrated circuits (ASICs), which can be used for nothing else than SHA-256d mining. The most likely way for a majority attack to come to pass on Bitcoin would be for someone to take over the mining controllers of multiple of the largest mining pools. I would hope that this would be discovered and remedied quickly.
That is not to say that your majority attack scenario hasn't come to pass before. Especially minority forks of larger networks, or other coins that use the same hashing algorithm than bigger networks have been majority attacked in the past. For example Bitcoin Gold was attacked with a 1,300 block reorganization in January 2020.


How to get the outbound and inbound capacity of a node using LND? I expected to find an option on lncli to get the exact inbound and outbound capacity of my node, but this is not the case. What is the best way to have this information?

lncli listchannels will tell you the local balance and remote balance of each channel (in satoshis).

You could simply sum up the the balances of all your channels to find the total outgoing capacity (local balance) and incoming capacity (remote balance) you have. Here is a one-liner that reports the sum of your inbound capacity (requires jq):

lncli listchannels | jq -r '.channels[].remote_balance' | awk '{sum+=$1} END {print sum}'

lncli channelbalancewill give you the total outgoing capacity you have, but until AMP is commonplace, it may be more useful to know the capacity of your largest channel alone.


How to send bitcoin from an address created at Coinb.in? I made a bitcoin address here:
https://coinb.in/#newAddress
How can I then send bitcoin from there once it receives some? I can't find any website services or android apps which let me import a private key to do that. (And to check the balance)
Thank you

Fortunately you have many options.
The bitcoin core client allows key import with importprivkey
Adds a private key to your wallet. Requires a new wallet backup.
Hint: use importmulti to import more than one private key.
Note: This call can take over an hour to complete if rescan is true, during that time, other rpc calls may report that the imported key exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes.
Arguments:

privkey    (string, required) The private key (see dumpprivkey)
label      (string, optional, default=current label if address exists, otherwise "") An optional label
rescan     (boolean, optional, default=true) Rescan the wallet for transactions

Alternatively there are many wallets out there that allow importing or sweeping a private key. Some of these include Electrum, Mycelium and Samourai (these are examples, not recommendations).
Lastly, coinb.in, the site you used to create the key allows you to build a transaction and sign it as well https://coinb.in/#newTransaction. I wouldn't recommend this for a novice user as you can end up losing your funds to miners fees if you do not include a change address. If you don't know what a change address is don't attempt this approach. You can practice on testnet or with small amounts until you get comfortable you know what you are doing.


How to find Reused R values I use software from  https://github.com/ca333/rng-scanner , I try to find r that is reused. from the software I found results

Bitcoin Address : 1GQdrgqAbkeEPUef1UpiTc4X1mUHMcyuGW
In Input NR : 141 ~ 220020a271a0897f1b7a7f0db9acb517ae2b6d53dda3833808d02c6a1cc21dc1a68680
Resued R-Value : a0897f1b7a7f0db9acb517ae2b6d53dda3833808d02c6a1cc21dc1a68680

How do I find the s and z of the reused r value?

This is list of many repeated random (ephemeral) keys used in bitcoin: https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k

AFAIK ever since around 2015, nearly all bitcoin wallets use RFC6979 (https://tools.ietf.org/html/rfc6979) which is a deterministic algorithm to get the ephemeral key instead of using an RNG so I highly doubt you'll find any recent ones (after around 2015)


What are all the different fees used in Ripple? This article mentions two fees:

200 XRP for creating an account
50 XRP for creating a credit line

Is the credit line fee one time or per credit line? Are there any other fees in Ripple? Is there a place that summarizes all the different fees, both inherent in the protocol and determined by gateways/users? This answer is rather comprehensive, but it doesn't mention fees for credit lines nor the number '50', so it isn't be complete.

The answer you cited discusses the fees that can be charged on fiat currencies by gateways, when exchanging currencies, and when using other users to swap IOUs. The XRP fees are imposed by the network itself.

The transaction fee is the only fee that is destroyed. Currently, it is 10 drops per transaction under normal load conditions. (A drop is a millionth of a Ripple.)

The fees you mentioned are actually reserves. Reserves are amounts of XRP you must hold to maintain an entry in the ledger. The reserve is returned when the entry is removed, however, there is no way to remove an account. The reserve is not destroyed, it stays in the account. You can use your reserve to pay transaction fees. You just can't create a new entry if you don't have the reserve to cover it.

Currently, the only entries that require a 50 XRP reserve are credit lines and offers. It is expected that future entries, such as contracts, will also require a reserve. A credit line only counts towards your reserve under some circumstances. Other people can't extend credit to you and increase your reserve.


How are transaction fees computed For example, how much would the fee be to send $350 to someone? The person is trying to tell me it would cost $270 for 225 bytes

The Bitcoin transaction fee depends on :

The size of the transaction
The current feerate

The transaction fee in $ depends in addition on the price of a bitcoin in dollar.
Simply put, the size of the transaction basically depends on the number of time you received bitcoins in the past (if you want to send 350$ the transaction size will be higher if you received a hundred times 3.5$ than if you received ten times 35$). This is the number of inputs of the transaction.
The feerate depends on the current demand for block space.

The bytes were 225

The estimated fee rate for your transaction to be included in one of the next ten blocks (1h40) is currently of 0.00002121btc / kilovbyte.
The current price of a bitcoin in dollars is about 8800$ / btc.
This transaction would cost you about 0.042$ (to be confirmed in the next ten blocks).
>>> 0.00002121 * 225 * 8800 / 1000
0.04199579999999999


Proof of Work vs. Proof of History Can someone explain the context of what Nakamoto exactly meant with: "To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-
of-work system..."? I don't quite get the importance of the time aspect, since the timestamp header field seems not to be very important. Maybe someone can clearly outline, with real use cases and thought experiments, which exact problems we want to avoid to run into. Solana's proposed proof of history method (with Verifiable Delay functions) tries to exactly solve that problem.
What I don't get: why is the passing of time the only thing we really want to prove? Concise problem descriptions are essential to understand the solution and caveats associated with it.

To put it simply: digital things are infinitely reproducible with very little cost, and so if we are attempting to create a digital money system, we need to make sure that users cannot simply copy & paste their money, to create (infinitely) more money. Functionally, this means that we need to solve the double-spend problem, and to do that, what we ultimately need is a way to give all transactions an explicit ordering. If we can reliably determine the order of transactions, then we can keep track of the network's state, and ensure that no user is allowed to spend their funds more than once.
With centralized systems, this is easy: you just trust the network admin to decide what the order is, and all other participants must follow suit.
But with a decentralized system... how do you create this ordering, in a way that all participants will reliably agree upon? The solution to this problem, as provided by Satoshi Nakamoto, is the bitcoin blockchain. It is a clock, with each block being the next 'tick' forward in the network's ongoing history.
This is the crucial point that allows the network to prevent users from double-spending their funds.

I don't quite get the importance of the time aspect, since the timestamp header field seems not to be very important.

The timestamp in the block header is more or less a sanity check, and it is used to help calculate network difficulty. More info can be found here.
This timestamp is not used to order transactions though, the blockchain itself is the 'clock' that provides that functionality.


How many IF/ELSE/ENDIF can be used in a script? Besides the 520 bytes consensus rule limit, is there a limit on how many of each OP_IF, OP_ELSE and OP_ENDIF can be used in a single script?

For example, a company that has 3 people in its purchase department would like to make a fast purchase if all people in the department agree and slow it down in case not everybody agrees, but not make it impossible in the final:

Alice, Bob and Carol store funds in a P2SH address. Initially, all 3/3 of signatures are required initially.
After some time, (OP_CHECKLOCKTIMEVERIFY) just two of them can spend (2/3 signatures required).
After more time, (first OP_CHECKLOCKTIMEVERIFY + more time), any one can spend (1/3 signatures required).

How would a script like this look like?

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

some pseudocode:

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


What is the purpose of submit header relative to submit block? I understand what the usage is for submit block, but submit header exists in the RPC API reference.  Is that a legacy function?  Or can it still be used?
Thanks

The `submitheader RPC checks the header against the candidate chain tip to check if it is valid(i.e has sufficient PoW).

Is that a legacy function? Or can it still be used?

This can still be used today. It's primary use in quickly checking if a certain header is valid without actually checking the entire block (compared to submit block). This is computationally much cheaper than checking the entireblock which involves checking the double spends, transaction signature verification, Merkel root calculations etc.
For example, you can implement the chain sync logic using headers-first outside bitcoind using this RPC. And according to the submitheaders PR, it was required for implementation of BetterHash protocol.


How do i parse the zeroMQ messages in java? This is the code that i have. I receive messages from the zeroMQ however a hashtx message for example looks like this --> "hashtx Ř�����v����|(8d �!��v��&�-�k�". Any help in turning that into a real hashtx is appreciated :)

public static void main(String[] args) {
    ZMQ.Context context = ZMQ.context(1);

    // Connect our subscriber socket
    ZMQ.Socket subscriber = context.socket(ZMQ.SUB);
    subscriber.connect("tcp://192.168.137.211:28332");

    subscriber.subscribe("rawblock".getBytes());
    subscriber.subscribe("hashblock".getBytes());
    subscriber.subscribe("rawtx".getBytes());
    subscriber.subscribe("hashtx".getBytes());

    while (!msg.equalsIgnoreCase("END")) {

        String printMe = new String(subscriber.recv());
        System.out.println(printMe);

    }

}

Bitcoin Core does not give you strings for the data from ZMQ. It provides the raw bytes of the transactions, blocks, and their hashes. You will need to interpret the received data as byte arrays and handle them appropriately.


Can the blockchain be outpaced by a chain of low-difficulty blocks? Let's say someone creates a blockchain fork starting from the genesis block, when the difficulty was absurdly low compared to today; then he starts mining new blocks from there up to the current block index.

Normally, this would require such an amount of time to make it completely impossibile to catch up with the real blockchain; even if he used today's powerful mining hardware, the difficulty increase would compensate for it quickly. But, here's the catch: he customizes his mining software to not ever increase the difficulty, even if it's mining hundreds of blocks per second; block timestamps are simply faked in order to make it seem they were generated at ~10 minutes interval.

When the fake blockchain is longer then the real one (currently ~300000 blocks), he starts broadcasting it; it appears to conform to all rules, and it's longer than the current one, thus all clients and miners treat this as a winning fork and switch to working on it. Of course, difficulty increases abruptly as soon as the full network hashing power is thrown at it, and after some time block generation resumes normal levels.

But now the creator of the fake blockchain owns all Bitcoins that have been generated from the genesis block to when he released it.

Is this scenario actually possible? If not, why? How would Bitcoin nodes reacts to a 300000-blocks-long fork? Is there a limit on how long a fork can be?

There are two problems with this:

The "longest" block chain is selected not by total number of blocks, but by total difficulty.  A chain with a large number of low-difficulty blocks would not win.
The Bitcoin reference client hard-codes the hashes of a relatively recent block as a "checkpoint" and will reject any chain not containing that block at the correct height.  So any chain that diverges before the checkpoint will be ignored.


Trying to recover a blockchain.info wallet from 2013 w/ a 29 (or 13?) word phrase I'm trying to check in on some BTC I stored in a blockchain.info wallet 4 years ago (12/2013).  I can log into my account just fine, but the wallet with my coins still needs a private key.  I've got a couple .aes.json files, but I haven't found any way to import them (best I found was something called "wallet-key-tool" that might work, but none of the passwords I tried did anything - could be bad password but could also be bad software).

I've also got a piece of paper with two sets of words: one with 29 words and one with 13.  I'm pretty sure these are related to the blockchain.info wallet, but I can't find any reference to this sort of recovery phrase (everything seems to want 12 words these days).

Finally, the last option would be to do a mini brute-force attack on the key.  I'm reasonably sure I could narrow the password options down to a few thousand - are there any command-line tools that can attempt to decrypt an .aes.json file and recognize when it worked or not?

I ended up adapting gist.github.com/fcicq/3368495 to read from a file with a hundred thousand possible passwords (which I generated by permuting the inputs I was pretty sure I used to generate it in the first place).

It turns out that the wallet was double-encrypted, but this at least took care of the first layer, and then wallet-key-tool took me the rest of the way, by trying a few passwords by hand (once I found out the first password, the second was easier to guess/recall).


Blockchain and anonymous data inside the chain A Blockchain is often said to be a log of all transactions that were ever verified on a network.

I understand that therefore a purpose could be to make sure that the records are not altered. If they would, the chain would fail by its construction.

However, what do you do when you have sensitive data that you want to store in these transactions? The reason I am asking is because the Blockchain being a Distributed Ledger, everyone has access to view all the transactions/chain.

Use case example: bank transactions

A bank could launch a Blockchain to make sure that the transactions of their clients are irreversible recorded. However, these transactions might contain sensitive information (like the details of their client). When a new block is created, the entire Blockchain is validated, meaning that the person who is creating the transaction has access to the whole chain and thus the details of the client in the previous transactions.

What is then the use case and how do people look at it this type of problem from their perspective?

However, these transactions might contain sensitive information (like the details of their client).

Bitcoin transactions simply do not contain sensitive information, they need no other information other than the amount and the receiver, meaning that the publicity of it is of lesser concern. There was still implicit privacy issues in Bitcoin, but you avoid any issues with personal information being stored in the chain by just simply not doing anything that would cause this information to be included.


How would one go about selling a large amount of Bitcoin? How to proceed to sell Bitcoin in the market when the purchase was made in 2010 was a value of 21k USD.

Open an account at a suitable exchange that services people in your area. In the United States, Gemini (now called Coinbase Pro) would be a good choice. You should not be paying fees more than 1% of the prices you see on bitcoin pricing sites like coinmarketcap.

By my math, that would be about 320,000 bitcoins with a current value of approximately $900 million. (You'd have 320K BCH and BSV too, worth about another $80 million.) But it's hard to imagine that this story is accurate because it would have been very difficult to buy so many bitcoins in a single transaction back when the supply was so small.


Is there an escrow-like mechanism that doesn't involve a trusted 3rd party? We know that escrow mechanisms are easy to implement when it involves a trusted 3rd party. For example if A and B don't trust each other they can simply send their goods to C whom they both trust. Then C can distribute the goods to them fairly.

However, is there a primitive that achieves the same when there isn't a trusted 3rd party? Basically, A and B don't trust each other and they want to exchange something. Can they do this without involving any trusted party?

There's "Decred cross-chain atomic swapping". It allows two people to exchange cryptocurrencies (currently BTC/LTC/Vertcoin/Decred) without trusting on a third party nor each other.

UPDATE: There's also Lightning Network atomic swap.

You can read about it on Decred blog or Github


Why are some transactions unavailable in my debug window? I got a block and asked for the data in its first transaction and that generated an error.  The following is from the console tab in the Debug window:

10:52:52 getblock 000000000030bfd22ed67169b6bbf9ba994618fa9840642d395b56134f15176c

10:52:52
{
  "hash": "000000000030bfd22ed67169b6bbf9ba994618fa9840642d395b56134f15176c",
  "confirmations": 332460,
  "size": 216,
  "height": 81626,
  "version": 1,
  "merkleroot": "1ebda57ace225010d23d72619dbda5ee250dc4536f7c3428a9a419f06438ca54",
  "tx": [
    "1ebda57ace225010d23d72619dbda5ee250dc4536f7c3428a9a419f06438ca54"
  ],
  "time": 1285297753,
  "mediantime": 1285295165,
  "nonce": 71992579,
  "bits": "1b4766ed",
  "difficulty": 917.8307413015116,
  "chainwork": "00000000000000000000000000000000000000000000000000650ba70ddba016",
  "previousblockhash": "00000000001272fc0e0cfa9d08d854cfac681a939dccc21aecd9f7074fb0df2b",
  "nextblockhash": "00000000001bd5ac7329097b9888628c33c7adeecfc6e46f74fbab006f4c2127"
}

10:53:42 getrawtransaction 1ebda57ace225010d23d72619dbda5ee250dc4536f7c3428a9a419f06438ca54

10:53:42 No information available about transaction (code -5)

This happens in Bitcoin Classic and in Bitcoin Core.  I don't have a bitcoin.conf file in the folder where bitcoin-qt.exe lives, but I do have one where the chainstate and blocks folders are located.  It has five lines in it and each one starts with "addnode".

You need the transaction index enabled of you want to use getrawtransaction on arbitrary transactions. By default, only transactions that have unspent outputs are available.

Run bitcoind with -txindex or put txindex=1 in bitcoin.conf. You'll need to reindex.


Has the TestNet ever been reset? The Bitcoin TestNet is a network identical to Bitcoin in every respect except that the bitcoins on it are worthless because no one accepts them in payment or values them for anything other than testing purposes.  In essence, TestNet btc are valuable because they are worthless, allowing for useful experimentation when developing.

I read somewhere that one way the TestNet can be prevented from acquiring significant value and mining power is by being reset from time to time so that TestNet btc remain easy to mine and acquire for testing purposes.  This made me curious--has this ever happened before?

The current testnet is on its third iteration, somewhat unimaginatively titled testnet3.

It was put that way by this commit:

  Testnet, Mark III

  gavinandresen authored 2012-04-12

Before that, we had testnet2: (though we didn't call it that back then)

  Reset testnet with a new genesis block

  davout authored 2011-02-03

Before that, testnet:

  Gavin's TEST network as -testnet switch, misc fixes
  git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@168 1a98c847-1fd6-4fd8-948a-caf3550aa51b

  s_nakamoto authored 2010-10-19

Man, sourceforge. Brings ya back, doesn't it?

Essentially, the devs want testnet coins to be worthless for two reasons:

to make them easy to mine
because it's nice to have a place to demonstrate attacks against bitcoin without actually disrupting the network. You can show that an attack is valid without costing people real money.

Now that I think of it, we're due for a new testnet soon. Sell those testnet coins!


HD Wallets, XPUB and child private key leaks So some generalisations on xpubs and current wallet providers.

Ledger and Trezor wallets can create xpubs which can show all transactions of a wallet
When a passphrase is added, this counts as a new set of private keys along with a new xpub
The children public addresses created from sending/receiving bitcoin are bound only to the xpub from the mnemonic phrase + passphrase i.e. if you create a new passphrased wallet it will have a new xpub
Children created by these wallets are not hardened
If an xpub is leaked for a mnemonic phrase + passphrase, if you have any of the children's private keys, you can compromise the entire wallet linked to the xpub and all other children, hardened or non-hardened BUT the attacker will not be able to compromise any other meomonic phrase + paassphrase you have as it has a different xpub, and ultimately different children

My question, assuming the above is correct, it's becoming more commonplace for 3rd parties (i.e. tax tools) to make use of xpubs - I want to know how it's even possible to leak a childs private key on a trezor or a ledger as none of the outputs are able to leak these, unless I'm wrong.
Just want to make sure I'm not leaving myself too open.

Children created by these wallets are not hardened

They are m/44'|49'|84'/0'/0' for trezor one/T and m/49'|84'/0'/0'   for ledger X/S. All subsequent children aren't hardened.

If an xpub is leaked for a mnemonic phrase + passphrase, if you have
any of the children's private keys, you can compromise the entire
wallet linked to the xpub and all other children, hardened or
non-hardened BUT the attacker will not be able to compromise any other
meomonic phrase + paassphrase you have as it has a different xpub, and
ultimately different children

This is the explanation from bip32: "knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys."

I want to know how it's even possible to leak a childs private key on
a trezor or a ledger as none of the outputs are able to leak these

Private keys should never leave hardware wallets without any extraordinary cause. Usually, only the master seed is transferable as a possibility from a hardware wallet device. And there are not many reasons to do so. If an attacker is able to backdoor your device and steal keys, the fact of sharing xpubs would be irrelevant.


What do I do with a bitcoin I recieved? I was given 1 bitcoin in a paper wallet as a gift.
How do I now convert this bitcoin to spend it?

You can buy all kinds of things from https://www.bitcoinstore.com/

You could also buy gift cards using bitcoin at http://www.gyft.com/

Finally if you want to sell your bitcoin for your local currency, you'd need to open an account at a Bitcoin exchange such as https://www.bitstamp.net/ - however this is the solution I like less because they require you to send them some personal information like your ID or bank account information to overcome fraud.


Would it be possible to add an RPC call to be able to determine if a node is fully synced? After reading this answer, where Peter Wuille talks about how a node can't really tell if it is synced or not, it got me wondering if there is a way we can tell that a node is as synced as it possibly can be given the peers it is connected to.

Could we add an RPC call like getsyncstatus that would have the node ask its peers for their highest known blocks and if a majority (or some percentage) of their peers all agree on the best known block height, then it could use that info to be able to say (with not perfect reliability) how synced the node is?

So, for example, if a node has 8 peers, and 7 of them are returning 330448 as the best block height, and the client has information about block 330448, then it could give a status code and message signalling that it is up to date. If the peers give different answers (which could happen if you connect to a malicious node that is falsely reporting it's best known height OR if other peers are not fully synced), then it could give a status code and a message indicating that the search was inconclusive and they should try again later. And lastly, if 87.5% of nodes are saying 330448 and the node is only synced up to block 1000, then it can give a status code and message indicating that the node is likely not sufficiently synchronized.

I think this would mainly be useful as a way to determine whether servers are sufficiently synchronized with the network for use on some application. The responses to this question describes a way to see if nodes are up to date, but they all seem kind of hacky, and I'm not sure they would be reliable enough.

Existing Methods
The Bitcoin client does have a way of detecting if it is not sufficiently synchronized. However, to my knowledge, it's not really exposed to RPC in a nice way.
It's called IsInitialBlockDownload(), and it will consider itself not synchronized if any of the following are true:

The client is importing from bootstrap.dat or reindexing the blocks it has.
The client has not reached all of its block checkpoints.
The client has received and verified a block in the last 10 seconds AND that block has a timestamp of more than 24 hours ago.

You can call getblocktemplate, and if IsInitialBlockDownload() is true, it will come back with an error of RPC_CLIENT_IN_INITIAL_DOWNLOAD (or -10).
Drawbacks

If your Bitcoin node is down for less than 24 hours, this won't detect anything wrong when it comes back up.
It's a bit ugly.
When your client gets within 24 hours of the current block, it'll think it's up to date, when it probably needs to get ~144 blocks.
If your client stops downloading blocks while it's still synchronizing, this won't detect anything wrong.

New RPC call
Let's suppose that we're designing a new RPC call from scratch. As other posters have noted, it's not possible to determine this perfectly in the presence of malicious actors. What factors could we measure to make an educated guess?

Node uptime. Has the node been up for at least five minutes?
Node downtime. Has the node been down recently? If so, take the amount of time that it was down, and divide it a thousand. If your node has not been up at least that long, then it is not synchronized.
Block timestamp. The network is fairly liberal about enforcing this rule, but my unscientific guess is that it's usually within half an hour or so. You could use this information in a similar way to how IsInitialBlockDownload() does.
Block height of central node. This is the "Look at blockheight of blockexplorer," solution mentioned in the other question.
Your method would probably work. The only issue I can think of is that if you connected to another node that was still syncronizing, you'd fail to fail.


Start and end parameters in historical price data request are ignored I trying to do some testing on historical coinbase data. Because I can only get 300 datapoints per request. Im looping the request and change the start and end paramter to got backwards.

My requests now look like this:
https://api.pro.coinbase.com/products/BTC-EUR/candles?granularity=60&start=2018-11-09T17:11:08Z&end=2018-11-09T18:11:08Z

AFAIK they are ISO 8601 formatted and the time difference between start and end is correct.

However, im getting not 60 points but 350, so the end date is ignored and the start date also changes whenever I reload the link.

Can someone shine some light on how to correctly do the request for 1 hour of data?

The coinbase API docs say:

  If data points are readily available, your response may contain as
  many as 300 candles and some of those candles may precede your
  declared start value.

So it looks like you need to parse and remove the extra data if you don't need it.


Picture of blockchain Can anyone point me to the picture I saw somewhere but can not find it anymore where blockchain is represented as a line of blocks chained together. There was a locker on each little block, and each block was chained to the next one.
The blocks were forming something like a line/queue of blocks
I'm googling for an hour now and can not find it anymore

UPDATE 1

Here is a sketch of what I had in mind.
I'm sure I saw it somewhere but it might have been in a video about blockchain.

And then the block chain was like a very long (infinite) line of blocks

This comes from the free e-book Mastering Bitcoin by Andreas Antonopoulos:


BIP44: What's the use of internal addresses? I've read other questions (and their answers) on this but I still don't see the use for internal addresses. I get that you're supposed to send the change of a transaction there but I don't see how this benefits you, all it does is move your remaining funds on an address, right? And you could just as easily move your funds to a new external address. I understand that the point is to use an address only once, but that can also be done with external addresses.

I hope that somebody can explain what benefits internal addresses have,

Thanks in advance!

The separation between internal and external addresses comes from BIP32.

Using a different chain for each permits you to give out an xpub for just the external ones to an auditor. They would then be able to observe your incoming payments, but not your spending.


create/sign/send raw transaction from specific Wallet account I've been playing with the createrawtransaction, signrawtransaction, and sendrawtransaction Bitcoin calls.

Let's say there are two accounts in my Wallet: Account1 and the default "" account. Let's also say account balances are "" = 0.00000000 and Account1 = 0.50000000 and that the only UTXO in my Wallet references a Bitcoin address owned by Account1 as the output address and is in the amount of 0.50000000.

When I create, sign, and send the transaction to another Wallet, the account balances appear as "" = -0.50000000 and Account1 = 0.50000000, and the balance of my Wallet equals the obvious 0.00000000.

Is there any way, when creating/signing/sending a transaction, that I can specify which account to send it from?

I'm familiar with the sendfromaccount call that would accomplish this, but I want to create my transactions manually so I can control the change (when necessary) and the transaction fees.

This is not possible and you should also mind, that the accounting system in bitcoin-core has been marked for deprecation.

The rawtx commands to not cooperate with accounts.

If possible, you should avoid accounts.