text:
Question about Bitcoin in cash app
Ok. So there's this man who said: "I will be making a mobile deposit of $5,150 from my crypto wallet  into your  cashapp and once the money is available you gonna keep 40% ($2,150) and send me  back 60%($3,000)."
Then he said: "Reason why I use people’s account to deposit my commissions, is because of banking limit & policies... and my money is currently in crypto currency, which is fluctuating, if I leave my profits there for too long I’d loose a lot of funds, which is why I’m using serious minded person’s account, and at the end I’d pay them 40%."
So the question I want to ask is: what are the risks if I do this? could there be something wrong that could get me in trouble?

It is certainly a scam run by criminals.
At best you are knowingly engaging in money laundering stolen money on behalf of criminals - this makes you complicit in their crimes and you are the first person the police will find.
At worst, it is the initial stages where the criminals test your gullibility and either trick you out of large amounts of your own money, or get you involved in assisting them and then blackmail you.

Thank you. I decided to not go through with it.

Looks like a scam.
Things apparently play good to you, but then they convince you they have a sudden problem and they want you to advance the money. You now trust them, advance the money, but they disappear.

is there anyway I can safely find out for sure about whether or not it's a scam? I mean, if he's the one who's depositing money into my account through cash app,  and it's being done without giving him my personal information, then how does one get scammed? thanks 4 your response

They'd go a couple full rounds without issues first, then they'd propose a bigger round, but tell you something like the device doesn't allow them an atomic pay, so you trust them now, advance the money, they disappear.

if I decide to just play ball, and accept the deposit into my account, what's the worse that can happen to me? How do I proceed from there? Wouldn't he be the one out of money if I decide to not give him anything he asked for after depositing it into my cash app account? because I have no intent on giving him any of my own money 'cause he told me that there's no catch"

Once you decide to con the con people, you know both parties are mischievous, which is a factor to your favor, unless the con people know you are going to be malicious. Each party can make higher and higher bets and the "game" ends when one of the parties execute the con.

Be careful!
they may disappear after u gave them money. not only persons, but there are also organizations who persuade you and after some time you can't reach them. their websites and emails and everything connected to them don't work.

After I give what money? The money he's giving me? Because that's the only money I'm giving. He told me "there's no catch." So if I decide to go through with it, what's the worse that can happen? thanks for your response

the crypto one. they are saying like as you will have the money profited. but there are bunches who don't give it


text:
Is my k nonce being re-used here?
I'm using bitcoin core 28.0 on Debian Bookworm. I enter the following into bash:
./bitcoin-cli signmessage "p2pkh-address-here" "abc123"
... and I get the signature output in the shell as expected. But if I then run exactly the same line again in bash, the newly outputted second signature matches the first signature. I thought this was not supposed to happen, and that core uses a different k for every signature, meaning every signature should be different even in cases where the privkey-and-message are identical.
Is my k being re-used, or am I missing something?

Bitcoin Core uses RFC 6979 deterministic nonces when generating the nonce for an ECDSA signature. The nonce is essentially generated by hashing the private key with the message, so it will always generate the same nonce given the same key and message. This is not considered nonce reuse as the nonce is not reused across different keys or messages.

source: Stack Exchange

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

sort: votes


text:
How do I use descriptors to put an ancient priv-key into a newly created wallet.dat file?
Running bitcoin core 26.0 on debian 12. I want to put an ancient priv-key into a newly created wallet.dat file. First, I'll do a test run:
$ bitcoin-cli createwallet test
$ bitcoin-cli loadwallet /home/user/.bitcoin/wallets/test/

This wallet.dat exists only for testing purposes and will be deleted shortly. Before it's deleted though, and strictly for testing only, I want to put the priv-key revealed on https://en.bitcoin.it/wiki/Private_key:
priv-key= 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
corresponding address= 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj
... into this test-only wallet.dat file. This particular priv-key is of course here only as a place-holder; nobody in their right mind would want this priv-key anywhere near a live wallet.dat file.
$ bitcoin-cli getdescriptorinfo 'combo(5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF)'
{
  "descriptor": "combo(04588d202afcc1ee4ab5254c7847ec25b9a135bbda0f2bc69ee1a714749fd77dc9f88ff2a00d7e752d44cbe16e1ebcf0890b76ec7c78886109dee76ccfc8445424)#nf3atn7u",
  "checksum": "qlt7uqzu",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": true
}

$ bitcoin-cli importdescriptors '[{"desc":"combo(5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF)#qlt7uqzu","timestamp":"now"}]'
[
  {
    "success": true
  }
]

... so that priv-key should be in the wallet.dat now, so I do a quick test:
$ bitcoin-cli getaddressinfo 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj
{
  "address": "1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj",
  "scriptPubKey": "76a9147ac00f979ff0df2fdcb65761dc8f9ef8b37142db88ac",
  "ismine": true,
  "solvable": true,
  "desc": "pkh([7ac00f97]04588d202afcc1ee4ab5254c7847ec25b9a135bbda0f2bc69ee1a714749fd77dc9f88ff2a00d7e752d44cbe16e1ebcf0890b76ec7c78886109dee76ccfc8445424)#yyv2g3h5",
  "parent_desc": "combo(04588d202afcc1ee4ab5254c7847ec25b9a135bbda0f2bc69ee1a714749fd77dc9f88ff2a00d7e752d44cbe16e1ebcf0890b76ec7c78886109dee76ccfc8445424)#nf3atn7u",
  "iswatchonly": false,
  "isscript": false,
  "iswitness": false,
  "pubkey": "04588d202afcc1ee4ab5254c7847ec25b9a135bbda0f2bc69ee1a714749fd77dc9f88ff2a00d7e752d44cbe16e1ebcf0890b76ec7c78886109dee76ccfc8445424",
  "iscompressed": false,
  "ischange": false,
  "timestamp": 1231006505,
  "hdkeypath": "m",
  "hdseedid": "0000000000000000000000000000000000000000",
  "hdmasterfingerprint": "7ac00f97",
  "labels": [
    ""
  ]
}

... so that looks good. Next thing is to rescan the blockchain, wait a few hours, and the btc controlled by that priv-key (likely an amount equal to zero in this case, obviously!) should be available to be spent by the bitcoin core client after the rescan is done.
Did I miss anything out? If I use this method to put a priv-key that controls a non-zero btc value into a live wallet.dat file, will I be able to use that wallet.dat file in bitcoin core 26.0 to spend the btc?

Yes, you will be able to spend the coins found through a rescan when importing a private key by the means of a descriptor in a Bitcoin Core descriptor wallet.

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


text:
Gradual deprecation of importprivkey call?
I'm running bitcoin core 26.0 on debian 12.
$ /usr/local/bin/bitcoin-26.0/bin/bitcoin-cli importprivkey "5-rest-of-priv-key"
error code: -4
error message:
Only legacy wallets are supported by this command

Okay so I can have bitcoin core 26.0 run with an old wallet.dat file, and the priv-key import will then work fine, so that's nice. But, this works only with old wallet.dat files.
Are there any plans, or is there a widely shared disposition among developers, to stop future releases of bitcoin core from being able to import priv-keys to old wallet.dat files -- as is already the case with newly created wallet.dat files -- and thus to deprecate the "importprivkey" call completely?

Yes, importprivkey will stop being supported entirely whenever support for legacy wallets is removed, probably in version 28.0. Old wallets will of course be covertible to the new format.
However, it is perfectly possible to import things into new wallets that involve private keys, using the importdescriptors RPC, which has different arguments and different semantics, but almost certainly covers your use case. See the documentation for importprivkey, which mentions:

Note: This command is only compatible with legacy wallets. Use "importdescriptors" with "combo(X)" for descriptor wallets.

The reason for not supporting importprivkey in legacy wallets is that its behavior is hard to reason about, and intentionally not supported anymore for descriptor wallets:

importprivkey is effectively a "here is a key, figure out what I want to do with it". It will cause certain (but not all) single-key addresses related to that key to become part of the wallet, but it will also do things like making a multisig script the wallet knew about go from watch-only to fully supported if it now has all its keys.
With importdescriptor (and the philosophy behind descriptor wallets in general), you have to be explicit about what/how you want to use the key.


text:
How to sell or convert recently delisted coins on Binance?
Binance recently delisted SERUM. I still have some left on my account and I want to convert it into another currency. Is it possible to do this and if so, how? I read the following statement: "Delisted tokens may be converted into stablecoins on behalf of users, after 2023-11-22 03:00 (UTC). The proceeds will be credited to users’ Binance account.". Source: Binance announcement of delisting several coins
Does this mean that it is impossible to exchange/sell/convert SERUM until the given date?

Yes, based on the information provided in the Binance announcement, it does mean that you won't be able to exchange, sell, or convert your SERUM tokens on Binance until after the given date


