When to worry about 1-confirmation payments A customer sends me a payment for some digital good at my service, where delayed delivery is a deal-breaker, so I only wait for 1 confirmation by the network before releasing the links for the purchased digital item.

The prices of these itemsrange from 0,0001 XBT to 50 XBT.

I do realize that I should probably configure my service to wait for more confirmations for more expensive items, and taken that the current reward for the miners for a new block is 25 XBT would it be safe to assume that no hacker will have any incentive from performing an attack the new block (that contains the transactions that paid for the digital items from my store) when the sum of value of the total items I have sold that have 0-confirmed payments is smaller than 25 XBT?

Likewise, would 2 confirmations (total miner reward: 2 x 25 XBT) be considered as a safe threshold for items that cost 50 XBT?

The thing to consider is, "what does the attacker have to give up in order to attack me?"  If the cost of that thing is less than the reward from a successful attack, then attacking is rational from a purely economic standpoint.  (Obviously, attacking someone comes with a non-economic moral cost.)

A miner who controls more than half of the network hash rate, and expects to maintain that control indefinitely, will lose nothing by attacking you.  This is the so-called 51-percent attack.

A miner who controls less than half of the hash rate will likely lose a chance at a certain amount of income, but how much depends on how close they get to half of the network hash rate.  I created the following image a few months ago to illustrate this:

If you look at the BlockChain.info mining pools chart, you see there are several which can make affordable attacks against both once-confirmed and six-confirmed transactions.  I suspect all that prevents them from doing so is their reputation in the community.

The others factor are:

How much can the attacker get from you in a single attack?  For example, can they order multiple 50 BTC items at the same time?
How easily can the attacker profit from an attack against you?  For example, how much can they resell those 50 BTC items for?  Most attackers aren't going to want 20 digital copies of Plan 9 From Outer Space, but they'd love 20 times 50 BTC worth of another crypto currency.

Unfortunately, this factors don't apply just to you: they apply to everyone the attacker can attack at the same time.  For example, if they can make 10 BTC by ripping you off and 190 BTC by ripping other people off, then an attack which costs less than 200 BTC is economically worth it.  This means you can't fully analyze your risk by looking just at your items.

Waiting for more confirmations will always increase your security substantially, and I expect there are few things is this world worth 50 BTC that people can't wait an hour or two for them to arrive.  (But hey, maybe I'm just not rich enough to be spending $20,000 USD on a regular basis.)

If this is all very depressing, I'm sorry.  Long term, the goal of the community will be to decrease miner centralization.  If no miner or mining pool controls more than about 1% of the network hash rate, attacks against once-confirmed transactions become both expensive and unpredictable, and attacks against six-confirmed transactions become practically impossible.

Footnote: Math

In the image above, the average cost of a successful attack here is

r * h * b / p(h,b) - r * (b-1)

Where r is the block reward (25 BTC), h is the percentage of network
hash rate, b is the number of blocks to create (confirmations plus
one), and p() is Satoshi's probability calculator from bitcoin.pdf page
7. r * h * b is the average value of work used per attempt; p(h,b) is
the probability of success per attempt; r * (b-1) is the block reward
the attacker would've received if they mined honestly.

For reference, the time (average number of blocks elapsed) an attack takes is simply

1 / p(h,b)


Why does SegWit offer P2SH nesting? I'm reading about SegWit and the BIP 141 in particular and I don't understand what is the motivation behind the P2SH nesting.

At first I thought the P2WPKH is not valid on non-upgraded nodes, so P2WPKH nested in P2SH is a way to make this a soft fork (with the P2WPKH being used only after all nodes are upgraded). But as I was looking into the definition of P2WPKH I came to a conclusion it is a ANYONE_CAN_SPEND transaction on the older nodes.

My another guess was that this might be to enable a segwit-unaware wallet to create a transaction containing a scriptPubKey, which can be redeemed later on using a segwit witness. Is that right? Are there any other benefits? It seems like a little bit too much of a hassle.

I'm not entirely sure, but I think the intent of that change is to allow non-segwit wallets to generate payments to segwit wallets. Imagine that you're a business that uses segwit, but 1% of your customers insist on paying using a wallet that doesn't support segwit.


Wallet Recovery with Bip39 Seed From having a list of bip39 seeds, is there any way of recovering a wallet?  In particular, I have a list of ~100 seeds--one of which is mine--and need an automate way of figuring out which is valid and has my funds.
Thanks

There are a few things to consider here.

First, do you know the path of the HD wallet? You can find out what type of path structure your wallet is using, and if the address with the unspent transactions was the very first one, then it would be account 0, for example.

See this on BIP44 paths...

If you know the path structure, and you know the exact address you are looking for at a given path, then you could do something like this using bitcoinjs-lib:

const bip39 = require("bip39")
const bitcoin = require("bitcoinjs-lib")

const network = bitcoin.networks.bitcoin

for (const phrase of phrases) {
    const seed = await bip39.mnemonicToSeed(phrase)
    const root = bitcoin.bip32.fromSeed(seed, network)
    const path = "m/44'/0'/0'/0"
    const child = root.derivePath(path)
    const { address } = bitcoin.payments.p2sh({
        redeem: bitcoin.payments.p2wpkh({
            pubkey: child.publicKey,
            network
        }),
        network
    })

    if (address === '3...') {
        //this is yours
    }
}

Note that this example is for P2WPKH wrapped addresses (3 prefix). You would need to change this a bit depending on the type of address you are trying to match.


Pseudocode to verify a signed message Can someone explain or point to some documents with pseudo code that would show me how to verify bitcoin address based on a signature and message. I know how to do this in clients I want to know how to programmatically do it.

Even better than pseudocode: here's some python code for message signing and verification, largely pilfered from the electrum client:

https://github.com/nanotube/supybot-bitcoin-marketmonitor/blob/master/GPG/local/bitcoinsig.py


How to minimize risk when accepting zero confirmation payments? I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like bitundo.com around), I just want to minimize the risk.

I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)

Check if the (unconfirmed) transaction appears on my own node / in my wallet
Check if the (unconfirmed) transaction appears on sites using online APIs like blockr.io and blockchain.info
Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.

If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point?

I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?

From
http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13, here is what services like MyCelium and BitPay may be doing:

More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can be increasingly certain that the transaction will be mined in the next block and receive one confirmation, then two, and so on and so forth.
What this means is that any Bitcoin transaction can be accepted with zero confirmations with a mathematically derived confidence level some refer to as “Transaction Confidence.”  This transaction confidence measure assures us that even if a double spend were attempted the original and correct transaction is already too heavily propagated to be overtaken.

But as you aptly noted, there is no 100% risk-free way of being able to do this if you don't trust the sender.  That's why the blockchain exists in the first place.
One risk of relying on "transaction confidence" is that there's nothing in the network that prevents someone from submitting a double-spend transaction directly to the miners, without broadcasting it to the network as a whole, under the agreement that any blocks that those miners find should pick their secret one instead of the one they broadcast to the network.  This is a risk no matter how much of the network sees the public transaction, which is one of the reasons why you can't have 100% confidence in a transaction that has never made it into a block.
In particular, if you accept a 0-confirmation transaction that spends inputs from other 0-confirmation transactions, the risk is much greater, because either the transaction directly to you or any of its 0-confirmation inputs could be double-spent, to your detriment.
Frankly, even 1-confirmation transactions aren't risk-free.  Even under normal circumstances, blocks get orphaned, which could create a window for double-spending, because the winning branch may not resolve the transactions the way that the losing branch did.
If you're serious about trying to minimize the risks of accepting BTC in "real-life" (a.k.a., brick-and-mortar) situations where speed is important, I can't think of a better idea than going with a service like Coinbase (no affiliation).  Those services operate on a scale where they can afford to eat losses from double-spends, which should be rare, so that you don't have to worry about it.  Currently, they have an economic incentive to increase adoption of the currency by being very attractive to merchants who choose to do so.


Limit the amount of change addresses Is it possible to limit the amount of change addresses used by electrum (and other wallets)?

I understand that change addresses will increase the level of privacy for the current user but it will also increase the transaction fees which you need to pay. The size of a transaction will be higher when more inputs (or ouputs) are needed for the transaction. Therefore i would like to limit the amount of addresses my bitcoin will be splitted to.

Having change addresses does not change the transaction fee at all.

Whether to use change addresses that are distinct or identical to one of the receive addresses is independent from whether or not to use change.

Change is created whenever the coins (transaction outputs) that are spent by the transaction do not perfectly match the sent amounts. Change results in a separate coin, independent of what address it is sent to. And separate coins need to be spent separately, independent of whether they were sent to distinct or equal addresses.

As a result, change addresses do not affect the size of transactions.


Why is the Bitcoin Wiki protected against editing? I recently found an error on the Bitcoin Wiki, when I noticed that I could not edit it.

I made an account a long time ago, so I logged into it, but still I am not able to edit pages.

Why is this? A wiki is supposed to be community-driven.

Who does have access to the wiki pages?

To prevent vandalism and spam. You can gain edit access by making a payment (in bitcoins, of course).

The payment required is (at least) 0.001 BTC, which is actually no longer trivially small in my opinion.

  BitcoinPayment is a MediaWiki extension to limit spam, by requiring a
  small one-time bitcoin payment before a user is allowed to edit or
  create pages.

  While the payment is deliberately trivially small for a normal user,
  it presents a barrier to a mass-spammer.

  Funds sent to this wiki will be used to keep the wiki online (cost of
  domain name and hosting), and remaining funds will be donated to the
  Bitcoin Foundation.


Which part of my wallet should I NOT lose? .wallet file or private/public key? Simple question.

I keep reading "don't lose your wallet", but which is the actual important part?  The .wallet file or the public/private key combo? Or is it both?

In the original Satoshi wallet (BitcoinQt), your private keys are stored in the wallet.dat file. SO essentially, you may not lose either.

You private keys are the data that grant you access to your coins, so those are the ones you should keep safe at any time. Most wallet clients call the file they store your keys in your "wallet". Various wallet apps will save the file under a different name, but mostly you can export it using the app itself or find it in their data directory.


Is there a connections limit on bitcoind? I don't know if it is a lot or a few, but I see this number of connections:

