text:
What are the considerations when assessing whether to deprecate a feature in Bitcoin Core?
What are the considerations when assessing whether it is appropriate to deprecate a feature in Bitcoin Core? What has the approach been in the past towards deprecation? Has this changed in recent times? Is there a process today to follow when deprecation is considered to be appropriate?

All software projects wrestle with deprecation trade-offs and these aren't necessarily specific to Bitcoin Core or Bitcoin projects (although Bitcoin Core would be considered on the more conservative side) or indeed the software industry generally.
Deprecating a feature has the upsides of reducing maintenance burden, shrinking the size of the codebase, reducing the test suite runtime and in some cases simplifying the user experience (e.g. if there are multiple features with overlapping functionality it can be difficult for the user to understand which feature to use).
The downsides of deprecating a feature are that it can potentially hurt the user experience and can break downstream projects with a reliance on that feature. As we are dealing with open source money in the worst cases this could mean users of those downstream projects lose money (though generally we are talking about stopping things from working rather than posing any particular risk to fund safety). Of course a deprecation could be botched too but implementation risk comes with any change, whether that be an added feature or a deleted feature.
These downsides can be mitigated to a material extent by staggered deprecations over multiple versions (warning log messages before full deprecation), release notes that highlight future intended deprecation and wider communication (e.g. mailing lists) that a certain feature is intended to be deprecated. Of course this does not guarantee that a user or downstream project reads of the planned deprecation but any project should at least plan to read the release notes of upstream projects that present a dependency. With awareness and with sufficient time to tweak their software ahead of time they should be able to avoid any negative impact on their users. It obviously requires developer hours to work around the deprecation.
Bitcoin Core is especially unique in that it eschews a BDFL (benevolent dictator for life) governance model (or indeed any model with an ultimate authority) and hence other than reviewed documentation there is no one individual to authoritatively say what its current approach to deprecation is.
In the past there have been a large number of deprecations across various areas (RPC inputs, entire RPCs, config options etc) and the number of deprecations does seem to have reduced over time as the project has matured and an increasing number of users and downstream projects have come to rely on it. However if Core were to stop doing any deprecations at all this would mean an ever increasing maintenance burden, ever expanding codebase/test suite and a user experience that could never be simplified. In the extreme these present security risks by themselves as contributor and maintainer time is allocated to things that should have been deprecated rather than more important things.
On a case by case basis it does seem Core will still allow deprecations in certain circumstances but only when they are assessed to be worth the cost when it comes to both communication requirements and downstream project risk.
There is a -deprecatedrpc=X option that lets you bring back a deprecated RPC temporarily (for RPCs that haven't had their code entirely deleted) but there isn't the equivalent for configuration options at the time of writing. (More details on RPC versioning are here.)
At the time of writing there are PRs/issues open that intend to deprecate the legacy wallet, UPnP support for older versions, the REST API etc. Just being open does not mean they will necessarily be merged and included in a release.
Here are some additional thoughts (1, 2, 3) from Core contributors:

RPC result fields (and sometimes input params) are still deprecated and a config option may possibly be removed (having a deprecation process for this may be an improvement). Removing an RPC outright seems much more rare to avoid needlessly breaking the API / user space, and sometimes an RPC is made hidden (not returned in the CLI help) but not removed. (Jon Atack)

If there is any user using this with a valid use case in mind, we shouldn't remove it nor deprecate it. (Marco Falke)

I am not a fan of deprecating features because there is another way to achieve something. This will put frustration and mental burden on our users, so there should be a convincing motivation for the deprecation. (Marco Falke)


text:
Which is the hash-preimage of a 2-input transaction?
When verifying a transaction, the Bitcoin node rebuilds the hash-preimage of it from the transaction that has received.
With one-input transaction, it is easy to build the hash-preimage of it:

Change the scriptSig to the scriptPubKey where the funds are being spent from.
Change the sigHash placement.

The result of the steps above is double hashed, then is verified with the public key and the "r" and "s" value of the signature.
But with a two-inputs transaction, which is the complete process?
To verify each input, does the hash-preimage include the other input?
Thanks in advance, it would be helpful if an example is provided.
[Context]
I wrote the following code that verifies using ECDSA math a one-input and one-output transaction, both P2PKH: https://github.com/SalvaZaraes/bitcoin-digital-signatures-article/blob/main/verify-p2pkh-tx.py
Now I having problems with building the hash-preimage of a two-input transaction, that's the reason behind asking the upper questions.

So, for example, a transaction like this one:
https://mempool.space/es/tx/592ea2010ec259252959b6047e227ceac6ffd0dbbe20bad71248960c18a5d890
That has two P2PKH inputs and one P2PKH output.
The corresponding Hash-preimage for the first input would be like this?:
010000000219f4d40cb4204ad8429ec3d98d240661593edcfcfb8efcb3b684141ceb0df2e4000000001976a914d52c9ce97c8dea0b71df687659a847a62c37732c88acffffffff22d07db06b68e4c15154db0ce0dd9c9dcd683a60a5117490451e0b52743492ca000000001976a91497ccdcca4f494b1bd652ad8f9d816b4bbb1108ac88acffffffff01c047bfe54d0000001976a91492512166101806dd6a695cbe56f883c3bea2a7e488ac0000000001000000
Breakdown:
01000000 - Version
02 - Number of Inputs
19f4d40cb4204ad8429ec3d98d240661593edcfcfb8efcb3b684141ceb0df2e4 - Previous Tx-id
00000000 - Input to be spent, in this case the Input at position 0 of the previous tx (First input in this tx)
1976a914d52c9ce97c8dea0b71df687659a847a62c37732c88ac - First Input Locking Script (scriptPubKey)
ffffffff - Sequence
22d07db06b68e4c15154db0ce0dd9c9dcd683a60a5117490451e0b52743492ca - Previous Tx-id
00000000 - Input to be spent, in this case the Input at position 0 of the previous tx (Second input in this tx)
1976a91497ccdcca4f494b1bd652ad8f9d816b4bbb1108ac88ac - Second Input Locking Script (scriptPubKey)
ffffffff - Sequence
01 - Number of Outputs
c047bfe54d000000 - Amount of Satoshis being locked in the new scriptPubKey
1976a91492512166101806dd6a695cbe56f883c3bea2a7e488ac - new scriptPubKey
00000000 - Locktime
01000000 - SigHash ALL

With multiple inputs, the inputs that are not being signed simply have blank scriptSigs. The preimage must be recomputed for each signature in each input as it will depend on both the input and the sighash flags that the signature specifies.

Thanks for the response. I have one more question, I have written it as an answer to my original question.
And thanks for your codes and contributions Ava! Your codes have been crucial for building my codes!

@SalvaZ No, you would not include the scriptPubKeys for the inputs not being signed. Those fields should be a single 0x00 byte.

source: Stack Exchange

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

sort: votes


text:
Subscribe PSBT inputs via Golang
I wrote the code to partially sign the PSBT. Briefly the server sends me a PSBT in Base64 format and N inputs to be signed. I encode the PSBT, sign the inputs with PK using Schnorr method. I update it back to Base64 and send it to the server (not finalised PSBT with unsigned input 0).
This is how it should look like after processing (correct):
{
    { ‘result’: {
        { ‘inputs’: [
            {
                ‘has_utxo": true,
                ‘is_final": false,
                { ‘next’: { ‘updater’.
            },
            {
                ‘has_utxo": true,
                ‘is_final": false,
                { ‘next’: ‘finalizer’.
            },
            {
                ‘has_utxo": true,
                ‘is_final": false,
                { ‘next’: ‘finalizer’.
            }
        ],
        ‘fee": 1.328e-5,
        ‘next": { ‘updater’
    },
    ‘error": null,
    ‘id": null
}

This is what it looks like after being processed by my script. The Updater status should change to finaliser for those inputs I signed, but it doesn't (incorrect) :
{
    "result": {
        "inputs": [
            {
                "has_utxo": true,
                "is_final": false,
                "next": "updater"
            },
            {
                "has_utxo": true,
                "is_final": false,
                "next": "updater"
            }
        ],
        "estimated_vsize": 286,
        "estimated_feerate": 7.0e-5,
        "fee": 2.002e-5,
        "next": "updater"
    },
    "error": null,
    "id": null
}

I checked signatures (they are correct), compared correct partially signed PSBT and my own (no differences except txid, which will be unique every time), even tried to finalise PSBT (although it is absolutely not need), but I still couldn't understand why the status of inputs remains Updater, when it is sent with finilize when signed via any wallet extension.I don't even understand where the error could be, since I do the logs BEFORE signing and AFTER signing, and their status in the logs is updated. Also, if you take the PSBT after my code has processed it and decoded it, it does update and is no different from the correct one except for the TXid.
I'm a complete newbie at coding, sorry if I said anything wrong

Wrong of my script:
Raw PSBT:
cHNidP8BAPwCAAAAAh/wxKDynlU3u3GZmUsMr8s/YrxCkOke8gFoZSDWOzMzUgQAAAD/////Q9g6nnkQbdroR/sr2jeNqZ9nlZbVuqSNdjakxTxLgYADAAAAAP////8ETQEAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOmGDAAAAAAAAIlEgsxHYe7mlcSxOwOnapg4WHRT5UuB+vWF8uMz6Oxu5Bf9DAgAAAAAAABYAFAnkWBtaeW/v/BxPBmkgboAct6nr/EgAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgAAAAAI/AJtZQNzaWdAzthBrUOlwXU1Igu3tpbp4SU60sbkdNSiEk6T0dMJUe0FlR7ZHOel2E/atN8Tiak8IT9P4PLKVFv40AxeROVOuwv8Am1lBnNpZ2V4cAhCeTYl8MAAAAABAStNAQAAAAAAACJRIDCs9kAJfdTiQei7Cf+RSH3Cwr5oxFjNj27APixQD2L4ARcgc+G1jBTUGzdWX447VOZ6zEec2eeffMqg8KTrQ6plriIAAQErrtgAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgEXIK0XtHBW7oxyV677kvzIL56kaRx0i5AADj3yumRxQD17AAAAAAA=

After a partial signature Signed:
cHNidP8BAPwCAAAAAh/wxKDynlU3u3GZmUsMr8s/YrxCkOke8gFoZSDWOzMzUgQAAAD/////Q9g6nnkQbdroR/sr2jeNqZ9nlZbVuqSNdjakxTxLgYADAAAAAP////8ETQEAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOmGDAAAAAAAAIlEgsxHYe7mlcSxOwOnapg4WHRT5UuB+vWF8uMz6Oxu5Bf9DAgAAAAAAABYAFAnkWBtaeW/v/BxPBmkgboAct6nr/EgAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgAAAAAI/AJtZQNzaWdAzthBrUOlwXU1Igu3tpbp4SU60sbkdNSiEk6T0dMJUe0FlR7ZHOel2E/atN8Tiak8IT9P4PLKVFv40AxeROVOuwv8Am1lBnNpZ2V4cAhCeTYl8MAAAAABAStNAQAAAAAAACJRIDCs9kAJfdTiQei7Cf+RSH3Cwr5oxFjNj27APixQD2L4ARcgc+G1jBTUGzdWX447VOZ6zEec2eeffMqg8KTrQ6plriIAAQErrtgAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgETQBvkTWkg2ZTZ+UZ/K7geb9GyQy4QiS7AGiP4OjhrxbzFHNhLKjTMpcmbOSAZtPFuepGYRmt4wVt3LNkCm5rxkEYBFyCtF7RwVu6Mcleu+5L8yC+epGkcdIuQAA498rpkcUA9ewAAAAAA

Correct:
Raw PSBT:
cHNidP8BAPwCAAAAAnMHa2DPvDr8AAHdLWOhY7syXfPc50uzAbNF8zH2MzMzIgQAAAD/////GZHgrBYm51oXH2xnmP7B58ww7ASUjKguqKsl2IUt2SUBAAAAAP////8ETQEAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOmGDAAAAAAAAIlEgsxHYe7mlcSxOwOnapg4WHRT5UuB+vWF8uMz6Oxu5Bf9DAgAAAAAAABYAFAnkWBtaeW/v/BxPBmkgboAct6nrrtgAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgAAAAAI/AJtZQNzaWdAftmCmUuo19ugM6sLcugvp5gSVViC1jqht25Z7TRUKU1d/Vt71BYtDObkQiDuQLoh6Eh1E96kTNglLr2uxsw+MAv8Am1lBnNpZ2V4cAhCeTYd8ReQAAABAStNAQAAAAAAACJRIDCs9kAJfdTiQei7Cf+RSH3Cwr5oxFjNj27APixQD2L4ARcgc+G1jBTUGzdWX447VOZ6zEec2eeffMqg8KTrQ6plriIAAQEr6GMBAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgEXIK0XtHBW7oxyV677kvzIL56kaRx0i5AADj3yumRxQD17AAAAAAA=

After a partial sign PSBT:
cHNidP8BAPwCAAAAAnMHa2DPvDr8AAHdLWOhY7syXfPc50uzAbNF8zH2MzMzIgQAAAD/////GZHgrBYm51oXH2xnmP7B58ww7ASUjKguqKsl2IUt2SUBAAAAAP////8ETQEAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOmGDAAAAAAAAIlEgsxHYe7mlcSxOwOnapg4WHRT5UuB+vWF8uMz6Oxu5Bf9DAgAAAAAAABYAFAnkWBtaeW/v/BxPBmkgboAct6nrrtgAAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgAAAAAI/AJtZQNzaWdAftmCmUuo19ugM6sLcugvp5gSVViC1jqht25Z7TRUKU1d/Vt71BYtDObkQiDuQLoh6Eh1E96kTNglLr2uxsw+MAv8Am1lBnNpZ2V4cAhCeTYd8ReQAAABAStNAQAAAAAAACJRIDCs9kAJfdTiQei7Cf+RSH3Cwr5oxFjNj27APixQD2L4ARcgc+G1jBTUGzdWX447VOZ6zEec2eeffMqg8KTrQ6plriIAAQEr6GMBAAAAAAAiUSCJwof7Xh35Js6aL/iDn8TPfRHPzAuFSuiewIWArB8uOgETQHvmy2yIG/Q/vgrA2GmZ40W/Ah7OT/ScTq2lTG7QxLJ6FjSgWf+rrkub+/PkZGp6FrIr7cXJQ+i+7lu+rkidy3oBFyCtF7RwVu6Mcleu+5L8yC+epGkcdIuQAA498rpkcUA9ewAAAAAA

Can you provide the PSBT before and after you have processed it?

https://justpaste.it/gpp9u  Not scam, just text share. Can't paste here because out of limit characters. There I specified Before/After (Raw/Partially signed) PSBTs and specified two cases: 1. This is what my script outputs. 2. Successful (which is received by the server successfully).
I'd like to point out that I don't sign input 0, because that's the PSBT I'm returning to the server. I also don't finalise inputs for the same reason. I swear I don't see any difference besides UNKNOWN and TXid fields which are unique every time a new signature is made. TBH I don't see the difference

I have edited your question to include the PSBTs.

The only difference appears to be the signature. BIP 340 recommends a particular deterministic nonce generation method, which should result in identical signatures even when signing multiple times with different software. That the signatures are different, coupled with the fact that analyzepsbt fails to consider the input finalizeable, suggests that you are signature is actually invalid.

Yes indeed, before I understand it. The problem is most likely in the generated SigHash, but I don't understand why it's calculated incorrectly specifically for PSBT partial signatures. I've made it more readable via GPT, but the it works the same.
https://justpaste.it/26pa0 - Full logs and output. Same Just code + PSBT output https://justpaste.it/i3o75. I also tried SigHashDefault/All (required 0, i.e. default) but nothing changed. Both PSBTs (good/bad) are without extra sig byte

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


text:
When was the 10,000 B limit for scripts introduced?
The file src/script/script.h defines a MAX_SCRIPT_SIZE of 10,000 B. Among other instances, the MAX_SCRIPT_SIZE is used in the IsUnspendable() check, which allows us to avoid adding outputs with excessively long scriptPubKeys to the UTXO set. It also causes input validation to fail if a scriptSig exceeds the permitted length.

In the context of talking about this limit, I was asked and didn't know: "When was the MAX_SCRIPT_SIZE introduced?"

It was introduced in v0.3.7, dated July 31 2010, in commit 73aa262647, titled "fixed segfault in bignum.h, additional security limits, refactoring -- version 0.3.7":
     vector<valtype> altstack;
-    if (pvStackRet)
-        pvStackRet->clear();
-    if (script.size() > 20000)
+    if (script.size() > 10000)
         return false;
+    int nOpCount = 0;

It apparently replaced an older 20000-byte limit (TIL!), which was introduced in v0.3.6, dated a day earlier, in commit a75560d828, titled "reverted makefile.unix wx-config -- version 0.3.6":
     if (pvStackRet)
         pvStackRet->clear();
+    if (script.size() > 20000)
+        return false;


text:
What are the steps to verify the inputs and outputs of a transaction. Excluding steps requiring blockchain access
{
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "1d8f38f6a5fbc7951568f64f3b9320a4ebd1053dce4641a5c5526d3cd7a805e1",
      "vout": 0,
      "prevout": {
        "scriptpubkey": "76a914293aa0e106ce67e0a538f79eba12be042012376488ac",
        "scriptpubkey_asm": "OP_DUP OP_HASH160 OP_PUSHBYTES_20 293aa0e106ce67e0a538f79eba12be0420123764 OP_EQUALVERIFY OP_CHECKSIG",
        "scriptpubkey_type": "p2pkh",
        "scriptpubkey_address": "14kzwSXGFcnmxypPuSGsXw2AJ6QYHMvAmW",
        "value": 43640
      },
      "scriptsig": "47304402205112f96bf7423703c221976603307f0e33913d39efc3344d68376fd2b8c0bd20022003ea588c06fa1a3e262e07ed6bf01a36f78741fe7bc6a91ff43c38a0a14e43fe012103bf68f1ce783df58a2459d549d5c655a1edc0f0cf4d79421fe978d358d79ee42a",
      "scriptsig_asm": "OP_PUSHBYTES_71 304402205112f96bf7423703c221976603307f0e33913d39efc3344d68376fd2b8c0bd20022003ea588c06fa1a3e262e07ed6bf01a36f78741fe7bc6a91ff43c38a0a14e43fe01 OP_PUSHBYTES_33 03bf68f1ce783df58a2459d549d5c655a1edc0f0cf4d79421fe978d358d79ee42a",
      "witness": null,
      "is_coinbase": false,
      "sequence": 4294967295,
      "inner_redeemscript_asm": null
    },
    {
      "txid": "6f7d353fb1c3af2694b54e268e9207ea59d1b699f56fc38fb0b4f410c1b6f36b",
      "vout": 1,
      "prevout": {
        "scriptpubkey": "76a9146012eb3f170e34c880d4d8f2e191e51940d23ad688ac",
        "scriptpubkey_asm": "OP_DUP OP_HASH160 OP_PUSHBYTES_20 6012eb3f170e34c880d4d8f2e191e51940d23ad6 OP_EQUALVERIFY OP_CHECKSIG",
        "scriptpubkey_type": "p2pkh",
        "scriptpubkey_address": "19kzXviUHUMLqbc3GgTN8jSC8iSoaYnGDw",
        "value": 221273
      },
      "scriptsig": "483045022100ccd24f74db54fc839996bf375d5a022fd7a7dbbab061f1dbe807e34ea2e365bc02206bf0f95a1018eee9ac868de517ff185a28d507cbc92972597a37604b5232ba34012103526b9a0a4ddcd0fc1cf7f0b5f4d202bc587ff44b7c253c68000b9e49a9434442",
      "scriptsig_asm": "OP_PUSHBYTES_72 3045022100ccd24f74db54fc839996bf375d5a022fd7a7dbbab061f1dbe807e34ea2e365bc02206bf0f95a1018eee9ac868de517ff185a28d507cbc92972597a37604b5232ba3401 OP_PUSHBYTES_33 03526b9a0a4ddcd0fc1cf7f0b5f4d202bc587ff44b7c253c68000b9e49a9434442",
      "witness": null,
      "is_coinbase": false,
      "sequence": 4294967295,
      "inner_redeemscript_asm": null
    }
  ],
  "vout": [
    {
      "scriptpubkey": "a914e00f79d486ff476db46eb6e188a5d31b5429a91387",
      "scriptpubkey_asm": "OP_HASH160 OP_PUSHBYTES_20 e00f79d486ff476db46eb6e188a5d31b5429a913 OP_EQUAL",
      "scriptpubkey_type": "p2sh",
      "scriptpubkey_address": "3N7jpoF34rPZp6WmcBmNxwpKAZZQCqDgbo",
      "value": 252238
    },
    {
      "scriptpubkey": "76a91441e4631b03326762604016821070aa95d7b15fde88ac",
      "scriptpubkey_asm": "OP_DUP OP_HASH160 OP_PUSHBYTES_20 41e4631b03326762604016821070aa95d7b15fde OP_EQUALVERIFY OP_CHECKSIG",
      "scriptpubkey_type": "p2pkh",
      "scriptpubkey_address": "171QX5w3Jvi5udAim7MyWhDRgeETfqZsTz",
      "value": 771
    }
  ]
}

In this type of transaction format, and we do not have access to the previous blockchain, what are the steps to verify the inputs and outputs of the transaction. Assume that the PrevOut in the inputs are correct and they exist in the blockchain.

The main confusion is which components I have to include in the trimmed transaction that i will prepare for signature verification of the inputs.


text:
Bitcoin transaction invalid no confirmations
Can some please help I had bitcoin sent to cash app wallet cash app rejected the deposit and reversed the deposit. Well the reversal never did confirm on the blockchain it show invalid my BTC is stuck this is the hash:
fc10ee8537db255493f1aeb9e07297f18714dd0f715698c8732c13de0b3cba3b.       What can I do to get my bitcoin

Does this answer your question? Why is my transaction not getting confirmed and what can I do about it?

The recipient address bc1qpwzp…kacv which was originally paid by the transaction that became invalid fc10…ba3b
later got paid a slightly larger amount (0.00500000 BTC instead of 0.00499346
BTC) by another transaction 31d1…fdb6.
If you were expecting to get paid about 5 m₿ to bc1qpwzp…kacv, it looks to me like you got paid on the 22nd of February, and you spent those funds on the same day in transaction 7953…c8c1.

Okay so here is another problem the original transaction was a withdraw from a casino. It was rejected from cash app and sent back to the casino they are saying I owe them the balance

That sounds like a very different matter. Unfortunately, we have no insight into the state of your customer relationships with either CashApp or the casino and cannot help you with that.


text:
What are the trade-offs between the different algorithms for deciding which UTXOs to spend?
When someone would like to make a transaction, their software has to choose which of their UTXOs to spend. Here are a few different ways that one might prioritize which UTXOs get spent.

Oldest UTXOs first
Newest UTXOs first
UTXOs with the smallest amounts first
UTXOs with the greatest amounts first
The Core Client Selection Algorithm: What is the coin selection algorithm?
Others?

What the trade-offs are for the different ways of prioritizing spending of UTXOs? Are some faster? Do some make make the block chain less big (grow less quickly)? Do some make the UTXO set smaller? What about making it so that the user has to pay the least fees? Taking all these factors into consideration, is there a method that is generally accepted to be the best way?
On possibility, which I like, is to spend the most UTXOs possible while still staying in the 1kb minimum fee limit. That way if nodes that prune the blockchain of STXOs (spent transaction outputs), they can prune more and it makes the blockchain smaller for them. Although, this might cause a small amount of bloating for nodes who keep the whole block chain, so it's a tradeoff.

Goals of Coin Selection
The challenge for picking a Coin Selection algorithm is that there are multiple goals to optimize for:
Privacy
A wallet's default behavior should be reasonable conducive to the users' financial privacy. The Coin Selection should reveal as little as possible about the wallet contents. Wallets should avoid linking too many addresses, not reveal excessive funds when unnecessary, minimize discernible patterns and fingerprints, but also maintain sufficient UTXOs to spread the balance out. Wallets should never reuse addresses.
Transaction Fee
The Coin Selection must aim to curtail the transaction fee for current transactions, but also minimize the total transaction fees in the long term. Since every UTXO must be spent eventually, it may be sometimes opportune to spend more UTXOs at a low feerate now, than at a high feerate later.
UTXO pool shaping
Dust should always be avoided, but generally small UTXOs will have a large relative cost at elevated feerates, so we should aim to avoid creating tiny change outputs. As a rule of thumb, wallets should not create UTXOs that cost a significant chunk of their value at moderate feerates. Aim for change to be at least 20–50k sats (less for smaller, more for larger input scripts).
Curtail UTXO set size
All UTXOs have to be stored on every full node, and all UTXOs have to be spent eventually. A wallet should keep sufficient UTXOs to maintain financial privacy, but as few as possible to minimize future blockchain data, fees, and the on-going storage cost on every full node.
Unfortunately, some of these goals are antagonal, and therefore every solution must find an appropriate balance for its priorities.
Common algorithms
Let's go over some of the most common algorithms for coin selection, as well as their advantages and disadvantages. We'll look at:

Oldest first (FIFO)
Newest first (LIFO)
Smallest first
Largest first
Random
Knapsack (used by Bitcoin Core)
Branch and Bound (used by Bitcoin Core)
Multi-algorithm (used by Bitcoin Core)

Oldest first (FIFO)
Pick UTXOs in order of descending confirmation count.
Good

Will consolidate small UTXOs eventually as they come up
Input sets are representative of your UTXO pool's composition, neither particularly small or large
Will transition wallet's UTXO pool to the new output format when a new output type is adopted for receiving
Will spend UTXOs from same period of time together which may reduce mixing of fingerprints due to different software versions

Bad

Gives a date for the oldest UTXO in the wallet, which e.g. reveals how long a user at least has been using this wallet
The values and confirmation count spacing of UTXOs may be used to estimate total wallet balance
The timestamp ranges on different transactions may form a serial pattern allowing to associate different transactions of the same wallet and to disambiguate it from other wallets using the same software (since time stamp ranges should never overlap except in last or first confirmation height)
Might be used to infer information about a wallet by watching when a known output is spent
Will not minimize the transaction fee

Newest first (LIFO)
Pick UTXOs with lowest confirmation count first.
Good

Most UTXOs have a small transaction graph, which may be beneficial for privacy
Spent UTXOs are closest in acquisition value to value at spending time resulting in smallest effective gain/loss

Bad

Hardly any consolidation at all if wallet's funds are increasing over time
Grinds latest UTXO down, until a newer is received or it is used up. May result in the wallet's UTXO pool having lots of small UTXOs.
Will combine the extensive transaction graphs of multiple youngest UTXOs when a larger amount is sent
Will link up all your recent activity by always reusing the newest change output
Will not minimize transaction fee

Smallest first
Pick UTXOs in order of ascending value.
Good

Consolidates small UTXOs ASAP, curbing the wallet's UTXO pool and minimizing future spending cost

Bad

Reveals lower bound for current UTXO values in wallet
Maximizes input sets which increases transaction fees for current transaction
Tends to overconsolidate the UXTO pool, reducing financial privacy
Links lots of addresses
Decreases value range of wallet's UTXO pool

Largest first
Pick UTXOs in order of descending value.
Good

Minimal transaction fees for current transaction
Links few addresses
Likely to create sizeable change outputs

Bad

Reveals upper bound for UTXO value in wallet
May reveal that wallet holds vastly more funds than necessary to make the current payment
Links consecutive transactions while change output is still the largest UTXO
Defers consolidation of small UTXOs, maximizing future cost
Bloats wallet's UTXO pool (and the global UTXO set) as single recipient spends are usually ±0 on UTXO pool count (minus one input, plus one change output), but incoming transactions increase the UTXO pool

Random
Draft UTXOs with equal chance randomly from all available.
Good

Selected UTXOs have no consistent fingerprints like age or value
Input sets are probabilistically representative of wallet's UTXO pool composition, becoming more consolidatory when more small UTXOs are present
Easy to implement
Random change output amounts increase value diversity

Bad

Does not minimize fees
May exhibit some fingerprints randomly such as revealing much greater funds in the wallet than necessary for payment

Knapsack (used by Bitcoin Core)
This algorithm (which incidentally does not solve a Knapsack problem) approaches Coin Selection by sorting all UTXOs by value and running 1000 iterations of selections randomly picking UTXOs with a 50% chance from largest to smallest. Whenever it overshoots the target, it deselects the last included UTXO and continues with smaller UTXOs. The algorithm is described exhaustively in in What is the coin selection algorithm?.
Good

Produces small UTXO pool
Pseudorandom selection of UTXOs reveals little information about the wallet

Bad

Aggressively consolidates tiny UTXOs including uneconomical outputs
Always aims for 10 mBTC change outputs (fingerprint and unnecessarily large)
With a lot of small UTXOs in your wallet, likely to cause big transaction fees
Unnecessarily expensive computation

Branch and Bound (used by Bitcoin Core since v0.17)
Deterministically search the UTXO pool's combination space for the least wasteful change-avoidant input set. Since there not always is a changeless input set, Bitcoin Core falls back to using the above described "Knapsack" approach in that case.
Good

Creates no change output which reduces current fees, future fees, cuts transaction graph for wallet, and has consolidatory effect on wallet's UTXO pool
Uses minimal input set among viable candidates reducing address linkage and fees
Selected UTXOs have no consistent fingerprints like age or value
Uses more inputs at lower feerates and fewer inputs at higher feerates due to waste metric
Prefers spending less blockspace efficient output types at lower feerates and more efficient output types at higher feerates due to waste metric

Bad

Does not always produce a solution
Sender cannot CPFP since there is no change output
More complicated to implement and expensive to compute

Multi-algorithm (to be used by Bitcoin Core v23+)
The next release after Bitcoin Core 22.0 will run Knapsack, Single Random Draw, and Branch and Bound coin selection in parallel and then choose among the three resulting input set candidates the one that scores best according to the waste heuristic, which was previously already used to pick the best Branch and Bound solution.
Good

Spends more inputs at low feerates, fewer at high feerates reducing total fees
Consolidates small inputs when economically sensible
Since input sets are sourced from multiple approaches, patterns are more difficult to identify
Often avoids change, improving privacy, fees and reducing linkage

Bad

Complicated to implement and test
Computationally intensive to compute
Still uses a fairly high minimum change of 10 mBTC (when change is  produced)

Update in Nov 2021:

Remove ambiguous use of term "dust"
Complete rewrite to update to my current understanding
Add Random Selection, Branch and Bound, and Bitcoin Core's multi-algorithm approach

Update in 2021:

Removed a few allusions to Coin Age Priority as transaction selection policy in block building which was removed in Bitcoin Core 0.12.0 in 2016.
Removed erroneous claim that spending multiple inputs from the same address is cheaper

Note that Bitcoin Core used the Knapsack solver as its only algorithm until 2017, but since then has added an improved algorithm proposed by the author of this answer.
Update in 2014:
I have been looking into coming up with a better Coin Selection Algorithm, but haven't found one yet that significantly improves on the Core Client Selection Algorithm.
Here are some ideas to improve it:

When a UTXO is randomly selected, add all other UTXOs associated with the same address as well: less linking of transactions improves privacy, potentially consolidates UTXOs into fewer.
Instead of selecting the smallest change, one could aim to create a change of the same size as the spending target. Assuming that people mostly send useful amounts, this would create new UTXOs of useful value instead of the smallest possible changes as it currently does. It also makes it harder to guess what was the change and what was the payment.
Select UTXO set to minimize transaction fee, instead of minimizing change output.

Thank you for this great, and very thorough answer. There were quite a few things in there I hadn't considered.

Thanks for this detailed answer. Looks like still legit in 2019, but is there any new "Coin Selection Algorithm" to look around ?

Yes, Bitcoin Core started using the Branch and Bound algorithm in 0.17.0: https://bitcoin.stackexchange.com/a/72928/5406. You can also read a bit more about coin selection in general here: http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf

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


text:
Extract sender ID and recipient ID of a bitcoin transaction
I'm new to this world and I'm trying to learn the blockchain world and especially now I've concentrated du bitcoin-core, I would like to parser and get the various information like the various sites where you enter ID of the wallet and you get all its information including transactions.
In particular I am interested in getting information on the type transactions, Id wallet sender and Id wallet recipient.
I do not ask any ready solution but only a hand to understand where to start and where to document.
I saw that on the net there are various blockchain parsers but at least the ones I met did not allow me to obtain the information I'm trying to figure out how to get them.
Thank you and above all excuse me if I asked stupid questions but I'm learning

Hell, welcome to Bitcoin.SE! I've linked a question above that has a lot of good basic info, I think it would be helpful to your understanding to read through some of it. As for your more specific Q: there is no information about sender/recipient wallets stored in the blockchain record, but Addresses can be viewed using a block explorer service. A user's wallet is a collection of addresses, but for privacy reasons it is important to not let the whole world know what all of your wallet's addresses are!

Thanks, guy, well @chytrik so the only address that I can extrapolate of the transactions is that of the sender, packed inside the secp256k1 public key? the recipient could extrapolate it from the content wallet of the sender, I understand?

Extract sender ID and recipient ID of a bitcoin transaction

Transaction data in the blockchain does not include any ID for a "sender" or "recipient".
Transaction data includes scripts used to spend cryptocurrency amounts listed in the transaction data. The most common of these scripts specify what is commonly called an "address" but that is derived from a public key and is nowadays usually unique to a transaction. It is designed to be difficult or impossible to identify a sender or recipient from these "addresses".

sites where you enter ID of the wallet

There are no sites (in general) that do that because cryptocurrency wallets don't have wallet-IDs. Certainly none that are part of transaction data in the blockchain.
The only really significant data in a wallet is the private-keys it contains. Recovery-phrases or seed-phrases may be used to re-create these private keys. A wallet's data may be protected by being encrypted on disk using a password or pass-phrase. None of these constitute a wallet-ID.
Blockchain explorer websites generally allow you to examine blockchain data associated with one of

address
transaction-ID
block number (height)
block hash

None of those really constitute a sender-ID a recipient-ID or a wallet-ID.

Decoding Transaction Data
A good explanation of the structure of a Bitcoin transaction in a blockchain block can be found at https://en.bitcoin.it/wiki/Transaction
This gets more complex as time goes on and new features are added (SegWit, Bech32, ...) or when you need to fully decode lesser-used types of transactions (n of m multisig?).
Search for Code to parse a Bitcoin transaction

A few unintuitive aspects of Bitcoin and similar cryptocurrencies:

Wallets don't contain bitcoins.
The blockchain does not contain bitcoins.
Bitcoins are not really sent or transmitted through the Internet.
Bitcoins don't really exist anywhere - they are more a unit of measure.
The blockchain is not really a ledger (it is a journal).
Bitcoin addresses don't label places or people or wallets.
Bitcoin addresses are not used to deliver transactions or bitcoins somewhere.
Bitcoin transactions don't have to include any addresses.

Hello @RedGrittyBrick, Thanks for the help in understanding, and I'm sorry if my questions are stupid.
So what I observe in this blockchain query are not id identifying the sender (maybe I misunderstand on the ID wallet), I would need the information of a transaction from whoever starts, just like in this link here. link.

@vincenzopalazzo: Your question isn't stupid (though my answer may be not as helpful as I intended). I've added a link to my answer which I hope you (and others) will find useful.

thanks for your help, I'll take a look at the link and I'll let you know.


text:
How Extracting address Bitcoin to script multi signature
I want to extract the correct address from a script multi-signature.
I have this real script multi-signature from this ScriptSig (tx index 1), so this is a readme script for this address
OP_2
    03385adff37fd3d0a620ebc4e9866e81dda8ba8616e5ebcae899c7f51899267ae7
    034c08511718f947d1a3e152195c5e2756588e3e0c2c7730927eb6647af4942107
    033da9f8938a5b947a723df21b73fbd3985b719249324d2c705acfb97d63a5df9e
OP_3 OP_CHECKMULTISIG

Now from this resource these value 03385adff37fd3d0a620ebc4e9866e81dda8ba8616e5ebcae899c7f51899267ae7, 034c08511718f947d1a3e152195c5e2756588e3e0c2c7730927eb6647af4942107, 033da9f8938a5b947a723df21b73fbd3985b719249324d2c705acfb97d63a5df9e are the public keys, so this value is a pure public key? and for exstract the address form these I can execute the procedure for build bitcoin primitive address ?
or I'm lost some information for this argument?
an example if I suppose this value is a public key 03385adff37fd3d0a620ebc4e9866e81dda8ba8616e5ebcae899c7f51899267ae7
This should be the compressed public key because it starts with "03" if apply the HASH160 I get this address "14r7XjPtqVijLRhY9BkGAtDqVDp4txsK1X"
Is my reasoning right?
More Information on the why I want to get the address to P2MSH
I don't want to break the privacy of the address 3CD1QW6fjgTwKq3Pj97nty28WZAVkziNom, I'm reading this article and it catalogated the address 3CD1QW6fjgTwKq3Pj97nty28WZAVkziNom how an scam address, but I think this is restrictive affermation, because the address with "3" can to hide more people/address.
I'm only learning and I don't want break the privacy of the people

The correct address is 3CD1QW6fjgTwKq3Pj97nty28WZAVkziNom. The individual public keys are only able to access the coins if they act together in a group of at least 2 out of 3. If you derive a regular p2pkh from each individual key, you will end up searching for utxos that likely don't exist.
Also note that each individual public key does not necessarily mean that there are that many individual people involved. Many security conscious companies and people have multisig addresses with each key stored on a separate device/location, requiring multiple signatures from different systems, etc. They may all still be under the control of a single entity.
When cataloging transactions and matching patterns across the network, you should be working with the P2SH address for a multisig address. Breaking it down into its components will produce incorrect results.

yes, I understand this, but I think if you build a graph oof address for analyzing the suspicious flows, you should be more analyzing the public key and not the address. So my question is aimed at the process of establishing address to a single public key in a P2MS.

The individual public keys here don't matter (mostly). You should only be graphing the utxo chain, which relies only on the entire redeem script - note that there are other types of redeem scripts as well, not only multisig ones. If you rely on a key following approach, you might not be able to work with all transactions.

But this is referer to the script no standard but I think if the bitcoin moved to the 3 different public key I must be represented the 3 nodes and not one. This could mislead the algorithms built on the graphs. also because if I am part of a clan investigated for scam, I can use the public key with the simple P2PKH script and this I shouldn't do it very lightly

I'm afraid I don't really follow what you're trying to do. Feel free to join me in chat


text:
tradehill.com alternative?
I am constructing a small online store where I would like to accept BitCoins as payment.
I have not had any luck running the Deamon on my server, so I was planning to use tradehill.com and then make use of the API.
But every time I log in i get the

"Socket not connected Sorry, our notification socket isn't connected
  yet. Try again in a few seconds!"

Error... And it's making me kind of anxious to use the system, since it seems a bit derelict.
Does anyone know any similar systems ? Or know what's going on backstage of TradeHill.com ?
Any suggestions will be much appreciated.

This question might interest you: http://bitcoin.stackexchange.com/questions/126/how-can-i-accept-bitcoins-on-my-website

You may want to consider an alternative approach using a combination of MultiBit and MultiBit Merchant. This will allow you to run your online store without putting any private keys on it. At the time of writing it's still early alpha, but progressing fast. See https://github.com/gary-rowe/MultiBitMerchant

If you have technical problems with Tradehill, your first step should be to contact them about it.
It's not clear to me in what capacity you want to replace Tradehill. If you want an exchange then Mt. Gox is an obvious possibility, or any one of the exchanges listed here. If you want an eWallet, most exchanges are good for this too, and flexcoin is another possibility. If you want merchant solutions, check out bitpay.

I have tried getting in touch with TradeHill for a week or two, but without any luck.

I'm sorry to hear that. I don't often hear complaints about Tradehill's customer service, and I often recommend Tradehill to people. I hope they are able to resume being responsive to customers.

It's ok. Still no contact, so concidering making my own little system.

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


text:
Why can we have small fractions of a Bitcoin?
I didn't study the inner workings of Bitcoin (yet), but already since when I just started using it, I wondered why a Bitcoin can be split up in parts.
Because there is a limit on the amount of Bitcoin that can be mined ever, fractioning Bitcoins is a huge advantage, especially if it's popularity increases.
Is there a limit on splitting Bitcoins into pieces?
EDIT:
I just found in this answer that BTC has a maximum of 8 decimals. Is it a good assumption then that every "BTC" consists of 10^8 smaller parts? So every block does not consist of 50 1-BTC parts, but 50*10^8 smaller parts?

Miners aren't awarded millions of "pieces": their accounts are just credited with an integer number of BTC base units ("satoshis"). When they transfer that BTC, the balance of their account is reduced and the balance of the recipient's account is increased. (This isn't exactly how it works, but it's close.)

It is presumed that the value of the Bitcoin is going to go up. If people can't afford one BItcoin they can afford a part of it.

Bitcoin amounts in the protocol and software are expressed as an integer number of "satoshis". 1 BTC is defined as 10^8 satoshis. So a block reward that is internally represented as 5*10^9 satoshis is displayed in the GUI as 50 BTC.
Splitting bitcoins to even smaller fractions will require a change in the protocol and software, and may be done when their value becomes much larger.

A psychological perspective
Most currencies allow for 2 decimal places for common use because they are strongly regulated by their issuing government. Some provide 3dp, others, like the Yen provide none (integer only). It should be noted that stock exchanges offer shares priced down to 4dp but given the surrounding fees it is not economical to purchase a single share at that price so is used mainly as a multiplying factor during a bulk purchase.
Nullifying an argument
When Bitcoin was being created it was completely unknown how the economy would grow and by pushing out to 8dp it immediately nullified the standard argument of "21 million bitcoins, why, that's not going to be enough to run the world - I won't bother with it". This is because the total number of currency units available becomes 21 * 1,000,000 * 100,000,000 which is 2.1 quadrillion - more than enough to run a global economy.
Forcing developers to work up front
A secondary effect of this decision is that it sets the tone of Bitcoin as being completely apart from other currencies. No other currency operates with 8dp and this has the effect of introducing some specialised currency handling for Bitcoin calculations. This is necessary for other currencies too, but having 8dp forces the issue in the mind of a developer far more than a standard 2dp currency.
Once that specialised handling is in place it can be scaled further than 8dp to any number within reason and this makes Bitcoin very scalable. If the time should come that 2.1q units is not enough, then the code can be altered to accommodate the new demand.

+1 @Meni's answer is more concise and to the point, i.e. quite better than this one given the question. But this one is still good and interesting, so it's definitely worth keeping and upvoting.

@Lohoris Thanks - that was what I was aiming for (and thanks to Meni for the correction d'oh!)

FYI - most currencies are traded to the 4dp.

(21e6*1e8)/7e9 = 300,000. Assuming an average net worth per person of $30,000, a satoshi can only be split down to $0.10 if it were globally adopted.

$30,000 is 2x the average global wage so $0.5 is probably closer. And then there are inflationary effects devaluing that dollar daily but I take your point.


text:
Can I use current Bitcoin protocol and Bitcoin client to create my own controlled currency?
Since Bitcoin network and Bitcoin currency are not so reliable and can't be controlled.
Also, they are open source. How difficult it is to use the current client and protocol to create a new, independent currency controlled by me?
I will use such currency as a medium for money transfer. Much like a website money or credit.
If I used the current Bitcoin as it is, I would be responsible for all Bitcoins in the world. I want to be responsible for the Bitcoins created by me only. So even if the project will end or the value of Bitcoins goes down, I can then compensate my clients for their loss.
What experience and knowledge needed to accomplish this?(Hardware and Software).

It won't really work well for this purpose ... there are simpler methods for achieving this (read about Open Transactions). Also, I believe this question is a duplicate, there was at least one very similar question some months ago.

I think it's called Solidcoin ;-)

@ripper234 I believe the question you are referring to is this: http://bitcoin.stackexchange.com/questions/1409/can-bitcoin-software-be-used-to-create-a-private-currency-single-issuer

Bitcoin is a decentralised cryptocurrency, meaning there is no central authority to control it. What you need to look into are centralized currencies. If you want to go for the easiest route, all you need is knowledge of programming websites and databases and you can easily make some database storing arbitrary numbers representing an amount of your currency belonging to someone. This, however, would be like Facebook credits, Microsoft Points or the like, not really a cryptocurrency. You could look into centralised cryptocurrencies, like loom.cc . Also worth noting are Open Transactions.
One could, however, create an alternative decentralised cryptocurrency, like SolidCoin, LiteCoin and dozen of others, but that doesn't create as much solutions as it causes problems. If you'd modify the source code you could make it so that only one address is allowed to create coins, but the whole system would be vulnerable to numerous attacks as your computing power might not be enough to secure the system.
All in all, it is not hard to create a centralised currency, but Bitcoin model might not be the best to use for this problem.

There is nothing stopping you from compensating your clients for a loss in Bitcoin with Fiat money.
Do you want to create your own centralized currency? Why?
What happen if you die? What stops you from printing endless amounts of it?
Why would someone use it and trust it?
If I give you 200.000 of my own private currency to compensate you for a loss in Bitcoin, its only valuable for you if you can get things or services for them.
The Bitcoin network has more mining power than a couple of supercomputers combined which makes it very expensive to bring it down. You would need to invest millions of dollars and many weeks to get that kind of computing power.


text:
How do I pay for something anonymously from the UK using bitcoins?
I've seen the following guide but it's no good as I can't use bitinstant from the UK. Can someone recommend an alternative?
Step 1.
Download and install TOR
Step 2.
While using TOR create a Tormail account
You can confirm the address at http://tormail.org/
Step 3.
While using TOR, visit http://www.bitinstant.com
Step 4.
Choose the Cash deposit to Bitcoin to email option.
Step 5.
Follow the instructions on Bitinstant to make your cash deposit, and have your Bitcoins sent to your new Tormail account.
No ID is needed.
Step 6.
Receive your Bitcoins via email.

Is the question only about "how do I purchase bitcoins anonymously from the UK"?

Buying coins non-anonymously in the UK:
Transferwise to Bitstamp's European account - £1 transfer fee, then <0.5% commission to buy.
Spending:
I guess you would use a mixer service

Transferwise no longer supports withdrawing to Bitcoin exchanges.  You can still use CurrencyFair though.

You can deposit cash into Mt. Gox's account with Barclays but you can't use Tor to set that up as Mt. Gox will insist on you providing identity to access your funds after your account first is accessed through Tor.

http://en.bitcoin.it/wiki/Mtgox#UK_.28GBP.29

There is a site called London Bitcoin Exchange, though there is not much about them yet but perhaps you can trade in-person.

http://londonbitcoinexchange.wordpress.com/

You can send cash (GBP) or check to Bitcoin Nordic, by mail, to purchase bitcoins:

http://en.bitcoin.it/wiki/Bitcoin_Nordic  (They accept other currencies, like EUR, as well.)

You might find a local trader (or place an buy order and see if anyone is selling):

http://www.LocalBitcoins.com

There are a number of methods:

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

[Update: You can also buy bitcoins from the UK now using BlockChain.info/wallet thanks to their integration with Barclay's Pingit:

https://blockchain.info/wallet/deposit-pingit

Or even better, using "Faster Payments" bank transfer:

http://blockchain.info/wallet/deposit-bank-transfer ]

[Update2: Tenakha does many person-to-person trades in London.]

And one other, temporary, option -- you can meet with the folks  as the London Bitcoin Conference:

http://www.bitcoin2012.com
http://bitcointalk.org/index.php?topic=67199.0

Buying bitcoins is location dependent.
Paying for a purchase using bitcoins is not location dependent, you can do that from anywhere in the world.
There are mixing services that will help protect the privacy of your payment.
Blockchain.info/wallet provides the ability to send a payment through a mixing service.
So after you've acquired bitcoins in whatever manner suitable in your location, then send them to your wallet on Blockchain.info/wallet.
You can access that wallet using Tor.

http://Blockchain.info/wallet


text:
Split transaction
Looking at this transaction I was wondering what the unspent part means. Does it belong to the original address owner? If so, how can it be used/claimed?
Edit: All cleared up, and seemingly a feature of Bitcoin-QT.

The word "unspent" doesn't appear on that page.  Can you explain specifically what you are asking about?

The link was missing a piece.

The transaction in question has as input 0.37210663 BTC from address 1JvHotWuLtAU991q1mVsBJJe3SiLYq4LQD, and its outputs are:

19eeheTSBooFHQHXDwJZjzoD9uyrXXQ2Mm  0.09507071 BTC
1EXmvaXW99eqATkcrMVM8CGe5xYKv9jCR9 0.27661134 BTC

The first output has already been spent.  This means that whoever holds the private key for address 19ee... created a new transaction using this one as an input.
The second output has not yet been spent.  This means that whoever holds the private key for address 1EXm... has not yet created a new transaction using this one as an input.  They are free to do so at any time.
It is likely, but not certain, that one of the addresses 19ee and 1EXm belongs to the same person as the sending address 1JvH.  Because the protocol requires that all coins from the input must be used in the outputs (or rather, any amount that is not used becomes a transaction fee), if the sender didn't actually want to spend all 0.372 BTC, they would have to send the remaining coins (minus whatever they wanted to offer as a fee) back to another address they control.  This idea is called change.  But there is no way for us to know for sure whether this happened, or if it did, which of 19ee and 1EXm is the "real" destination address and which one is the change address.
It is even possible that all three addresses belong to the same person, who simply wanted to split his coins among some new addresses for some reason.  Again, we have no way to know.

Thanks. This question is a duplicate of the one you linked to.


text:
Extracting addresses from wallet.dat without knowing password
It is a pink flash with a comb icon on it. It contains a wallet.dat file. I have read about pywallet or syncing with bitcoin core, but I am an amateur and apprehensive. Is that a good route? Is there an easy way to identify the wallet address to check activity?
Any advice is greatly appreciated.
Photo below.

In my part of the world a lost wallet remains the property of the person who lost it and honest people finding lost wallets are expected to take the found wallet to local police (or maybe property owner) . My advice would be to avoid stealing money from someone else's wallet.

Plugging “lost” devices found in the wild into your computer is a great way to catch malware.

@RedGrittyBrick The police (enforcers of fiat law) were not the rightful owners over the wallet either and given the state of the law they would rather take all of the funds off of it before the rightful owner (who may have purposefully 'lost' their keys you never know) . @ Murch while its true that plugging in unknown hardware devices is dangerous on devices you actually use, its plenty safe to plug one in to a spare clean device that is disconnected from any access to your personal data. Which is advice that is more in line with the user's question.

Furthermore simply finding a wallet.dat file does not imply that this is a full wallet, the user may have very well had multiple backups of the wallet and moved their funds once they realized they had lost one of the copies. Simply assuming the worst in this situation seems irrational.


text:
How to obtain private key from BIP-39 mnemonic
Trying to obtain a lost private key from 24 mnemonic phrases and a 25th word. Has anybody successfully managed to do this ? Have looked at BIP39 converter but not sure if this has that ability, and seems to return 128 character key and the wallet requires a 64 hexadecimel input

seems to return 128 character key

That could be the seed number not the key.
As BIP-39 says

This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods.

I think you need to apply BIP-32 to the seed, using a suitable derivation path.


text:
Use new phone to access previous account on old phone
I previously had an account on an old phone. I have now redownloaded but seem to have been issued a new account. Is there anyway to access the previous one? My Google play email is the same as when I originally downloaded the app many years ago


text:
Sent bitcoin to qrong address
I sent bitcoin to the wrong address due to my wallet app putting the wrong address in.
bc1q5f2csqmdmd6kawa4f8yemywjr9zj3z0e2nf3ed
Just looking to see if anyone can help me to contact this wallet address's owner to try and get my bitcoin back


text:
How do I start -testnet in -deprecatedrpc to test a script?
I hope all is well during our COVID-19 pandemic.
My question: How do I start "bitcoind -testnet" in "-deprecatedrpc=signtransaction" mode?
Do I simply start it the same way without being a test and insert "-testnet" between "bitcoind" and "deprecatedrpc" like this"bitcoind -testnet -deprecatedrpc=signrawtransaction" (I mean, I need this to make sure my script is tested before running it and it keeps saying "error: Could not connect to the server 127.0.0.1:18332 (error code 1 - "EOF reached").
Thanks.

Can you point to where this identical question has been asked and answered? Also, my question refers to "bitcoin", not the website (?).

...I only found where the issue referred to -testnet and the server protocol in general, not the use of -testnet in -deprecated mode. I do hope this clears up the understanding of my question. Have a nice day.

@RedGrittyBrick's comment was about your corollary question whether you may offer a contest to incentive answers to your question.

I was able to start -testnet in deprecated mode to test my script like this:
bitcoind -testnet -deprecatedrpc=signrawtransaction


text:
Lost access to ledger hidden wallet
Hi Yep I know I'm a prat but I am totally confused how this has happened. So I have my ledger 24 seed phrase. No issues there at all. But I set up the advanced feature on ledger I believe is called bip39 which allowed me to have a hidden wallet attached to this new passphrase. Unfortunately and I have absolutely no idea how but when I type in my passphrase the wallets with the money in don't show. I wrote down each passphrase (I had two, yes another mistake) and have no idea why they are not showing my wallet addresses with the money in. I guess I made a mistake and didn't write it down correctly or not at all but I only ever use the same passphrases so I either did a typo twice when I set it up or I've somehow forgotten them. I can see the wallet addresses on chain as I went into the exchange and copied the address and went to the explorer and the money is still sat there. I can honestly say I'm baffled as I'm not new to crypto either so very annoyed with myself. Is there anyway I can get access to these hidden wallets without the passphrase? I have the 24 word seed phrase. Someone on Reddit mentioned Ian Coleman? Anyway I am offering a small reward if I get it back. Many thanks

Make sure to turn off wifi and stay offline when interacting with Iancoleman also make sure to reset your cache before going back online.

Is there anyway I can get access to these hidden wallets without the passphrase?

None whatsoever.

I am offering a small reward if I get it back.

Expect to be overwhelmed by offers from skilled confidence tricksters pretending to be recovery agents.

In case you just have a typo, there is a good chance that you can recover your wallet with the help of btcrecover.
They have different ways to configure possible typos. You can find more about them here.


text:
No Account number or Address in listtransactions for generated blocks
I am in the need (for my app development) of having more information printed with the "listtransactions" of the bitcoind daemon.
For blocks generated it shows the account as "" and no bitcoin address is shown either.
Why in fact not? The blockexplorer shows the address that "mined" the block, and the mapping of the address to the account number works perfectly when receiving coins, why not for generated blocks?
Even this request doesnt make it into the mainstream client, any help telling me where in the code to put it (if at all technically feasable) is very much appreciated.

In addition to your question here, you may also want to create an issue on the Bitcoin GitHub for your feature request. As for the solution, I know Bitcoin keeps the whole blockchain available and searchable, that's how sites like BlockExplorer work, I'm just not 100% sure of how to access that particular database. I'm sure someone in our community will know, though :)

Come to think of it, would a private Bitcoin-abe server work for your purposes? At the very least you should be able to find code to parse the blockchain somewhere in there, and it's Python so it should be easy to understand.

There is an embryo of a  patch on github which was precisely meant to solve this issue. It was announced on the dev mailing list but never received much attention. Now it's a bit outdated (the latest merge with master is from Sep 26). Maybe you can start from here.


text:
Is Quickbitcoins.net gone with all money?
Site is down, google finds no new address. Can find nothingness on bitcoin forums, but Gregor not brightest crayon, perhaps doesn't know how to search.

The site was shut down in November and the former operator claims to no longer be involved with the service.
That operator is now attempting to raise funds for a new venture, Ziggap.
QuickBitcoins didn't take deposits.  They were a service used to buy coins for immediate delivery or for selling coins with immediate cash-out.
If you are owed bitcoins or funds from a cash-out transaction, the operator at the time would still be responsible for that liability, regardless of whatever disclaimer is provided about now "no longer having any relationship" with the service.


text:
I'm in the uk, I wish to purchase bitcoins, but the process seems to be very convoluted. There has to be an easy way?
Any way that doesn't involve days of delay, verification etc? Are private traders available?

Provided there is someone near you who advertises on LocalBitcoins, it's probably the most effortless solution available at the moment.

Localbitcoins.com is best for bank transfers now. You don't need to live near the seller, just have an account in GBP to transfer £ to the seller's account. You can search for all sellers within X miles of a city near the middle of the UK.
However be careful, since the Localbitcoins.com system isn't designed for bank transfers. Review the profiles carefully if you use this method.

You can use:
http://quickbitcoin.co.uk
https://bitbargain.co.uk/
Both work fine.


text:
Which is better back-end mining pool?
So far I've seen Pushpool, PoolServerJ and P2Pool. Which one of this would be easiest to set-up, maintain, effectiveness, and overall security?

PoolserverJ seems the best so far and easiest to set up.
Pushpool was the original but has some issues. The documentation is also a little hazy if you're a newbie to linux.
P2Pool is a decentralised pool, meaning that if you want to set up your own private pool, you can't use P2Pool.

there are several new mining pool server with new protocol for fastest connection, one of them is eloipool
See this table for mining pool comparison, https://en.bitcoin.it/wiki/Poolservers


text:
Bitcoind running in vagrant can't import bootstrap.dat from external directory
I am working on a bitcoin development environment in a box, and I've got the bitcoin reference implementation compiling and running so far in this vagrant environment: https://github.com/tlehman/bitcoin-vagrant
Another feature I would like to add is an optional script in /home/vagrant that can download the bootstrap.dat file to speed up downloading the blockchain. My first stab at this problem was to use transmission-cli to download  https://bitcoin.org/bin/blockchain/bootstrap.dat.torrent, and then copy it to ~/.bitcoin/, and then fire up bitcoind for the first time. This works, but it fills up the virtual machine, and it still takes a long time to get imported. On top of that, a vagrant destroy command would blow away all the blockchain data, which is not desirable, I'd like to decouple the data from the program and it's dependencies.
The way I tried to solve this was to mount ~/.bitcoin/ as /vagrant/data/ (which is mounted to a folder in the host filesystem). The problem I am having is that when I run bitcoind -daemon, I get an error saying
Bitcoin server starting
vagrant@precise64:~$ : Error opening block database.

Do you want to rebuild the block database now?

My first guess was that the ~/.bitcoin/bootstrap.dat file was corrupted, but the SHA256 of the file is d05062052be4dd6fbaeac5f17598e52f7ad545f9f938acefaf7067ecce1d7b5a, which matches the SHA256 in the torrent's readme.
My second guess was that LevelDB needs some filesystem feature that isn't present in VirtualBox's synced directories, but I am not sure what that would be.
What can I do to fix this or work around it?

Can you create/edit files in that directory from the guest system? My hunch is that it doesn't have write permission.

@NickODell Yes, I can create and delete files as vagrant user.

are you running the vagrant box on a Windows machine or Linux? I've encountered strange problems before due to the difference in file-structures on the mounted directories

@OACDesigns I'm running vagrant on Mac OS X, using HFS (case sensitive).

With bitcoind 0.10 (current release candidate) you don't need bootstrap at all anymore as it downloads faster and more efficient than bittorrent would. Bootstrap is probably going to disappear soon. So you might not want to bother at all.

You don't say, I'll remove the bootstrap part anyway, since it's kind of awkward.


text:
What if ISP's block port 8332?
Hypothetically, if it were a well coordinated NSA-type shut down and ALL ISP's suddenly blocked port 8332 (major ones anyway), how would the Bitcoin system immediately handle it?

Bitcoin can be configured to handle any port for both peer-to-peer communication, as well as JSON RPCs. However, as Bitcoin clients do not encrypt their messages, it would still be fairly easy to filter out Bitcoin-related activities. One could then switch to using Bitcoin through TOR, or the developers could implement message encryption if needed be.

We would all switch to port 80.

Port 80 is HTTP standard; many servers running Bitcoin are also running websites, so I doubt that would work. AFAIK, though, just switching ports in the client software would work.

Yes, mostly my answer was to illustrate the futility of trying to kill Bitcoin by port blocking.


text:
How does SatoshiDice operate with 0 confirmations?
I understand they use your bet as an input, but what does that mean and how do they do it? Can they use the standard bitcoind as a server against which to run the API from?

They are not running the standard bitcoind.

How do you know?

SatoshiDice uses bitcoinj to create its transactions.

Does bitcoinj offer anything that bitcoind doesn't?

@Shamoon of course it does, why would they be using it otherwise?

@lohoris can you clarify as to what it offers that's different?

@Shamoon no, I have no idea. It is just obvious it does.

@Lohoris its not actually obvious. you are making an assumption. would be nice if when you make assumptions that you would attempt to explain

This is oversimplified, but here's one sequence showing a serie of payment transactions:
Miner --> You -->  Me -->  SatoshiDice --> Me
So you send half a bitcoin to me and I use a client that lets me send it instantly to SatoshiDICE.   SatoshiDICE then includes at least part of that payment in their win or loss return payout.
Once your payment to me confirms, then mine to SatoshiDICE can confirm.  Once my payment to SatoshiDICE is confirmed, then their payout back to me can confirm.
So if you cheated me and your payment to me was a double spend it will then never confirm (reaching 6 confirmations).  And in turn, my transaction to SatoshiDICE will never confirm.  And in turn, the SatoshiDICE payout transaction back to me will never confirm.
So it doesn't matter that I saw a payout transaction from SatoshiDICE right away, I can't spend it anywhere until it confirms.
Because even a transaction with one or two transactions can get orphaned due to a block reorg and a double spend attack, even if you see a confirmation that doesn't mean the transaction will clear.  That is why, unless there is recourse, only six transactions is the recommended number of confirmations to require.
Here's an example of the transactions for a losing 0.02041833 BTC bet:

http://satoshidice.com/lookup.php?tx=0419fdcbc82add4b46b6fe11e362561d0a3d18329770b36a637a2b60a881cf1e
http://blockchain.info/tx-index/16106266/0419fdcbc82add4b46b6fe11e362561d0a3d18329770b36a637a2b60a881cf1e
http://blockchain.info/tx-index/16106269/e69d7d733d4de5eee6fae0d402fe0db0fdd2544e9ece0f169922d143a8eaf850

You can see the flow visually here:

http://blockchain.info/tree/16104343  (click on the orange dot for the 0.01569037 BTC payment, which was one of the two inputs that paid for the bet.)

Wouldn't it be better to use a transaction of a winning bet as an example?

I just tried to find a nice standalone winning transaction that was as easy as the one I had chosen for this but the ones I kept finding were all serial bets (from bots) which introduce confusion.  So no, this shows everything that's needed and I don't have a winning bet to show. Sorry.

Can I send coins the same way as SathoshiDice does using the standard client?

If SatoshiDice paid out as quickly as they possibly could then what say an attacker did the following when sending bitcoins to make a bet:

If the bet wins, the attacker receives the winnings and does nothing further, or
If the bet loses, then the attacker tries to get a double spend of the bitcoins out to the majority of the network. If successful, they essentially get their SatoshiDice bet back.

Even fractions of a second would make a difference to the potential success of such an attack, so if SatoshiDice has, say, a 10 second delay before they payout, then the attack may become virtually impossible to achieve unless the attacker somehow cut SatoshiDice off from the majority of the network (very difficult to achieve).

They could still do it without cutting SatoshiDice off by using a Finney attack. But a Finney attack is expensive enough to launch (risk of losing a mined block) that I don't think there's anything to worry about.

You create a transaction with a Transaction Output ID and they pay you out creating a transaction using that Transaction Output ID as the Transaction Input ID. So if your payment doesn't go through, theirs doesn't either.


text:
Bitcoin client won't connect to the network
I installed Bitcoin QT yesterday and it was very slow to connect to the network. It didn't actually get there for over an hour.
Today I opened it again and it won't connect to the network at all. Any ideas why?
I'm running a Macbook Air with all software updated.

It would be useful if you could elaborate on exactly what Bitcoin QT seems to be doing - does it have any indication it's downloading the blockchain? From memory, as it does that it has a progress bar labelled with something like "Synchronizing..."

I have the same issue, but it isn't a matter of verifying the block chain. I had it fully verified and up and running, and then one day, 0 connections. I can't connect to the network at all, so for me, the problem isn't a matter of waiting for the block chain to update. I just can't find the network. I'm running Windows XP. Any suggestions?

You should get the best results if you port forward port 8333 to your laptop. It is also advised to leave your computer on for a long time the first time you connect to the network, as it has about 1GB of data to download and check. After that the operation should be easier.

Why does forwarding port 8333 provide best results? What if your tethering?

Bitcoin uses port 8333 for listening to other clients. Normally routers block such incoming transmissions, unless they are told to forward them to a specific computer. Basically, it allows your client to connect to more clients than without forwarding. Don't know much about tethering, but the situation might be similar.

You are probably still not synchronized to the network. When the client first starts up, it doesn't trust anything or anyone. So it has to validate every single thing the Bitcoin network has ever done in order to understand what coins are valid now. This can take 12 hours or so, depending on your connection speed and CPU speed.

You can download the blockchain and hence skip this long lasting initialization step.


text:
P2Pool - I get only rejects
I started mining with P2Pool / cgminer.
bitcoin-qt.exe is running. run_p2pool.exe is running. cgminer is running.
But all I get are rejects.
What might be the problem?

What do you mean rejects? Are you asking why haven't you found any coins / blocks? If so, please edit your question and I'll undo my downvote.

His question makes sense to anyone with a clue about p2pool, which you apparently don't. Don't abuse downvotes just because you don't understand.

@Luke-Jr - if you mention my name with a @, I'll be notified of your comments. Downvote undone.

This might mean your internet connection is too slow. With p2pool, you are basically competing against all the other miners for internet latency. If you have bandwidth-intensive software running (downloads, uploads) try stopping it.


text:
Why is Bitcoin so susceptible to credit card fraud?
I understand that you can't buy Bitcoins with a credit card due to massive fraud problems involving chargebacks. Why is Bitcoin more susceptible to this then the thousands of other businesses that take credit card payments for non-physical products (say, RPGNow, Bandcamp, iTunes and so on).

Bitcoin strongly enforces two concepts - high anonymity and no chargebacks.
Because of high anonymity, it is nearly impossible to be 100% certain who you are sending Bitcoins to. In the end, the Bitcoin address is just an arbitrary string of characters.
Because of no chargebacks, once you send someone Bitcoins, they are irreversibly theirs (assuming no double-spends and no 51% attack). You can't later recall the money you sent this way.
When someone would buy Bitcoins with a credit card, they could wait until the coins appear in their wallet, and then claim that their credit card was stolen used by someone else to purchase Bitcoins without their intent. They could get away with their chargeback claims, as it would be impossible for the seller to prove that they sold the coins legitimately to the person. Moreover, the seller wouldn't be able to get their Bitcons back due to "no chargebacks" rules.
What makes it different from services like iTunes and the like, is that the value of the Bitcoins is close to how much it costs the seller to aquire and sell them, whereas iTunes' costs are marginal. For example, buying a 1$ song from iTunes would mean that they have to probably spend less than a penny processing everything and providing you content (logging transaction, letting you download the song, etc), whereas if you send 1$ in Bitcoins, you are sending about 1$ worth of goods. When iTunes gets charged back, they lose a penny and can still sell the song any amount of times. When a Bitcoin seller gets charged back, they lose a dollar and can't sell the same coins again.
Bitcoins can't be copied and distributed to multiple people at marginal cost, that's what makes chargebacks so costly for any potential sellers.

Don't forget the pseudonymous nature of Bitcoin and how easy it makes money laundering. If I were a thief/hacker who had a big stack of skimmed CC numbers and there were an easy way to buy bitcoins with CC, they'd certainly be my first thought.

It's because bitcoin transactions are final, and exchange margins are low.
Businesses selling something for download can afford to be hit by fraud without incurring any real loss (other than potentially an opportunity cost, but even that is likely to be minimal as fraudsters would be unlikely to pay even if they couldn't defraud). ie margins are high.
However, when bitcoins are purchased with a credit card, it's more similar to a physical cash withdrawal from a credit card. Once physical cash or bitcoins are handed over the transaction is final. The party that hands over the cash or bitcoins has a lot to lose if the credit card transaction is reversed. They can't get their cash or bitcoins back. Fees charged for performing an exchange are low, so can't cover the cost of fraud.
Other types of businesses that sell physical goods online and ship them are probably careful to ensure they have validated identification or a physical address so that they have something to pursue in case of fraud. In some cases, the cost of the physical goods may be low enough that some risk of fraud is acceptable.

Bitcoins are liquid. Everybody wants bitcoins, and as many as they can get - if not for some immediate use, then to sell them for other currencies which are of immediate use. Even someone who doesn't need or believe in Bitcoin can still steal them. Thus a Bitcoin CC trader will attract all the fraudsters in the world. A site like RPGNow will attract only those fraudsters interested in RPGs, who are a minority among people interested in RPGs - and even they won't bother to steal a few $10's worth of games.
Bitcoin is traded on thin margins (which is also a result of being liquid). This has two implications. One, that every fraud incident is much more painful. Two, that legitimate customers will be looking for ways to buy bitcoins without paying the high CC fees - meaning that fraudsters are an even higher percentage of the traffic. Any attempt to increase fees to compensate for losses from fraud will just drive out the good customers, and keep the thieves who don't care how much fees they "pay".
Bitcoin payments are irreversible. With at least some of the other vendors, the vendor has some control over the platform with which his product is used. If he receives a chargeback he may have the power to revoke the usage of what he sold.

A pizza purchase is also final. It doesn't matter if you used your CC or paid in BTC it is still final and there is no way to get it back.


text:
For a non-technical person, how do I generate a ECDSA key pair easily?
I want to know because I would like to generate a vanity address at Vanity Pool.

Install OpenSSL. When the executable in your path, enter this command to generate a private key:
openssl ecparam -genkey -name secp256k1 -noout -out myprivatekey.pem

To create the corresponding public key, do this:
openssl ec -in myprivatekey.pem -pubout -out mypubkey.pem

This will give you both keys in PEM format. I'm not sure what format the web page wants, but it shouldn't be difficult to convert. You can use variants of the last command to output other formats. Remove -pubout if you want the private key, leave it if you want the public key. And you can use -outform DER to get DER format. You can use -text to get hexadecimal.
Do not give any form of your private key to anyone else.

To generate an Elliptic Curve private key in PEM format using the secp256k1 curve (which is the one used in Bitcoin):
openssl ecparam -genkey -name secp256k1 -out tmp/data.pem

To convert the private key from PEM (human-readable and extended) to a hex format:
openssl ec -in tmp/data.pem -outform DER|tail -c +8|head -c 32|xxd -p -c 32

To retrieve the public key in a hex format:
openssl ec -in tmp/data.pem -pubout -outform DER|tail -c 65|xxd -p -c 65

Explanation of the piped commands above
1) openssl ec -in tmp/data.pem -outform DER
    Converts the private key from PEM to DER (binary) format.
2) tail -c +8
    Skips the first (due to "+") 8 bytes (due to "c"), which should be the header of the DER format.
3) head -c 32
    Returns the first 32 bytes which is the private key length.
4) xxd -p -c 32
    Does a hex dump on the binary format of the key.

-p is for having the output in plain hexdump style
-c 32 is for having the 32 characters in one line, default is 16.

What are those xxd's about?

What's the background of getting the pub/priv Bitcoin key from the ecda keypair?

@DepressedDaniel I've edited the answer with more information about xxd.


text:
What does a double spend look like?
What does a double spend look like? Can anyone link to an example on blockchain.info?
Will invalid half of the double spend simply remain at 0-confirmations, or might it ever reach 1 or 2? Will the standard bitcoind client provide any type of flag for known invalid transactions?

You won't be able to see a double-spend in the block chain, because it is invalid. You will see one of the transactions included in the chain though. Blockchain.info has a page showing the most recent double-spends.
Double spend is just two (or more) transactions claiming the same input, so they will look like an ordinary pair of transaction. One of them will get included in a block, the other will eventually be forgotten by the network. A conflicting transaction to the one included in a valid block can never become a part of another block (at least until the first block will become invalidated by a 51% attack).
The standard client will not flag any invalid transactions, but it will reject any transaction that conflicts with a known transaction. It will, however, accept a transaction that is a part of a block, even if it conflicts with a 0-confirmation transaction that you know of.

So lets say my bitcoin client receives a 0-confirmation transaction. It then accepts ten blocks which have a conflicting transaction. Does the original 0-confirmation transaction remain listed in my client's transactions, or does it just disappear? What if the first transaction had 1 confirmation instead of 0?

The transaction will remain in your client, but other clients will start forgetting about it. It will have 0-confirmations. If the first transaction has 1 confirmation, it means it was a part of a block. Should a conflicting block be mined, it will be reverted to 0-confirmations.

When he says "an example on blockchain" perhaps he means on blockchain.info - I've seen it claim transactions were potential double spends before.

Ah yes sorry, I did mean blockchain.info. However, ThePiachu has explained it well without it.


text:
How does "Sign Message" work?
How does "Sign Message" option in the Bitcoin QT client work? I can't find any description or documentation of it.
Do I have to use this option to sign some message when I receive bitcoins? If so, how do I do that and what should I write?
This is how it looks (Sorry for danish client language):

Out of curiosity, what made you think you would need to sign a message to use bitcoin?  Are you by chance using the #bitcoin-otc marketplace where you use GPG?

I don't know what made me think that. I just received some coins that I (?) had to verify somehow to get them. So I just concluded I had to sign the transfer to verify them.

You don't have to manually verify Bitcoins you receive - the according transaction is verified automatically by your Bitcoin client. If you see a green checkmark left to the transaction you received (in the Transactions view) then it means that the rest of the Bitcoin network has confirmed the payment as well and you can safely consider the coins yours.
The "Sign Message" feature is an advanced functionality of the Bitcoin client which allows you to sign arbitrary messages to prove to somebody that you are (were) in control of the funds of some Bitcoin address. For a usage example see this answer. You normally don't need this feature for day-to-day use of Bitcoin.

This is incorrect. Sign Message does not prove you control funds. It proves you receive (title to) funds sent to the address.


text:
Callback from computation threads to root UTXO without trusted third party signature
No expert on Bitcoin. How I understand it, loops can be done by UTXO storing a hash of the code it requires to run the next iteration in, and then the next iteration creates a new UTXO and runs it there. And this works for indefinitely long loops as long as someone pays for each step. I assume it can be programmed so that anyone can sign each step (thus removing reliance on certain third parties).
What I'm interested in, is if there is a way to return the result to a "root" UTXO, in a way where it can be authorized that it came from a "thread" that originated from the root, without relying on a trusted third party to sign the callback. I cannot think of a way to do so. This then in analogy to what I described before, the thread itself being able to churn along without specific third parties signing things.

Hi Johan, I’m having a hard time trying to figure out what your question is. Are you asking how output scripts are evaluated?

@Murch Hi, guest account. I'm trying to understand a few claims I've heard. I was able to understand the "it actually can loop" claim, as that is based on technique described here, https://xiaohuiliu.medium.com/op-push-tx-3d3d279174c1. A related claim I've heard, is about callbacks and, as I describe in the question, multiple threads returning the "winning" value. Could not see exactly how that would be done, so asked here if there was expert who knew.

This blog post does not appear to be rooted in reality, there is no way to build a signature hash as described in the context of the input script validation.

Well, I'm no expert, but I have an OK understanding of basic computer engineering. And implementing elliptic curve signature in some arbitrary instruction set should be pretty easy. I've skimmed Bitcoin script (said to be Forth like, and have also looked briefly at Forth), and it seems to have a lot of the normal instructions. Bitwise and arithmetic. If you are convinced it is impossible (as in not reality) to run signature script in Bitcoin, do you know what the constraint is? Is it script size limit? Or is there an instruction you miss?

A lot of what is written in the question differs from my understanding of BTC. Which is as follows:
In general1 a transaction spends one or more "coins". These spent amounts are listed as "inputs" in a transaction and there is also a list of "outputs" which are new amounts typically being placed under the control of someone else.
Each of the inputs are just a reference to an output of a previous transaction in which the current sender received money. The reference is the Transaction-ID of the previous transaction plus the index number (0,1,...) of one of the outputs in that transaction.
Usually one of the outputs is a "change" output returning excess to the sender. Just as when you buy a $4 coffee using a $10 note, you get $6 back in change. You cant spend part of a $10 note, you have to hand over the whole note and expect to receive change back.
A transaction output is often abbreviated TXO. A TXO that has never been referenced by an input of a later confirmed transaction is an Unspent TXO or UTXO. This is what people mean by a coin.
A UTXO that is referenced by an input of a confirmed transaction is no longer unspent and so is now a TXO not a UTXO. The UTXO was destroyed by being used as an input. A TXO cannot be referred to by an input of another transaction. Only UTXOs can be used. A UTXO can only be used once.
The lists of inputs and outputs in a transaction are separate, there is no link between any individual input to an individual output. It is often not possible to say which inputs fed which outputs. It is often not possible to determine which output, if any, represents "change".
Each output has an associated locking script ("scriptPubKey"). Each input has an associated unlocking script ("ScriptSig"). If the unlocking script is executed it leaves a stack of data values. If the locking script from the referenced prior transaction's output is then executed, it typically uses the stack data and computes a true/false result. If true the transaction is valid, if false the transaction is invalid and discarded.  This way the unlocking script proved the spender has the right to spend, and thereby destroy, these particular UTXOs.
The scripting language used has no means to explicitly refer to other transactions.

From the above, it should be apparent there can be no threads or loops of the sort suggested by the question. At least not in the standard process as I understand it.

1. excluding coinbase

How I understand it, you can enforce that the "UTXO" can only be signed if you submit the right script to it, and a check can be done that compares what you submit, to a hash. With this, you can enforce specific computation in the next "UTXO", and can easily implement for example a loop. I've considered Ethereum the next step after Bitcoin since 2014, but, it is still interesting to understand why some argue Bitcoin having significant capacity for "smart contracts". And I agree it loops, although it is very cumbersome, & easier to use superior machine https://wiki.bitcoinsv.io/index.php/Script

@BipedalJoe: An unlocking script cannot affect or constrain any locking script in the same transaction or in any subsequent transaction.  No threads or loops can be formed that way.

Not that into the terminology. But, the locking script, as long as it can push a constant onto the stack (OP_PUSHDATA1), and, as long as it can generate a hash of the new script in the next "UTXO" (with OP_PUSH_TX?), and then push that to the stack as well, it can compare the values with OP_EQUALVERIFY. Is there any step there that you do not agree is possible? It's also mentioned on this Wiki, https://wiki.bitcoinsv.io/index.php/Script.

There is no OP_PUSH_TX. By the way, your link refers to BSV not BTC.

"OP_PUSH_TX" is that you include the transaction pre-image in sigScript. Not an OPCODE but a technique. scriptPubKey then contains private-public key pair, and script to generate signature. and script finishes with OP_CHECKSIG.. It's described well on that Wiki and there are a few other good articles about it if you use a search engine. I mean, Ethereum was successor to Bitcoin in 2014, I am just interested in understanding the perspective of those who still argue about Bitcoin for "smart contracts".

OK so that's a hack of OP_CHECKSIG in a UTXO locking script that can be used to constrain the outputs of the transaction that spends the UTXO. Since all the discussion is in the context of BSV I've no idea whether it can apply to BTC and I still don't know what you mean in the question by "return the result to a "root" UTXO" or why any of this necessarily involves third-party signatures. If I were you, I'd rewrite the question to explain in detail or move the question somewhere more technical. Sorry.

While Ethereum was clearly successor to Bitcoin back in 2014, I'm interested in understanding the perspective of those who for some reason think it is still impressive that Bitcoin can do script. Instead of just dismissing claims I've heard, I verify them. Such as the claim "it can loop", and well, technically, although very overcomplicated, it seems like it can. And I was interested in the claim that seemed to suggest you could return thread results somehow. I mention in the question that I'm no expert on the terminology, I think it can be understood as it is.


text:
Blockchain app says payment amount is over limit
I have the Blockchain app on my iPhone which I've been using regularly for years but which in fact I haven't used for the last 4 months. It currently has around $2000 worth of BTC in my private wallet. I have just gone to make a purchase for goods of around $50. I click on Send, select Private Key Wallet, enter the recipient's address but as I type $50 it tells me in red that I am trying to send an amount over my limit. Can anyone tell me what's happening with this?

Have you received a huge number of very small payments? Is it possible that most of your UTXOs have tiny amounts and spending them costs more than they are worth?

Make sure you are trying to send $50 and not 50 Bitcoin


text:
How to distinguish watch-only addresses from spendable addresses when deleting addresses
An answer to I have watched addresses in my wallet..how do i use them? says:

"If you do not have the private keys for those addresses, then they are not yours and you cannot do anything with them. Those addresses and their associated Bitcoin do not belong to you, so you cannot use them.
You can delete the watch only addresses if possible; you will not lose any money if you delete just those addresses because there is no money that belongs to you in the first place with those addresses. However be careful of deleting the wallet entirely, it could have addresses and private keys which do belong to you and those you do not want to delete."

Based on the answer above, how do you then establish which addresses belongs to me that I must not delete?

It depends on which wallet you are using, if you are using the Bitcoin core wallet for example, you can see the amounts separated, the watch-only amount will be one, and the spendable amount will be another one.
You can also use the command listunspent into your console to know which addresses contain the spendable amounts.

I have no idea how to do that

The ways will be different on each wallet, you should edit your question and mention which wallet you are using.


text:
My friend's address was spent right after I paid him. What happened?
Last time I sent some bitcoin to my friend and the fee that I used was a little low, so I tried to broadcast the tx with online broadcasters. After that the tx was spent from my friend's address (not from mine). It showed that my tx confirmed, but as it confirmed another tx was initiated from my friend's address without the permission of him and was spent to another address what kind of attack is it? I think it's not called double spend since it's not spent from my address, it reached his address first but was then spent from him. Can someone explain??

At risk of stating the obvious, your friend should not trust that wallet anymore and switch away from it.

If I read it correctly, your friend had an address, to which you paid. Then someone took it from their wallet?
It might be because your friend's device is hacked or he doesn't use a trustworthy wallet.
Or it was him who spent the coins. It's also possible that they are lying to you so that you pay them again.
Double spend attacks involve the same person spending to two different addresses. Since your friend is not the voluntary author of both transactions, this is not double spend.
I can't comment further without more info.

I have send the payment to him at 2:00 and my tx was showing me unconfirmed until 3:10 but after it has confirmed my tx shows that it has been confirmed at 2:35 they spend it from his wallet at 2:35 and confirmed their tx at 3:10 which means my tx was showing unconfirmed until they spend from his wallet and confirm their tx i think this will be helpfull to figuer it out