text:
Code for computing SigHash for various input types
I am looking for code examples (in rust-bitcoin, but even in Python) of how to calculate sighash for various input types. Specifically, I need to calculate the sighashes for M of N multisig unlocking script inputs for these transaction types: P2MS, P2SH, P2WSH  and P2TR (to determine which M of N keys correspond to the M input signatures).
For example for a P2SH case, I am looking at output 0 in this tx.
In the spending transaction, the input #3 contains a redeem 2 of 3 mutisig script with 3 compressed 33 byte PubKeys
OP_PUSHNUM_2 OP_PUSHBYTES_33 02261f84d51bb64371cb5e9eec3bbc0c0c7320eb7fa9c5076a394a48a9cd74bfd3 OP_PUSHBYTES_33 023e66621cf94ac25d8bb687abef86d01847805d6e9bff8c3999f18f478cde5ab6 OP_PUSHBYTES_33 02d844059fae247b8e1325f56519d1eb7d4b632ec77b9f71f03102167f3c7fa591 OP_PUSHNUM_3 OP_CHECKMULTISIG
and two signatures in the ScriptSig (OP_PUSHBYTES_71 and OP_PUSHBYTES_72). I concretely want to know which two of the three PubKeys above correspond to these two signatures.
For that, I need to double-loop over the two keys and the three signatures and pass these pairs along with the scriphash into verify_ecdsa(&script_hash, &signature, &pubkey) from secp256k1, and I would like to understand in detail how to compute the sighashes. I am also not clear if these multisig inputs can have any of these three sighash flags SIGHASH_ALL, SIGHASH_SINGLE and SIGHASH_NONE, or only the first one is ever used with multisig?
PS. In the Andrew Poelstra's answer, there's an example sighash computation for P2WPKH. Although I do not need the P2(W)PKH cases because I am not trying to verify the blocks, the example involves manually converting the P2WPKH output into a P2PKH output by wrapping the pkh into OP_DUP OP_HASH160 <pkh-from-P2WPKH-out> OP_EQUALVERIFY OP_CHECKSIG and passing the result into sighash.segwit_encode_signing_data_to(). It would be good to see explicit multisig examples.

I would suggest rewriting this question to emphasize that you actually want to compute a sighash, which is very different and more complicated than figuring out the CMS pubkey mapping. To answer the easy parts of your question: no, Bitcoin Core does not expose sighashes in any RPC, and its internal architecture would make this a little tricy. rust-bitcoin exposes the https://docs.rs/bitcoin/latest/bitcoin/util/sighash/struct.SighashCache.html type which will assist in computing sighashes, but we have not written any worked examples.

I have opened https://github.com/rust-bitcoin/rust-bitcoin/issues/1698 to track the lack of documentation in rust-bitcoin.

Andrew, I have rewritten the question. When you synthesize the P2PKH output locking script 76a914f5693fbaf062221baf891d813d5856e4f8ab54eb88ac from P2WPKH output in your answer, you drop the first 0x19 byte from
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki : "The item 5 :
For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac"  Why is that 0x19 there in the BIP 143?

The 0x19 is a length prefix. It is automatically incuded by rust-bitcoin.

I have the following code laying around for the transaction 663becacc6368150a46725e404ccdfa34d1fffbececa784c31f0a7849b4dad08, which I picked off my mempool the other day, whose hex is:
020000000001015ce1d4ffc716022f83cc0d557e6dad0500eeff9e9623bde014bdc09c5b672d750000000000fdffffff025fb7460b000000001600142cf4c1dc0352e0658971ca62a7457a1cd8c3389c4ce3a2000000000016001433f57fe374c6ceab61c8639128c038ac2a8c8db60247304402203cb50efb5c4a9aa7fd369ab6f4b226db99f44f9c610b5b50bc42f343a6aa401302201af791542eee6c1b11705e8895cc5adc36458910dc91aadcafb76a6478a29b9f01210242e811e66fd17e9a6e4ef772766c668d6e0595ca1d7f0583148bc460b575fbfdf0df0b00
use bitcoin::consensus::deserialize;
use bitcoin::hashes::{hex, sha256d, Hash};
use bitcoin::util::sighash;
use std::env;
use std::str::FromStr;

fn main() {
    let rawtx = env::args().skip(1).next().unwrap();

    let bytes: Vec<u8> = hex::FromHex::from_hex(&rawtx)
        .expect("hex decoding");
    let tx: bitcoin::Transaction = deserialize(&bytes)
        .expect("tx deserialization");

    let pk = bitcoin::secp256k1::PublicKey::from_str(
        "0242e811e66fd17e9a6e4ef772766c668d6e0595ca1d7f0583148bc460b575fbfd",
    ).unwrap();

    let mut sighash = sighash::SighashCache::new(&tx);
    let mut out_bytes = vec![];
    sighash.segwit_encode_signing_data_to(
        &mut out_bytes,
        0,
        &bitcoin::Script::from_str("76a914f5693fbaf062221baf891d813d5856e4f8ab54eb88ac").unwrap(),
        200000000,
        bitcoin::EcdsaSighashType::All,
    ).expect("computing sighash");

    println!("{}", hex::ToHex::to_hex(&out_bytes[..]));

    let sig = bitcoin::secp256k1::ecdsa::Signature::from_str(
        "304402203cb50efb5c4a9aa7fd369ab6f4b226db99f44f9c610b5b50bc42f343a6aa401302201af791542eee6c1b11705e8895cc5adc36458910dc91aadcafb76a6478a29b9f",
    ).unwrap();
    let secp = bitcoin::secp256k1::Secp256k1::new();

    let hash = sha256d::Hash::hash(&out_bytes);
    let msg = bitcoin::secp256k1::Message::from_slice(&hash[..]).unwrap();
    secp.verify_ecdsa(
        &msg,
        &sig,
        &pk,
    ).unwrap();
}

This works only for this specific p2wpkh transaction, but it may help you get started. The weird thing is that the script_code is created by synthethizing a p2pkh output from the p2wpkh output. For p2wsh or p2sh (as any CHECKMULTISIG) script will be, this is simpler: you can just use the redeem/witness script here.

I created a GitHub repo with the answer examples.


text:
Would sidechains help Bitcoin scale?
Are sidechains intended to help Bitcoin scale? Do they reduce load on Bitcoin's main chain?
If not, why not?

Scale in what way? What kind of "load" are you referring to?

@GregHewgill Scale in the sense of having more transactions per second.

No. They can increase scale, but that is not what they are good at or intended for.
Before giving a longer answer, let me first talk briefly about the difference between scale and scalability.
Increasing scale means increasing the throughput or number of participants to the system. It's very easy to achieve (decreasing the time between blocks, or increasing the size of blocks), but it would come at a cost of higher centralization pressure for mining and increased validation cost to the system. Whether these increased costs are acceptable is controversial, but there are certainly costs involved.
Increasing scalability means changing the system in a way such that increased scale comes with less increased costs. Known mechanisms for better scalability include better peer to peer relay protocols, faster digital signature systems, software improvements, technology on top such as payment channels or lightning to reduce on-chain transaction need, ...
Sidechains don't improve scalability. If we want the same security level with sidechains, the same amount of people and miners need to be validating them. That is at least as costly as just increasing the block size of Bitcoin itself, and sidechains come with extra compromises on top of that.
So, sidechains may increase scale, but are not better at it than larger blocks would be.
What sidechains do bring is the ability to experiment. To be able to build networks that run on different - and possibly better-scaling - technology, but without needing to first beat bitcoin's (the currency's) network effect.
Sidechains are intended to improve scalability, but only indirectly: by enabling innovation. Not because they can just offload things from Bitcoin.

Sidechains don't increase scale without changing the security.  However they could allow people making lower security (e.g. lower value) transactions to opt-in to use a higher scale, lower security chain.  The security would be lower for two reasons: because the security model on a side-chain is slightly different than main chain, and because if the sidechain has bigger blocks, we would expect less people to validate it, so it would be more likely to suffer policy attacks.
Given that about 45% of Bitcoin's 30-40% full blocks are values under $1 that could perhaps be of interest to many types of application and allow practical scale and be a reasonable tradeoff for many people.
For example I might say: put $100 in a sidechain with bigger blocks, and top it up when it runs out, with the intent to use that as spending money for small value items: tips, cup of coffee, VPS service, etc.  I would be happy doing that because basically I could afford to lose $100.  Also spending money is not at significant risk of political attack, and there is less risk of political attack because there is a recourse: if your spending money wallet coins were politically attacked, you could move them to the main chain.  The attackers would know this and therefore also be less likely to try the attack.
So while it's not a silver bullet and doesn't reduce the amount of bandwidth, it is a potential option people may start to try deploying as federated or full p2p sidechains technically come online.  (There is a testnet federated sidechain that has been online since Jun 2015.)
One argument can be that if there are a lot of fees on the sidechain then someone who has bandwidth only to verify the main chain, would receive less profit, and maybe become unprofitable and so have to stop vs a bigger miner with more bandwidth.  However it is possible to pool mine the sidechain and self-validate the mainchain, and so collect the sidechain fee reward via a pool and be equally profitable though not helping with the level of decentralisation security of the sidechain.
This kind of higher scale sidechain is strictly optin for security, it is the recipient that choses which chain their receiving address is on.  It is also backwards compatible (though the details are a bit more complex) so someone on the mainchain who receives bitcoin from someone on the sidechain, they are at no elevated risk of losing those funds if they chose to stay on the mainchain for decentralisation security reasons.

What do you mean by policy attack?

Yes. Check IOHK video about sidechains.
Sidechains creates the space for sharding..sidechains reduce the work from being done on the main chain.

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


