text:
Address Reuse and ECDSA Concern
I have a question about address reuse. Admittedly, I'm a little confused on the matter, so please bear with me if the framing of my question doesn't make much sense.
Recently I started using Sparrow Wallet and Coldcard (previously I was using a Nano X and Ledger Live) and noticed I'd been reusing receiving addresses in batches of two, always one after another within the span of a few hours or a few days. After some thinking, I realized that these were my withdrawals from the Fold rewards card. Even though my wallet was creating new receiving addresses each time it detected one had been used, there was, of course, no way for it to detect I was copying and pasting the address over to Fold, hence the reuse.
I understand that this has compromised my privacy somewhat, which is a shame, but not a major concern.
The major concern I have is that a potential security vulnerability has now been exposed. I can't claim to understand this very well, but I know it has something to do with ECDSA, and if ECDSA is ever cracked in the future, my coins could be vulnerable.
However, I've only ever reused receiving addresses. I've never spent from the same address more than once, so does that exclude me from that concern?
If it is still a concern, what's the best recourse? Creating an entirely new seedphrase and transferring the funds over? Coinjoining?
Again, I'm not particularly well versed in all of this, so please explain to me like I'm 5.

Address reuse is chiefly a privacy issue: because your UTXOs share the same output script, they are obviously controlled by the same entity. Reusing addresses reveals your receiving pattern, and if you spend those UTXOs in multiple different transactions, it heavily suggests that all spending transactions are (co-)authored by the same spender.
Address reuse would be a security issue if ECDSA were to become insecure in the future. The hypothetical scenario is that when a public key is known, an attacker would be able to use a quantum computer to solve the discrete logarithm problem and calculate the private key from the public key to steal your funds. Since many output types lock the funds to a hash, and hashes are more secure against quantum computing, a reused address would be more vulnerable because its public key has been revealed while an address that has only received funds would still have its public key hidden behind the hash.
You do not need to lose sleep about this. Quantum computers are decades away from doing anything interesting, if they ever will. Further, if quantum computers end-up being more of a thing than cold fusion, more than a quarter of all bitcoins are in outputs whose public keys are known. Your withdrawals from Fold would not make much of a dent either way, it would necessitate a network wide solution to keep Bitcoin viable.

So in this hypothetical scenario where ECDSA is cracked, am I right in understanding that address reuse would only put the coins associated with that particular address at risk? Not the entirety of the coins associated with the main seedphrase?

Note that in theory, it's possible that even without quantum computer, elliptic curve cryptography, the secp256k1 curve, or even just ECDSA specifically get broken. If that happens, key reuse may or may not help such an attack. Similarly, even with a sufficiently powerful quantum computer capable of attacking secp256k1 ECDSA, key reuse may or may not help the attack. In general, it's very hard to talk about hypothetical future cryptographic or computational breakthroughs.

I see, yes. But I think I'm still a little confused on some fundamentals. When I spend from a particular UTXO, I reveal the public key associated with it, right? So, if in the future a way to reverse engineer a public key is found, the funds associated with that particular UTXO would be at risk, correct? But what about all the other UTXOs that are associated with the parent seedphrase. Would they be at risk also? Or not?

@anonpleb That all depends on which piece of cryptography is broken, and what is revealed. In general, if all the attacker has is a way to break break EC keys, they cannot go from one key to another key generated by the same seed. However, if they have the parent xpub of both keys, it is trivial.

And what would have to happen for an attacker to gain access to the parent xpub?

@anonpleb You, or someone else who has it, must reveal it to the attacker. It can't just be computed from observing your addresses or signatures. How really depends on how you interact with your key (e.g. in multisig setups, it's common to your cosigners know your xpubs), and what software you use.


text:
Exodus import from computer to computer
I got my

seco

files but if there is encrypted how am I supposed to read them.

If data in the files are encrypted, you are supposed to read them by running the Exodus application and giving it the passphrase when it asks for it. The software then uses the passphrase as a decryption key, or to produce one.
Alternatively you should be able to recreate the wallet from the recovery phrase you wrote down when you first created the wallet.
Related :

I have lost my wallet, what can I do?
Wallet gone and lost recovery phrase, how to get back my bitcoins?

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Why does Bitcoin Core’s algorithm uses ancestor score instead of just ancestor fee rate to select transactions?
In Bitcoin Core’s implementation of the greedy knapsack algorithm to select transactions to go into a block for mining, the heuristic used to order transactions is based on an "ancestor score" which is the minimum between the ancestor fee rate of the transaction and the fee rate of the transaction itself (see txmempool.h, and bitcoinops.org).
Why is this a better heuristic than just using the ancestor fee rate?

This is intended to be a performance optimization when generating a block template for mining. The issue is around how many transactions we end up looking at while iterating over the mempool during block construction.
At a high level, the mempool sorts transactions by ancestor feerate, and in the mining algorithm we iterate over those transactions in descending ancestor feerate order to select transactions for a block. As we select transactions, we have to do some bookkeeping to update the new ancestor scores of descendants of those transactions (to reflect only the ancestors that are not yet selected), but because we can't modify the mempool when constructing blocks, we still look at each transaction in the same order it appears in the mempool.
So if the mempool were to sort a child transaction based on an ancestor feerate that is higher than its own feerate, you might expect that it has some higher feerate parent that would be selected first, and therefore the child's ancestor feerate would overstate its true mining score. This in turn would mean that we might look at many more transactions from the mempool than should be necessary when constructing a block, because those children would appear earlier in the mempool's sort, so we'd look at them only to decide that the true feerate is lower than indicated.  Instead, we try to
avoid this scenario by sorting transactions based on the minimum of the two feerates.
The implementation details are somewhat more involved than I described; see https://github.com/bitcoin/bitcoin/blob/d80348ccb65601d19b4b408d442e0999b5a6cf98/src/node/miner.cpp#L292C1-L429 for the full mining logic.

I'm not sure if I understand your answer, if this were only an optimization matter, then, the ordering of the transactions with the ancestor score ordering would be the same as the ordering with ancestor fee, but this is not the case.
Also, you say that if the ancestor fee rate is higher than the ancestor score, then there is an ancestor with higher ancestor fee rate, but then again this is not the case (a transaction diamond with appropriate weights and fees show the contrary).

@algo2043 Ignoring diamonds, I believe it is just an optimization: while the sort order is different, any case where the child has a lower feerate than the parent will have their parent included before, and thus during actual block building the child's ordering won't be what matters anymore (the local inside-block-building ordering of feerates-with-included-parents-removed will be used for the child), and the resulting block will be the same. With diamond structures present that is possibly not the case, but the mining logic is known to be suboptimal in that case anyway.

@PieterWuille Got it. Thanks!

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Different balances between fullnode and bitcoin explorer
I looked up Block 200 at https://www.blockchain.com/explorer/blocks/btc/200 and found out that coinbase transaction was made and sent 50 BTC to 1HwmP33SaknLYShXfjVU8KmVThU3JiuVgH.
But if I check utxos that 1HwmP33SaknLYShXfjVU8KmVThU3JiuVgH has by using scantxoutset from my bitcoin node, there is no such 50 BTC at its result.
{
  "success": true,
  "txouts": 111958375,
  "height": 800185,
  "bestblock": "000000000000000000025a01c53bd3a6842321e50345373a2bcf7975b02a8d59",
  "unspents": [
    {
      "txid": "cc66c9303cdf1f6bf52549918fd2b2de776edb220e796ef1b72dec1fae37a447",
      "vout": 160,
      "scriptPubKey": "76a914b9dd855e0ea21b3ed1c13c896682475e0c05416788ac",
      "desc": "addr(1HwmP33SaknLYShXfjVU8KmVThU3JiuVgH)#t4jlhv9w",
      "amount": 0.00000547,
      "height": 665222
    },
    {
      "txid": "cdb8076b0f120959f310b3f2def52378843a2a213feb4bdb007827b3f672dd53",
      "vout": 340,
      "scriptPubKey": "76a914b9dd855e0ea21b3ed1c13c896682475e0c05416788ac",
      "desc": "addr(1HwmP33SaknLYShXfjVU8KmVThU3JiuVgH)#t4jlhv9w",
      "amount": 0.00000547,
      "height": 643265
    },
    {
      "txid": "1d2362fba0bd11cabdae3e080dad5f0f4db43799052ccaedfe1823baf3b702da",
      "vout": 273,
      "scriptPubKey": "76a914b9dd855e0ea21b3ed1c13c896682475e0c05416788ac",
      "desc": "addr(1HwmP33SaknLYShXfjVU8KmVThU3JiuVgH)#t4jlhv9w",
      "amount": 0.00000547,
      "height": 670662
    }
  ],
  "total_amount": 0.00001641
}

I knew that the reward of the genesis block is unspendable.
Is it true for other old blocks or is there any special rule for this?

Did you use an addr(ADDRESS) descriptor to scan? My guess is that if you use combo(PUBKEY) instead, you will see it. Also, if you look on more modern block explorers (like blockstream.info, or mempool.space) you will also not see it. If so, the difference is due to the fact that in modern interpretation 1... addresses are exclusively for P2PKH outputs, while this block's coinbase output is P2PK. Historically, some software used to "reinterpret" these as having the corresponding P2PKH address, but this is very confusing.

You appear to have searched for a Pay to Public Key Hash (P2PKH) address, but the output on the coinbase transaction of block 200 is a Pay to Public Key (p2pk) output.
There is no address standard for P2PK outputs, but in the past P2PK and P2PKH were considered more closely associated than today. For these historic reasons some older block explorers still show the corresponding P2PKH address for P2PK outputs. Block explorers that are being more actively developed, e.g. mempool.space or blockstream.info will show correctly that the transaction has a P2PK output:
 via mempool.space


text:
Deriving revocation_pubkey BOLT #3
I'm trying to reproduce keys derivation for testing vectors in Bolt #03.
At the moment I'm can not reproduce the local_revocation_pubkey: 0212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b19
Which revocation_basepoint and per_commitment_point shall I use for the derivation (I know the formula and have tested it with the other example)?
There is a description how to derive another revocation_pubkey 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0, but not the one used in the first commitment.
Could it be that the values of revocation_basepoint and per_commitment_point needed for derivation of 0212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b19 are not included in the testing vectors?