bitcoin-cli getnetworkinfo | grep connections

  "connections": 66,

It does not seem to get over 70, is there an in-built limit? If yes, can I tweak the limit of connections to get higher?

By default, bitcoin-core allows up to 125 connections to different peers, 8 of which are outbound. You can therefore, have at most 117 inbound connections.

I think there is no need to handhold bitcoind to control the connection management.

You could try to limit the maximum connections with -maxconnections=<num> to reduce the amount of internet traffic produce by your node.


Is it true the genesis block reward can't be spent forever? Is the genesis block reward forever unspendable?

There is no technical constraint causing the genesis block's reward to be unspendable forever.

It is a bug that has now become the accepted standard.  In the future the genesis block reward could be spent but clients must be updated to fix this bug or they will reject blocks containing a valid input referring to this transaction (4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b).

Other clients outside of bitcoind, like btcd, also mimic this bug so they don't risk a fork if Satoshi ever decided to spend these coins.  Seeing that Satoshi isn't around much fixing this bug isn't exactly a priority and there is a good chance that this might never be "fixed".


Can I cancel a transaction that has not been successfully broadcast yet? In Bitcoin Core, is it possible to cancel a transaction whose status is:

"Status: 0/offline, has not been successfully broadcast yet"

The client hasn't caught up with the network. It looks like it's going to do that first, and then send the transaction.

Is that right, or is the transaction already irrevocable?

If I can cancel the transaction, what's the best way to do that?

I tried abandontransaction but it gives the error:

Transaction not eligible for abandonment (code -5)

I did a trick back in the day when I send btc I did not mean to. If you have a backup of your wallet then load this up on a new machine and u can send the coins from that address to another, thus double spending and voiding your initial first transaction. So long as first transaction has not been broardcast then this should be possible.


What is the memory usage for checking transaction inputs? Whenever a transaction is received by a node, the node verifies its validity. To that end, it checks for each transaction input whether that input is part of the UTXO set. It is my understanding that the UTXO set is stored in the chainstate database, which is held in a LevelDB structure.

I previously thought that he UTXO set was kept available in memory, but since I've learned that it is currently about 1.2GiB in size that seems unlikely.

So, I assume the chainstate-db is stored on disk, but accessed multiple times per second to check transaction inputs. What amount of memory usage does this induce on a node?

You are right UTXO set is stored on disk on .bitcoin/chainstate directory using leveldb. It is stored in compressed state and the current size is around 1.5GB

To speed up access bitcoind uses an in memory cache which can be configured using -dbcache option.

  So, I assume the chainstate-db is stored on disk, but accessed
  multiple times per second to check transaction inputs. What amount of
  memory usage does this induce on a node?

Accessing the leveldb database itself is like accessing any other nosql database. You basically lookup the key which is the utxo and get a value as output which you need to deserialize and store in a memory variable


Could Taproot create larger security risks or even hinder future protocol adjustments re Quantum threats? I am quoting here a user named "blk014" who responded to Pieter's Taproot tweets from 24JAN. I find this user's comments very interesting and would like to ask a developer expert how much of a security issue this "Schnorr's linearity" can be in the future process of finding quantum resistant solutions? And how possibly mitigate or prevent this risks in advance?

  While both, ECDSA as well as Schnorr signatures are unsafe vs quantum
  computers, Taproot exploits Schnorr's linearity for which no
  quantum-safe replacement is known today. While making Bitcoin
  quantum-safe is already hard, making Bitcoin-Taproot quantum-safe will
  be a nightmare.

  Enabling taproot now should be supported by a rational risk
  assessment. The outcome depends on your choice of the following
  parameters: (1) time until QCs break ECC (2) time until QC-safe
  taproot replacement developed+vetted (3) time to upgrade network, ...

  what to do with ignorant/dead user that wont upgrade (Satoshi, address
  re-users) whose UTXOs become vulnerable by (1)

  Given these risks, an upgrade to tap root is not very risk averse,
  which is the appropriate approach in developing safety-critical
  systems, and which was followed so far.

  It's not just a matter of priorities, because without taproot
  achieving QC-safety is hard, but a path is at least on the horizon
  (cf. current NIST standardization efforts). After taproot, the problem
  is completely open.

  On a final note: I'm not personally against activating taproot (it's
  very elegant), but I would also like to have consensus on a rational
  assessment of the risks that are being accepted here [with Taproot].

The user goes on to describe 3 step approach to a solution, where without Taproot only 2 steps would be needed. But with Taproot a much more difficult 3rd step comes into play:

  I think there are 3 major QC problems to solve: (1) find an
  appropriate post-quantum DSA (2) solve the transition problem before
  QCs become large, (3) find a linear PQ-DSA. Items (1)-(2) have to be
  solved in any case, as long as you believe QCs will become large
  eventually.

  And Goolge's recent Quantum Supremacy experiment is significant
  evidence that we are on that track. With taproot activated, we also
  need to solve (3). If we solve (1) and (3) together, this may take too
  long to achieve (2). That's the risk we take by activating taproot
  now.

  it might push the the time to make Bitcoin quantum-secure from 5-10 to
  10-20 years, as much more research is needed. Risk assessment should
  conclude whether we have the time and want to take the risk.

Thanks for your expert views on this issue.

This particular response is approximately tripe. Building on Pieter Wullie's comment.

  find an appropriate post-quantum DSA

and

  it might push the the time to make Bitcoin quantum-secure from 5-10 to 10-20 years, as much more research is needed.

We really know what to do to make Bitcoin Quantum safe, there's been methods for doing hash based cryptography in varying forms since 1979, which predates even Schnorr in 1991. Adding a new signature type to Bitcoin can be done with a soft fork, even though the specifics of how this would work (they would likely be a merkle tree of public keys).

I personally wrote a patch for adding OP_LAMPORTVERIFY as a project while bored on a plane in 2015, other than coming up with something sensible for the formats and desperately trying to convince people not to re-use addresses (for real this time!), it's engineering that can be done on a short international flight.

  With taproot activated, we also need to solve (3). If we solve (1) and (3) together, this may take too long to achieve (2). That's the risk we take by activating taproot now.

The two are basically orthogonal, there's no difference between migrating between outputs stored with taproot and those using raw ECDSA. The existence of taproot doesn't make this any more or less difficult functionally.

If any quantum computing was a significant threat (ie, wasn't just theoretical or slower than classical computing), we would have a lot more to worry about than just Bitcoin regardless.


What are the benefits of running a bitcoin daemon? Can I get some fees on others transactions coming through my PC (creating blocks or whatever)? Transit-fees I mean.

Can I get some tiny bits of newly mined BTCs just on keep running bitcoind.exe in the background in 2013 and later?

Any other profits of keeping the full bitcoin database instead of using lite thin clients like MultiBit?

The bad side of MultiBit is you can not set the full zero fee. Official bitcoin wallet does.

You will not get anything money wise from running bitcoind, however the Bitcoin network depends on people running it for verifications.  Its providing a service to the rest of the bitcoin community.  I run it because I participate in the bitcoin community and want to give something back.

This is how the "decentralized" part of the bitcoin protocol works.  People like you and I run the daemon and it verifies everyone elses transactions, the more people who run bitcoind the more secure the network becomes.

As for your other questions, I can't speak to speculation and this website will suspend your posts if you ask opinion or theoritical questions.


How can address' hash160 be used to determine information for malicious purposes? (Ie reusing of the same address) I've been playing around with Richard Kiss's Pycoin app which is clarifying how P2PK works. I see that the hash160 of the value: (0x04) (x-coordinate) (y-coordinate) (for an uncompressed Testnet private key in this instance) gives a hash160 value used to prove ownership of the private key.

How is this detrimental for reuse of private keys if there is no issue with PRNGs providing low entropy? I understand how the Android bug was exploited (to a degree, it reused "random values"), but I fail to understand why only sharing the hash160 in a single transaction can be maliciously exploited. To clarify, I'm not talking about privacy concerns of tracking addresses through the Blockchain.

EDIT: The vulnerabilities in question (as specified in the answer are related to quantum computing and/or EDCSA weaknesses, neither of which exist)

If your PRNGs are good, you don't lose any security by using the same address any number of times. Some websites claim that addresses should not be reused because that will make your bitcoins vulnerable to quantum computers and/or some newly discovered weaknesses in ECDSA. However, both of these scenarios are unrealistic at the moment, and I think that if they do become realistic, this will be such a big problem for the world's cryptography that you won't be the first victim (unless you are Satoshi Nakamoto).


Does it make sense to design a mutable blockchain? I work in a large consulting firm which is marketing a mutable blockchain solution to its clients. But I personally fail to grasp any advantage of using a blockchain design if you are discarding immutability. Am I missing something here?

I agree more context is needed to provide a more directly meaningful answer.

But in general: a blockchain allows users to interact without trusting a central authority, instead they verify the system’s state on their own. As a user, I can verify that I own some amount of bitcoin by running a node, and seeing the transactions that paid me as confirmed in the blockchain record. I know that the network’s rules do not allow those coins to be moved unless a transaction is signed by the valid keys (which I control). If the system allows mutability, then how confident can I be that the transaction which paid me will not be changed in the future? With an immutable blockchain, the energy spent on POW mining helps guarantee this, but if mutability is allowed... ??? How can I be sure?

If some form of mutability can be added while preserving this factor of trustlessness, then maybe a ‘mutable blockchain’ is reasonable. But I am yet to see such a proposal. If the user must trust a central authority to not change the system, then using blockchain architecture is superfluous.

In reality, I suspect in most cases a ‘mutable blockchain’ would be an inefficient way to implement a database, albeit one that can be dressed up in marketing buzzwords and sold to customers more easily due to the ‘blockchain hype’.

  But I personally fail to grasp any advantage of using a blockchain design if you are discarding immutability. Am I missing something here?

Advantage: customers love blockchain hype, so they’ll be more willing to buy what you’re selling.

I’m sorry to say, but I think your intuition is correct. Frankly, such projects seem either misguided, or scammy to me.

EDIT: perhaps worth mentioning as well: allowing a central authority to alter the blockchain record creates a monstrous security risk. No matter how well intentioned or benevolent the authority is, an attacker targeting their system of control represents a huge existential risk to the network. There is no such thing as a secure backdoor that only ‘the good guys’ can access.


Script To Limit Transactions To Specific Wallets I am trying to write a script that will allow the receiver of my coins to only spend them on two wallets I specify. After that check has been done I want to perform the usual verification that the current client does to verify a transaction. This is where I am at, but I am not sure if things are in the right order, if OP_EQUAL pushes to the stack, and if OP_BOOLOR reads from it.

scriptPubKey: OP_EQUAL Wallet1_Value [Wallet]
              OP_EQUAL Wallet2_Value [Wallet]
              OP_BOOLOR
              OP_VERIFY OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

scriptSig: [Wallet] [Wallet] [sig] [pubKey]

How to use OP_BOOLOR and OP_EQUAL?

You can see the actual implementation for script opcodes in Bitcoin's script.cpp.

OP_BOOLOR does this:

[...]
CBigNum bn1 = CastToBigNum(stacktop(-2));
CBigNum bn2 = CastToBigNum(stacktop(-1));
CBigNum bn;
[...]
case OP_BOOLOR:              bn = (bn1 != bnZero || bn2 != bnZero); break;
[...]
popstack(stack);
popstack(stack);
stack.push_back(bn.getvch());
[...]

So it's effectively reading from the stack, popping the values and pushing the result.

OP_EQUAL is pretty much the same:

[...]
popstack(stack);
popstack(stack);
stack.push_back(fEqual ? vchTrue : vchFalse);
[...]

It's popping two values from the top and pushing the result of the comparison.

Is the script correct?

Let's run the scripts and see what happens! scriptSig is executed first:

scriptSig: [Wallet] [Wallet] [sig] [pubKey]

This code is just pushing into the stack, so after the scriptSig runs the stack looks like this:

[pubKey] <- TOP OF THE STACK
[sig]
[Wallet]
[Wallet]

Notice the elements are reversed. The first thing pushed goes to the bottom of the stack.

Now scriptPubKey is run keeping the contents of the stack resulting from running scriptSig. If we do that with your script...

scriptPubKey: OP_EQUAL Wallet1_Value [Wallet]
              OP_EQUAL Wallet2_Value [Wallet]
              OP_BOOLOR
              OP_VERIFY OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

...the first thing that gets executed is OP_EQUAL, which compares the top two elements of the stack [pubKey]  [sig] which are obviously not equal so 0 (false) is pushed. I'll just stop here since it won't make sense at all to continue.

Building the correct script

I guessed what you actually meant to do, and this are my proposed scripts.

First, I guess the spending user supplies [sig], [pubKey] and [Wallet] where [Wallet] is either Wallet1_Value or Wallet2_Value to be able to spend the funds:

scriptSig: [sig] [pubKey] [Wallet]

Final stack after running:
    [Wallet] <- TOP OF THE STACK
    [pubKey]
    [sig]

That's scriptSig, and it's what a user supplies when he wants to spend the funds. We're done! Let's build the next step, i.e. the scriptPubKey that checks if the supplied values are fine.

The first thing you want to do is to check whether [Wallet] is one of Wallet1_Value or Wallet2_Value. First let's duplicate [Wallet] so we can check it twice. The first step in scriptPubKey is OP_DUP. Let's run both scriptSig first and the the new scriptPubKey:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP

Final stack:
    [Wallet] <- TOP OF THE STACK
    [Wallet]
    [pubKey]
    [sig]

Of course we want to check it against Wallet1_Value first:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value]