text:
Import WIF key for P2PKH into Bitcoin Core descriptor wallet
Can someone create a step by step, how to import a legacy P2PKH WIF key on testnet (let's say cSTHGbKgKLCGDRRn5AgtS7L4KHkqmdBau4nsEw8ckAzXV784bgeR) into Bitcoin Core 25.1 descriptor wallet using the Debug Console?

Does any of those answer your question? https://bitcoin.stackexchange.com/a/108392/101498, https://bitcoin.stackexchange.com/a/108392/101498, https://bitcoin.stackexchange.com/a/118130/101498.

thanks.. but most solutions are so complicated.. I was hoping that there was a simple 2-3 step process

Added an answer, you've got a step by step guide in the last link. You simply need to use pkh() instead of pk().

ah.. so let me make the step by step

getdescriptorinfo "pkh(cSTHGbKgKLCGDRRn5AgtS7L4KHkqmdBau4nsEw8ckAzXV784bgeR)"

result:
{
  "descriptor": "pkh(030264ff3c978d2845efd78ff3092650ff80e49a95bebe2fe2f0e9328f72e31799)#kfn7yc4w",
  "checksum": "h9ya7gkd",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": true
}

important info is "checksum": "h9ya7gkd"

importdescriptors '[{"desc":"pkh(cSTHGbKgKLCGDRRn5AgtS7L4KHkqmdBau4nsEw8ckAzXV784bgeR)#h9ya7gkd","timestamp":"now"}]'

At this point I can see my address under receiving addresses

getaddressinfo mv9u2iuhXL86Y4JKHazEYvAzAXvbt5bwwo

result
{
  "address": "mv9u2iuhXL86Y4JKHazEYvAzAXvbt5bwwo",
  "scriptPubKey": "76a914a08e6d3854c35052dd64757f423c1bf91326c5b888ac",
  "ismine": true,
  "solvable": true,
  "desc": "pkh([a08e6d38]030264ff3c978d2845efd78ff3092650ff80e49a95bebe2fe2f0e9328f72e31799)#ywkyykha",
  "parent_desc": "pkh(030264ff3c978d2845efd78ff3092650ff80e49a95bebe2fe2f0e9328f72e31799)#kfn7yc4w",
  "iswatchonly": false,
  "isscript": false,
  "iswitness": false,
  "pubkey": "030264ff3c978d2845efd78ff3092650ff80e49a95bebe2fe2f0e9328f72e31799",
  "iscompressed": true,
  "ischange": false,
  "timestamp": 1706106032,
  "hdkeypath": "m",
  "hdseedid": "0000000000000000000000000000000000000000",
  "hdmasterfingerprint": "a08e6d38",
  "labels": [
    ""
  ]
}

This answer contains a step-by-step guide to import a testnet WIF private key under a pk() (for P2PK) descriptor on a Bitcoin Core wallet using the command line. You can use the same commands in a Bitcoin Core GUI Debug Console. For P2PKH, you simply need to substitute pk() for pkh().

ah.. so let me make the step by step

@MichelvanKessel: Self-answers are encouraged, so please post it as an answer here!


text:
How to do RBF using the Ledger Nano / Ledger Live
Would anyone here please be able to tell me how to do RBF using the ledger nano- I can see the transaction has been stuck for about 12 hours now. The TX is 4acdaa2926d62893b15b186974bfff6cb2d13aa5c04c1121f58d9a2f607a4ee5 and it still has not been accepted.
I have been looking at accelerating it and also RBF, I have been unable to find anything for RBF in line with Ledger Live. I would really appreciate any help and if you could look at the transaction ID for me. I do not understand it unfortunately.
Many Thanks

Blockchair.com shows that transaction as having 32 confirmations -- so there is no longer any need to do anything.

I have been unable to find anything for RBF in line with Ledger Live.

So far as I can tell, the "Ledger Live" app does not support RBF.
You can use Electrum with a Ledger Nano. Electrum supports RBF.


text:
Winner of block reward command
What is the bitcoin-cli command to view the winner of each block reward in bitcoin mining? How do you find out the winning mining pool of each block reward?

Short answer:
There is no command in Bitcoin Core to show who mined a specific block, and there likely never will be. You can use it to get the block's coinbase transaction and see if it contains the miner's identification (however depending on the method the miner can more or less easily pretend to be another miner).
Long answer:
Miners (and especially mining pools) often identify themselves in the blocks they mine using the coinbase transaction (the first transaction of a block which contains the mining reward). Two fields of the transaction are commonly used:

Many miners and pools modify the coinbase script (usually called input script or scriptSig in non-coinbase transactions) to include a string tag identifying the pool. For example, the coinbase scripts of today's largest pools include the tags "Foundry USA Pool", "Mined by AntPool", "/ViaBTC/", and "F2Pool", respectively. However, nothing stops other miners from including any of these tags as well. I'm not aware of this ever happening nor of any reason why it ever would, but it's something to keep in mind.
In case a miner doesn't identify themselves in the coinbase script or they switch to a new coinbase tag that you don't yet recognize, you can still try to identify them if they use a static address for paying out the mining reward. Using a new address for every transaction is essential for privacy, but mining pools usually don't care about that (to the contrary, they often desire to be transparent) so they don't bother. Pretending to be another miner using this method would require forfeiting the mining reward in favor of the victim miner, so there's even less reason for anyone to do this, however it's still possible.

Because miners and pools come and go, and existing ones often change their coinbase tags and payout addresses, someone needs to constantly maintain a list of known miner identifications. One such list is maintained by 0xB10C and is used by many blockchain explorers that show who mined which block. However, online services like these can update their lists in a matter of hours or days, while Bitcoin Core has a release cycle of 6 months, so even the latest version might be unable to identify multiple large pools. That's one of the reasons this feature will probably never make its way to Bitcoin Core, another one being that it's just not really in the project's scope (which is a Bitcoin node and wallet, not an all-purpose blockchain explorer).


text:
When should Bitcoin Core functional tests be run?
When should functional tests be run? Or is it always a good time to run functional tests?

Does this answer your question? Should I run the tests every time I review an open Bitcoin Core PR?

Not really. I would presume that the answer is to run test_runner.py as often as possible; the more the better? And if a test fails, what should I do?

It depends what you're doing. If you aren't changing the code then running the tests repeatedly makes no sense. If you are opening a pull request with a code change in it then you can run the tests on your branch and check they pass before opening the pull request. If you are reviewing someone else's pull request branch then that link answers your question.

The functional tests are part of the test framework used for developing Bitcoin Core.
Developers will regularly run the functional tests, and other tests, when they are working on proposed changes to the code, to validate those changes. Which tests are helpful for that is up to the developer's judgment. Often significant changes will require changes or additions to the test framework too.
When a change is actually proposed, all tests (on a variety of platforms) are automatically performed by the CI (Continuous Intgration) infrastructure. Maintainers will not merge changes that do not pass all tests.


text:
C before Amount
I see CAmount mentioned here and elsewhere in the Bitcoin core codebase. What does the 'C' before Amount denote? Is it Consensus?


text:
Not sure how I see my bitcoin balance
Ok so in 2018 I purchased $1500 worth of bitcoin through Coinspot and transferred most of it - well the keys to it of course - onto a Ledger. Since then Bitcoin has moved up a decent amount so I know the $1200 still sitting on Coinspot reflects the Bitcoin I left there.
I haven't touched or moved anything since then but want to see what the value is of my bitcoin that I moved to offline.
I know the ledger doesn't actually contains coins and all that stuff, I'd just like a simple method to see how much bitcoin I own right now.
I'm probably missing something very obvious but would appreciate some help.

Do you remember what proportion of coins was sent to the ledger versus stored on Coinspot? If so, you can work it out based on the increase in price of the remaining amount. You could perhaps find an old email or something with the details of the purchase, or look on Coinspot at your transaction history, to see how much you bought and moved to the ledger.
Otherwise, you could plug your ledger in and check the balance through its software.

Thanks appreciate the answer. I suspect it was like 80% but I just want to some peace of mind. OK so once I get the ledger "open" (forgot my pin but have my 24 words phrase) then it will be able to display the value of the coins sent to the ledger? Thats awesome thanks for your help!

You'll have to plug it into a computer to allow it to access the internet I think.


text:
How to spend an anyone-can-spend input
I'm trying to teach myself bitcoin script, and so far I'm failing with a seemingly trivial example.
I'm using the Bitcoin Test Framework, and this is what I'm doing (simplified):
# p2sh address for OP_TRUE, according to  https://bitcoin-script-debugger.visvirial.com/
address = '2ND8PB9RrfCaAcjfjP1Y6nAgFd9zWHYX4DN'
scriptPubKey = hex_str_to_bytes(self.nodes[0].validateaddress(address)['scriptPubKey'])

blocks = self.nodes[0].generatetoaddress(101, address)
tx0 = self.nodes[0].getblock(blockhash=blocks[0], verbosity=2)['tx'][0]

send_value = tx0['vout'][0]['value'] - Decimal("0.0001")

tx = CTransaction()
tx.vin = [CTxIn(COutPoint(int(tx0['txid'], 16),0), CScript([OP_TRUE]))]
tx.vout = [CTxOut(int(send_value * COIN), scriptPubKey)]
tx.calc_sha256()
tx_hex = tx.serialize().hex()

txid = self.nodes[0].sendrawtransaction(tx_hex)

This fails with the following error message:
test_framework.authproxy.JSONRPCException: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element) (-26)

My understanding is that by providing OP_TRUE as a scriptSig, it should match the hash160 encoded in the address/input, and then the script itself should be executed and put 1 on the stack, which should successfuly unlock the input.
What is wrong in my reasoning?

You are setting the scriptSig directly to the script that is being hashed, but that is incorrect. The way that P2SH works is that the script in the scriptPubKey will copy the top stack item and check its hash. Since the script is OP_TRUE, you need to push the bytes for OP_TRUE to the stack, not execute OP_TRUE as your code currently does.
Instead of doing
CScript([OP_TRUE])

you should do
CScript([CScript([OP_TRUE])])

This does what I described. First you make a script which corresponds to the address you made. This script is encoded as bytes, and included as just a byte array in another script that will be the scriptSig.


text:
Is Bitcoin core V.0.9 not updated on PPA ppa:bitcoin/bitcoin?
Version 0.9 of Bitcoin-Qt just came out. When will ppa:bitcoin/bitcoin be updated? In the meanwhile, any steps showing how to upgrade are welcome!