BOLT3 describes how to derive it already, could you add more details to your question such as what you tried and didn't work?

Hello Pawel, could you please edit your question post to provide more information instead of posting comments?

When you repeat the description how to derive the second revocation_pubkey, does your method reproduce the described results?

Yes, I can reproduce with my code revocation_pubkey 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0. But this key is not used in transactions examples, the revocation_pubkey that used in transaction examples is 0212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b19. My goal was just to manually recreate all transactions in testing vector, but I believe revocation_basepoint and per_commitment_point are not included in testing vectors


text:
Next step to understand Bitcoin Core
After compiling Bitcoin Core, what should be my next step to understand the codebase?
I’m a very new contributor and developer.

Does one of these related topics answer your question: https://bitcoin.stackexchange.com/q/37684/5406, https://bitcoin.stackexchange.com/q/92581/5406, https://bitcoin.stackexchange.com/q/41692/5406?

Yes, they worked out. Thanks


text:
What is "blockchain hang/hung"?
I sent Btc to an address. I verified address. Verified with my wallet that it was sent successfully. Receiving party sees the transaction, but say it is still "pending" on their end. Said it is "hung" in the blockchain. Funds have been removed from my wallet. How do I find it/fix it? Was also told to send it again, same amount, within 7 days, and original will be reversed and sent back to me. Not sure if that's trustworthy? Any help would be nice, especially to know how to not have this happen. again.

The receiving party appears to be lying to you

Receiving party sees the transaction, but say it is still "pending" on their end.

There is no such thing as "pending" in standard Bitcoin transactions where the receiver has a normal "self-custodial" type of wallet.
Furthermore, for normal Bitcoin transactions between normal (self-custodial) wallets, the receiving wallets play no part in receiving money after they provided the sender with the receiving address. The recipient can receive money even if the device holding their wallet is turned off, is defective, broken or has been destroyed.
Once your transaction is recorded in the blockchain you have done everything that is necessary and can do no more. Any problems the recipient claims to have are not your concern and do not change the fact that they have received the money and have exclusive control over it.

Said it is "hung" in the blockchain.

This simply is not possible. If the transaction is recorded in the blockchain, it is thereby confirmed and has already completed. There is no further step.

Funds have been removed from my wallet.  How do I find it/fix it?

Look for the transaction-Id (txid) in your wallet - you can check the state of the transaction in any "bitcoin explorer".

Was also told to send it again, same amount, within 7 days,

Someone wants to steal more than they already stole.

and original will be reversed and sent back to me.

Bitcoin transactions are irreversible, they cannot ever be cancelled, undone or reversed.

Not sure if that's trustworthy?

What you describe looks completely untrustworthy to me.


text:
How can one query the mempool of an Electrum server?
How does one go about querying a public Electrum server’s mempool? Not just for a address, but the entire mempool.

I don't think this is possible. See the protocol methods list.


text:
Invalid checksum when generating BIP-39 Mnemonic
I am trying to generate a mnemonic seed in Javascript, and while everything seems to be working, I am not getting a mnemonic with a correct checksum. Here is my implementation:
export const generateMnemonic = async () => {
    const ent = window.crypto.getRandomValues(new Uint8Array(16));
    const entBits = toBinString(ent);
    const entHash = Array.from(new Uint8Array(
        await window.crypto.subtle.digest("SHA-256", ent)
    ));
    const entHashBits = toBinString(entHash)
    const checksum = entHashBits.slice(0, 4);
    const entCS = entBits + checksum;
    const chunks = Array.from(hendecadsFromBits(entCS));
    const words = [];
    for (let i = 0; i < chunks.length; i++) {
        words.push(wordlist[chunks[i]]);
    }
    return words;
};

const toBinString = (bytes) => bytes.reduce((str, byte) => str + byte.toString(2).padStart(8, '0'), '')

function* hendecadsFromBits(bits) {
    let i = 0;
    let val = 0;
    for (const bit of bits) {
        if (i == 11) {
            yield val;
            i = val = 0;
        }
        val |= bit << i++;
    }
    if (i > 0) yield val;
}

Is it because I am padding the bytes with zeros?
I would really appreciate your help!

There is a few problem in your code, in the hendecadsFromBits function, you need to use the numeric value of bit and in the generateMnemonic function, when you call hendecadsFromBits, you need to pass the result to Array.from()
Here is how you could fix your code:
export const generateMnemonic = async () => {
    const ent = window.crypto.getRandomValues(new Uint8Array(16));
    const entBits = toBinString(ent);
    const entHash = Array.from(new Uint8Array(
        await window.crypto.subtle.digest("SHA-256", ent)
    ));
    const entHashBits = toBinString(entHash)
    const checksum = entHashBits.slice(0, 4);
    const entCS = entBits + checksum;
    const chunks = Array.from(hendecadsFromBits(entCS));
    const words = [];

    for (let i = 0; i < chunks.length; i++) {
        words.push(wordlist[chunks[i]]);
    }
    return words.join(' ');
};

const toBinString = (bytes) => bytes.reduce((str, byte) => str + byte.toString(2).padStart(8, '0'), '')

function* hendecadsFromBits(bits) {
    let i = 0;
    let val = 0;
    for (const bit of bits) {
        if (i == 11) {
            yield val;
            i = val = 0;
        }
        val |= parseInt(bit, 10) << i++;
    }
    if (i > 0) yield val;
}


text:
Are there any UTXOs that can not be spent?
I have heard that there are UTXOs that can not be spent. From my understanding it is because the scriptPubKey is constructed that way.
If this is correct, are there some real life examples on the blockchain? Was this done intentionally or by mistake? How many are there?

Related to https://bitcoin.stackexchange.com/questions/49625/

@Mercedes I am not talking about burn address. If you could get PK for that address than you can spend it. P.S. I do know that it is practically impossible, but theoretical possible. As I said is it possible to make UTXO with ScriptPubKey that is theoretical impossible to solve.

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

Yes, there exists transaction outputs which are provably unspendable, regardless of cryptographic assumptions (so even when hashes and/or elliptic curve security were broken).
One well-known example are OP_RETURN outputs. Since the OP_RETURN opcode immediately abort script execution, any output whose scriptPubKey contains this instruction (outside of an OP_IF branch) is irrevocably unspendable. This is a popular mechanism for committing extra data inside Bitcoin transactions.
Another example of unspendable outputs are ones whose scriptPubKey exceeds 10000. Creating such outputs is legal, but such large scripts are unexecutable, and thus cannot be used in inputs.
Whether you consider these outputs to be UTXOs is a matter of perspective however. Bitcoin Core for example detects certain classes of outputs are provably unspendable (those whose first byte is OP_RETURN, and those with a scriptPubKey longer than 10000 bytes), and does not even insert them into its database of unspent outputs as a database size optimization. The outcome of this is that attempts to spend them will fail due to "UTXO does not found" rather than "invalid script", but the block or transaction it occurs in is invalid either way.


text:
"Error parsing JSON": how to use `testmempoolaccept` on Windows?
The documentation for bitcoin-cli testmempoolaccept suggests
bitcoin-cli testmempoolaccept '["0100000001abcd..."]'

but that throws Error parsing JSON. I have tried numerous variations of this, but none of them work. How can I use testmempoolaccept on Windows?

The correct format that works for this is bitcoin-cli testmempoolaccept "[\"0100000001abcd...\"]"

The version in the question would work on Linux, it is a difference between how Windows and Linux handle quoting in commands.

Okay, but the question is about Windows, not Linux or Mac OS

That wasn't made clear in the original form of the question. 2. I thought others reading this might not be aware of this OS difference and might find it helpful to know.


text:
Bitcoin Core wallet: two people with the same passphrase?
I set up the Bitcoin Core wallet and set up a passphrase to access the wallet. It seems to be the only way/needed input to access my wallet.
The passphrase was NOT randomly autogenerated as I was expecting. What happens if someone else uses the same passphrase as me? Since it's not random I suspect this is very possible.

The passphrase for the Bitcoin Core wallet is just a passphrase for encrypting the wallet file. It is not a seed phrase from which the key material itself is derived. The keys are derived from a securely generated seed, independent from your passphrase (and not shown to the user).
Nobody can guess your keys unless they have both the wallet file (with the encrypted keys) and (a correct guess for) the passphrase (to decrypt the keys). That also means the passphrase is not sufficient for you to gain access to your funds - you need the wallet file or a backup thereof.

Thank you for this! Can I please clarify something with you - what happens if I lose my computer that stores the wallet file -> will I no longer be able to access the Bitcoin Core Wallet?
How then do people "spin up and use" their own wallets and access them remotely in emergencies? I've been to Bitcoin meet ups where the speaker encourages people to download Bitcoin Core and create their own wallets rather than relying on a cold storage, 3rd party wallets (e.g. ledger). Thank you!

If you lose the computer with your wallet on, you lose your wallet. Make sure to make backups of the wallet.dat file.


text:
How to gpg verify my bitcoin core download step by step on ubuntu server?
I am a newbie when it comes to setting up a bitcoin node but I am trying to gpg verify my bitcoin core download the pub keys to do so are no longer available. I have tried doing my own research but I can't seem to find someone to explain in Layman's terms how to do so now.
I have downloaded all three files needed to do so:
bitcoin-24.0.1-x86_64-linux-gnu.tar.gz
SHA256SUMS
SHA256SUMS.asc

I have verified the checksum of the release file
sha256sum --ignore-missing --check SHA256SUMS

Now I am totally lost on what to do from here because the txt file is not on GitHub anymore. I have been trying to figure this out for a while now but can't seem to do so. Any help is much appreciated.

The builder keys file has moved to a different repository. The download verification instructions on the bitcoincore.org website were updated. Follow the steps detailed there to verify your Bitcoin Core download.