Final stack:
    Wallet1_Value <- TOP OF THE STACK
    [Wallet]
    [Wallet]
    [pubKey]
    [sig]

And now check the top two items for equality:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL

Final stack:
    (== Wallet1, either TRUE or FALSE) <- TOP OF THE STACK
    [Wallet]
    [pubKey]
    [sig]

Now we want to check the duplicate [Wallet] against Wallet2_value but the previous result is at the top of the stack. We must swap it first using OP_SWAP:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP

Final stack:
    [Wallet] <- TOP OF THE STACK
    (== Wallet1)
    [pubKey]
    [sig]

Again, we push the value we want to check, and OP_EQUAL it:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL

Final stack:
    (== Wallet2) <- TOP OF THE STACK
    (== Wallet1)
    [pubKey]
    [sig]

The script is pretty much done. Now just OP_BOOLOR OP_VERIFY:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL OP_BOOLOR OP_VERIFY

If OP_VERIFY finds FALSE at the top of the stack it will reject the transaction. If it finds TRUE the script continues and the stack looks like this:

Final stack if correct [Wallet] was provided:
    [pubKey]
    [sig]

Which is what the stack looks like after a regular scriptSig! So the rest of the scriptPubKey is just a regular pay-to-pubkey-hash script. The final scriptPubKey is:

OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL OP_BOOLOR OP_VERIFY
OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

Actual security

Now, regardless of the order, the script is not very secure. I get this might just be an exercise in understanding scripts or is not meant to be secure (it might be only a check to avoid spending from unwanted wallets) but I think it's important to show how this is actually not secure at all.

Whenever you publish a transaction using this scheme, the output scriptPubKey is publicly available and looks like this:

OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL OP_BOOLOR OP_VERIFY
OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

Both Wallet1_value and Wallet2_value are public for anyone to see in the blockchain! The security still depends ONLY on [sig] [pubKey] since I know exactly what's required to spend the transaction, i.e. the script security is equivalent to a regular pay-to-pubkey-hash transaction!

EDIT: A little bit safer (response to comment)

  Could you require Wallet1_value and Wallet2_value be hashes instead? Then the scriptsig would have to supply a hash of one of the two wallets.

Yes. Actually it's very easy (changes shown in bold face):

OP_HASH256 OP_DUP [Wallet1_hash] OP_EQUAL OP_SWAP [Wallet2_hash] OP_EQUAL OP_BOOLOR OP_VERIFY OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

As you can see the top of the stack is hashed (OP_HASH160 or OP_HASH256, whichever you prefer) before duplication, so now you can compare the provided data to match with one of two hashes instead of values.

This is a bit better since the data is not there in plain sight. You would have to brute-force to find one of WalletN_hash. The problem is as soon as you spend it, the WalletN_value becomes public in the spending transaction, so WalletN_hash can't be used in a transaction again! It would be one-use only. If you published several transactions with the same WalletN_hash, you'd have to spend all outputs at the same time or else the unspent ones might be hijacked.

Bear in mind the scheme is still secure because there are signatures involved. If the scriptPubKey lacked the standard signatue verification it would just be:

OP_HASH256 OP_DUP Wallet1_hash OP_EQUAL OP_SWAP Wallet2_hash OP_EQUAL OP_BOOLOR OP_VERIFY

Any miner could listen for this type of transactions and, as soon as anyone tried to spend one with scriptSig = [WalletN_value], the transaction could be modified (even the outputs!) instead of relaying it since the transaction is not signed at all, so the miner could redeem the outputs himself.


What is needed to create a pool with merged mining? What is needed to create a new pool with merged mining?  (Bitcoin, NameCoin, and possibly others)?

I'd like to create a new pool that will

Include transaction fees in the payout
Charge no pool fees
Hosted on Amazon (Low latency)
Do merged mining if that doesn't create any inefficiency

I'm mostly interested in software, or general knowledge that will get me started in the right direction.

You will need to be running the standard client with some special configuration - server=1 along with rpcuser and rpcpassword set. After that, you need to build your pool server to communicate with it through Bitcoin API and handle everything else. Last part is not too Bitcoin-specific and will consume a lot of your development time (I would know, I tried it ;) ).


How to avoid contagious media stories affecting Bitcoins? There is an integral connection between fiat currencies and shop prices.

Can crypto's achieve the same shop use?

If a crypto has a giant user base, It can be less physical than Fiat. It needs to have some physical coin, institutional and material equivalence, how can that be achieved?

Can crypto's achieve the same shop use?

For Bitcoin, the trend is in the opposite direction.

Bitcoin’s soaring transaction fees, following the digital currency’s 1,300 per cent surge in value in the past year, have made it practically useless as a token of exchange in Hong Kong.
“A customer wanted to pay for a HK$56 cup of coffee, but since the transaction fee was HK$97, we had to decline,” said Paul Li, manager of the Crescent Moon in Kowloon, one of 30 establishments in Hong Kong that accept the digital currency in lieu of cash. “The transaction fee was only about HK$5 to HK$6 in August. Now there is no incentive for people to actually use bitcoin.”

SCMP

If a crypto has a giant user base

I guess Bitcoin still has by far the largest user base of all the cryptocurrencies.


How single usage of bitcoin address is resistant to quantum computing _and_ replace-by-fee? It is often said that if a bitcoin user uses addresses only once, then quantum computer cannot compromise their security since the public key is revealed only when the money are actually spent.

But how come an attacker could not detect a transaction, reverse the public key and forge a transaction from the same address with a higher fee before the first transaction is mined?

It is often said that if a bitcoin user uses addresses only once, then quantum computer cannot compromise their security since the public key is revealed only when the money are actually spent.

There's no quantum computing algorithm that can easily find the pre-image of a hash. Therefore, single-use P2SH/P2PKH/P2WSH/P2WPKH addresses are safe. Its not so much to do with single-use. Single-use helps with Privacy, but the hash protects against an adversary with a quantum computer that is capable of breaking ECDSA.

  But how come an attacker could not detect a transaction, reverse the public key and forge a transaction from the same address with a higher fee before the first transaction is mined?

This follows from the fact that there's hashing involved while producing bitcoin addresses.


Is there a reward per hash? So after reading some information about mining I wanted to know if the only reward for a miner is the block reward or if there a reward per hash, if yes how to find the amount a miner generate per hash?

The reward is per block, it can't be per hash because the number of hashes a miner computed is not known to the network. Furthermore, only the miner who finds a block is rewarded.