The PPA is on 0.8.6, which is very recent (just missing 0.9, but I'm gonna hopefully upload that today). What you're referring to is the Ubuntu package distribution, which is very, very, very out of date (to the point of it being largely non-functional).

Unfortunately, 0.9 is having build trouble for Saucy and Trusty https://launchpad.net/~bitcoin/+archive/bitcoin/+packages

I'm confused. The OP has linked to the PPA (and has not edited the post as far as I can see), but you seem to indicate that the OP is referring to something other than the PPA.

0.9.0 was posted earlier today.

I second this. The PPA is very outdated (I think using < 0.4). The only way I could think of manually upgrading would be to pull the latest Git Tag for 0.9.0 and re-make (compile) from source.

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


text:
Compiling bitcoin error : A compiler with support for C++17 language features is required
I am reading the "Mastering bitcoin: Programming the Open Blockchain" book by Andreas Antonopolous. In the chapter about compiling bitcoin, the instructions were to execute first
./autogen.sh

and the output was
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
glibtoolize: copying file 'build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build-aux/m4'.
glibtoolize: copying file 'build-aux/m4/libtool.m4'
glibtoolize: copying file 'build-aux/m4/ltoptions.m4'
glibtoolize: copying file 'build-aux/m4/ltsugar.m4'
glibtoolize: copying file 'build-aux/m4/ltversion.m4'
glibtoolize: copying file 'build-aux/m4/lt~obsolete.m4'
configure.ac:45: installing 'build-aux/compile'
configure.ac:28: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
glibtoolize: copying file 'build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build-aux/m4'.
glibtoolize: copying file 'build-aux/m4/libtool.m4'
glibtoolize: copying file 'build-aux/m4/ltoptions.m4'
glibtoolize: copying file 'build-aux/m4/ltsugar.m4'
glibtoolize: copying file 'build-aux/m4/ltversion.m4'
glibtoolize: copying file 'build-aux/m4/lt~obsolete.m4'
configure.ac:36: warning: The macro `AC_PROG_CC_C89' is obsolete.
configure.ac:36: You should run autoupdate.
./lib/autoconf/c.m4:1652: AC_PROG_CC_C89 is expanded from...
configure.ac:36: the top level
configure.ac:15: installing 'build-aux/compile'
configure.ac:9: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
glibtoolize: copying file 'build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build-aux/m4'.
glibtoolize: copying file 'build-aux/m4/libtool.m4'
glibtoolize: copying file 'build-aux/m4/ltoptions.m4'
glibtoolize: copying file 'build-aux/m4/ltsugar.m4'
glibtoolize: copying file 'build-aux/m4/ltversion.m4'
glibtoolize: copying file 'build-aux/m4/lt~obsolete.m4'
configure.ac:812: warning: $as_echo is obsolete; use AS_ECHO(["message"]) instead
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
build-aux/m4/ax_pthread.m4:89: AX_PTHREAD is expanded from...
configure.ac:812: the top level
configure.ac:94: installing 'build-aux/compile'
configure.ac:48: installing 'build-aux/missing'
src/Makefile.am: installing 'build-aux/depcomp'

While the output aligned with expected output from the instructions, the next command
./configure

Exits with an error that C++17 isn't available from the compilers on the machine. The output was
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking build system type... x86_64-apple-darwin19.6.0
checking host system type... x86_64-apple-darwin19.6.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... ./build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++... gcc3
checking whether g++ supports C++17 features with -std=c++17... no
checking whether g++ supports C++17 features with +std=c++17... no
checking whether g++ supports C++17 features with -h std=c++17... no
checking whether g++ supports C++17 features with -std=c++1z... no
checking whether g++ supports C++17 features with +std=c++1z... no
checking whether g++ supports C++17 features with -h std=c++1z... no
configure: error: *** A compiler with support for C++17 language features is required.

and on running
g++ --version

gives
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-
dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

and g++-11 --version
gives
g++-11 (Homebrew GCC 11.2.0) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now both GNU GCC and also Clang compiler versions I have support both C++ 17 standard and the associated flags, why does this error happen?
I made sure my path is set correctly and also other cpp programs execute correctly. I am unable to find the mistake here. Can anyone please guide me?
This is my first question, first one even on stack exchange as a whole. Please excuse any obvious ideas I missed.
I am using the source from repo and version v22.0. Thanks!

@Prayank tried that, still the same issue


text:
P2TR: Is pub key hashed in address?
Are the new Taproot addresses (SegWit v1) also a hash of the (potentially tweaked) public key, or is the public key directly encoded into the address, without hashing it?

Public keys are not hashed in Taproot (SegWit v1). The Taproot (Merkle) tree in the script path uses hashes but the Merkle root of this tree tweaks the unhashed public key (internal key) and the resulting tweaked public key is not hashed either. For more details on why see the reference 2 in BIP 341.

Does that mean that there are roughly 2^256 possible Taproot addresses (eg pubkeys)?

Right, not quite 2^256 possible points on secp256k1 curve but pretty close https://bitcoin.stackexchange.com/questions/114135/how-does-ecdsa-work-when-generating-the-public-key/


text:
Error 400 when pushing tx hex to mempool.space's API
I am using the code syntax provided by mempool.space for a POST transaction request from their website here:
https://mempool.space/api
const mempoolJS = require("@mempool/mempool.js")

const init = async () => {

  const { bitcoin: { transactions } } = mempoolJS({
    hostname: 'mempool.space'
  });

  const txHex = '0200000001fd5b5fcd1cb066c27cfc9fda5428b9be850b81ac440ea51f1ddba2f987189ac1010000008a4730440220686a40e9d2dbffeab4ca1ff66341d06a17806767f12a1fc4f55740a7af24c6b5022049dd3c9a85ac6c51fecd5f4baff7782a518781bbdd94453c8383755e24ba755c01410436d554adf4a3eb03a317c77aa4020a7bba62999df633bba0ea8f83f48b9e01b0861d3b3c796840f982ee6b14c3c4b7ad04fcfcc3774f81bff9aaf52a15751fedfdffffff02416c00000000000017a914bc791b2afdfe1e1b5650864a9297b20d74c61f4787d71d0000000000001976a9140a59837ccd4df25adc31cdad39be6a8d97557ed688ac00000000';

  const txid = await transactions.postTx({ txHex });
  console.log(txid);

};
init();

This code snippet isn't working for me. I keep getting a UnhandledPromiseRejectionWarning: Error: Request failed with status code 400. I am unsure if it's because I am using the require instead of import? Or I am not correctly sending a POST request? Or not handling the Promise syntax correctly?
Would appreciate suggestions.

Would I be entering all this into the same .js file?

I tested your code and apparently the code is right but your Hex string is wrong.
The API response is as follows:
data: 'sendrawtransaction RPC error: {"code":-22,"message":"TX decode failed. Make sure the tx has at least one input."}'
Make sure that you have right Hex to post your tx. :)


text:
Trade Execution v.s. Trade Execution Update
Using the Bitfinex WebSocket API I am subscribing to trades.
The data I receive looks like this:
  chanId  msgType tradeID   Timestamp      Amount     Price
[ 139260, 'te', [ 73962571, 1507383025000, 97.628437, 0.503 ] ]
[ 139260, 'tu', [ 73962571, 1507383025000, 97.628437, 0.503 ] ]

te = Trade Execution
tu = Trade Execution Update
As stated by the Abbreviations Glossary
What I do not understand is that for the same tradeId I first get a te message and then a moment later a tu message. There is no difference in content of these messages, so what is the purpose of the tu message?
What is the difference between a Trade Execution and a Trade Execution Update?

The documentation of the authenticated side of the API from where these orders are created states the following:

After a te message you receive shortly a tu message that contains
  the real trade id (TRD_ID) and additional/updated fields.

These updated fields are for example fees that are charged afterwards.
Although from the public side of the API this real trade ID is already known and fees are irrelevant. Therefore, the data of the te-message is identical to the tu-message.
So, it seems tu-messages can be ignored.
+
Bitfinex now has it explained at their Bitfinex API module for Node.JS.
https://github.com/bitfinexcom/bitfinex-api-node
How do te and tu messages differ?
A te packet is sent first to the client immediately after a trade has been matched & executed, followed by a tu message once it has completed processing. During times of high load, the tu message may be noticably delayed, and as such only the te message should be used for a realtime feed.


text:
How can I send bitcoin from my bisq wallets?
I feel terrible to ask this question as it is so basic that it makes me feel stupid to ask, but I am searching the web since days and cannot find an answer.
Here is the situation:
I have a Coinbase account and I understand that Coinbase cannot use different/multiple wallets but has one wallet that cannot be changed.
I also use bisq and I bought a bit of bitcoin there without hassle. However, bisq has distributed my bitcoins to multiple wallets for reasons I do not understand. It has generated countless wallets, most of them empty, but there are still 3 wallets having a bit of money each.
Now I want to sell my bitcoins, but bisq has a number of downsides for selling btc:

I have a limitation of 0.06 btc. I don't understand why, because I have bisq installed since ages and I thought the limitation would start with 0.25 and grow over time, but anyway, bisq tells me I cannot offer more at a time.
Selling all my coins at this rate would take ages!
Since I have two small kids now, I cannot have the computer running all the time (shielding it from the kids) and be there when a buyer comes

What I want is to sell all my funds. The easiest way that I see right now would be to transfer all funds (0.49btc) to my coinbase wallet as from coinbase I can sell any amount of btc whenever I want.
But... I found no way to transfer the BTCs in bisq. In Coinbase there is a function "receive bitcoin" but all it gives me is the wallet id. So, what is the best way to merge/transfer (all) funds from the 3 bisq generated wallets to the coinbase wallet?
Of course, if you have another suggestion on how to sell the funds easily other than through coinbase, I'd be open for that, too.
Cheers,
8bitdefender
btw: I tried to include the tag "bisq" but could not as that would be a new tag

Ah, sorry guys! Now I did find a simple "send bitcoin" function in bisq... I must have been blind!
Still, if you think that my idea to send all btc from all 3 wallets to the coinbase wallet is a bad idea, I'd be happy for your input.


text:
Countries where ICOs can be conducted
I'm trying to find the way to understand where ICOs have been conducted.
Though there are many articles written on how favourable a country is to the practice of ICO (eg. http://fintechnews.sg/12836/blockchain/the-state-of-icos-around-the-world/), I haven't yet found sufficient information on where exactly ICOs have been launched.
My understanding is that, since ICOs are conducted on the Internet, it is the geological location where the project team is located that is important in terms of regulation.
For example, I understand that Ethereum was launched "in Switzerland" since its team (Ethereum Foundation) is apparently "located" in Switzerland.
However, there are other projects whose "birthplace" is not clear.
For example, IOTA has seven main developers in total but their geological locations aren't limited to one particular country (Germany, the US, New Zealand etc).
I'd appreciate it if someone could provide some insight into how to recognise where an ICO is launched.
Thank you.

Why is the location important?

@Max Vernon
When talking about ICO ecosystems around the world, people often talk about the subject in terms of countries (or their locations) in which ICOs are conducted. In addition, different countries (locations) have different regulatory frameworks which will then affect the way in which ICOs are operated.

The OP is asking where they won’t be jailed for running an unregistered security and selling it to consumers. More of a question for a lawyer really.

@eponymous I think what I'm asking is how to determine the "location" or "country" of an ICO project, especially when the team members are distributed around the world as is the case in IOTA.

Setup a registered office somewhere comfortable for an ICO and everybody telecommutes.


text:
What incentivizes non-miner nodes to propagate transactions?
I know miners are incentivized to verify and propagate transactions for their own benefit (by hopefully publishing it on their block before other miners do). But when a transaction is initially created, e.g. from a wallet that happens to only share a single (non-miner) peer, what incentive does this node have for propagation of the transaction to the rest of the network? Especially since the majority of the network is composed of non-mining nodes, where does this implied trust that they will reliably flood to all known neighbors come from?

The incentive to propagate a transaction is so that adjacent peers cannot distinguish what transactions actually belong to the origin node.
Since all nodes by default relay all fee-paying transaction, it is not possible for a malicious actor to determine which transaction actually belongs to you as transaction that contain your inputs/outputs of interest will be masqueraded among transactions of interest to anonymous peers. This implicitly grants you more privacy since it makes it harder for a malicious observer to correlate transactions to your peer identity (e.g. ip address).

I guess my question is less about privacy concerns and more about trusting this relaying behavior is done by other neighboring nodes. Cryptography prevents fraudulent verifications of tampered transactions, but nodes can still theoretically just start dropping and refusing to send them. What if some malicious authority ensembles a large group of nodes that work benevolently for some time but at some later time decide to stop flooding many transactions. What if a wallet whose only peers were these previously thought to be benevolent relayers?

If a malicious node decides to stop relaying, then it is a good sign that it exhibits odd behaviours and it can then be used to recognise malicious nodes. Honest nodes will then be programmed to disconnect these nodes. If a wallet whose only peers were these "malicious nodes", then unfortunately, the wallet owner would have been successfully "spied at".

So, in other words: non-miner nodes are incentivized to propagate transaction so they're more secure.


text:
Question on Mining Profitability
So I found this question: How much Bitcoin will I mine right now with hardware X?
I'm interested in understanding what exactly are the following values: 65535 and 2^48. I know that the former is concerned with 16 bits? And if that is correct, then for the unsigned integer of 16 bit size, you can express 2^16 - 1 values (i.e. we do not count zero), so you get 65535. I do not understand why we plug it into this equation though:
  (H*B/D) * (60*60*24 * 65535 * 10^6 / 2^48)
= (H*B/D) * (5.662224e15 / 2^48)              BTC per day (1)

But I also know that D*((2^48)/65535) is the number of hashes (in Mhash) that you have to solve to find a block.
So the equation that I gave you, I can understand that 60*60*24 is number of seconds in a day. Let's denote it as S. Then:
(H*B/D) * (S * 10^6 * (65535 / 2^48))

So I assume, 10^6 is some kind of hash to Mhash modifier (and that makes sense because 65535/2^48 is inversed, so we have to multiply and not divide).
So my question is, what is 65535 and 2^48. And then what is 2^48/65535 and what is 65535/2^48. Please be technical, but clear. Thank you.
EDIT:
From here: https://arxiv.org/pdf/1112.4980v1.pdf, I understand that 1/(2^32 * D) is the probability of finding a correct hash, or more precisely: (2^16 - 1)/(2^48 * D). They once again, do not tell us what those numbers are though
EDIT EDIT:
Number 16 must either deal with the fact that you require 16 leading zeros in block hash that you are looking for, or the fact that you have 16 hexadecimal values (0,1,2..,9,a,b,c,d,e,f). It probably deals with former because we have 2^16, which feels like it is binary state 16 times. Another reason why its trailing zeros is because hash has 64 values, and we have another number 2^48. And you get to 48 by deducting 16. So you have: total number of binary permutations in the numerator minus one (for length 16 bits) divided by total number of binary permutations of length 48 bits.. hmmm


text:
Private key to mnemonic words, is it safe?
Is it safe to do the following?
Suppose I do not want the HD wallet, but I do want the convenience of using mnemonic words to remember the private key. I know I can convert the private key's hex representation to byte format from which I can get binary format, from there I can follow BIP-39 to generate 24 words that are represented by that private key (because general addresses are used by randomly producing a 256 bit word which is equivalent to 24 words). Can I now use these "mnemonic" words to remember my private key, and completely disregard it (since I can always use these words to get back to the private key). I guess what I am wondering is whether there are cases where different private keys can produce the same collection of 24 words.

actually the above wouldn't work. Because You won't get equal number of bit chunks if you use 11 bits like in BIP39.

Extended keys used by BIP 39 are 512 bits in length. Generally speaking, the path from BIP 39 words to private keys, especially when using detached keys, are not invertable.  This is unlike Electrum mnemonic seed words that are invertable. The Electrum mnemonic can represent 256 bits.

@Naz correct, you would have to remember to discard the checksum when restoring the private key from the words, since the last word only carries 3 bits from the private key, whereas the last 8 bits are the checksum. I just provided further feedback in an answer, hope that helps.

Here are two mechanisms for converting a 256-bit (64 hexadecimal  characters) seed into a Electrum seed word mnemonics, and back again.
#1 JavaScript-based
#2 C++ - based
However, the command line interface example below, using mechanism #2, uses one of the most unsafe private seeds is used for demonstrative reference purposes only.
1% echo -n "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | ./bytes_to_words
rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper
2% echo "rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper" | ./inverse_mnemonics
0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff
The results are repeatable using mechanism #1.
BIP 39 doesn't require invertability support (analogous to ./inverse_mnemonics for Electrum words) albeit it can be accomplished. See How to generate a valid hash for a bip39 seed phrase? for an approach for accomplishing this task.
The mapping back to the BIP 39 root seed in hex is guaranteed to be unique. However, due to normalization associated with ed25519 cryptography, not currently used by Bitcoin, it is possible to have multiple two sets of 25 Electrum words that map to the same functional private key.

What do you mean by unsafe private seeds? I have implemented my own method today. Similar to bip39. Split the byte buffer into equal size bit chunks and then use them as indices for words.

I have about the same number of combinations of words as in bip39 between level with 24 words and whatever is before 24 (21 words?)

The key 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff has very little entropy and can be easily guessed and used by a bot. The Electrum example provided uses 25 words. The 25th Electrum word is always a repeat of the other 24 words and is used for error checking purposes.

Oh I got it. Thanks. How exactly is it used for error checking? Is it like a checksum?

% echo -n 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff | bx mnemonic-new
abandon above dust dust case often baby melt fever creek oven upper mass error grit fetch roof taxi creek roof ten jazz zoo unique

The BIP 39 example just provided is essentially not invertible. Each 32-bits of hexadecimal numbers maps to three BIP 39 words. I believe but am not sure how the 25th Electrum word provides checksum services.

See How to generate a valid hash for a bip39 seed phrase? and https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-the-mnemonic for how the last BIP 39 word impacts error checking.

that's not a valid electrum seed

Short answer is yes but you shouldn't, see point 1 below, and long answer is no its not safe or advisable.
I would say what you are proposing which is akin to a brain-wallet style single private/public key pair in this question is inadvisable for a few reasons:
1) The biggest risk is a lack of return change address (due to the absence of BIP32) in the case of sending anything less than the full balance will result in 100% loss of the difference (see here for more )
2) because of the checksum used in BIP39 which would alter your pasted binary data (i.e. pasting 256 bits for 24 words will later give you back 264 bits because of the 8-bit checksum that is appended to the last 11-bit group).
2) Besides Electrum, most wallets only allow the importing of mnemonic recovery phrases that are BIP39 checksum compliant and won't allow you to use an elliptic curve private key. In my opinion, it is better to have a checksum compliant mnemonic, despite its security being 256 bits, or 8 bits lower than 264-bit mnemonic with no valid checksum. Because it is more widely usable across wallet, in case electrum goes down or no longer works/supported, etc...
3) Decoding risks: if you are using a software that generates the private key in Base58 format, there is potential payload/checksum data attached that will increase the risk for errors when converting back to hex manually. Otherwise, if your are obtaining the private key in hex format, and are absolutely sure that it is the correct one in terms of the elliptical curve calculation to derive the public key and subsequent bitcoin formatted address, you can backup that string of hex characters in a number of ways.
Still, it would be better to back up the entire bip 39 Mnemonic crypto vault and then use an offline tool to access any related needed private key such as Ian Coleman's BIP39 tool offline (note: I am a contributor to that Github repo). Although you will still have to deal with converting Base58 encoded private keys, which I don't reccomend unless you know 100% how to do so without error.
4) Error checking: not all 256-bit numbers are valid private keys, as per the Elliptic Curve specifications used in Bitcoin (here is a related applicable post). So there must be error checking if you are generating the private key yourself manually, to make sure the key is smaller than the maximum permitted value 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141.
5)Regarding potential collision of private keys with mnemonics: yes there such collision, and it would be equal to two people randomly choosing or guessing the same private key (i.e., if the initial entropy for a mnemonic is the same entropy for an elliptic curve private key). Otherwise, the keyspace of private keys is the referenced above in point 4, and no two private keys point to the same address on the elliptic curve secp256k1 used in Bitcoin. The initial entropy range is 2^256 which is equal to the range of potential mnemonics 2048^24 minus the mnemonics with invalid checksums (otherwise the keyspace of mnemonics would be 2^264 ==2048^12 without the checksum requirement but both still wouldn't change the curve private keyspace ).
Again, I think it would be safer to follow the industry standard and use an HD wallet (which you would backup with a mnemonic).
P.S. You can further compress your backup using just the first 4 letters of each of the 24 words, provided that you are using the English BIP39 version, and concatentate them as a string of 44 characters. But when importing into a wallet, some don't autocomplete and you may have to lookup words manually from the list of 2048 BIP39 English words. I use an ecoding scheme that can further reduce the 44 charcters to 22 characters (including special symbols and numbers) with no information loss, but only to complement backups and not as a standalone replacement for BIP39 mnemonics.


text:
Hashgraph public ledger (51% attack)
I have some basic doubts about consensus algorithm like hashgraph. For instance, let's take Raft the simplest leader based consensus algorithm, we cannot use it in a decentralised setting because it's very easy for a single attacker to take control of the cluster by spinning thousands of nodes to support him.
"In summary, the voting based algorithm makes it very easy for the attacker whether its leader based or leaderless. So we cannot use it in a decentralised setting."
Algos like PoW make its difficult for a single attacker to take over the network through the computational puzzle.
Taking about hashgraph it's again a voting based algorithm, so wondering how it prevents a single attacker from getting control of the network in a decentralised setting (where you cannot trust your peers)???
I do understand how hashgraph works but wasn't able to visualise it in a decentralised setting. Any insights? Thanks

Why tagged as Bitcoin core?

yeah thats a mistake, removed it

Seeing this a year late, but if this is still a question then -
Hashgraph isn't exactly a voting based algorithm. It does "virtual voting" through "gossip about gossip" i.e. nodes not just gossip that there is a new transaction, but also gossip about when they heard it, who told them/how they heard it (literally gossiping about the gossip!)
This way every node has the COMPLETE knowledge of the network. If node A knows everything that node B knows, A can also find out what B will vote (WITHOUT B actually voting!)
Also, hashgraph never says that 51% attack can't occur. Through Byzantine Fault Tolerance even a  34% attack can occur (if more than 1/3rd of the nodes are malicious).
Hashgraph just says that DDoS or DoS (Denial of Service) attacks can't occur because there are no leaders.
Refer to the Hashgraph whitepaper or the scientific paper on its consensus algorithm: https://docs.hedera.com/docs/hashgraph-overview or https://www.hedera.com/whitepaper


text:
Canceling my pending withdrawal BTC
How can i cancel my pending withdrawal BTC of $1,240. Its been pending for 2 days. it has no confirmations and on the blockchain it says it receives 0 and sent 0. Someone PLEASE help me!

Are you withdrawing from a custodial service? If so, this is a customer service concern and you'll need to contact the service to ask for their help. If you are withdrawing from a non-custodial wallet and you have already broadcast the transaction to other nodes on the network, then there is ~no way to cancel it.

You can not cancel the transaction, but what you can do is to spend that same UTXO to a different address of yourselves (effectively a double-spend).
The reason it has no confirmations is likely that the fee is not sufficient for miners to prioritise your transaction in their mempool. As long as it has no confirmations, you can still double-spend to an address of your choosing.

how do i double spend and how much do i have to put

You 're'-spend the same, unconfirmed UTXO to an address of yourself. At this time, if you set a fee of 110 sats/byte (https://bitcoinfees.earn.com/), then your transaction will be confirmed in the next block.


text:
What do you think about "squashing" the blockchain?
So for some time i was thinking about a process where you "squash" the blockchain.
This would reduce its size significantly while maintaining integrity.
The process would look like this:

Summarize all transactions to a certain block
Throw away adresses with a balance of 0
Create a new genesis block containing all adresses that have a positive balance

Would this be possible?
What do you think about this?
Ps: Im new to blockchain and this community. So please dont be too harsh :)

Running a full node allows a user to independently verify the state of the bitcoin network. In order to verify the state of the network, the full node will run through every transaction in every block, and this is only possible if the full node has access to all of the data that comprises the network's history.
If you 'squash' (compress) this information, then the necessary verification cannot take place. Given a compressed piece of data, it does not seem possible to verify the validity of the uncompressed data (according to whatever rules), without having the uncompressed data itself. So instead you would need to trust that someone else had verified this data before it was compressed, and doing so would be counter to the goals of the bitcoin network (ie allowing every user to independently verify the network state).
Further, the blockchain record is not well-suited for compression.

Throw away adresses with a balance of 0
Create a new genesis block containing all adresses that have a positive balance

The bitcoin network does not keep track of address balances, it keeps track of UTXOs.
Note that you can run a full node with pruning enabled, so that old blocks will be discarded from your local storage after verification has been completed.

But where is the difference between:

Everybody on the network agrees on adding a block to the blockchain
and
Everybody on the network agrees on shorting the blockchain in a certain way

Every Node would just have to compare hashes.
(I cant create newlines here :()

@Freehunt nodes that are joining the network need to determine which chain is correct, amongst potentially many different chains. Knowing that the network starts from the genesis block (it is hardcoded in), and that they can follow the consensus rules to determine if any particular chain is valid, will allow them to determine which chain is the longest (and thus valid) chain. If presented with two chains that start from some arbitrary place in history, how could a similar determination be made? Simply having a valid hash isn't enough - the entire history preceding that hash must be valid.

@Freehunt if you are interested, you could search this site for questions concerning blockchain 'checkpoints' (a largely abandoned idea, but note that assumevalid allows similar benefits, with much better trust assumptions). You could also search for information about UTXO-set commitments, they are perhaps similar to what you are considering (eg Utreexo).

Cool! Thanks for this informations! Love you :)


text:
How many ways are there to Read Satoshi era Wallets?
I've come acrossed a few -
running the original Satoshi v.0.1.0 through v.0.1.5 Clients all the way up to Satoshi v.0.7.x - I believe all of these can read Original Satoshi Wallet.dat(s) -
I have a Satoshi v.0.8.6 Client that does have the Coin-Generation Feature enabled - though I have to set it in the Bitcoin.conf file or through the Debug Console - either way - it works.  It can generate the past transactions and any rewards mined with the default (gen=0) - though, it cannot read the keys correctly.  So sending and receiving is null.  And, signing raw transactions is also null.
The third option I'm aware of.  Is running BitcoinSV - but, I'm unsure at the moment, as to whether or not, BitcoinSV Node or Lite Wallet, can generate the Ungenerated Rewards mined under the Gen=0 default coin-generation setting.  Which is what I'm looking for.
So, I'm planning to run my Wallet.dat(s) with Satoshi v.0.8.6 and generating any passed transactions and/or rewards - then running them in a BitcoinSV Node or Lite Wallet, then dumping the Private Keys - then importing the Private Keys into a Satoshi v.0.8.6 or more recent release.  Then, figuring out the routine for Wrapped Bitcoin, BCH, and other Forked Reward Blockchains.
I'd prefer it if the Bitcoin Developer Teams - tried to reproduce the Problem I'm seeing.  And fixed it - as I'd like to access all of my Mined Rewards and Received Bitcoin.  Though, I literally just get slapped with "It's impossible" then effectively banned from asking or answering anything else.  What should I do?  Does anyone else have this problem?
Bitcoin Security - literally was Privacy Security - Not Wallet Security.
Sounds like theres a scam in the making.  Specially with CSW suing the Developers to fork all Dormant coins over to him.  I have what I believe is the Genesis Block reward, which makes me remember helping whoever it was, I believe it was CSW - do to conversations I had with said developer/software programmer.  And, I would claim I created the idea, and worked with someone on it, who disagreed with my ideas, and that person decided to make it this way, rather than my way - but overall the general technology works - and I made it opensource slash freeware - doubt I can do much now - but, ok.
First things first - help me access said Rewards and Transactions stuck in a Satoshi Era Wallet.dat - If CSW or anyone that knows CSW can ask CSW to contact me or help me, it would be appreciated -
But, before anyone decides to punish me further.
Replicate my issue, then get back to me!
Or, point me in the direction to talk to said Developers myself.
Thanks - hopefully this is addressed, rather then demoted.

Your approach of "regenerating transactions" is unproductive and unnecessary. Every version of Bitcoin Core can import wallets created by any prior versions. From there, the node will rescan the blockchain and identify all its coins automatically.
The relevant issue is that you "cannot read the [private] keys correctly".
The apparent explanation would be that your wallet file does not contain a copy of the relevant private keys.
If that is the case, no developer can help with that. You are describing the system working as intended: not your [private] keys, not your coins.
Given that anyone can create a watch-only wallet that follows the public keys of early block rewards, "seeing those balances" is neither particularly impressive, nor evidence of having been involved in the creation of Bitcoin.


text:
How do I access information on blockexplorer.com or blockchain.info without issuing requests to those websites?
Suppose I want to

get the balance of an address I don't own, or
see all the transactions recently made

Bitcoin Block Explorer has this information, but I don't want to use it

because of security (they might lie)
because of privacy (they might log queries)
because it introduces an additional point of failure
because it's not terribly quick, being a free service and all

How can I get this information from my bitcoind?

bitcoind doesn't give you a way to query this, but by looking at the files it writes to disk, we can build our own tools that let us look at this. One such tool is Abe, and this is how you use it:
Installation (Ubuntu)
I'm assuming you have the standard bitcoin client running already.
Download Abe. Unpack it, and run python setup.py install
Go into abe.conf and add these lines:
# SQLite3 example:
dbtype = sqlite3
connect-args = abe.sqlite
# Specify port and/or host to serve HTTP instead of FastCGI:
port 2750
host localhost

A note about firstbits
If you want to do firstbits lookups, you need to add one more line to the config.
use-firstbits

Note that you need to do this before you run abe, or else you'll need to run Abe.reconfigure too.
Back to the normal installation
Run python -m Abe.abe --config /path/to/abe.conf
You should see the screen get spammed with
block_tx 38944 39254
commit

At time of writing, this will need to count up to 220,000. This took me about 8 hours. After the first startup, it will load in about a second.
Try opening http://localhost:2750/. If it shows no data, then there was an error. The output that the abe command produced immediately before saying that it was listening should give you some sort of insight.
Now your application can issue http requests to find out about the blockchain! There is a link to some documentation (http://localhost:2750/q), but you'll mostly be interested in

getreceivedbyaddress (http://localhost:2750/chain/Bitcoin/q/getreceivedbyaddress/ADDRESS)
getsentbyaddress (http://localhost:2750/chain/Bitcoin/q/getsentbyaddress/ADDRESS)
fb (http://localhost:2750/q/fb/ADDRESS)

I tried this but I got the error message ImportError: No module named NCTestnet

I am actually working on doing this myself for a project, like the above poster said you can use the bitcoind API.
To get the information on addresses you don't own the commands "getrecievedbyaddress" and so on wont work.
You will need to work your way through the blockchain which can take a long time and i would not recommend doing it manually.
Here is the order of commands you would follow in order to do follow the blockchain.

getblockcount - this will give you the total number of blocks in the network
Now starts the endless loop of going from block to block with the following command - getblockhash {index} index the is block height. For example when you do block count you might see something like 200890. So the index of the last block is 200890 so you would input getblockhash 200890 which will return the hash number of a block.
getblock {hash} This command now gives you all the transactions within the block.
Now your going to use each transaction ID in the block with the following command getrawtransaction {txid} This is going to give you a list of the inputs and outputs of each transaction. Here you will see the addresses which received and sent within that transaction and the amount involved.

Now you'll basically loop this until you've built up a database of the entire blockchain, their is no easy way to do it unfortunately. I am just starting out on all these steps so i may have missed something, but the general idea is thier.
Hopefully you find that block of text useful in some way =)

To see all transactions recently made (by anyone on the network), you can use the getrawmemorypool RPC call, it will give you a list of all txids in the memory pool (not yet in a block). Those can be passed to getrawtransaction to retrieve the actual transaction. getblock can be used to see the transactions in recent blocks.
Querying the unspent outputs by address (required to calculate the "balance") requires an index from addresses to txids. Bitcoind does not maintain such an index, as it is not required for normal operation, but it may be added as an optional feature somewhere in the future.

You can use the API to access each block, and then Raw Transactions to access each transaction within each block.  It isn't trivial but it can be done.

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

Seems like this might take a while if you wanted to figure out the balance of an account. It's probably the right move if you want to find out about recent transactions, though. Good information!


text:
Does Namecoin support the bootstrap.dat file?
If I create a bootstrap.dat file for Namecoin from an existing install will it use it?

No. This feature does not exist (yet) in Namecoin.


text:
BTC on Mycelium to Bitcoin Gold?
I have some BTC on my Mycelium (Android) wallet and I was wondering if it's possible to now access (hopefully) my Bitcoin Gold. It seems I can't get the normal private keys off of Mycelium, but I have my 12 word seed at hand.
Are there any wallets compatible with Mycelium's 12 word seed that will allow my to access the Bitcoin Gold?

Do not use your seed! It will compromise your whole wallet.
Export your current account's private key in settings->export on an account.
Before using this private key anywhere. Add a new account and send your Bitcoin to this new account in Mycelium. Now you can use the exported private key to claim your Bitcoin gold.
However where you can do this is still unknown to me. Apparently Bitcoin Gold will provide guides for all wallets including Mycelium.

authors: Лариса Аушева


text:
Why bitcoin cash supply is currently 100k more than bitcoin on coinmarketcap (as of Oct 17)

Is it a mistake or is there a significant difference in coins generated?

EDA (Emergency Difficulty Adjustment):

Median Time Past of the current block and the Median Time Past of 6 blocks before has to be greater than 12 hours.
  If so, it gets 20% easier to create proof of work. In other words, miners can find blocks 20% easier.

Source: Jimmy Song
As EDA is one way (difficulty down), miners abuse it. They stop mining, and after the EDA comes, they start mining with a big hash power. This is the cause of Bitcoin Cash's hyperinflation: ~7500 blocks ahead of BTC and 7500*10/60=1250 hours of blocks ahead.
The developers are aware of this issue, and it'll be replaced on 13th of November, by a newer difficulty algorithm.
They haven't decided which algorithm to switch, but probably it'll be Dgenr8's. [1][2]
1: https://www.yours.org/content/dgenr8-s-difficulty-adjustment-algorithm-explained-01a2de286460/
2: https://reviews.bitcoinabc.org/D622

Thank you for the correct answer, I thought something stupid :D

This is because Bitcoin Cash is highly centralized with mining power. By allowing this to happen prior to mining becoming more decentralized the promoters stand to gain a huge potential bonus. This bonus can also help them support the price with wash trades and real trades.
This is my analysis and opinion. I'm sure bag holders will flame otherwise since the truth hurts.

They had months to make sure they had the best tested algorithm that could adjust properly, they also could have redeployed as little as a week or two once this was noticed if not planned. Instead months. The largest promoter is also the manufacturer of the majority of hashpower at the moment with the greatest ability to manipulate the ebb and flow, thus the mining rate for profitable gain. All answers should show who benefits financially.


text:
What can blockchain do that normal databases systems won't?
Aside from cryptocurrencies, what advantages may blockchain(either public or private) have and real life use cases that can be more useful implemented in blockchain over traditional databases based systems ?

Distributed consensus

Why is this tagged bitcoin-core?

removed the bitcoin-core tag

Blockchains are data structures, whose only advantage is that storing data in that structure allows you to achieve decentralization under certain conditions.
So your question reduces to "how is decentralization important"?
Decentralized systems tend to have the following favorable attributes:

Open (anyone can participate; not permissioned)
Borderless (as long as you can reach one other connected node, country/regional borders don't matter)
Neutral (the system doesn't care what you use it for)
Censorship Resistance (transactions/data entry is unstoppable)
Trustless (falsified data is easily detectable by verifying across multiple nodes)
Immutability (data cannot be removed or altered)
Public

Excellent response, I would add to the list data immutability. What do you think?

Another major aspect is trustless. You don't need to trust individual nodes to believe that the data is correct as long as there isn't a majority of nodes conspiring against you.

Many of these properties are indeed present in a functional blockchain based system, but rely on having economic incentives (if miners are not paid for valid blocks, there is no immutability as rewriting a chain becomes trivial, or degrades into a trust-based system instead to protect against that). It's very hard to disentangle the most useful properties from the cryptocurrency use case, which is what OP was asking about.

Indeed, I alluded to this with the intentionally broad qualifier "under certain conditions". That is, having a blockchain is a necessary but not sufficient tool to achieve decentralization. This answers the question what can blockchain do, not what all blockchain-using systems do

Some of these points are dubious - borderless payments may be novel, but "a borderless database" doesn't make much sense; "public" just means the same as "open"; and I'm not sure what makes blockchain more "neutral" than any other technology.

Borderless database makes sense, you can store data that may be otherwise illegal to store. Public meaning all the data is viewable by everyone; eg Venmo's system is relatively open (still permissioned, but it's easy to obtain permission to use it), but private because the data in each person's account is only viewable to them. Yes, "Technology" is generally decentralized, which makes it generally neutral. This is decentralization of data storage/transmission which is otherwise usually subject to some ToS, namely, the centralized entity storing or transmitting the data.

This is hard to answer, as "blockchain" isn't a very well defined thing. Often the term refers to some use of cryptography in a distributed system, but what it means beyond that depends on who you ask. To those who use it as a generic term, it is usually little more than a marketing term.
If you assume that at least there is an actual chain of blocks being built, either by a permissionless set of participants based on economic incentive ("miners"), or by a permissioned set of signers with long-term identities, the question you're asking actually does not make sense. Blockchain consensus algorithms do not compete with or replace databases as such. They are a mechanism for obtaining consensus on a global state, where multiple participants have authority to accept changes. Arguably, each of those participants already needs a database themselves - the blockchain is merely a log of all accepted updates to those databases. Even in Bitcoin, every node actually has a local database with the UTXO set. In Bitcoin Core, that is a LevelDB database, but there is no fundamental reason why another database couldn't be used.
Of course, in some scenarios all you need is a single authority deciding on all changes to the database. In that case a database is indeed all you need. But that's a silly comparison: there are plenty of use cases for distributed systems with multiple writers today, in production use, that have no relation with blockchains. Look up Paxos, or Google Spanner for example. The complexity is not in the database part, but in keeping the participants synchronized. That is what a consensus algorithm does. Most production instances I know of this use mutually trusting authorities (and a distributed system is used for performance/latency reasons rather than trust), but algorithms that permit distrusting participants are well known as well, e.g. PBFT.
Now, digging deeper: how does a private blockchain compare with such a system? The answer is trivial: it is effectively a new way of looking at the same thing. Private blockchains (i.e. there is a set of known identities that can approve changes) rely on running a traditional consensus algorithm (e.g. PBFT) between the block signers to make sure only a single chain emerges. Here the "blockchain" is literally the log of changes, as many of its properties (e.g. the ability to temporarily fork) aren't even used. That log may be useful for auditing purposes, and if you structure it as a hash chain, you could indeed call it a blockchain. But there is no innovation here whatsoever. That doesn't mean "blockchain technology" is necessecarily useless  here, as some of the cryptography for e.g. transaction verification may still be applicable (depending on the use case), but, arguably, the blockchain as a datastructure itself not novel in any way here.
Things get much more interesting when you're talking about a public blockchain (where anyone can become an authorizer of changes) but its use cases are very limited. I'm going to focus here on proof-of-work, as I don't believe any solution that completely avoids PoW actually securely offers the same properties. What PoW does is replace the signing of blocks by known identities with betting on particular versions of history and paying for the bet. Everyone who consistently bets with the majority ("miners") gets paid, and those who diverge don't. There are two fundamental changes here: (a) there must be something of value to pay miners, which typically implies that your blockchain needs to define its own currency, limiting the use cases to effectively just cryptocurrencies (b) you don't get guaranteed convergence anymore, only probabilistically and under economical assumptions.
To summarize, the answer to your question really depends on what you mean by blockchain, and what kind of thing you're comparing it to:

Cryptography used in blockchains may be widely applicable in a variety of settings, but doesn't really have anything to do with blockchains or databases themselves.
Using consensus algorithms (private or public, including typical "blockchain based" ones) in situations where there is only a single authorizer is silly; you should use the database directly.
Using fault tolerant consensus algorithms (either traditional BFT like ones, or PoW) is overkill when your authorizers are trusted (e.g. because they're all run by the same company). Use something like Paxos instead.
Using trustless consensus algorithms like PoW does add something no other construction gives you (permissionless participation, meaning there is no set group of participants that can censor your changes), but comes at a high cost, and its economic assumptions make it pretty much only useful for systems that define their own cryptocurrency. There is probably only place in the world for one or a few actually used ones of these.

I think you left out the case where there is a consortium of companies, some of which may join and leave, where each participant trusts the majority but still wants high level of accountability.

Lack of trust
A major difference over a traditional database system is that blockchains enable a "shared database" without having to trust the holder of that database.
It doesn't necessarily have to be a proof of work system like many cryptocurrencies  but even for a centralized, shared database implementing it as a blockchain (in the technical sense of a Merkle tree of blocks linked with cryptographic signatures) would enable all the many parties interested in the contents of that database to work even if they believe that the holder(s) of that database may be malicious. For example, there can be systems that allow people to verify that "their modifications" have been properly written to that system; they (and the general public) could verify that no backdated modifications have ever occurred, and all this can be done even while keeping some contents of that database private.
In essence, it is one way to enable a publicly verifiable ledger between untrusted, potentially malicious parties. Which is quite useful in certain situations - many (but not all) of them related to decentralization, where lack of trust is a key issue.

You seem to be applying a very broad definition of "blockchain" that makes it basically a synonym of "Merkle tree". There are many database-like applications of Merkle trees with the verifiability properties you mention, such as distributed version control (e.g. git, Mercurial), but they would not generally be called "blockchains".


text:
What are the benefits of using btcd instead of bitcoind?
btcd 1.0 was released October 3, 2013. Why use it instead of bitcoind?

EDIT (2014-09-05): I have updated this answer to the most recent information.  The previous answer was outdated in regards to the cons.  It was accurate as of version 0.3.0-alpha, however btcd is now in beta, up to version 0.8.0-beta, and nearly all of the previous cons have since been addressed.  Also, I've updated all references to bitcoind to Bitcoin Core to reflect their name change
I'll try to answer this as unbiased as possible, but, as a disclaimer, I am the lead developer for btcd.
First, a small correction.  The initial release is version 0.3.0-alpha (https://github.com/conformal/btcd/releases).  It is not yet up to version 1.0 as we first want to get a ton of public testing from early adopters before claiming it is production ready.  We fully understand the importance of avoid block chain forks and are making herculean efforts to do everything we can to prevent that from happening.
I'll provide a list of pros and cons that I can think of for btcd relative to Bitcoin Core below, but one thing I'd like point out isn't specifically related to btcd or Bitcoin Core, but rather the Bitcoin ecosystem as a whole.
Diversity is something the Bitcoin ecosystem is in dire need of.  Diverse, inter-operating implementations make the Bitcoin network more robust against several things such as denial-of-service attacks, vulnerabilities, and individual application bugs.  History has shown that for any protocol to thrive and gain wide-spread acceptance, multiple implementations on multiple devices is inevitably required.  One prolific example is TCP/IP.  TCP/IP would not be where it is today if only a single implementation existed.
Pros

btcd offers a unique architecture in that it separates the chain services from the wallet services (see NOTES [a])
btcd is written in Go which has several advantages over C++ (See NOTES [b])
btcd is a clean refactor of the entire Bitcoin protocol rather than one that is monolithic
the btcd codebase strives to provide easy to follow and well-commented code (Bitcoin Core is definitely improving in this area, but there is still a lot of undocumented "magic")
the btcd core packages provide more extensive unit test coverage to help prevent regressions (for example btcwire provides 100% test coverage)
btcd incorporates a package that has been highly optimized specifically for the ECDSA curve parameters used by Bitcoin (secp256k1) making it faster than OpenSSL
btcd is capable of running as a real service on Windows (see NOTES[c])
btcd provides a compatible RPC interface with Bitcoin Core has which makes it relatively straight forward to use it in existing infrastructures
btcd is able to sync the entire block chain from scratch in around 5 hours on an Intel i7 with an SSD

Cons

btcd does not daemonize itself and instead relies on external tools such as daemonize and upstart to perform that function
The uPnP functionality is currently disabled by default and does not appear work with all devices, so it might be necessary to manually open ports on your router and use the --externalip flag

Notes
[a] A full discussion of the advantages of separating the chain and wallet services would require an entire blog post, but a few examples are that it opens a lot of opportunities for lower powered hardware, offers better multi-user support, and results in less waste in small networks which can share the chain services.
[b] Some advantages we believe Go has over C++

Integrated test infrastructure
Platform independent code
Simpler parallelism and excellent support for concurrency
No active memory management which leads to eliminating an entire class of the most common security vulnerabilities like buffer overflows
Built-in profiling and documentation facilities
Significantly faster compilation times

[c] The Windows installer does not provide the option to install or run it as a service, however btcd itself has command line options to do so.  To install it as a service: btcd.exe /s install

It's times like these one wishes they could cast more than one upvote.

does it have address index?

as davec mentioned, btcd is written in go, and thus runs on any platform that go runs on. although not officially supported, go runs on plan 9, and so i run btcd on plan 9. proof:

This is awesome.


text:
What happened to Sidechains
Seems like the interest to work on sidechains has died in favor of Lightning and Segwit ( I might be wrong about this, that just seems to be the vibe I get from social media and seeing what kind of things people are working on and excited about). There doesn't seem to be much interest in the required soft fork to get side chains working ( See also this question where it was predicted that this would be done in 2016, well now its 2018: Is it likely that side-chain support will be added to Bitcoin? ).
Some Core developers like Peter Todd have also expressed serious concerns about the potential downsides ( https://soundcloud.com/mindtomatter/ltb-e104-tree-chains-with ). There also seems to be political obstacles to enabling side chains because it is not clear what benefit it would give to Bitcoin itself.
The only people seriously interested in getting sidechains to work seems to be RSK project and the Drivechain project.
So what kind of progress/work is being done on sidechains and will sidechains ever see the light of day?

I don't think this is any more opinion-based than the question linked.  A lot has happened (Liquid) and hasn't happened.  A factual account can be written here by those knowledgable.


text:
How miner deduct Transactions fees from transaction?
How is it possible for a miners to deduct the transactions fees from the UTXO output which is locked by locking script or encumbrances?

The sum of a transaction's inputs must be greater than or equal to the sum of outputs as part of the validation rules.  This difference is the transaction fee.
So to answer your question directly, when a UTXO is spent, it is referenced as part of a transaction input.  A UTXO is always completely consumed (analogous to how if you spend a dollar bill, you have to spend the whole bill and get change), so the fees are not taken from that per se.  It is the difference of the inputs (sum of the UTXO values being spent) and the outputs of a properly formed transaction that becomes the miner's fee.

Greater or equal. Fees are not a consensus rule.

Or put otherwise: the transaction itself commits to turning some of its input values into fees. Miners are allowed to take it, but they take it from the amount redirected to fees by transactions already - they don't modify the transaction in doing so.