gpg --list-keys
wget https://raw.githubusercontent.com/bitcoin-core/guix.sigs/main/builder-keys/achow101.gpg
wget https://raw.githubusercontent.com/bitcoin-core/guix.sigs/main/builder-keys/benthecarman.gpg
wget https://raw.githubusercontent.com/bitcoin-core/guix.sigs/main/builder-keys/fanquake.gpg
gpg --import achow101.gpg
gpg --import benthecarman.gpg
gpg --import fanquake.gpg
gpg --verify SHA256SUMS.asc

You'll just have to follow the steps listed at
https://bitcoincore.org/en/download/
But essentially, you're doing it right, downloading those three files and then running sha256sum returns the following:
$ sha256sum --ignore-missing --check SHA256SUMS
bitcoin-24.0.1-x86_64-linux-gnu.tar.gz: OK

So I don't need to get public keys anymore and verify it? Cause when I follow the instructions the rest doesn't make sense cause of missing pages on GitHub.

Not really sure what steps are you following. The official documentation is the one I linked to on my original answer.

This answer seems to be missing most of the point.

That's verifying the checksums match, bit is missing the gpg verification of the checksum file's authrnticity


text:
When calculating the hash of transaction, why is the version used as "01000000" instead of "00000001"?
According to the protocol documentation for tx, the first field on the transaction data is a version number of size 4.
Based on this, I am trying to format the array of bytes needed to calculate the TX hash for the genesis TX, so I retrieve the block information from my node:
{
  "hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
  "confirmations": 708859,
  "height": 0,
  "version": 1,
  "versionHex": "00000001",
  "merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
  "time": 1231006505,
  "mediantime": 1231006505,
  "nonce": 2083236893,
  "bits": "1d00ffff",
  "difficulty": 1,
  "chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
  "nTx": 1,
  "nextblockhash": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
  "strippedsize": 285,
  "size": 285,
  "weight": 1140,
  "tx": [
    {
      "txid": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
      "hash": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
      "version": 1,
      "size": 204,
      "vsize": 204,
      "weight": 816,
      "locktime": 0,
      "vin": [
        {
          "coinbase": "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 50.00000000,
          "n": 0,
          "scriptPubKey": {
            "asm": "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG",
            "desc": "pk(04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f)#vlz6ztea",
            "hex": "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac",
            "type": "pubkey"
          }
        }
      ],
      "hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000"
    }
  ]
}

I see the version inside tx has the value 1, so I understand the array of bytes should start with 00000001, but on How to calculate a hash of a Tx?, the accepted answer shows it starting with 01000000 and I don't understand why, could someone help please?

See Transaction format

Because it's encoded as a little endian number, meaning the least significant byte goes first.
Example:
Number 1234 would be encoded as byte sequence 000004D2 when encoded as 4-byte big endian, and it would be encoded as byte sequence D2040000 when encoded as 4-byte little endian.

bitcoin protocol use little endian order in it's byte array.


text:
Why can the CHECKMULTISIG bug not be solved?
I was reading Mastering Bitcoin and I read about a bug in CHECKMULTISIG. If the starting ideas of this command should work like this
<Signature B><Signature C> M <Public key A><Public key B><Public key C> N CHECKMULTISIG

But CHECKMULTISIG works like it needs an extra parameter, so M+1 parameters in total.
There's a workaround where you put a 0 at the beginning of the line, for instance, assume that M is equal to 2 and N to 3 (), like this
0 <Signature B><Signature C> 2 <Public key A><Public key B><Public key C> 3 CHECKMULTISIG

Why can't we fix this? If the consensus is reached, can we fix this? Why should someone not want to fix this?

I think it remains for backward compatibility. If it changed, then older transactions would no longer work. So it would probably require a new opcode.

There are currently Bitcoin on the blockchain at various (non Taproot) addresses locked behind a script that includes the CHECKMULTISIG opcode with the bug in it. So you wouldn't want to change the scripts locking those funds because it might prevent the owner spending them. It would be changing the consensus rules for those funds without the owner's permission.
You could introduce a CHECKMULTISIG2 opcode (as a soft fork) without the bug so that could be used instead of CHECKMULTISIG for future usage. However, the Taproot soft fork introduced a more efficient replacement for CHECKMULTISIG called CHECKSIGADD that doesn't include the CHECKMULTISIG bug. If you use a SegWit v1 address (Taproot) you wouldn't use this CHECKMULTISIG opcode regardless (it was disabled for Taproot spends in BIP342) so there isn't much point introducing a CHECKMULTISIG2 opcode.

You could also fix it by if (script_blockheight < CONSTANT) do_bugged_CHECKMULTISIG(); else do_fixed_CHECKMULTISIG(); that way the old ones work.

Changing the behavior of an op-code could mean that old (unupgraded) nodes interpret a transaction with that op-code differently than new (upgraded) nodes. If nodes interpret transactions in two different ways, this may cause the network to split as some nodes accept a block as valid while others reject it as invalid. We call such a breaking change in the protocol rules a “hard fork”.
Since we cannot go back and change how old software behaves and cannot force users to upgrade their software, we are careful to introduce changes in a forward-compatible manner. If we introduce new behavior, then in a way that makes the old nodes accept it, even when old nodes cannot fully validate the underlying script. We call this style of protocol rule upgrade a “soft fork”.
Changing OP_CHECKMULTISIG to pop one fewer element off the stack would be a hard fork. Even if a majority of the nodes was upgraded when such a rule took effect, the first transaction that makes use of the new rule would cause all old nodes to stop processing the most-work chain, forking the old nodes off the network.

Sure, there are ways to make it smoother, e.g. putting in the fix now to activate for outputs starting five years from now. It’s still a hard fork because anyone that will still fork off anyone that hasn’t upgraded at that time. And it would still break chains of presigned unbroadcast transactions.


text:
Why are AssumeValid blocks manually added?
Couldn't we just define an AssumeValid block each N blocks, instead of adding it manually?
What is the difference from just periodically picking sufficiently confirmed blocks? Anyway those blocks have been verified by the whole network

If your suggestion is to automatically treat any block that has N blocks on top of it as assume-valid, that would be a very fundamental change in the trust model.
Right now, blocks don't become assume-valid unless they're actually valid. It's assessed by the contributors, reviewers, and maintainers of the Bitcoin Core software (assuming that's the assume-valid you're talking about), but you're already trusting that group collectively to provide you with software that correctly implements the Bitcoin protocol any time you update. It's also auditable (and audited) by anyone who wants, by running the software with assumevalid disabled and verifying history.
If instead your local node would automatically treat any block with a sufficient number of blocks on top (without actually validating it) as assume-valid, it would imply that a cabal of dishonest miners could make you accept invalid blocks. Note that while an honest majority of miners is part of Bitcoin's assumptions, this is only the case for consensus, not validity. There is no way today that even 99% of miners today could make your full node accept a block that contains a transaction which steals your coins without valid signature. In a world where sufficiently-buried blocks are considered assume-valid this does become theoretically possible.

I think you mean that "most worked chain" and "most worked valid chain" are completely different. However wouldn't it be practically irrelevant? If we set the assume-valid block deep enough it's hard to see how these blocks aren't valid.

Right, that is my point. And of course, in practice it's hard to see how a very deeply buried block could be invalid. But the reason why we can make that assumption that is exactly because full nodes don't ever accept invalid blocks (making it wasted effort to make invalid blocks). If you're suggesting in some cases not doing that validation anymore, we need to re-evaluate whether this isn't introducing an incentive for miners to try to build a very long secret chain with invalid spends? Full nodes are full nodes, and I don't think Bitcoin Core is likely to accept deviating from that.

I understand much better the difference now, thanks!


text:
I forgot my spending pin number. Is there anyway I can get around it to get my bitcoin?
I forgot my spending pin number, is there anyway I can get around this?

As anoncoin said in the answer, we could use a bit more information to actually be able to answer this. What software or wallet are you using? Are your funds in a custodial or self-custodial setup?

"Spending PIN"s aren't a feature of Bitcoin; if you are keeping your bitcoin in a self-custody wallet like Bitcoin Core, all you need to spend your bitcoin is access to the wallet file itself (or your seed phrase to regenerate it). If you encrypted the wallet file, you will need your password; this cannot be circumvented, as the whole point of the encryption is to keep people out who get your wallet file off your computer but don't know the password.
Judging by calling it a PIN and not a password though, I think you bought Bitcoin at an exchange like Coinbase, Bitfinex, or Kucoin and did not withdraw it to your own wallet, instead letting the exchange keep it in the account you have with them. Not knowing which exchange you used, I cannot speculate on their exact processes; you will need to contact your exchange's customer support about any problems with your account with them, such as a forgotten PIN.


text:
Private key from paper wallet does not match to public key, so I can not withdraw the BTC on the paperwallet anymore
for a Gift, i created on https://walletgenerator.net a paperwallet. I inserted the privatekey i want to have, and let create the public key out of it. Than i send a little amount of BTC to that created public key.
But after checking with other Tools online, i found out, that the private key does not fit to the public key.
I was ablel to reconstruct the error with another private key.
Private key : 5KMoeKdiB92SFZYTf6KbGzo2MuWuSqvk6TDsCSj6pFRDxB5rCRi
genereted public key: 1GGPWDsTZfLeXKU4ykGBxtPsyXp2CmS3sh
Next time i clicked on Apply ( so the tool create the public key) it created a completly different public key.
next public key: 18bSJFR3d4wFx1MFbuaWkTdbKAuHTXEgsA
next public key: 17A5XwizFCWVyGg8SJ9sC5d1H2V5jsgUpR
.
.
My problem is now, that i can not withdraw the BTC of my paperwallet, because i found out, that there is only one public key for my privatekey matching.
Is there somthing i can do about ?
Ore even worse, is this website a scam ?

Yes, walletgenerator•net appears to be a scam website that has been around for years. According to some people on /r/bitcoin, the JavaScript code on the page contains some 60 hard coded addresses, and most likely people using wallets generated with that page are sending their money directly to the website owner.
Sorry for your loss.