How can you find how many keys you wasted in bitcoinj? Supposed you create a new wallet and pre-populate it with 100 keys (so you don't need to back it up after each transaction).

How do you know, given an instance of Wallet, which keys have been "used up"? Or, in other words, if you want to use a new key for every transaction, how do you which key to use, given only the wallet state?

Are you supposed to save this information elsewhere?

Wallets contain a pool of 100 unused keys plus every key ever used. You can never run out of unused keys because the client adds new keys to the unused key pool as you use them.

The reason it maintains a pool of unused keys is so that future transactions that happen after a backup can still be recovered.

You should frequently back your wallet.dat up off-site using non-flash media. You should also backup your wallet.dat after every 50 send transactions (receive transactions do not use up unused keys unless you frequently create new addresses to receive coins with, which would also use the key pool up; in that case, every 50 transactions of any kind).


How run c-lightning with the local node bitcoin I have a bitcoin-core-18.0 with on my linux mint, and I don't have downloaded the bitcoin with the ppa but I downloaded the official zip directory on site bitcoin.

Now my question is, c-lightning with this configuration bitcoin-core?

I'm running this command and I have this error

./bitcoin-0.18.0/bin/bitcoind -datadir=/media/vincenzo/Maxtor/BitcoinCore/node/ -daemon -testnet &
./clightning-v0.7.2.1/bin/lightningd --lightning-dir=/media/vincenzo/Maxtor/C-lightning/node/ --network=testnet --log-level=debug

The error

2019-08-22T13:00:06.878Z DEBUG lightning_gossipd(9943): pid 9943, msgfd 20
bitcoin-cli not found. Is bitcoin-cli (part of Bitcoin Core) available in your PATH?

Make sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.

You can verify that your Bitcoin Core installation is ready for use by running:

    $ bitcoin-cli -testnet echo 'hello world'

Exist some propriety configuration c-lightning?

It is complaining about not being able to find the bitcoin-cli binary of the Bitcoin Core installation (which is normal since you are running it from a location that is not on the $PATH hence it can't find it).

To fix this issue you can tell lightningd explicitly which binary to use as bitcoin-cli by doing this:

./clightning-v0.7.2.1/bin/lightningd \
      --bitcoin-cli=$(pwd)/bitcoin-0.18.0/bin/bitcoin-cli \
      --lightning-dir=/media/vincenzo/Maxtor/C-lightning/node/ \
      --network=testnet \
      --log-level=debug

This will tell lightningd to use the bitcoin-cli located at $(pwd)/bitcoin-0.18.0/bin/bitcoin-cli. The $(pwd) is there to make the path absolute since lightningd will change directory internally after starting, so that relative paths might not match anymore.


btc-e price quotes throught api Can anyone give me the API details on how to access the prices quotes shown on home page of BTC-E.com.

the api link on the site does not provide details on how to access bid and ask prices.

You can get any price quotes, in a JSON format, using these kinds of endpoints:

https://btc-e.com/api/2/ltc_usd/ticker
https://btc-e.com/api/2/btc_usd/ticker
https://btc-e.com/api/2/ltc_btc/ticker

The structure of the endpoint is https://btc-e.com/api/2 and then currency_currency and then /ticker.

Hope that helps!


Where are the receiving and sending address descriptions stored? Are the sending and receiving address descriptions stored in the wallet file, or as some other file managed by the Bitcoin client app?

If I move or copy my wallet to a new installation of the Bitcoin client, will I still have my descriptions for my sending/receiving addresses available?

Yes, all of those are stored in the wallet.dat file. I myself have successfully migrated the wallet file to a new computer and have the addresses and descriptions intact.


Use BIP39 to generate SSH or TLS keys? Is it possible to use the same Bip39 mneumonic that generates addresses/keys to generate deterministic key pairs for use outside of cryptocurrency, say in ssh, tls, etc?
I know that bip39 doesn't use RSA and some conversion would need to be done, but I'm just wondering if it's possible.
For the simplest example of what I'm trying to achieve I'd like to convert the derived public/private keys from the table from here: https://iancoleman.io/bip39/ into ssh pairs, as a start.

SSH is a generic protocol within which a user can deploy keys from a variety of algorithms, one of which is ECDSA (same as Bitcoin signatures).
The Ledger hardware wallet even has an application for its devices to perform SSH signatures using keys derived from the same seed used for cryptocurrencies.
TLS also has EC available as an algorithm so there might be a way to use your BIP39 seed for this as well.


Bitcoin core wallet transactions and synchronisation I have Bitcoin Core wallet.

I wanted to know if each transaction I need sync the wallet?

(I have a new business that accept bitcoin and I must to save each transaction)

With Bitcoin Core you'll run a full node. So, for every transaction someone does to your business, your Bitcoin Core wallet need to be synchronized with the complete blockchain.


Monitor all transactions on bitcoin network - API I am searching for a solution to monitor all bitcoin transactions (or for first ties at least for addresses inside my bitcoin client).

I found http://blockchain.info/api_websocket is this really reliable? What happens if my client is offline?

Is perhaps the better way to run a bc-client an use a poll - every second?

This can be done with some degree of effort using the Bitcoin API.

v0.7 even has support for this for addresses that are not in your own wallet:

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

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

libBitcoin
Armory (see Extras)
Bitcoin ABE


How can I buy Mastercoins? What is currently the best way to purchase Mastercoins?

Are there exchanges out yet?

Do I need some special Mastercoin-Address/Wallet?

The best way for you to purchase the funds are to go to http://www.buymastercoin.com/ and make  a purchase as described on the site.

Or just go to the google spreadsheet that is used as a sort of an exchange where you can purchase from the MSC holders themselves: https://docs.google.com/spreadsheet/ccc?key=0ApGPLGUd5ZCzdHFxbnhHQjBDSDVKamY5UHlWdkNMNWc&usp=sharing#gid=0

No need for a special Wallet but it is definitely recommendable to make a new address for the Mastercoins


How do I open an Armory .wallet file in the MultiBit Client? Sorry, I'm incredibly new to this whole thing.  I started off using the Armory Client for my Bitcoin wallet then was suggested to try "MultiBit".  I've saved my .wallet file from Armory, however cannot open it in MultiBit.  Is this normal?  How does one use the same wallet?  Stick to one bitcoin client?  I also don't see the option to load a wallet on the original bitcoin client.  Is it just easier to setup a wallet with a service like blockchain?

It is normal. Each Bitcoin client makes its own choices on how it stores its private keys and balance information. The main (Satoshi) client uses a BerkeleyDB database, BitcoinJ serializes its wallet object directly to file, and other clients do other things. While I'm not 100% certain how Armory or MultiBit store their wallets, chances are they've chosen different techniques which are not compatible. If you want to switch clients, I'd suggest generating a new wallet in your new client and using the old client to send all your coins there. If you have addresses that you'd like to keep from the old client, you'll need to find some way to export the private keys from the old and import them into the new via some standard they both support, like WIF (Wallet Import Format) private keys. Sadly, not every client will give you easy access to the private keys so it may not actually be possible - I'd refer to both clients' documentation for that answer.


Unexpected result after calling RPC 'listaccounts', 'getaccountaddress', 'getreceivedbyaddress' sequentially bitcoin > bitcoin-cli listaccounts
{
  "": 5648.99996160
}

bitcoin > bitcoin-cli getaccountaddress ""
mui4xgNgZBr3XhdL4dDDHkRFEvSXZmSi7t

bitcoin > bitcoin-cli getreceivedbyaddress mui4xgNgZBr3XhdL4dDDHkRFEvSXZmSi7t
0.00000000

I expect it will return 5648.99996160 after calling 'getreceivedbyaddress'.

An account can have multiple associated addresses. Presumably you had another address associated with "" beforehand, and received money using that address.

The getaccountaddress RPC call gives a fresh address. If money had been received already on the previous account address, a new one is created and associated with the account.


Is the idea of a "honey hole" such as in gold mining, present in bitcoin mining? I understand the output of the SHA-256 hashing function is a random number between 0 and 2^256. Does the randomness of this output imply that there cannot be a, so to say, honey hole in the hashing.

For instance this reddit post, http://www.reddit.com/r/BitcoinMining/comments/1rysqh/is_there_something_strange_about_block_272754_and/

They point out that someone relayed two blocks very close together, approximately 10s apart. Could they have found an occurrence where two block solving hashes sit close to each other?

I guess this kind of doesn't make sense though. Once a block is found, or a transaction is accepted, and even for each 3 seconds(timestamp) the block header is changed. So you would really could never find a block with the same hash just one number off (same block header, with two blocks one with nonce and the other nonce+1), because the first block will not be included in the second one, the second will become a dead fork in the blockchain?

No, the SHA2 hashing function is not vulnerable to any known attack that significantly reduces the difficulty of finding a block, but it is a highly random process.

Randomness is funny sometimes. Statistically it it works out to be even over a longer time period or larger population, but if you focus in on a small set of samples sometimes you see a cluster or a gap. This is why the estimated hash rate of the network on blockchain.info is woefully inaccurate on anything less than a multi-day average, and bitcoin is based on a 2 week correction period instead of a smaller number.

(which is why the unlucky miner can't expect to find 2 blocks quickly "because" he had a drought, and you should not expect a gap to "make up for" earlier luck, it's the  population that matters.)


Getting transactions from mempool to block I have a question about getting transactions from mempool to be added to block. Imagine the situation where we have 500 transactions in mempool, when we decide that is enough to start adding them to the block? Also what if we sre in the middle of mining (so we have Merkles tree root already) and the new transaction is added to the mempool? The process of our mining in my node is starting again?

You can start to work in a block at any moment, you can even mine an empty block. If any new transaction arrives you rebuild the merkle tree and continue.


How to use API of BTC.com I'd like to get some information(BTC's difficulty, hash rate).
I think I can get that from api of BTC.com, and I checked github of btccom, but I can't mount api with python.

How Can I use btccom api(v3)?
maybe for the first time, I need to install something on terminal(mac).
It's like a [pip insall ***].

Than you

BTC.com APIs are Web APIs. This means you can use them by making HTTP requests (GET/POST requests).

Like all online APIs, you can access them through whatever program/script you want, provided they are able to make HTTP requests and handle the answers.
Requests/responses are usually encoded using the JSON format.

You can find a good introduction here.

You can choose your favorite language. However, since data is in JSON format, I would suggest to use either Javascript or Python.
In Python you can use the 'request' package. Here you can find a quick introduction.

In Javascript you have the 'request' library.
I wrote a generic lib to make Web API requests: https://github.com/frz-dev/webapi.js/blob/master/webapi.js


How to obtain the Channel_ID from the Short_Channel_ID? Is there a way to retrieve the Channel_ID knowing the Short_Channel_ID without using any lightning network explorer?

How is the Short_Channel_ID calculated? Is this operation reversible?

The short_channel_id points to the funding transaction of the payment channel by the format blockheightxtransaction_indexxoutput where the x is used to seperate the 3 values and the three values are depicted in decimal. This is at least the BOLT 1.1 agreed format for the short channel id. Previously the shortchannel id might have been encoded and depicted differently depending on the implementation. For example c-lightning used a colon instead of an x to separate these fields.

According to BOLT02 the channel_id is created as follows:

  This message introduces the channel_id to identify the channel. It's derived from the funding transaction by combining thefunding_txidand thefunding_output_index, using big-endian exclusive-OR (i.e.funding_output_index` alters the last 2 bytes).

as the funding_txid is a hash of its fields this has no relation with the short channel id. So without looking at the blockchain data I believe it is impossible transfer the short_channel_id to the channel_id or back.


Consequences to reducing `checkblocks` in console on a node? At start up it will check the last N number of blocks to verify, default is 288 or 48 hours. If I changed mine to 72, approx the last 12 hours instead are there any foreseeable negative consequences to doing so? Would my node still be considered valid, would it increase my ban score, or disable the wallet feature as it does to those who run pruned nodes, etc?

checkblocks and checklevel are simply for local sanity. It's just making sure when your node is coming up that things aren't completely crazy, it won't catch malicious alteration or set any flags anywhere. If the checks fail the node won't start up at all and will show nasty error messages. Turning them down in all probability won't have any impact on you, the only downside is that if your node state is left inconsistent the sanity check might not catch it.


Ledger Nano X stuck in loop before being initialized So I just unboxed my Nano X direct from Ledger.  I started the device and it said download Ledger Live.

So it set it down to go look for my phone.  The thing was, I had trouble finding my phone and by the time I did that, the Nano screen seemed to be in some kind of screen saver mode.  Still, I downloaded Ledger Live onto my iPhone and turned back to work with the Nano.

However, it seems to be stuck on a menu with 3 options: Close/Exit control center, Battery, Power Off.

The left and right buttons will take me through those three items all day long.

I expected pressing the left and right buttons together would take me someplace useful, but not so.  I have held the left and right button together for up to 60 seconds . . . nothing.   I have even held both button while looking at each of the three menu items thinking one of them night work.  No so.  To my surprise, holding both buttons while looking at power off doesn't power off the device either.

I never got far enough to set a pin yet, so it isn't asking for one so I cannot enter it three times wrong.

Suggestions?

==== Next Day ====

The next day it seems like the Nano X had started over.  I ran through all of the startup messages and eventually got to the point it asked if I wanted to setup as new device.  However, when I press and hold both buttons, instead of asking for a PIN it goes to the 3 options mentioned above: Close/Power Off/Battery.

I've done this a couple of times now . . . the device has yet to ask me for a PIN or try to give me restore words . . . I have no idea what to try next except returning it to Ledger.

Frank

When pressing both buttons, it appears there is some kind of "long click" that does different things than a quick press of both buttons.  Not knowing that I was consistently doing long click which confused the Nano X.  Once I figured out that a quick tap of both buttons was all that was needed to select an item, thing started getting more sane.

Having done a long click once at the very beginning, put me into that special menu mentioned above and once I was there I was lost.  However, I let the device timeout and go to sleep, then using quick/short double presses only, everything worked as per documentation.


How to redeem deposits to my wallet A couple of days ago I installed bitcoin-qc and loaded the latest block from eu1.bitcoincharts.com/blockchain/. Then to test it out I withdrew a small amount of BTCs from my mtgo account to the address that appeared in the client upon install. Not having received anything yet, I today went to blockexplorer.com and search for that address. The record shows "First seen?: Block 164269 (2012-01-28 19:37:08)" and "Received transactions: 1", but also says "Public key?: Unknown (not seen yet)". The client says today, "Catching up... Downloaded 164146 blocks of transaction history. Last received block was generated 2 days ago". Do I have to send a public key separately? If so, how do I do it? Thanks for taking the time for a beginner.

Your client won't show the transaction until it's received the block the transaction was included in. This website has the block count in the header: http://bitcoincharts.com/charts/

Right this moment, there are 164472 blocks (and I'm responding to your question quickly) so there's clearly still some downloading to do. Try to determine whether the block download is still occurring, and work from there. There should be a percentage complete figure for the block download in the bitcoin-qc client.


On multibit how do I update my sending address? I have bitcoin in my transactions but it does not appear in my wallet.
It says updates stopped

You can get the 'updates stopped' if MultiBit detects some other user or process has edited one of the MultiBit files.

If you close down MultiBit and restart it it reloads all files.

There is more help on if transactions don't appear in your wallet in the multibit.org help so also have a look through there.


Has a spend from a hybrid public key ever made it to the blockchain? If so, could you please give the TXID of a transaction that spends from a hybrid public key?

Surprisingly, there's a number of UTXO entries for the obscure hybrid key format. The transaction 657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1 makes a number of interesting P2PK outputs, two each of which are 0x06 and 0x07 respectively.
OP_PUSHBYTES_65 06da9be28d6e6266ddc0bc71b09032f3a810ffc917b5876e23a03c118f24f6a84dae4a9a5244fbf47860bc0760102d6bde6257bfcb7155d3dd66b97181119f98c5 OP_CHECKSIG

OP_PUSHBYTES_65 07d19ef6ba5b92b87078dba3a00df392efc16917defb2be08f22e41ce2873335705bff95fed463550f291d3b1fd559af11e432256a47e738572be3b74fc6f73ed0 OP_CHECKSIG

None are spent, but there's no technical reason for this, the outputs are valid.


What is an "insecure transaction type", as mentioned by Bitcoin Wallet for Android? I am running Bitcoin Core v0.11.0.0-gd26f951 (64-bit) at home on Ubuntu, and have installed the Bitcoin Wallet for Android on my phone. I sent two transactions from home to my phone: First, Second. One had a very low fee and took days, so I sent another one with a slightly higher fee which took only minutes. Both arrived though, and have almost two thousand confirmations by now and show green in the app.

The Bitcoin app now (I first noticed it today and I don't think it initially said it) says

 This payment was delayed because the sender used an insecure transaction type.

underneath both transactions. What does that mean?

I googled the phrase and got exactly one hit, in a resource bundle that is part of the code for the bitcoin-wallet project on github, which appears to be the Android app. The corresponding key is transaction_row_message_received_rbf, which generated no hits at all.

Can anyone tell me what this "insecure transaction type" could be, and why Bitcoin-Qt would be using it? Do I need to prevent it, and if so how do I do so?

TL;DR:

It seems that Bitcoin Wallet for Android incorrectly labels nLockTime transactions as OptInRBF due to a bug in bitcoinj. The issue has been reported. You don't need to do anything.

Apparently, Bitcoin Wallet for Android recognized your transaction as OptInRBF (as pointed out by the code you found). The warning you are seeing was only added to the app on March 10th 2016.

What is OptInRBF?

OptInRBF is short for "Opt-in replace-by-fee", which was added to Bitcoin Core in 0.12.0. The new version allows Bitcoin Core to receive and correctly treat replace-by-fee transactions. However, Bitcoin Core cannot create rbf transactions, yet. Wallets have to "opt-in" to send them.

Replace-by-fee is a flag that can be set on transactions to communicate that one might want to change the transaction before it is included in a block. Therefore, such transactions shouldn't be considered reliable until they get their first confirmation. After they are included in a block, they are just as safe as any other transaction.
Mining pools that support rbf will allow a newer version of the transaction to replace the older, especially if the newer transaction pays a higher fee. This is for example useful for increasing the fee on a transaction when it is stuck, or to combine multiple transactions into one when you decide to send another transaction before a previous is confirmed.

Where does the warning come from?

Looking at the raw data of the first transaction, it turns out that the transaction's sequence number is indeed below max value: It shows 0xFEFFFFFF while the maximum would be 0xFFFFFFFF. The sequence with an E in second place is an unsigned little endian long for "one below maximum". This is the sequence of a nLockTime transaction.

OptInRBF have sequences that are smaller than the nLockTime sequence, i.e. sequence < MAX - 1. Therefore, it appears that either bitcoinj or Bitcoin Wallet for Android misclassifies nLockTime transactions as OptInRBF. The problem is that since Bitcoin Core 0.11 all transactions have an nLockTime sequence.

At first glance, the bitcoinj code that checks whether a transaction is OptInRBF seems fine:

public boolean isOptInFullRBF() {
    return sequence < NO_SEQUENCE - 1;
}

However, Java natively uses big endian format instead of little endian format.
<speculation>Therefore, there may be an issue withNO_SEQUENCE - 1 which might resolve to 0xFFFFFFFE and the nLockTime sequence 0xFEFFFFFF read as big endian would appear much smaller than that and could therefore be labeled as OptInRBF.</speculation>1

I've reported the issue and am trying to craft a bug fix.

1 It turns out that my speculation was incorrect. BitcoinJ and Bitcoin Wallet for Android handle transactions with the nLockTime sequence fine, and parse it using little endian format as required. So far, the maintainer was unable to reproduce the described issue with the provided transactions (instead they were shown correctly without warning). Therefore, the reason for the warning's appearance is still unknown.

Thank you to Pepijn Schmitz, Gregory Sanders, Andreas Schildbach, and Wladimir van der Laan for help in figuring this out.


Why is there an addrlocal field in the output of the RPC call getPeerInfo, and how SPVs handle it? According to the Bitcoin core developer reference, the RPC call getPeerInfo has in its output a field called "addrlocal" which holds our IP from the worldview of the peer.

Why is this output there? Is it used anywhere? Does it have a use case?

Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?

Why is this output there?

Because it is part of the version P2P message. getpeerinfo largely outputs the information provided by the version message.

  Is it used anywhere? Does it have a use case?

Currently, no. However it may have been included in the version message because Bitcoin was originally designed for things to go directly to IP addresses. There used to be a Pay-to-IP thing where this could have been useful.

  Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?

Because it is easier to implement and no one actually uses it.


Oauth - can my application use Stellar Oauth? Does Stellar have Oauth, or is it on your road-map ?

Oauth isn't presently on our roadmap, but feel free to check back in future.


Why is my p2pool share not payed out? I'm mining Litecoins in the q30.qhor.net P2Pool node at a current rate of around 75 kH/s.

I've been reading that decentralized p2pool mining differs a bit from centralized mining pools, e.g. that you only get paid out when a block is solved successfully.

Now, I'm mining for about 8h now in this p2pool and during that time 3 blocks were solved:

Block   Time                            Luck
409925  Tue, 20 Aug 2013 17:09:16 GMT   155.4%
409848  Tue, 20 Aug 2013 14:02:12 GMT   95.1%
409784  Tue, 20 Aug 2013 12:07:41 GMT   165.1%

That means, some payouts occured during that time. I checked some of the other addresses, they really got instant payouts. But I didn't.

Address                             Hash Rate   Stale   Amount (LTC)
LV6GjHN8...someltcaddress..aWdKZ2g  2.93MH/s    4.36%   0.21685736
LWoKVQ8y...someltcaddress..2dm5FqL  2.44MH/s    5.12%   0.22766967
LedmP6yA...someltcaddress..hGBdLHW  1.97MH/s    7.02%   0.13804534
...
LUj1UAKL...myaddresshere...jWYAPA9  77.8kH/s    1.69%   -

I'm using pool's cpuminer 2.3.2 and see a lot of accepted shares.

 $ ./minerd --version
cpuminer 2.3.2
libcurl/7.31.0 OpenSSL/1.0.1c zlib/1.2.8
 $ ./minerd -a scrypt -r 1 -t 12 -s 6 -o http://q30.qhor.net:9327 -O LUj1UAKL...myaddresshere...jWYAPA9+0.00001800:1
...
[2013-08-20 20:57:05] thread 1: 168 hashes, 6.48 khash/s
[2013-08-20 20:57:05] accepted: 4270/4396 (97.13%), 76.76 khash/s (yay!!!)
[2013-08-20 20:57:05] thread 9: 4116 hashes, 6.41 khash/s
[2013-08-20 20:57:05] accepted: 4271/4397 (97.13%), 76.76 khash/s (yay!!!)
[2013-08-20 20:57:06] thread 2: 7452 hashes, 6.47 khash/s
[2013-08-20 20:57:06] accepted: 4272/4398 (97.14%), 76.76 khash/s (yay!!!)

But I did not get any payout, yet. Why?

The answer is hidden in this forum post here.

  "You have the same problem that is common in P2Pool threads, your miner is (relatively) slow compared to the size of the pool, as such you are not solving the required 1 P2Pool share every 24 hours (not the work your miner is submitting). You will get paid when your miner solves a share with a difficulty greater than the current P2Pool Share difficulty (see the website), this is currently about 1.320658 (or 87.4k in CGMiner speak)."

The PPLNS payment system is not to be considered as the best for slow hash rate miners. To get payouts, you need to:

solve at least one hash every 24h hours which is higher than the p2pool share difficulty = gets at least one payout each day.
solve at least one hash within the window of the current block with a difficulty higher than the p2pool share difficulty = gets at least one payout each block.
check if your p2pool server avoids dust payments, meaning that very small payments are hold back until a certain threshold is reached, e.g. > 0.01 ŁTC.

I'm mining at around 100kH/s (867.9 block difficulty) and only recieving payments once every four/five blocks. This is a bit discouraging but in total I'm getting higher payouts than mining in normal pools.

By the way, the minimum recommended hashrate for p2pool-miners is 590 kHash/s.

Multiply by 65536 to convert to P2P difficulty to CGminer difficulty.


QUESTION ABOUT SLOW API do you know about api requests cryptocurrency exchanges? Simple ticker request may be viewed like this: https://api.kucoin.com/v1/open/tick or like this: https://www.okex.com/api/v1/ticker.do?symbol=ltc_btc

Different: in first case we get info about all currencies in one request and then pick up certain symbols and parameters, we need. Symbols are the keys of dictionaries or lists and other params are their values.

In second case I should create new request for each currencies I considering. Is it neccesary? If I consider, for instance 60 symbols, and do operations with them in Python - programm bot become slow enough. One-two ticker requests are long about 30 sec - for compare, in first case - 5 sec.

How can I solve this problem? Thanks.

You can solve this problem by making a request to https://www.okex.com/api/v1/tickers.do (without the symbol parameter). This will give you all the tickers in one request.


Why do we need revocation in both the offered/received HTLC outputs and HTLC timeout/success outputs? The witness script for the output in the HTLC success/timeout transaction is:

OP_IF
    # Penalty transaction
    <revocationpubkey>
OP_ELSE
    `to_self_delay`
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

Which already exists a penalty transaction. While in the offered HTLC and received HTLC outputs in the commitment transaction, we have,

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
...

Why don't we put the revocation in the HTLC-Timeout/Success outputs only?

HTLCs have a different timeout (cltv_expiry) than the regular timeout that we use for penalty transactions (to_self_delay). That is the reason why we use a separate transaction stage (HTLC success/HTLC timeout) to allow our counterparty sufficient time to exercise their right to get the entire balance of the channel in case we broadcast the previous state of the channel.

To elaborate further, when your counterparty tells you to add a HTLC, your version of the commitment transaction will have 3 outputs:

Paying to your counterparty immediately
Paying to self, guarded by the revocation key for to_self_delay time
Received HTLC output like below

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

When you supply the HTLC pre-image to your counterparty the transaction gets resolved. However, even after successful resolution of the HTLC with your counterparty, let us say you decide to cheat them by force closing the earlier state of the commitment transaction containing the HTLC. As soon as you publish this commitment transaction, you publish the HTLC success transaction that consumes the OP_IF part inside the OP_ELSE. Since the HTLC success transaction is consuming an output that is not timelocked, you are not providing enough time for your counterparty to use their right of the revocation key which is in the received HTLC output. That is the reason there is a second stage, where your spending from the offered HTLC output to yourself is locked until to_self_delay which allows your counterparty to use the revocation secret.

Now you might wonder, why the revocation exists in the commitment transaction received HTLC output if it is provided in the HTLC success/timeout transactions. Let us take the above case to explain it. You added the HTLC and signed the commitment transaction. That HTLC was settled by you providing the pre-image to your counterparty and the commitment transaction containing that HTLC was revoked. Despite that, assume you try to broadcast the previous commitment transaction containing the HTLC and refrains from publishing the HTLC success transaction. If revocation did not exist in the commitment transaction, the counterparty might not be able to get their funds back until the cltv_expiry which might extend to hundreds of blocks (couple of days) if there are a number of hops. This is cumbersome since that HTLC was already settled (especially if there are number of previously satisfied HTLCs), and the provision of revocation in the commitment transaction allows the counterparty to settle them immediately.

The revocation part is designed so that your counterparty never suffers because of the actions you decide to take to cheat them. The presence of revocation in commitment transaction and the HTLC success/HTLC timeout transaction help protect the Lightning Network participants from frauds committed their peers.


Problems with Blockchain API Im having problems because when a user pay to a forwarding address, the forward address receives bitcoins instantly, but takes nearly 1 hour to send those bitcoins to the destination address, the real one, and it only calls the API when it transfers to the real one. How can a user deposit the btc instantly? or faster? Thank you!

Blockchain.info's receive API has been all wonky for the past month or two. The forwarding used to be almost instant, but lately it has been taking up to 24 hours for the payment to be forwarded.

Remember that THEY pay the transaction/mining fee for you, so they pay as little as possible which can cause a delay in transactions.

In my opinion you should try another forwarding service that is not free. I suggest you try Blockcypher's payment forwarding service. It's very similar to Blockchain's however the mining/transaction fee will be taken from the funds received and you will need to register and create a token.


How do I find the exchange an address belongs to How do I find the exchange that an address belongs to? I have an address that I have sent Bitcoin to but I forgot what exchange that address was for.

It is basically impossible to identify who (whether it is an exchange or someone else) owns an address unless they announce that they own the address. You will not be able to figure out what exchange the address that you have belongs to by just looking at the address alone.

You will have to look elsewhere, and knowing the address is not really important. Look through your emails and think of the exchanges where you have made an account on. Only through other data that you have (e.g. your emails, saved login info, etc.) can you figure out what exchanges you have used and thus potentially deposited coins to. The address that you have is irrelevant.


lost my entire transfer ok, I had put all my investments into USD wallet on Binance, then I went to coinbase.com under account tools hit the drop box for addresses took the USD address there and copied it.

I returned to Binance and scheduled the transfer. it left Binance and within an hour it came as pending on coinbase.com, where it remained 7 days.

here's the hitch. I transferred 464.00 and some change. after 7 days it shows as 6 cents in my coinbase BTC wallet.

the irony is you can't even transfer 6 cents ..and I have emailed both parties and keep getting stupid replies that are no place near what I'm asking them.

and no phone numbers to call a real person. where my money? can I get it back?

don't know if this help
but I had the same problem
COINBASE FIX IT
sent btc to my coinbase receive address but I did not cover the fee>> fee amount to low .
2 1/2 week went by it showed pending on coinbase
blockchain showed no transaction completed.

it first show back in my personal wallet
then a week later coinbase shows I received btc 0.000685 btc

    I sent 0.3555000
    but 1 week later it pulls from my wallet and goes to coinbase in full.
    so coinbase did something on there end to push it through.
    I was out nothing .
    but it takes 3 to 4 weeks for them to fix it .
    hope it help you


Does Ripple has support for HD wallets? I know Bitcoin supports HD wallets. In simple terms, child keys are generated for the private and public keys. And the child key can be used to restore a wallet.

I was wondering whether this kind of mechanism is available for XRP?

Or is that only specific to Bitcoin?

If XRP has HD wallet support, which wallets provide that feature?

HD wallets are coin agnostic. The BIP32 and 49 systems simply dictate how the key derivations from a root key work. Once any particular private key is generated, it functions the same way as a non-HD key.

Thus, you can technically use an HD wallet system for ripple. However, since Ripple addresses require a minimum funding of 20 XRP, which is permanently locked in that address, wallets will usually make you use only 1 address so that you aren't forced to burn 20 XRP each time you make a transaction.


How can I prevent Armory from getting stuck at "30 seconds" Building Databases on OSX 10.9? I'm running Bitcoin-Qt v0.8.6-beta and Armory 0.90-beta on OSX 10.9. I've been stuck at "30 seconds" for several hours. This has happened twice now. Activity monitor displays no disk activity, but ~90-120% cpu usage. Bitcoin-Qt is fully synced and displays a green checkmark.

Any help would be appreciated, thanks!

EDIT:
The log file contains a bunch of messages similar to this:

  -ERROR - 1394339952: (leveldb_wrapper.cpp:1145) Block height exceeds DupID lookup table
  -ERROR - 1394339952: (leveldb_wrapper.cpp:1145) Block height exceeds DupID lookup table
  -WARN  - 1394339952: (BlockUtils.cpp:4617)    Tx: d5fdcc541e25de1c
  -ERROR - 1394339952: (leveldb_wrapper.cpp:1145) Block height exceeds DupID lookup table
  -ERROR - 1394339952: (leveldb_wrapper.cpp:1145) Block height exceeds DupID lookup table
  -WARN  - 1394339952: (BlockUtils.cpp:4617)    Tx: 982051fd1e4ba744

WARNING: Triple-check you have a backup of all of your Bitcoin-Qt and Armory wallets before deleting anything.

Deleting the Armory and Bitcoin data directories (~/Library/Application Support/Bitcoin and ~/Library/Application Support/Armory) and re-downloading the entire blockchain (starting with a fresh bootstrap.dat) in Bitcoin-Qt fixed this for me.


bitcoin-cli how to verify balance I've read that addresses alone are a "confusing" way to think about "where" bitcoins "are".  Nonetheless I was formerly (2018) able to correlate what I got from bitcoin-cli commands with what I saw on blockchain explorers like https://www.blockchain.com/btc/address/
e.g. back in 2018 getaccountaddress would list 1 address, getaddressesbyaccount would list that plus a 2nd address, getaddressesbylabel would list those same two addresses, getwalletinfo would show a 0.0003 balance, and listaddressgroupings would also show that balance.
Now in 2020, that online explorer still shows that 0.0003 BTC balance, as it did in 2018, but due to deprecated cli commands, how can I confirm that with bitcoin-cli?
Background... I have been running a full bitcoin node on Ubuntu 16.04, kept updated, so currently Satoshi:0.18.0, and just to experiment and educate myself, I played around in 2018 with a bitcoin faucet until I managed to get 0.0003 BTC.  Then I had the faucet site transfer it to one of the addresses in my bitcoin node's wallet.
For non-deprecated commands I've also found
bitcoin-cli scantxoutset "start" "[\"addr()\"]"
from this question
https://bitcoin.stackexchange.com/questions/92342/how-to-quickly-get-the-balance-of-any-bitcoin-address-with-no-third-party-api however that too shows a zero balance for the two addresses that I can list from getaddressesbylabel.

I've read that addresses alone are a "confusing" way to think about "where" bitcoins "are".

Yep, addresses are only an encoded description of how the coins are locked, not when(*) they are.

e.g. back in 2018 getaccountaddress would list 1 address, getaddressesbyaccount would list that plus a 2nd address, getaddressesbylabel would list those same two addresses, getwalletinfo would show a 0.0003 balance, and listaddressgroupings would also show that balance.

The listreceivedbyaddress command is probably the most similar one : it lists coins locked to each address, if an address has been reused then you'll see multiple txids.  The balance will be updated accordingly.
Given your first sentence, you might be interested in checking listunspent which will give you a less abstract representations of the coins you received.

Now in 2020, that online explorer still shows that 0.0003 BTC balance, as it did in 2018, but due to deprecated cli commands, how can I confirm that with bitcoin-cli?

So, you can use :

getbalance for your total balance
listreceivedbyaddress for the representation by address
listunspent for the representation by unspent transaction

Finally, check the Wallet section of bitcoin-cli help for more commands. For more details about a command, use bitcoin-cli help <command>.
(*) You used "where" in your question, but I think since we are talking about blocks, it makes more sense to reason chronologically.


Block #338819 deemed invalid by v0.15.1 I am attempting to sync from scratch a full node (v0.15.1) on a linux machine (Linux Mint running Ubuntu precise 12.04.1 LTS).
The sync grinds to a halt on block #338818.
From examining debug.log I can see the issue is the next block #338819 being deemed invalid. Here is an excerpt from debug.log demonstrating that:

2018-02-02 16:36:52 ERROR: AcceptBlockHeader: block 0000000000000000159e7d66c954312bccb5f12de808f2991b3859205665c442 is marked invalid
2018-02-02 16:36:52 ERROR: invalid header received
2018-02-02 16:36:52 ProcessMessages(headers, 162003 bytes) FAILED peer=217

bitcoin-qt continues to ask peers for the block header and keeps rejecting it as invalid, even though this block seems to be valid as part of the main chain, at least according to all known nodes that I checked (e.g. blockchain.info, blocktrail and several others).

I googled for this block # and found nothing, so I assume nobody else has this problem. What is going on? What should I do to continue with the sync?

That error means that the block got corrupted somewhere so it became invalid. The only way to fix this is to re-download the block.

To do so, first stop Bitcoin Core. Then go to the Bitcoin Core data directory and then the blocks folder within that. Delete the highest numbered blk*.dat and rev*.dat files. Then start Bitcoin Core again. When it asks whether you want to reindex the databases, choose yes. Bitcoin Core will now rebuild the block indexes and then continue with syncing once it is done. Note that while it is reindexing, it will look like it is syncing the blockchain again, but it is not. It is using the data on disk to build the block index and chain state until it needs to download blocks again to continue syncing.


Master Seed from Mycellium does not concord with address Mycellium app generated for me Created MYCELLIUM wallet in 2017 - copied down Master Seed, been transacting ever since.
Upgrades of various phones, always reinstalled latest Mycellium and used master-seed to restore, no issues.
Last week, app was "acting up" -- didn't want to sync and seemed to hang.  I decided to delete it and reinstall/restore from master-seed.  This time, incorrect balance is shown, and transaction log as well as looking on blockchain of public key shows no more transactions after 2018 ?!  (even though been busy until last week!)
Used this site https://iancoleman.io/bip39/ to generate the derived addresses from my master seed.  Seems to be accurate as the first 10 addresses are indeed mine and show me what MyCellium shows me.  However, when I do a search (in the pool of derived addresses) for a Mycellium generated receiving address I successfully used last week ... that address is NOT found ?!   I assume the addresses are used sequentially?  I generated 5000 addresses and still can't find that address in there!
Any insight/help/etc would be greatly appreciated!  I've never imported other private keys into MyCellium, only used the addresses provided by the app, and created another HD wallet from within the app.
Any chance to recover my lost coins ?

Used this site https://iancoleman.io/bip39/ to generate the derived addresses from my master seed

Please do not enter seed on any website. It's only safe if you run it locally on your machine from https://github.com/iancoleman/bip39

Any chance to recover my lost coins ?

I would suggest restoring wallet in Electrum. You can follow the steps mentioned in this answer: https://bitcoin.stackexchange.com/a/99441/
Basic things to keep in mind: Either system used for wallet is offline or not affected with malwares, download from original source, verify it and never share your seed with anyone else.
Also for gap limit refer to: https://electrum.readthedocs.io/en/latest/faq.html#gap-limit and https://bitcoin.stackexchange.com/a/98919/


I am afraid of private key collision... What is the solution? I know that there are a massive number of keys, but lets say that someone generate a private key that belongs to me.
I know that is nearly impossible. But I want to make that more and more impossible.

Is the Multisig Addresses is the best solution?
Because even if someone generates a private key belongs to me, he needs another private key to get my money.

Is that the best solutuon?

Bitcoin addresses are 160 bits in length. That means there is an extremely large number of possible addresses. From the Bitcoin wiki:

Generating tons of addresses
Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.
Also, a collision is highly unlikely.
Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power) Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15 x 10^38)

In other words, don't worry. Even if someone deliberately targets your address for cracking, it would take them trillions of years. An accidental collision is even less likely.
Multisig isn't made to protect against private key cracking (which is impossible), but to allow the existence of addresses that must have the authorization of more than one device or person to spend from them.
Say, you have a 2-of-2 multisig address. One key is in your computer, and the other is in your smartphone. While an attacker won't ever crack even a single one of your keys, they could try infecting your device with a private key stealing trojan, or a keylogger to watch you type your wallet passphrase.
Now, it's much less likely that the attacker will successfully hack both your computer and your phone. So multisig does improve your funds' security, but not for the reason you mentioned.


Why is creating a bitcoin fork very difficult and a Ethereum fork easy? There are a dozen of projects based on Ethereum but very few based on the Bitcoin network. Why is this?

Forks of both are equally hard. What you're describing as "Ethereum forks" are actually tokens/smart-contracts that run on the Ethereum network, which isn't very common on Bitcoin (but there's Omni)

EDIT: Remved Rootstock as per darosior's clarification. Its only to relation to Bitcoin is that it uses merged mining, just like Namecoin.


Historical intraday data for altcoins that can be exported? I've been looking around lately for historical data, like opening price, closing, high, low etc for altcoins. All I have come up with is daily data or higher, but what I need is like 5, 10, 15 minutes etc.

I need to be able to have data for at least a few weeks back. And I need to be able to export it as a CSV file or something.

Any ideas?

You can try my website at cryptodatasets.com which has raw and sampled historical data for BTC, ETH and LTC in .csv format.


Did any customers lose money with the Mt Gox / Dwolla legal situation? This crucial piece of info has been frustratingly absent from the news accounts I've seen. Specifically from what I understand, an account was "frozen".  What does that mean for the people unlucky enough to have had their transaction present in the account at the time of "freezing"?

Here is the timeline for my deposit, which shows that at least one deposit was honored:

May 14 @ 10:14 AM CST --> Dwolla notified me that money was sent
May 14 @ 12:16 PM CST --> Dwolla notified me that DHS seized Mt Gox's account
May 14 @ 08:53 PM CST --> Mt. Gox notified me that funds from dwolla were deposited

I can't speak about other transactions with certainty, but from the fact that my deposit went through and the lack of any major "I lost $3,700 during the DHS crackdown" news stories, my guess is that all transactions that happened around this time were either honored or rolled back.


Am I paying Double fees? On testnet I sent a transaction

I believe this was for TBTC1.000 and a 0.0001 fee: i.e. inputs - outputs = 0.0001.

When I try to claim the transaction I am only allowed to claim 1 - 0.001. If I claim (what I expect to be) the full amount (TBTC1.000) I receive an err #26.
If I claim TBTC0.9999 everything works

I presume I'm doing something wrong, and would be happy to understand what that is.

Thanks for any suggestions

OK - now I understand. The fee comes from the second txn. I sent 1.000 but when it's spent I need another fee.


How to create the   part in "scriptSig"? I've decoderawtransaction and see in the vin part a "scriptSig" ,which
I believe to be the "unlocking script"  . Assuming I have
the private key in a paper wallet and someone send me transaction to
my bitcoin address, How do I generate the    to unlock it
?
My second question is: after I generated it, can someone copy this
part and use it in the future to unlock a future transaction made to
my same bitcoin address ?

First question has a long answer, because it depends on the scriptPubKey, but also of the sigHash flag, I assume you are speaking about classic P2PKH transactions. (ScriptPubKey expose the condition for "unlocking", while ScriptSig satisfies them for "unlocking". It can use signature... or not, but will assume you are using P2PKH scriptPubKey, so it does)

So the scriptPubKey is

OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

Where PubkeyHash is given by your bitcoin address.

The scriptSig should be

<Sig> <PubKey>

The PubKey is simple. From your Private key, you can get the public key (curve secp256k1)

Q = dG

where d private key : int, Q public key : EC Point, G : ECPoint given by curve.

<sig>

is composed of 2 components

<ecdsaSig> <sigHash>

ECDA Sig is the signature of a hash of the transaction in DER encoding. sigHash is a byte that specifies how to generate this hash (ie: what is actually signed).

sigHash itself contains 2 informations.

<AnyoneCanPay><All|None|Single>

So what is signed is a calculated hash of your transaction depending on the sigHash. The human friendly explanation is here, and the most readable code doing that is here.

Once you calculated the hash, you need to sign it according to this math on elliptic curves.
Due to the need in the algorithm of a random K value, it supposes a fair RNG.
So RFC6979 describes a way for finding a K value that is not random but secure to use.  (implementation here)

So here is what is signed, depending on the sigHash you choose:

AnyoneCanPay : You allow someone to modify any input in the transaction. (don't sign inputs, except yours)

All : You deny modification of outputs in the transaction. (sign outputs)

Single : You deny modification of the output having the same index as you input (sign one output)

None : You allow modification of any output in the transaction. (sign no output)

Second question :
No, whatever the sigHash you use, part of your signature contains the previous output reference you are spending. Since you can't double spend, you can't reuse the signature.
However, if you really want to do that, then use the same K value for signing 2 different hashes, then you basically leaked your private key. So anyone would be able to "unlock" a future transaction made to your bitcoin address by knowing the two signatures.


What do `minerd`s feedback messages (LONGPOLL, yay, boo) mean? I have been testing a script that essentially runs (incomplete command shown here!): minerd --algo scrypt -s 45 --retry-pause 5 --threads $threads --url ...

Among the feedback messages, while minerd is running, there are once in a while following messages:

LONGPOLL detected new block
...accepted: 1838/2122 (86.62%), 49.94 khash/s (yay!!!)
...accepted: 1832/2116 (86.58%), 50.00 khash/s (booooo)

What is a LONGPOLL and how is it related to the bigger picture of mining? What is the difference between a (yay!!!) and a (booooo) accepted message?

Finally, what is the percentage in parenthesis in an accepted message (as above) showing exactly? Why does it both increase and decrease during mining? Shouldn't it grow only upwards reaching the 100% level?

If I recall it correctly, the "boo"s mean: your answer's correct but somebody else had solved the problem before, so you wasted your electricity and time - sorry. And the "yay"s are: you did it first, congrats.

As for "LongPoll", it's a protocol that enables a miner to keep in touch with its pool's servers so that it's communicated as soon as possible when someone (within the pool or outside of it) discovers a solution for the current block - the miner can then stop working on that block immediately. All work up to that moment has been wasted, of course, but the waste's minimized this way - otherwise, your machine would just keep going, produce a result and deliver it... only to be informed then that it was way too late. Today, most pools support it - so you should see a lot of "longpoll" messages but relatively few (if any) "boo" :-)

Finally, as to the percentage: it tracks the number of solutions your machine has dispatched to your miner pool's servers, comparing the number of accepted ones versus the ones that got rejected. In an ideal world LongPoll would ensure your machine gets notified immediately upon someone else's discovery of a block's solution, and your machine would stop working on that block right away - so the percentage would always be 100%. In real world, lots of bad stuff can prevent this from happening.

What can you do to improve that percentage? Find out why you're having rejections! You might not be receiving the longpoll notifications, either due to your Internet connection being slow or the pool being under a DDoS attack - so change your Internet provider or go to another, smaller pool. You may have set up your ASIC or graphic cards to a too-aggressive configuration, try changing the settings of your miner. And some other things I can't remember right now - there are questions and answers about that on this site.


Did Satoshi object to embedding data in the block chain? Why? From this post:

  Our beloved Satoshi is on record that he doesn’t think it appropriate
  to embed data willy-nilly in the block-chain

Is this claim true? If so, why did he object?

I don't think it's "wrong" in any sense to embed data in the blockchain, because you're essentially paying for it. Since the protocol allows it, it is a legitimate service.

He supported IsStandard, but he was not against small amounts of arbitrary data. Satoshi said:

    why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

  That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.

  I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.

He always promoted putting hashes in the chain instead of the arbitrary data itself, though I don't know whether he was strongly opposed to the latter.


Bitcoin Transaction Fees When Buying and Selling After dipping my toes in the water with Bitcoin, turning £ into BTC, I immediately noticed around a 10% loss through transaction fees. This seems high firstly. Is this normal?

Secondly, with the rate of raise for BTC at the moment, this 10% loss has repaid itself after around 24 hours (which in itself is crazy and unsustainable), but this value is currently stored purely in BTC. If I want to turn the BTC into £ again, I'm guessing this is going to result in ANOTHER transaction fee of around 10%.

All in all, meaning that the value of BTC would need to raise by at least 20% purely to cover the transaction fees when converting between £ to BTC to £ again.

Have I understood all of this correctly? And here I was thinking that PayPal had some expensive transaction fees!

Bitcoin not related to fiat currency, I don't know which wallet you're using but its really of the exchanger.

I guess you're using coinbase.com which is not recommend.

Find another wallet to store your bitcoin and exchange your bitcoin locally or using person-to-person trade.

UPDATE

  To follow on with a few more question, could you please expand. 1)
  When you say "Bitcoin not related to fiat currency" what do you mean?
  2) "I guess you're using coinbase.com which is not recommended" - I
  initially tried with those guys but their website was appaling so
  couldn't even verify my identity. So no. But out of interest, why are
  they not recommended? 3) Re. "find another wallet", would you
  recommend a wallet that sits on my computer, or phone, and what is the
  best method for P2P exchange? How to go about it? –