text:
Unable to send bitcoin from trust wallet getting Code 400
I tried to send bitcoin from my trust wallet to my Coinbase account and I received an error  -26: Txn-mempool-conflict  Code 400 I am a beginner so can someone help me with this

I have read that "txn-mempool-conflict happens when inputs have already been spent and you try to spend again."
I would check the list of recent transactions made by the wallet.


text:
Where can I learn about open research topics in Bitcoin?
I am currently doing my Master's Thesis, and I really want it to be about blockchain technology, and specifically Bitcoin. I was wondering if anyone here has any ideas on improvements or further research that may be needed or even well-needed on the topic blockchain or Bitcoin.

May I suggest speaking to potential supervisors on what they think? At the end of the day, you will be working with one, and therefore you want to pick a project that they can offer assistance with.

What discipline are your studies in? Answers are likely different depending on how you're approaching it, e.g. from a math, computer science, social science, etc., perspective.

The list is going to be very long so I'll point you to some resources instead.
Blockstream has a list of research areas and an archive of research papers here. Similarly Chaincode Labs and BitMEX.
There is a repository of open Bitcoin research problems and a working group on Bitcoin Contracting Primitives.
You can also subscribe to the bitcoin-dev and the lightning-dev mailing lists that often discuss research topics.


text:
Why would someone create a transaction where the fee is bigger than the sum of the outputs?
At the moment I am writing this question, the network is extremely bloated with, more than 60k transaction in the mempool. Inspecting the recent transactions, I found 4 very weird examples, at least very weird for me:

c7147a309240b768ca12ef35d3966048966d44a0d5246667d1d6b22554cd6d58
d9521aa9dcc4159d2020e6c8735f46e0da6b3b4467e5d80b8262226e5407b436
6fd8c85ff1982d9664a016492ae502bde49b2fb56eda50b26b11c49a5f7383b4
2997928c120e2b218ab14356271202433f9431f2d6653627c9bf86dfda0a7459

All these transactions have more fees than what they are sending as output to the receivers, unless I am interpreting it wrongly.
Why would someone do something like that? I can't think of any reasonable non-malicious reason for that.

My guess is those are Ordinals Inscriptions (NFTs). They typically have a single output of 10000 Satoshi (about $28 US).
Update: Yes, typical huge witness data in one I checked. So fee correspondingly higher. Some ordinals are small though.

If you tie an inscription (NFT) with a small output, like 10000 satoshi, wouldn't it be a problem to transfer/sell the NFT to another address later on, because you need to pay the transaction fee? Are you essentially limiting how many times one can transfer the incription?

@Delorean, You should ask that as a New Question


text:
Why does Bitcoin Core print SHA256 hashes (uint256) bytes in reverse order?
When converting uint256 (the datatype used to represent hashes) to string in Bitcoin Core, the bytes are reversed. When debugging functional tests, this can create potential confusion when comparing hashes passed to script on the Python side and hashes naively printed from within Bitcoin Core's cpp.
Why are the bytes reversed when getting HexStr() for hashes in Bitcoin Core?

Glad to see you on Bitcoin StackExchange, James! I expect we might get a few questions on OP_VAULT in the coming months/years, so you picked an excellent time to join in on the fun.

Does this answer your question? Why does the Bitcoin protocol use the little-endian notation?

From sipa on IRC (2023-01-06):

jamesob: Probably dumb question, but why does uint256::ToString() (-> HexStr()) print out the blob in reversed byte order?
sipa: Because that's what it has always done, really.
sipa: And people expect txids and block hashes in hex notation to be reserved.
sipa: Historically, that was because txids/block hashes were 256-bit numbers constructed by interpreting the double-sha256 output as a little-endian integer, and then printing it out for human consumption in hex (where humans expect numbers in big endian).
sipa: But now uint256 is just a byte array wrapper, the behavior is maintained because block hashes and txids are always printed in reverse.
sipa: (block hashes are still interpreted a little-endian numbers for the purpose of comparing PoW to the target, but that's handled by the arith_uint256 class now)


text:
How to choose a nothing-up-my-sleeve (NUMS) point on secp256k1 for use in Taproot?
Per BIP-341, if you want to create a Taproot output that is only spendable via the script-path spend (and not a key-path spend), you must "pick as internal key a point with unknown discrete logarithm."
This requires using a nothing-up-my-sleeve (NUMS) point as your internal public key which has no valid corresponding private key.
How should I go about choosing such a point? Are there canonical examples to draw from?

Does this answer your question? Taproot - Eliminating Key Path

Regardless, welcome to StackExchange James :)

Kind of - when I searched "NUMS point" I didn't get anything relevant, so it's probably not indexed for that.

The way to get round that would be to add a "NUMS point" tag. But I don't think that should be a tag, it is pretty specific. You should be searching for Taproot, secp256k1, script tags and hopefully find it through that. Of course the StackExchange search functionality could be improved but that is kind of out of scope for a particular Q&A

In my experience, the best way to search on Stack Exchange is to use a regular search engine restricted by “site:bitcoin.stackexchange.com”.

In BIP-341, an example NUMS point is given, along with a cautionary note about leaking information:

One example of such a point is H = lift_x(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0) which is constructed by taking the hash of the standard uncompressed encoding of the secp256k1 base point G as X coordinate.
In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer r in the range 0...n-1 uniformly at random and use H + rG as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to G by revealing r to a verifier who can then reconstruct how the internal key was created.

For what it's worth, the point as-written is encoded in DER format, so in order to get the corresponding integer you have to remove the first byte (0x02).

Nit: this is not DER format; DER is only used in Bitcoin for ECDSA signatures. This is a public key is SEC compressed encoding (it's still wrong in the BIP though; lift_x just takes an X coordinate as input).


text:
Is there a particular order in which transaction inputs are checked for script validity?
When a transaction is being checked for validity, is there a particular order that the inputs are evaluated for script correctness?
This might be relevant when determining what consensus changes might be practical to design. For example, if we wanted to add incremental metadata for a given transaction during validation -- for example, "sum the nValues for inputs that are related ways x, y, z - but do it on the fly so we don't impair validation speed."
Whether or not inputs are validated in a certain order would help gauge the feasibility of  a consensus change that relayed on those kinds of "lazy" data computation.

Right now in the source code, the CheckInputScripts() function creates CScriptCheck objects in order of vin. Does this mean that input scripts are validated in order of vin-index?
// validation.cpp

    for (unsigned int i = 0; i < tx.vin.size(); i++) {
        [...]

        // Verify signature
        CScriptCheck check(txdata.m_spent_outputs[i], tx, i, flags, cacheSigStore, &txdata);
        if (pvChecks) {
            pvChecks->push_back(CScriptCheck());

If we got cross-input signature aggregation, would that change such an ordering?

Inputs are not necessarily evaluated for script validity in any particular order. Indeed, today certain calls to CheckInputScripts() will push the created CScriptCheck objects onto a vector (pvChecks). Those script check objects will be pulled off the vector by asynchronous workers and may be evaluated in any order.
Since there is no particular ordering today, the implementation of cross-input signature aggregation will not affect any guarantees that exist today.
This lack of ordered script checking may make dynamically computing certain data about "like" inputs difficult, which may be relevant when trying to design covenants whose spends can be batched together.


text:
MtGox API Overview and explanation of steps required to create connection
I am trying to write a simple app that uses the Mt Gox. (bitcoin exchange) API.
It's very simple to use the price API it's just a http request that returns a .JSON string.
However now I want to do more with my app, I was thinking it would be good to be able to log into the users mtgox account and show their balance of bitcoin.
I have an API key (you can generate one on their site) but I'm finding it really hard to understand whats required to generate a connection and pull the balance.
Is there anyone who might be able to point me in the right direction?
I have researched quite a bit and turned up very little information - API Overview: https://bitbucket.org/nitrous/mtgox-api/overview
In the above link they have some python code, but i'm finding it difficult to translate into Objective C.
So if anyone can:
A. Give me a highlevel overview of the steps required to log in and get a bitcoin balance using the API.
B. Give me some pointers on how to turn their Python example into Objective C I would really appreciate it.
I understand to use the API I need to use this URL to Get my current balance    mtgox.com/api/0/getFunds.php -- however first I need to get a "nonce" parameter to the post data (which must be an ever-increasing interger, for example with PHP in 64bits: (int)(microtime(true)*1000000)) and two HTTP headers: Rest-Key (your key) nad Rest-Sign (a signature generated by doing a sha512-hmac on the POST data with the secret as key, encoded in base64).
I found this documentation: bitbucket.org/nitrous/mtgox-api/overview -- still not clear however, how to code in Objective C thanks

This is a badly titled question. Please give some kind of indication of what the question is about in the title.

Updated thanks. need to type more chars because of the silly limit where by you cannot just say thank you.

Take a look at the Java XChange project
While it is not Objective C it will provide you with all the details you'll need to get your library off the ground including the HMAC authentication process and websockets.
You'll also find a range of other exchanges supported so you can implement those as well thus providing your application with a broader range of potential users since not everyone uses MtGox these days.

Yep, I'm very pleased with the way that XChange has shaped up. There's been a lot of good work done on it.

going to mark this as answered as yours is as close as I'll get!

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Location of blockchain locally on different platforms, and structure of blockchain file?
I just downloaded Bitcoin-QT, and torrented a snapshot of the block chain that is a couple weeks old. I put the bootstrap.dat in ~/Library/Application Support/Bitcoin and started up the app. Right now it is "Importing blocks from disk". Where do the blocks goes once they've been imported? A friend of mine says that the Bitcoin app makes a Merkle tree out of the blocks in the block chain. How is this stored? I want to write a program that takes snapshots of the block chain every couple hours. It would be much better if I could just update a copy of the block chain as needed instead of making an entire new copy and deleting the old copy.
How do I make a bootstrap.dat out of the blkXXXXX.dat files?

You will find the .dat files in the following locations:

Linux: ~/.bitcoin/blocks
MacOS: ~/Library/Application Support/Bitcoin/blocks
Windows: %APPDATA%Bitcoin\blocks
WinXP: C:\Documents and Settings\YourUserName\Application data\Bitcoin\blocks
Win7/Win8/Vista: C:\Users\YourUserName\AppData\Roaming\Bitcoin\blocks

I always found the following attached image helpful in order to understand the structure of the dat files. I am sure it will help you too.

In windows it is stored in Local>AppData>Bitcoin folder on linux it is stored in the Bitcoin folder > blockchain and then blkxxx.dat

http://bitcoin.stackexchange.com/questions/10381/creating-my-own-bootstrap-dat

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Why have my funds in Bitcoin Block Explorer's online wallet decreased in value?
I feel I may have been cheated by Bitcoin Block Explorer whose URL is http://blockchain.info
Here's the background:
I am using the online wallet provided by Bitcoin Block Explorer. It contains 1.5 BTC.
According to the website http://blockchain.info/stats, the weighted average price is 134.19 USD for 1 BTC on September 11. It means that my 1.5 BTC  is worth 201.29 USD.
However after logging in to my wallet, on the top right-hand corner, the USD equivalent shows 186.18 USD. It means the weighted average price is 124.12 USD.
Could some experienced guy explain to me the discrepancy?
Added a second question
After going through the comments posted here, a second question comes to mind.
An online merchant gives his customers the option of paying using one of the following methods: Visa, PayPal or Bitcoins.
The price of the product is 50 Euros if the buyer uses Visa or PayPal to pay but 0.52 BTC if he chooses the Bitcoin payment system.
According to some posters here, Bitcoin/USD rates vary across exchanges.
My question is: if I am the customer, how can I be sure that I am not overcharged if I use Bitcoins to pay? (0.52 BTC may worth more than 50 Euros)

Hello user5556, usually it is better to ask follow-up questions either in the comments or as new questions, depending on how much different from the original question they are. In this case I think it might have been better if you asked a new question, because it goes significantly beyond the two answers that already exist.

To answer your question, 1) with the Bitcoin network growing up and the exchanges becoming more accessible and competitive, arbitrage should mostly eliminate differences in the exchange rate on different exchanges. 2) There are different websites that offer a Price Index, for example yesterday CoinDesk announced their new Bitcoin Price Index. Long-term one of the Price Indexes will gain more traction than others and become Bitcoin's "Dow-Jones".

@Murch, is probably right -- probably would have been a bit better as a follow up question.

Bitcoins are traded on many different exchanges.  The prices are varying  constantly just like any currency.  As an example:  at this time three rates are Mt.Gox - $143.0983; CampBX - $125.8000; and BTC-E - $124.0000 (all USD).  As I learn more, and become familiar with the exchanges, I may try some arbitrage.  I have a feeling there are problems, or people would be doing it now, and all the exchanges would be more in line with each other.

I didn't know that BTC/USD rates vary across exchanges. What this means is that for the global financial community, Bitcoins can never become a global currency (fiat currency) unless there is a uniform conversion rate (I mean BTC/USD).

I thought about arbitrage too. But the reason MtGox is so high right now is that people are having great difficulty withdrawing USD from their accounts there. This inconvenience and the risk that you might never get your USD devalues the USD in a MtGox account,    meaning that  BTC trades higher. You can't call it arbitrage if there's risk.

@user5556 - Every commodity, ETF, equity, trades on numerous exchanges and there are differences all over the world all day.  As more Bitcoin transactions and trading occurs the differences will decrease.

@Nate - Arbitrage risks are never zero. :-)  As long as I know I will eventually get my money, MtGox still may serve as a vehicle for profits.

@DcShank: As long as I know I will eventually get my money: Ah, but do you?

Nope.  You go first.  :-p

DcShark, the difference in the MtGox and CampBX price seems to indicate that someone did go first... and failed.

@DcShank :I have added a second question. I would appreciate it if you could help answer it.

Being overcharged is an opinion.  I have downloaded an app for one of my on-line store to accept Bitcoins.  I will have to charge an additional percentage because of the volatility.  As with options, the higher the volatility, the higher the premium, because the chances of losing money are greater.  The flip side, which is why I am considering it, is that the chances of making money are greater also.

It looks like blockchain.info is using different conversion rates in different places. Why they are doing this (and where they are getting their data) is really something only the owners know.
I'd like to thank you for bringing this to our attention; however as blockchain.info is an important source of data for the entire community and it's important that we are aware of discrepancies like this.
As for the second part, the answer lies in the field of economics. The truth is the price of things -- that is, what people are willing to give up for something else -- is constantly changing throughout the world, though you may not notice it locally, especially if you are used to a fixed pricing system as is used in most of the western world. In a way, our financial systems are built to mask this fluctuation, but bitcoin is new and our financials systems simply aren't built to cope with it, thus we are currently seeing a lot of unusual market phenomena involving it.
Bitcoin, like all things, actually, doesn't really have a "fixed price" -- just how much, on average a bunch of people are willing to sell it for. The price that you see on the web is actually based on an average of what many people have posted on many exchanges as their own individual bids that they are willing to share and for how much. Different sites read different bids and possibly use different methods of calculating this average, so this is why you see varying prices in various places.
It should also be noted that a person may sell different amounts of bitcoin for different prices, say 10 BTC for $100 and 20 BTC for $180 (A 10% discount for buying double!). This can also affect changes in price.
Now, since bitcoin's price isn't fixed, you kind of have to throw the idea of "overcharging" out the window. Let's say you buy a bitcoin for $100 and I buy one for $90. Were you overcharged by $10? Perhaps. Or perhaps tomorrow someone may offer you $150 for that bitcoin. It looks like you may have been undercharged by $50. Again, since there is no real fixed price, and what people are charging for it varies so much, the idea of "overcharging" doesn't really make sense. However...
My best advice to avoid "overcharging" is just to be diligent search around for what ever is cheapest, but also be aware of what's most convenient for you.
Coinbase.com is fairly cheap, but it currently it takes about a month before you get full access to instantly purchase bitcoin. There are faster methods, but they are usually on the expensive side and I would generally avoid them after spending you month on Coinbase.
MtGox.com (as I've been informed) suffers from having both a high price and along wait to get money out of it, although their high sell price is appealing to some, such they are willing to forgo the inconvenience.
LocalBitcoins.com and Satoshi Squares (tf you can find or start one) are also good options to meet up and trade bitcons. Here, you may actually be able to negotiate face to face to ensure that you're getting a good price.

I am equally surprised that Bitcoin Block Explorer (a.k.a. Blockchain.info) does not host a forum for their members. (I consider myself a member as I opened an online wallet with them) That's the reason I made the original post on this StackExchange forum.

:I have added a second question. May I have your answer to it? Thanks in advance.

@user5556: That's the thing: This is not a forum, it works quite a bit different. :) Stackexchange facilitates getting answers to question, it isn't a good tool for discussions (which is the domain of forums). See the about for a better explanation, if you are curious.

@John Henry :Thank you so much, pal. I think I am more educated now than before.

@user5556 no problem :). Pay it forward.


text:
What prior work influenced the design of the Bitcoin instruction set?
The "Script" system used by Bitcoin transactions is commonly described as a Forth-like, stack-based language.
What prior work influenced the design and layout of the Script instruction set?
There may have been a research paper or essay about a "Security Forth" published in the early 2000s which shared unusual similarities with the Bitcoin instruction set. Though in recent years, no one has been able to locate a copy of this work.
What was the title of that work? Where was it published? Can anyone find a copy?

This is an imperfect answer but in the absence of anything else here are a couple of resources.
I'm not sure if this is what you are looking for but there is a 2013 research paper "SVFORTH - A Forth for Security Analysis and Visualization" (Wes Brown). It discusses a Forth language environment written in JavaScript with primitives and functions that make it useful for security visualization and analysis work.
On the influence of Forth on Bitcoin Script, Andrew Poelstra discussed this during his talk on Miniscript at London Bitcoin Devs in February 2020.