i'm not fluent in english but i'll try my best!

1- Bitcoin not related to fiat currency, I thought you were talking about bitcoin core and transactions fee. which is not possible to lose bitcoins or even turning your bitcoins to any fiat currency.

2- coinbase isn't recommended because they don't provides full access to bitcoins. its just like PayPal. Your bitcoins in there are just bunch of numbers. And they are custodial Bitcoin wallet.

3- I recommend you to install Bitcoin-core from bitcoin.org but if you don't want to download the whole blockchain(145 GB) and your usage for bitcoin is just simple. You can use blockchain.info they are non-custodial bitcoin wallet and gives you full access to your bitcoins , nobody can track your account and no verification needed.

4- Localbitcoins.com.


Is there bitcoin implementation in python or C#? I want to play with the implementation to better understand the inner workings of Bitcoin. I'm familiar mostly with python and C# and found no clients in either of the languages. My C skills are rusty because I haven't done any C in last decade.

There isn't yet a complete implementation AFAIK, but there are different libraries that implement bitcoin features (wallets, keys, utilities,

Depends on whether you want an implementation of bitcoin network protocol or wallet or just an overlay on top of the JSON-RPC interface of bitcoind.

Useful code on github:

https://github.com/jgarzik/python-bitcoinrpc - Python interface to bitcoin's JSON-RPC API

https://github.com/etotheipi/BitcoinArmory - Python-Based Bitcoin Software

https://github.com/gavinandresen/bitcointools - Python-based tools for the Bitcoin cryptocurrency system

https://github.com/jgarzik/python-bitcoinlib - Bitcoin library

https://github.com/spesmilo/electrum - Electrum thin-client

https://github.com/spesmilo/electrum-server - Electrum server

https://github.com/spesmilo/sx - Python CLI tools


BIP 144 transaction format and soft-forks and old nodes I was trying to manually parse a raw Bitcoin transaction in order to better understand how it works.

This is how it starts:
"0200000000010141035625cd030eca667c95d1729a"

I think I've parsed the Tx version just fine but then the next byte was 00. I imagine this has something to do with BIP144. Correct?

If so in BIP 144:

  Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.

Does this means that old nodes do not relay Segwit transactions? They will think they are invalid? But once they are put in a block it's already in a format that an old-node can understand?

Sorry for the messy question.

This is correct. As an upgrade mechanism, nodes do not relay or mine transactions which they know that they can not correctly validate. The P2P network expressly avoids situations in which it could cause invalid transactions to be included in a block. It will however accept these transactions in a block.