Q - Last question on script. It is very hard to judge Satoshi ten
years on. There’s a lot of subtle complexity here. Do you honestly
think back in Satoshi’s time, 2009 that you’d have had the perspective
to design a better language?
A - The question is in 2009 could I have done better? Or could we have
expected Satoshi to have done better? Essentially no. There are a
couple of minor things that I think could’ve have been done better
with a bit of forethought. For some historical context the original
Bitcoin script was never used. It was this idea for this smart
contracting system and smart contracting was something in blog posts
by Wei Dai, Nick Szabo and Hal and a few other people. It was this
vague idea that you could have programmable money. Script was created
with the intention that you be able to do that. Basically it was a
copy of Forth, it actually had way more of the Forth language than we
have today. We had all the mathematical opcodes and we had a bunch of
other weird stuff. There was also this half baked idea for delegation
where the idea was that your script is a script you execute but also
the witness is a script that you execute. The way that you verify is
you run both scripts in a row and if the final result is true you’re
good, if the final result is false…. The idea is that your
scriptPubKey which is committed to the coins should check that the
earlier script didn’t do anything bad. There were a couple of serious
issues with these, two that I will highlight. One was there was an
opcode called OP_VER, OP version. I can see some grimaces. It would
push the client version onto the stack. This meant that when you
upgraded Bitcoin say from 0.1 to 0.2, that’s a hard fork. Now script
will execute OP_VER and push 0.1 onto the stack for some people and
0.2 onto the stack for other people. You’ve forked your chain. Fortunately nobody ever used this opcode which is good. Another issue
was the original OP_RETURN. Rather than failing the script like it
does now it would pass the script. Because we had this two script
execution model you could stick an OP_RETURN in what’s called your
script signature. It would run and you wouldn’t even get to the
scriptPubKey. It would just immediately pass. You could take any coins
whatsoever just by sticking an OP_RETURN into your scriptSig. Bitcoin
was launched in the beginning of 2009. This was reported privately to
Satoshi and Gavin in the summer of 2010. This was 18 months of you
being able to take every single coin from Bitcoin. In a sketchy commit
that was labelled as being like a Makefile cleanup or something,
Satoshi completely overhauled the script system. He did a couple of
interesting things here. One was he fixed the OP_RETURN bug. I think
he got rid of OP_VER a little bit earlier than that. Another was he
added all the NO_OP opcodes. Around this time if you guys are
BitcoinTalk archivists you’ll notice that talk of soft forks and hard
forks first appeared around this time. It would appear forensically
that around this script update, the one that fixed OP_RETURN was the
first time that people really thought in terms of what changes would
cause the network to fork. Before that nobody was really thinking
about this as an attack vector, the idea that different client
versions might fork off each other. Either explicitly or because there
is different script behavior. And so the NOP opcodes or the NO_OPs
were added as a way to add updates later in the form of a soft fork.
The fact that this happened at the same time as the OP_RETURN fix is I
think historically very interesting. I think it reflects a big leap
forward in our understanding of how to develop consensus systems.
Knowing that historic context the original question was in 2009 could
we have done better? The answer is no basically. Our ideas about what
script systems should look like and what blockchains should look like
and the difficulty of consensus systems, nobody had any comprehension
of this whatsoever. The fact that there were bugs that let you steal
all the coins for over a year tells you that no one was even using
this, no one was even experimenting. It was just weird, obscure thing
that Satoshi put in there based on some Nick Szabo blog posts and
nobody had really tried to see if it would fulfill that vision or not.
Q - Did he literally copy something from Forth or did he reproduce it
selectively or precisely from a manual?
A - The question is did he literally copy from Forth. Or did he use a
manual? I don’t believe there is any actual code copying from any
Forth compiler or something like that. The reason I say that
everything is copied from Forth is a couple of specific things. The
specific things are the stack manipulation opcodes like the SWAP and
OP_ROTATE which rotates in a specific direction that isn’t useful for
Bitcoin but is probably useful in Forth. All of the stack manipulation
semantics seem to have come from Forth. These are just Forth opcodes
just reinterpreted in a Bitcoin context. Beyond that I don’t know
Forth well enough to say. There are a couple of specific things that
are really coincidental that suggest that he was using the Forth
language as a blueprint.
Q - He either copied something or he made something up. In the latter
case he must have thought about it?
A - The statement is either he copied something or made something up.
If he made something up he must have thought about it. I don’t think
that’s true. I think he made up a lot of stuff without thinking about
it.
Q - It accidentally worked?
A - That’s a very good point. Someone said it accidentally worked.
There are a lot of things in Bitcoin that accidentally work. There’s
pretty strong evidence that some amount of thought went into all of
this weird stuff. There are a lot of accidentally works here. There
are a lot of subtle bugs that turned out not to be serious but by all
rights they should’ve been. I don’t know what evidence to draw from
that. One idea is that Bitcoin was designed by a number of people
bouncing ideas off each other but the code has a pretty consistent
style or lack of style. It is all lost to time now.


text:
There was a transaction spendable only by someone who provided the double hash of the genesis block. How was that transaction created?
I can't find it anywhere, but I remember reading about a transaction that was spendable only by someone who provided the double hash of the genesis block. Was it simply that the private key of an address was seeded with the genesis block hash and coins were sent to that address as an output?
Is there a transaction type that allows you to specify that providing a pre-image of a hash is the only requirement of redeeming coins?

This transaction is described quite well on the wiki.
https://en.bitcoin.it/wiki/Script#Transaction_puzzle


text:
jsonRPC calling createrawtransaction in PHP
I can't get createrawtransaction to work in PHP using jsonRPC.
I found this thread https://bitcointalk.org/index.php?topic=133769.0 from a few months ago describing the process. It won't work however, no matter how many different ways I try it...
$arg1 = array( array( "txid"=>$lasttx, "vout"=>$n));
$arg2 = array( $address=>$coins);

array(1) {
  [0]=>
  array(2) {
    ["txid"]=>
    string(64) "valid_tx_id_goes_here"
    ["vout"]=>
    int(1)
  }
}
array(1) {
  ["valid_address_goes_here"]=>
  float(0.01)
}

$this->bitcoind->createrawtransaction($arg, $arg2);

EDIT: All of the other commands work, like getblock and etc. So I'm connected to the RPC server clearly. The errors aren't helpful either -- it says unable to connect when I output the error for createrawtransaction, but all of the other commands go through the RPC fine and are able to connect. I wish I knew how to even begin debugging this.

you should pass parameters as an array.
try like that:
$bitcoin->createrawtransaction(
    array(
        array(
            "txid"=>"aed23bb3ec7e93d69450d7e5ea49d52fcfbef9d380108f2be8fe14ef705fcea5",
            "vout"=>2
        ),
        array(
            "txid"=>"b28c740c66726ab2f0397be29f2d25f091b8ab353b98b9ebf9e6ccfd080cdf49",
            "vout"=>3
        ),
    ),
    array(
        "1GTDT3hYk4x4wzaa9k38pRsHy9SPJ7qPzT"=>0.006,
        "1ApD64wpNUM6GBeSmKYhsyaNwFot3FMC5y"=>0.004,
    )
);


text:
What are the segregated witness tradeoffs?
Segregated witnesses sound like a win in a lot of ways, I'm just trying to understand how they apply to scalability. If I understand correctly, there is a second Merkle tree of witnesses mirroring the transaction data. The witness tree's root is committed to in the coinbase, but otherwise this second tree lives outside of the block.
Don't the witnesses still have to be relayed to other nodes to validate? Why is it acceptable now to send more data, but raising the block size was dangerous, and exclusionary of nodes on slow connections before?
Also, if witnesses are outside of the block and prunable, how will a fresh fully validating node get up to date? If a smaller subset of full nodes hosts all witnesses, does that trade off security for amount of transactions in a block?

The title makes this appear to be a duplicate of http://bitcoin.stackexchange.com/questions/41764/what-is-segregated-witness-and-how-can-it-improve-network-scalability, but I think the underlying questions are deeper.

Edited, let me know if you can think of something better.

If I understand correctly, there is a second Merkle tree of witnesses mirroring the transaction data. The witness tree's root is committed to in the coinbase, but otherwise this second tree lives outside of the block.

That is my understanding as well.

Don't the witnesses still have to be relayed to other nodes to validate?

Only nodes that actually care about the signatures. There are thousands of SPV nodes, for example, that want to be able to calculate the TXID of the transactions they care about but that don't actually need the scriptSigs other than that, since SPV nodes rely on confirmations for security instead of fully checking scripts.

Why is it acceptable now to send more data, but raising the block size was dangerous, and exclusionary of nodes on slow connections before?

Many people rejected the idea of increasing the block size limit simply because it was a hard fork. The extra data and exclusion of some nodes is still an issue, and I'm sure there will still be plenty of arguments about how to count the witness data. This just eliminates/postpones the hard fork max block size debate.
Pieter Wuille's current proposal is to give a 75% discount on signature data, increasing the effective max block size to about 4 MB in the worst case, but that would probably never come close to being realized in any normal, non-malicious, circumstance. I would estimate that a full 1M normal block would be a 1.8 MB block of completely SW transactions.

Also, if witnesses are outside of the block and prunable, how will a fresh fully validating node get up to date? If a smaller subset of full nodes hosts all witnesses, does that trade off security for amount of transactions in a block?

When a full node comes online now, it currently doesn't even check the script evaluations in anything older than the most recent checkpoint. In this sense, it's not a 'fully validating' node, it's more of a 'fully validating from 6 months ago onward' node. But, unfortunately, to build the UTXO set right now you still need to download the scriptSigs, even though they're not used for any validation. The Segregated witness change makes it so that in the case of SW transactions, excessively old scriptSigs that wouldn't be verified anyway don't have to also be downloaded, because the TXIDs don't use them.
Note that some transactions using Segregated witness doesn't magically make old-style transactions more prunable, unfortunately. However, if Segregated witness were fully in use by all transactions today, then in 5 years from now, a node that was getting up to sync wouldn't have to download a lot of the signature data from the past 5 years, just the most recent signature data.
So, there is a security trade-off there, but it's the exact same trade off that already exists. With SW, though, you just have to download less data (~60% less of the new SW transaction data) for the same security.

To improve that security trade off another option will become possible thanks to SW: you could download for example a random 1% of the older signatures. If every node double checked a different random set of signatures, together they will quickly statistically cover 100%. And thanks to Fraud Proofs, which will also become possible with SW, nodes can actually inform each other about problems. Another extra security effort you could chose to do is, when you receive a payment, trace back and verify all the parent transactions that the coin came from by downloading only those signatures.

I'm not sure about the 2.5MB number. I get 2.22 MB, assuming signatures used to be 60% of the block and that they get a 75% discount while in SW.

@NickODell, I think 2.2 MB would be over the 1 MB counted limit. I just tried doing the math, and got a typical upper limit of 1.82 MB. http://pastebin.com/u4frCUfb Maybe you could check my math, and once we agree on the number I'll update my answer?

@StephenM347, Re "but it's the exact same trade off that already exists", what are you referring to?


text:
ripple consensus - mathematical certainty for all unl graphs?
It has been stated that ripple reaches to consensus with mathematical certainty.
If we analyze the consensus protocol, we can see that a specific validator can have a very narrow view of the state of the rest of the validators. At least 80% of his unl list must have proposed to include the transaction. Each of them received from 70% of their unl list such a proposal etc....
Unless all those nodes represent the 80% of the unl list of any validator, one cannot assume that the initial validator has knowledge there has been a global consensus on the new ledger.
A problematic example is a unl graph whose directed distance is more than 6 and has low connectivity.
Is this correct? if true what are the assumptions ripple makes on the unl graph so that the above happens?
Edit: wouldn't 2 disconnected networks reach to 2 different consensi, and thus have complete luck of knowledge of the second consensus? If we assume a graph and 2 subgraphs that are connected but have a core that is far away from their boundary. A validator that is inside that core, it will assume that consensus has been reached and only the validators at the boundary will know that there is no consensus.  In other words, shouldn't the unl list be build by a uniform random selection of all the trustworthy validators,or there is chance to not be able to detect the absense of consensus?

The conclusion that no consensus has been reached is a valid conclusion and can result due to poor topology or Byzantine failure. Certainty is always with respect to something that has occurred in the past. It is not possible to know with certainty the present state without observing at more points than will normally be possible.
So each server runs out ahead of what it knows for certain, applying transactions and attempting to reach consensus on them. When and if a consensus is in fact produced, the server later determines this with certainty, and thus can advance what it knows for certain.
Essentially, the consensus process produces a a stream of signed messages called "validations" from which it's possible to determine with certainty whether a consensus had actually been reached at some point in the past.
It is possible to create UNL topologies that frequently fail to reach consensus. The plan is to have Ripple servers build their UNLs using an algorithm that makes such topologies exceedingly unlikely.
Even with a perfect topology, two types of Byzantine failures are possible.
One, which is not that uncommon (one out of every 200 rounds or so), is a local failure. In order for a consensus to ever arise, someone has to declare a consensus. And for that to happen, someone must declare a consensus first. When that happens, whoever makes that declaration can't know for certain that others will declare that same consensus (or they would have already done so, and so he wouldn't be first). So it's always possible that he declares the wrong consensus.
In this case, the server that suffered the Byzantine failure quickly discovers that the other validators have built a different ledger than it did and it begins its resynchronization process. Other servers will still, from the validations, which ledger was the majority ledger.
A much less common type of failure is complete Byzantine failure. In this case, several servers declare different consensuses and there is no clear majority ledger. In this rare case, the network as a whole must reconverge before a true consensus will emerge. Ripple has an algorithm to do exactly this. Servers will see the conflicting validations and know with certainty that there was no actual consensus.


text:
bitcoin-qt stops subsequent RPC calls, then won't shut down
I am running latest bitcoin client,  0.9.2.1 - running on 64bit ubuntu..
I can start up the bitcoin client, via bitcoin-qt -server or bitcoind -daemon (both have the same behaviors)....
... once the client is running, my Railo app is making the RPC JSON calls.. The first couple work perfectly, but from that point on, the http calls will simply time out.
then I restart the client, well, try to.. upon restarting it, it tells me "cannot obtain a lock on data directory..  bitcoin core is probably already running".
so at this point, it's impossible to gracefully stop the client (I have tried waiting overnight for it to stop, and no go).   If i restart the computer, start the bitcoin client again, I will be able to process a couple commands and then it'll start timing out again.
2014-09-08 17:20:22 AddLocal(73.my.ip.addy:8333,4)
2014-09-08 17:20:22 ext-ip thread exit
2014-09-08 17:20:23 146 addresses found from DNS seeds
2014-09-08 17:20:23 dnsseed thread exit
2014-09-08 17:20:27 receive version message: /Satoshi:0.9.2.1/: version 70002, blocks=319733, us=73.my.ip.addy:50804, them=74.someone.else.240:8333, peer=74.someone.else.240:8333
2014-09-08 17:20:27 Added time data, samples 2, offset -1 (+0 minutes)
2014-09-08 17:20:27 receive version message: /Satoshi:0.9.1/: version 70002, blocks=319733, us=73.my.ip.addy:49165, them=74.someone.else.180:8333, peer=74.someone.else.180:8333
2014-09-08 17:20:27 Added time data, samples 3, offset -1 (+0 minutes)
2014-09-08 17:20:39 receive version message: /Satoshi:0.9.2.1/: version 70002, blocks=319733, us=73.my.ip.addy:54101, them=37.someone.else.27:8333, peer=37.someone.else.27:8333
2014-09-08 17:20:39 Added time data, samples 4, offset -1 (+0 minutes)
2014-09-08 17:20:43 UpdateTip: new best=0000000000000000092cd65c42a96763e0028edd607555  height=319734  log2_work=80.577054  tx=46257023  date=2014-09-08 17:20:32 progress=1.000000
2014-09-08 17:20:43 ProcessBlock: ACCEPTED
2014-09-08 17:20:45 receive version message: /Satoshi:0.9.1/: version 70002, blocks=319734, us=73.my.ip.addy:50345, them=61.someone.else.11:8333, peer=61.someone.else.11:8333
2014-09-08 17:20:45 Added time data, samples 5, offset +0 (+0 minutes)
2014-09-08 17:20:45 nTimeOffset = -1  (+0 minutes)
2014-09-08 17:21:08 receive version message: /mining.bitcoinaffiliatenetwork.com:0.9.2.1/: version 70002, blocks=319734, us=73.my.ip.addy:52554, them=74.soemone.else.12:8333, peer=74.soemone.else.12:8333
2014-09-08 17:21:08 Added time data, samples 6, offset -1 (+0 minutes)
2014-09-08 17:21:08 connect() to 173.soemone.else.82:8333 failed after select(): Connection refused (111)
2014-09-08 17:21:20 receive version message: /Satoshi:0.9.1/: version 70002, blocks=319734, us=73.my.ip.addy:35721, them=46.someone.else.134:8333, peer=46.someone.else.134:8333
2014-09-08 17:21:20 Added time data, samples 7, offset +0 (+0 minutes)
2014-09-08 17:21:20 nTimeOffset = -1  (+0 minutes)

at this point, i do my rpc calls again, and it starts to time out..  so I figure i'll restart the bitcoin client..
username@computer:~$ bitcoind -stop
: Cannot obtain a lock on data directory /home/username/.bitcoin. Bitcoin Core is probably already running.

after I type the above, the log file then shows:
2014-09-08 17:30:17 : Cannot obtain a lock on data directory /home/mrtom/.bitcoin. Bitcoin Core is probably already running.
2014-09-08 17:30:17 Shutdown : In progress...
2014-09-08 17:30:17 StopNode()
2014-09-08 17:30:17 Shutdown : done

Even after reading through the whole log, there are no strong error messages..
Maybe i'm hitting a connection limit or something really fast?

Hi Tom! We're going to need a bit more information from you to figure out the problem. In your Bitcoin data directory, there should be a file named debug.log. When bitcoin stops responding to your requests, can you post the last ten lines or so?

Use bitcoind stop, not bitcoind -stop. Also, can you post logs from when bitcoind stops responding to the RPC requests? Thanks!

The logs I pasted includes whatever happens when the RPC calls start timing out - it truly shows nothing that stands out.  interestingly, when I do the -stop (which I didn't realize tht was invalid since it "does" something), but -stop is what reports the "cannot obtain a lock..." message.
and doing just bitcoind stop does nothing - it just hangs there and adds nothing to the log..

I'm starting to think Railo is causing problems...  once the RPC calls start to time out, i restart the Railo service, and I can get a couple more RPC calls.

There's a way to tell if the problem is with Railo or with Bitcoin - wait until it stops responding to queries, then try running bitcoind getinfo at the command line. If it works, then bitcoin is responding to RPC.

yes, pretty sure railo.. had it happen again, immediately executed a command in bitcoint-qt debug console, it worked, restarted railo service, refresh web page, problem goes away, at least for a refresh or 3.

I was having a different somewhat related problem and stumbled across this thread. It seems that bitcoin-qt creates a .lock file to make sure no other program is using the same folder. If the app crashes, the lock file might not be deleted which could cause it to throw up an error about the program already being open. The .lock file is hidden, though, so you won't see it unless you have hidden files turned on. Deleting the .lock file might fix this for you.


text:
Blockchain Parser not working on blockchain generated in regtest mode using bitcoind. Any help?
Has anyone used this blockchain parser for Bitcoin https://code.google.com/p/blockchain/ ?
http://codesuppository.blogspot.in/2014/01/a-command-line-interface-for-blockchain.html
I tried to parse blockchain generated by Bitcoin (bitcoind -regtest -daemon) in regtest mode but it is not reading(parsing) it correctly.
I copied the file blk00000.dat (this is the only file generated in regtest mode) to /home/somesh/Desktop/blockchain-read-only/ folder.  I executed the command:  ./blockchain.out /home/somesh/Desktop/blockchain-read-only
output:
Successfully opened block-chain input file '/home/somesh/Desktop/blockchain-read-only/blk00000.dat'
Welcome ...
Commands available: ... (then prints all the available commands)

then I selected scanning option
scan

The following is the message I get on scanning
Scanning block-chain re-started from block 0 up to a maximum of 500000 blocks..

Warning: Missing block-header; scanning for next one.
Failed to open block-chain input file '/home/somesh/Desktop/blockchain-read-only/blk00001.dat'

Finished scanning block headers. Built block-chain with 0 blocks found..

It is working fine for Bitcoin's real blockchain but not for the blockchain generated in regtest mode.
I think the parser is not able to find the block header in blk00000.dat and is skipping to next file.
Warning: Missing block-header; scanning for next one.
what changes do I have to make ?

First: are you sure it is looking for the files in the right directory?  ls /home/somesh/Desktop/blockchain-read-only/blk00001.dat confirms that the file exists?  (Normally it would be in a subdirectory called blocks.)  Can you also include the exact command you are running, with all arguments?

I updated my question with the commands that I used.

When working in regTest (or testNet) mode the 'magic number' identifying the start of each block is different to what it is for the live network.  The parser you mention may well use the magic number to identify the start of blocks. This may be the cause of your problem and why it is not finding any blocks in the regTest blockchain file.
RegTest (and testNet): 0xdab5bffa
 Live: 0xd9b4bef9
Hence it is likely that the parser code needs to be modified to work with regTest/testNet magic numbers.


text:
What values should be initially assigned to Checkpoints for a new Genesis block?
I have created a new Genesis block. What values should be assigned to these fields?
namespace Checkpoints
{
typedef std::map<int, uint256> MapCheckpoints;

struct CCheckpointData {
    const MapCheckpoints *mapCheckpoints;
    int64_t nTimeLastCheckpoint;
    int64_t nTransactionsLastCheckpoint;
    double fTransactionsPerDay;
};

The original Checkpoints assignment for main network can be found here: https://github.com/bitcoin/bitcoin/blob/v0.10.2/src/chainparams.cpp#L55-L77
static Checkpoints::MapCheckpoints mapCheckpoints =
        boost::assign::map_list_of
        ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
        ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
        ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
        (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
        (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
        (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
        (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
        (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
        (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
        (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
        (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
        (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
        (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))
        ;
static const Checkpoints::CCheckpointData data = {
        &mapCheckpoints,
        1397080064, // * UNIX timestamp of last checkpoint block
        36544669,   // * total number of transactions between genesis and last checkpoint
                    //   (the tx=... number in the SetBestChain debug.log lines)
        60000.0     // * estimated number of transactions per day after checkpoint
    };

You can generate several blocks and put (block_height, block_hash) pairs into the following field. Or just delete all of the checkingpoints : )
static Checkpoints::MapCheckpoints mapCheckpoints =
        boost::assign::map_list_of
        ( BLOCK_HEIGHT, uint256S("0xBLOCK_HASH"));

static const Checkpoints::CCheckpointData data = {
        &mapCheckpoints,
       bitcoin-cli getblock [last checkpoint block], then get the unix time, // * UNIX timestamp of last checkpoint block
        Write a script to count?,   // * total number of transactions between genesis and last checkpoint
                    //   (the tx=... number in the SetBestChain debug.log lines)
        estimate_a_number     // * estimated number of transactions per day after checkpoint
    };


text:
Blockchain.info, How to receive new transactions (not websocket)
I'm trying to build safe transaction-confirmation app and need to synchronize new not-processed transactions.
For example I monitor address A and have processed last transaction B,
how can I ask blockchain "give me all new transactions for address A, which occurred after transaction B",
or the only way here is to use

/address/[***]?format=json

url with offset and limit options ? Thanks

"give me all new transactions for address A from transaction B" - can you clarify this. By definition a transaction has input and outputs, where outputs are the real indicator, also called UTXOs (unspent transaction outputs). Giving an example with transaction IDs and addresses would certainly get you a better answer.

Blockchain.info's API doesn't operate like a stream like the Twitter feed.  You can't page back and forth through the API like that.
For taking payments, it's best to generate a fresh address to receive the coins than to reuse an address over and over.  It becomes too much trouble to keep track of where/who each coin came from outside of bitcoin (the software running the wallet).  The software does it automatically if you just let it by using a new address for each incoming transaction.  Save the unique receiving address in the db and when it receives funds, you can easily find the order to complete.
Try their Receive Payments API.  They automate much of the process and post a callback to you once the funds are received.


text:
Query Blockchain: Reference previous transaction in "txin"
I'm currently working with a postgresql database I've downloaded here which has the following schema and has probably been parsed using Bitcoin-ABE (I added some indexes and redundant columns):

Now I'm stuck trying to make a connection between a transaction input and the previous output. According to the API that belongs to the sql dump, the field prev_out references "the output that this input spends". My problem is, that I can't find any of the txin.prev_out values in tx.hash. Is this line of thinking correct, or am I connecting the wrong fields?
FYI: As you can see both fields are of the type bytea. I was able to use the function encode(hash, 'hex') to get the actual transaction hash and find it at blockchain.info. For the field txin.prev_out however, the hash cannot be found at blockchain.info.

txin.prev_out contains the txid in internal byte order. This is the opposite of tx.hash
You need to reverse the bytes. Here's a short python program that will do that:
import binascii
hash = '32d7724fb0d244f50281a500f505818bb655bc029158fd59d477f4445a6ed64a'
def reverse_hash(hash):
    hash = binascii.unhexlify(hash)
    hash = hash[::-1]
    return binascii.hexlify(hash)

print reverse_hash(hash)

I just checked and encode(prev_out,'hex') is 64 hex-characters long, which is 32 bytes, right? Also there is already an extra field for the index of the previous output transaction: prev_out_index. An example would be "32d7724fb0d244f50281a500f505818bb655bc029158fd59d477f4445a6ed64a" which is "2\327rO\260\322D\365\002\201\245\000\365\005\201\213\266U\274\002\221X\375Y\324w\364DZn\326J" in bytea format.

@Juergen Hmmm. Try reversing the order of the bytes in the prev_out field. Bitcoin uses two endianesses. (One internally, and one for showing to the user.)

Thanks, it worked for me. Unbelievable, I would have never thought of that. I used the reverse function for byteas from here: http://stackoverflow.com/a/26494661/4166885. Why would you say that doesn't work?

@Juergen I was reversing the hash without converting it to a sequence of bytes. Whoops. You're right, it does work.


text:
How are transactions secured?
I'm a programmer and want to get to know more about encryption and how Bitcoin works, but there is not much on the web describing how all this code works. It would help if there was some visual way to describe the concept of how and what its doing.
How can someone send the public key and private key to another computer without giving away the private key? If you didn't send the private key, how would the other computer know the transaction was from you and not someone else pretending to be you?
I have read up on key pairs and have managed to generate a key pair in java. Everyone's example of 'using' key pairs is very vague. How do you "use" the key pair to confirm a transaction. I know you have a private key that signs the transaction and the public key some how confirms the transaction but i don't understand the "how" it is "used" if you send a transaction with your secret key wouldn't that no longer be a secret key? How is the public key confirm the transaction was signed correctly? How can you send your secret key out with out some one using it once they get it? If Bob sends a transaction to Tim would Tim not now have Bobs security key?
I'm very sorry if this question sounds dumb. I'm just having a hard time understanding how you can send some one a transaction and be able to "sign" that transaction and how its confirmed. a lot of posts people are saying its Elliptic Curve Digital Signature Algorithm (ECDSA) but how is it doing all of this.

What do you mean by 'security code' and 'security key'?

From what I can see its using a key pair. Where it makes two keys one public and one private. I could be wrong.

Hi Patrick, welcome to Bitcoin.SE. Please check out our [tour] for a quick overview how our site works. As you might imagine many questions have already been asked and answered, so please check whether a question already exists before you ask it again. Also, it is easier to compare answers and to merge questions when there is only one question per post. I suggest you check out What is a private key and a public key? and maybe this collection of questions: I am new to Bitcoin, how can I get started?

Patrick: It would be great if you could edit your question to only ask about one topic and give it a descriptive title. You can ask as many questions as you want, so you can create a new one for each of the other topics. :)

I think I should start with a more basic understanding of what is going on under the hood prior to getting two in depth into questions.

In addition to the pages that @Murch linked to, I also find this video to be very informative: https://www.youtube.com/watch?v=Lx9zgZCMqXE.

You never share your private key. You only share your public key, and a signature that proves you have the private key (without revealing the actual private key). See more detailed answer below.

I would like to thank all of you for the information provided. I'm still researching this stuff and have a long way to go in understanding the inner workings of how digital currencies work.

First of all, nothing is encrypted in Bitcoin, there is no "encryption" involved whatsoever. Cryptography: yes, but encryption: no.
The main aspect of private vs public key signing, is dat you can openly share your public key (that's what bitcoin balances are associated with), and then using your private key you can create a "digital signature" for a transaction spending coins from that public key. Other people can verify if this signature is correct, thus knowing that the transaction was signed by the one holding the private key. But here's the catch: this verification can be done without having the private key.
So essentially, the digital signature algorithm allows you to prove that you have the private key that corresponds to a certain public key, without sharing the actual private key.
And, obviously, neither is there a feasible way to reconstruct the private key from a given public key and a valid signature.
This is called ECDSA or "elliptic curve digital signature algorithm", because the inner workings are based on elliptic curves.
How this all works technically is somewhat complicated, there's some fancy maths involved. If you want to get into the dirty details, here's a good explanation: http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/

Also check out http://blog.chain.com/post/95218566791/the-math-behind-bitcoin

I'm going to say up front, I've referred to several sources but as of this stage have yet to send a raw transaction myself. So I think OP's question is quite relevant in that there is no concrete example available on Bitcoin SE outlining the transaction process (which is convoluted, especially for newcomers).
Start with this blog then check out:

Bitcoin.org Developer Section (the nitty gritty)
BTC Wiki technical section (more nitty gritty)

http://www.royalforkblog.com/2014/09/04/ecc/

Not really relevant, what the question is all about is just the ECDSA, and hashes or redeeming or raw tx layout is not part of that.

You're right. I've actually been confined with the iOS SE app which is finally HD (ie not an iPhone port); can clearly read OP's post (I missed the tail of it)


text:
what file/method is block reward processed?
I have managed to build an altcoin (from litecoin source) but my coin requires that I make changes to the way rewards are made. I have been looking at the source code to try to find where block reward is handled and what method does all the work. I did find this (In what line of what file does the block reward depend on?) however this looks to be old as i don't see a main.cpp file in the litecoin source.
does anyone know the modern files/methods that handle this. I already managed to follow the steps for creating my genesis block and everything looks to be working. I'm now in the phase of making changes. I would like to find the method that handles creating a block with a block reward. I will be changing how the block reward is done.
while I see chainparams.cpp has an ability to change the reward amount. I'm looking for a way to build a new type of reward system so i will need to look at how a coin is made from nothing. My coin will not be minting coins on block creation so i need to change how that method works.

The function is called GetBlockSubsidy now and it can be found in validation.cpp.

it looks like this method returns the amount how does this amount get accepted into a block. As this would be a transaction with no inputs and only the output of the reward.

does IsCoinBase() have to do with that?

Coinbase transactions have a special txid and vout combination that marks them as being coinbase transactions, which is what IsCoinbase() returns. If a transaction is a coinbase transaction, all input checks are just skipped. You can see that in ConnectBlock. The block reward is then checked after the inputs are checked here: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1940

I see thank you this gets  me on the right path. This looks to have solved two questions i had with removing the reward from the block and how to change how the reward is given out. Thank you.


text:
How do you deploy a Bitcoin-Cash full node on a Cent OS 7 server?
I'm looking to compile it on CentOS 7.
Perhaps a guide.

Follow this deployment guide.
https://github.com/CanadianRepublican/BitcoinCash-Daemon-Deployment-CentOS7
it includes a systemd service file, and a logrotate configuration file