text:
Can CLN be configured to use a bitcoin node running on another machine?
CLN 0.12.1
I have bitcoin core running on one machine (Debian 11) and would like set up CLN (C-Lightning) on another machine (Ubuntu 22.04) on the same network. My first test was to use the --bitcoin-... command line parameters to try to get this application connected to my node.
Here is the result.
$ lightningd --lightning-dir=./cln-dir/ --bitcoin-rpcuser=xxxxxx --bitcoin-rpcpassword=xxxxxx --bitcoin-rpcconnect=192.168.1.38 --bitcoin-rpcport=8901

bitcoin-cli not found. Is bitcoin-cli (part of Bitcoin Core) available in your PATH?

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

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

    $ bitcoin-cli -rpcconnect=192.168.1.38 -rpcport=8901 -rpcuser=... -rpcpassword=... echo 'hello world'
2022-11-22T21:31:31.451Z **BROKEN** plugin-bcli: \nbitcoin-cli not found. Is bitcoin-cli (part of Bitcoin Core) available in your PATH?\n\nMake sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.\n\nYou can verify that your Bitcoin Core installation is ready for use by running:\n\n    $ bitcoin-cli -rpcconnect=192.168.1.38 -rpcport=8901 -rpcuser=... -rpcpassword=... echo 'hello world'\n
2022-11-22T21:31:31.451Z INFO    plugin-bcli: Killing plugin: exited before we sent init
The Bitcoin backend died.

I have bitcoin-cli on the machine I am running CLN on, so I tried it again, this time providing the bitcoin-cli command line parameter, but I got the same result. If I give it the bitcoin-datadir parameter (which is actually a directory on the other machine), it gives me the same result.
I decided to try bitcoin-cli just to make sure it is possible. With bitcoin core 23.0 running on one machine and bitcoin-cli running on the other, the following command worked.
$ bitcoin-cli -rpcconnect=192.168.1.38 -rpcport=8901 -rpcuser=xxxxxx -rpcpassword=xxxxxx echo 'hello world'
[
  "hello world"
]

Is there a way to run CLN without using bitcoin-cli?
I just started trying to set this up today, so I am not familiar with CLN at all. Is it even possible to do what I am trying to do? If so, what parameters need to be set in order to get it to work?

This looks like the bitcoin backend plugin bcli cannot find the bitcoin-cli executable, since the command seems to be working when run from the same machine with the suggested parameters.
This suggests that the $PATH variable does not include the directory the executable is. To amend this you can do the following:
which bitcoin-cli

This will tell you where the executable you manually tried is. This will be something like /usr/local/bin/bitcoin-cli.
Next we also tell lightningd exactly where it can find the bitcoin-cli:
$ lightningd \
  --lightning-dir=./cln-dir/ \
  --bitcoin-rpcuser=xxxxxx \
  --bitcoin-rpcpassword=xxxxxx \
  --bitcoin-rpcconnect=192.168.1.38 \
  --bitcoin-rpcport=8901 \
  --bitcoin-cli=/usr/local/bin/bitcoin-cli

Notice that last line now points to the executable, please adjust the path according to the which command earlier.

It looks like the --bitcoin-cli parameter has no effect. I did finally get it to work when I moved bitcoin-cli into a $PATH directory. With bitcoin-cli in the $PATH, the --bitcoin-cli parameter is not needed at all. But when bitcoin-cli is not in the $PATH, the --bitcoin-cli parameter does not work.

Interesting, I had started writing an answer with PATH but though --bitcoin-cli would be easier. Entering the full path to the executable in --bitcoin-cli didn't work?

No, it didn't work for me. But I created a symbolic link the bitcoin-cli in one of the PATH directories and it worked fine after that.

Ok, that sounds like the --bitcoin-cli option should be fixed to work with non-path binaries when the absolute path is specified.


text:
Blocked transaction wallet on my phone
Ok I have a wallet on my phone that I put bitcoins in on monday, They have been blocked now for a week. How do I unblock them and the wallet I am using I can get it on my mac. Its called bitwallet by sollico software. at this point I am so confused I really just want to get the bitcoins I put in the wallet and use them to put ads up and I cant cuz its still blocked. PLEASE HELP ]1 Thank you so much in advanced !
EDIT:
When I go to pay it won't let me send. It keeps saying "insufficient funds." Maybe I'm doing it wrong.

when i go to pay it wont let me send unless im doing it wrong which is Very possible lol

I'm not sure what you mean that they've been "blocked" ?
That screenshot shows the "block" number that the transaction was mined in, which means that it has been confirmed on the Bitcoin network and is available for you to spend.
Have you tried to use that wallet to pay for something and you're getting an error? Because as far as I can see it seems fine:)

It seems like you are confusing block with blocked. The block id shown in your screenshot is the number of the block in the blockchain where your transaction is stored in. (Meaning that the network mined and confirmed that transaction)
I personally don't use bitwallet but it seems like to use it on a Mac you need to use the web interface.
If you want to know more about how bitcoin works check Wikipedia.

source: Stack Exchange

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

sort: votes


text:
How to know the destination address of a multisig?
Run this command:
bitcoin-cli getrawtransaction 56214420a7c4dcc4832944298d169a75e93acf9721f00656b2ee0e4d194f9970 2
You will see the first vout is a multisig as follow:
 {
      "value": 0.04030000,
      "n": 0,
      "scriptPubKey": {
        "asm": "2 02c08786d63f78bd0a6777ffe9c978cf5899756cfc32bfad09a89e211aeb926242 033e81519ecf373ea3a5c7e1c051b71a898fb3438c9550e274d980f147eb4d069d 036d568125a969dc78b963b494fa7ed5f20ee9c2f2fc2c57f86c5df63089f2ed3a 3 OP_CHECKMULTISIG",
        "hex": "522102c08786d63f78bd0a6777ffe9c978cf5899756cfc32bfad09a89e211aeb92624221033e81519ecf373ea3a5c7e1c051b71a898fb3438c9550e274d980f147eb4d069d21036d568125a969dc78b963b494fa7ed5f20ee9c2f2fc2c57f86c5df63089f2ed3a53ae",
        "reqSigs": 2,
        "type": "multisig",
        "addresses": [
          "1PfTD843HiN2PPpxFnMwyxN7se6MEf2ech",
          "1JXc8zsSeAPwqfAzLbBnZxNTfetZexH2bW",
          "1Ng4YU2e2H3E86syX2qrsmD9opBHZ42vCF"
        ]
      }
 },

And from bitinfochart, we can see the destination address is not

1PfTD843HiN2PPpxFnMwyxN7se6MEf2ech
1JXc8zsSeAPwqfAzLbBnZxNTfetZexH2bW
1Ng4YU2e2H3E86syX2qrsmD9opBHZ42vCF

but 3844dWM7n5c1oAYhtQc5uLtKB6TjN5PSW4
Can someone tell me how to get the destination address, 3844dWM7n5c1oAYhtQc5uLtKB6TjN5PSW4?

You keep overwriting my edits but you seem to misunderstand their purpose. See my answer, 3844dWM7n5c1oAYhtQc5uLtKB6TjN5PSW4 is not the "destination address": their is no concept of address for the bare multisig scriptPubKeys. The explorer you consulted misleaded you.

The website displays the scriptPubKey of the first output as if it was a P2SH (more commonly used for multisig), but it's not.
This is a bare multisig. As another explorer example, Esplora displays it more accurately (there is no address for this Script type).
The addresses field of getrawtransaction (and a few other commands) output will for bare multisig outputs give you the P2PKH address of each of the key used in the multisig.

What do you mean the scriptPubKey of the first output? There are many fields in scriptPubKey.

So those who own these three addresses can spend the bitcoin?

1st question: I mean the actual scriptPubkey (or output locking script), not the JSON entry of the getrawtransaction output.
2nd question: In this specific case (2 of 3), 2 of them agreeing can.

Last question. Where can I find the actual scriptPubkey ? Thank you.

The actual scriptPubkey is represented as hexadecimal in the ["scriptPubkey"]["hex"] JSON entry.

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


text:
Do p2pk and SIGHASH_SINGLE still working nowadays?
Seems like p2pk - pay to public key may be working or not in modern wallet apps. Is it still working or not?
EDIT: Can old p2pk addresses be used to move balance to new addresses (for example bc1q...)?
The same about SIGHASH_SINGLE - is there any Python library that supports this hash type today?
EDIT: And is there wallet app which supports it currently?

Can you clarify what you mean by "working"?

Both P2PK and SIGHASH_SINGLE are still consensus valid and accepted by Bitcoin Core's default mempool policy. SIGHASH_SINGLE was even included in the Taproot soft fork for use in signatures in a Taproot spend.
As for using these, python-bitcoinlib provides enough low level utilities that you can create and spend P2PK outputs and create SIGHASH_SINGLE signatures.

p2pk addresses

There is no such thing as a P2PK address. They do not have an address type. You can create P2PK outputs, but there is no address type for instructing other people to create P2PK outputs that you can spend.

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


text:
Decipher xprv or seed from keystore when I know the password
I know http://iancoleman.io/ but it does not help me as this is the other way around.
I have dump with: keystore: xprv and seed. I want to decipher xprv or seed because I know the password, but I have no tool to do that.
How can I do that?
EDIT: This is a .json file.

What software was used to encrypt the xprv and seed? Was it a known version of a specific wallet application?

@RedGrittyBrick I don't know that. I have .json file.

Could be a blockchain.info wallet? https://bitcoin.stackexchange.com/q/35914/13866

@RedGrittyBrick rather not.


text:
Why does Bitcoin support both compressed and uncompressed keys/addresses?
My question is about the difference between compressed keys and addresses, and i know it was addressed in another question but my question is less about the theory and more about how the keys are used practically in Bitcoin.
So heres what I did: I used dumpprivkey for an address 183Tw2TqXKkbk5ZeocTYwmxg8x46ADXb6c in the .7.2 client, and got L5DTi7rgqsPg7Vq1vTU2dP2HWMEsNM5w5JCqEDXXXXXXXXXXXX. When i pasted this into bitaddress.org's wallet details script it returned several things. First, it showed a different address 1FKswUuFsjWKyr4ZPSe3vEpp1iCXXChBZm, but it also showed the address above and said it was the compressed version. I sent like 0.0001 to each of the 2 addresses and my satoshi client only shows a transaction recieved from the 183 (compressed) address.
Can someone please explain in practical terms what the difference is and why they both even exist in Bitcoin? Any help is appreciated.

^^ bitaddress.org*

The reason they exist both, is because Satoshi didn't know about compressed public keys, and it was only recently discovered that they would be possible to use without compatibility problems (support only exists as of version 0.6 of the reference client).
The advantage is clear: their public keys are smaller, resulting in smaller transactions on the network, saving block chain size for everyone.
Update: inside SegWit spends, only compressed keys can be used.

thanks for the answer, but what i really dont understand is, in terms of usability, how come when i sent to the compressed, the satoshi client recieved the transaction, and when i sent the uncompressed, it did not. also, why do sites such as blockchain.info see them as 2 different addresses. also, is it possible to determine the uncompressed from the compressed, and vice versa?

The address is just the hash (in base58 encoding) of the serialized public key. Compressed public keys are a more efficient serialization, so they correspond to a different address. Given a public key, you can determine the "compressed address" and the "uncompressed address", but not from just an address. Clients can only receive coins on compressed addresses if they support compressed public keys in the first place.

Still, shouldn't a post-0.6.0 client recognize both the send to the compressed address, and the send to the uncompressed address, because it has the private key sufficient to spend either?

What's the point? No peer can have the address for the wrong one in case you only give out one. No need to double the number of addresses checked if we know only one is ever shown.

Does this mean if custom software gives out the base58 address for an uncompressed address it is unspendable or that it is spendable through RPC ?

If I want you to pay to a compressed pubkey address, I'll give you a compressed pubkey address. If not, I'll give you an uncompressed one. You cannot even know, and you certainly shouldn't care.

Do both a compressed address and its uncompressed one have distinct balances? If then, can I spend (“make a transaction transferring”) the sum of their balances from one of them? (Related: https://bitcoin.stackexchange.com/a/67137/59572.)

Internally Bitcoin does not have a concept of "balance" anywhere. Transactions spend specific explicit outputs of previous transactions. So if you received two payments - whether to the same address or to different addresses - you always need multiple inputs to spend then (which is possible, though makes the transaction larger and thus costlier).

"Still, shouldn't a post-0.6.0 client recognize both the send to the compressed address, and the send to the uncompressed address, because it has the private key sufficient to spend either? – Quizzical Nov 27 '13 at 2:16"
You have a private key? Great! Open bitaddress.org(offline) and scroll to wallet details tab, then enter the private key. You'll find the compressed and uncompressed addresses in the right and left side respectively. Scroll down you'll find the compressed and uncompressed private keys there.
Yes! Private keys when denoted in base 58 check format have different values in compressed and uncompressed form. This was done to ensure that the clients don't get confused as to which address to map (compressed or uncompressed).
The point being: WIF format for every hex private key are different in compressed and uncompressed form.
Hope this answer helps.

Posting a secret key into any website is generally a bad idea. These services should really only be used for testing, and even that is arguable.

I said "offline" which means on an airgapped machine. Bitaddress.org is a Java based client side webpage you can easily download the source from git and verify the pgp then use it offline without compromising the security of your private keys.

@prof.Zoom It's not Java-based. It's JavaScript-based.

@AlexWaters How would using them for testing be a bad thing? What are they going to do? Steal the 10 cents you use for testing? Plus, he wrote that you shouldn't do this while you're online.

Shouldn't be downvoted, +1 for this non-intuitive nugget: 'Yes! Private keys when denoted in base 58 check format have different values in compressed and uncompressed form' Saved me lots of stress exporting old keys from blockchain.info that showed uncompressed addresses but exported as compressed WIFs. Instead of (offline) bitaddress.org I used: ku -Wu <compressed WIF>

Though Bitcoin initially took only one; the uncompressed public keys, if it then changed to not allow the use of uncompressed keys (and only allowed the use of compressed keys) those people with wallet addresses that correlated to a private key's uncompressed keys would have been unable to access their funds.
This is because a Public Key:

02E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0 (compressed)

Has an address of

1MEqCrJfxPAh2uCcGmAV2Bgkj6qD69XgfF

While the uncompressed version of that public key:

04E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0E44402759C51ED0D3BA2F53E749B30A6D1772F0DAE1E3F465E8C8828DF899FE2 (uncompressed)

Has an address of

1JGTdegLcK8N9mqwhXmGjeUgbQNugii3rm

If Bitcoin stopped accepting your uncompressed version, you'd have to find a compressed public key that would result in your same address to continue to access your funds.  Doing that is just as difficult and unrealistic as trying to crack the bitcoin algorithm.

Good point! I like the fact that one can have 2 address types for the same private key. Migrating to the new compressed public key is the way to go :)

authors: Константин Ван

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


text:
Miners influence
How many people represents the bitcoin's minors? Thousands ? Hundreds ? Or just a few organization controlled by a minority of people that possess the means to run minig plants?
https://www.youtube.com/watch?v=K8kua5B5K3I
Can the price of BTC be manipulated by minors? for example if they all decide together to sell every btc the create to lower the price.

max amount of BTC : 21'000'000 - gift for mining a block 25 BTC - one block mined approximativly every 10 minutes  >>>  1'300'000 BTC mined every year - if one or a few organization mined every blocks for one year it could possess at term around 15% of total BTCs

Since all bitcoin originates as a mining reward...100% of all bitcoin in existence was at one point collected by miners.  Are you instead asking about mining centralization?

Technically... more than 100% all bitcoin in existence was collected by miners, since (1) sum of tx fees in all blocks > 0 and (2) bitcoin has no block reward penalty :P

This question is not clear at all. as others have already stated, all bitcoins originate from mining. Please clarify your question.

How much represents the total amount of BTC collected by miners compared to the total number of BTC?
Miners collect all the Bitcoin! Some will keep it, some will set it to pay for mining equipment and energy costs. Most miners are probably somewhere in between.
In the beginning miners collected 50BTC per block (plus transaction fees) not then collest 25BTC per block. Soon the reward will drop to 12.5BTC.
Bitcoins are sold, traded and spent. Although miners initially collect all the BTC they do not own most of it in the long term because it circulates around the world to users of all types


text:
I can not access use bitcoin rpc via php : easybitcoin.php
Bitcoin RPC is working on UBUNTU but not on Windows.
I am using exactly the same library.
My php code :
<?php
require_once('../Easy_btc/easybitcoin.php');
$bitcoin = new Bitcoin("rpcuser","rpcpassword","localhost","80");
$b = $bitcoin->getinfo();
var_dump($b);
var_dump($bitcoin);
?>

The error I get :
object(Bitcoin)#1 (12) {
  ["username":"Bitcoin":private]=>
  string(7) "rpcuser"
  ["password":"Bitcoin":private]=>
  string(11) "rpcpassword"
  ["proto":"Bitcoin":private]=>
  string(4) "http"
  ["host":"Bitcoin":private]=>
  string(9) "localhost"
  ["port":"Bitcoin":private]=>
  string(2) "80"
  ["url":"Bitcoin":private]=>
  NULL
  ["CACertificate":"Bitcoin":private]=>
  NULL
  ["status"]=>
  int(0)
  ["error"]=>
  string(23) "Empty reply from server"
  ["raw_response"]=>
  bool(false)
  ["response"]=>
  NULL
  ["id":"Bitcoin":private]=>
  int(1)
}

The library I use :
<?php
/*
EasyBitcoin-PHP

A simple class for making calls to Bitcoin's API using PHP.
https://github.com/aceat64/EasyBitcoin-PHP

====================

The MIT License (MIT)

Copyright (c) 2013 Andrew LeCody

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

====================

// Initialize Bitcoin connection/object
$bitcoin = new Bitcoin('username','password');

// Optionally, you can specify a host and port.
$bitcoin = new Bitcoin('username','password','host','port');
// Defaults are:
//  host = localhost
//  port = 8332
//  proto = http

// If you wish to make an SSL connection you can set an optional CA certificate or leave blank
// This will set the protocol to HTTPS and some CURL flags
$bitcoin->setSSL('/full/path/to/mycertificate.cert');

// Make calls to bitcoind as methods for your object. Responses are returned as an array.
// Examples:
$bitcoin->getinfo();
$bitcoin->getrawtransaction('0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098',1);
$bitcoin->getblock('000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f');

// The full response (not usually needed) is stored in $this->response while the raw JSON is stored in $this->raw_response

// When a call fails for any reason, it will return FALSE and put the error message in $this->error
// Example:
echo $bitcoin->error;

// The HTTP status code can be found in $this->status and will either be a valid HTTP status code or will be 0 if cURL was unable to connect.
// Example:
echo $bitcoin->status;

*/

class Bitcoin {
    // Configuration options
    private $username;
    private $password;
    private $proto;
    private $host;
    private $port;
    private $url;
    private $CACertificate;

    // Information and debugging
    public $status;
    public $error;
    public $raw_response;
    public $response;

    private $id = 0;

    /**
     * @param string $username
     * @param string $password
     * @param string $host
     * @param int $port
     * @param string $proto
     * @param string $url
     */
    function __construct($username, $password, $host = 'localhost', $port = 8332, $url = null) {
        $this->username      = $username;
        $this->password      = $password;
        $this->host          = $host;
        $this->port          = $port;
        $this->url           = $url;

        // Set some defaults
        $this->proto         = 'http';
        $this->CACertificate = null;
    }

    /**
     * @param string|null $certificate
     */
    function setSSL($certificate = null) {
        $this->proto         = 'https'; // force HTTPS
        $this->CACertificate = $certificate;
    }

    function __call($method, $params) {
        $this->status       = null;
        $this->error        = null;
        $this->raw_response = null;
        $this->response     = null;

        // If no parameters are passed, this will be an empty array
        $params = array_values($params);

        // The ID should be unique for each call
        $this->id++;

        // Build the request, it's ok that params might have any empty array
        $request = json_encode(array(
            'method' => $method,
            'params' => $params,
            'id'     => $this->id
        ));

        // Build the cURL session
        //$curl    = curl_init("{$this->proto}://{$this->host}:{$this->port}/{$this->url}");
        $curl    = curl_init("{$this->proto}://{$this->username}:{$this->password}@{$this->host}:{$this->port}/{$this->url}");
        $options = array(
            //CURLOPT_HTTPAUTH       => CURLAUTH_BASIC,
            //CURLOPT_HTTPAUTH       => TRUE,
            //CURLOPT_USERPWD        => $this->username . ':' . $this->password,
            CURLOPT_RETURNTRANSFER => TRUE,
            CURLOPT_FOLLOWLOCATION => TRUE,
            CURLOPT_MAXREDIRS      => 10,
            CURLOPT_HTTPHEADER     => array('Content-type: application/json'),
            CURLOPT_POST           => TRUE,
            CURLOPT_POSTFIELDS     => $request
        );

        // This prevents users from getting the following warning when open_basedir is set:
        // Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set
        if (ini_get('open_basedir')) {
            unset($options[CURLOPT_FOLLOWLOCATION]);
        }

        if ($this->proto == 'https') {
            // If the CA Certificate was specified we change CURL to look for it
            if ($this->CACertificate != null) {
                $options[CURLOPT_CAINFO] = $this->CACertificate;
                $options[CURLOPT_CAPATH] = DIRNAME($this->CACertificate);
            }
            else {
                // If not we need to assume the SSL cannot be verified so we set this flag to FALSE to allow the connection
                $options[CURLOPT_SSL_VERIFYPEER] = FALSE;
            }
        }

        curl_setopt_array($curl, $options);

        // Execute the request and decode to an array
        $this->raw_response = curl_exec($curl);
        $this->response     = json_decode($this->raw_response, TRUE);

        // If the status is not 200, something is wrong
        $this->status = curl_getinfo($curl, CURLINFO_HTTP_CODE);

        // If there was no error, this will be an empty string
        $curl_error = curl_error($curl);

        curl_close($curl);

        if (!empty($curl_error)) {
            $this->error = $curl_error;
        }

        if ($this->response['error']) {
            // If bitcoind returned an error, put that in $this->error
            $this->error = $this->response['error']['message'];
        }
        elseif ($this->status != 200) {
            // If bitcoind didn't return a nice error message, we need to make our own
            switch ($this->status) {
                case 400:
                    $this->error = 'HTTP_BAD_REQUEST';
                    break;
                case 401:
                    $this->error = 'HTTP_UNAUTHORIZED';
                    break;
                case 403:
                    $this->error = 'HTTP_FORBIDDEN';
                    break;
                case 404:
                    $this->error = 'HTTP_NOT_FOUND';
                    break;
            }
        }

        if ($this->error) {
            return FALSE;
        }

        return $this->response['result'];
    }
}
?>

Thanks in advance.

Is Bitcoin running in RPC mode on both computers? What port do you have Bitcoin configured to use for RPC?

I resolved it using bitcoind commands -server -rpcuser -rpcpassword

don't know why on windows either with bitcoin-core or bitoind I cannot update and set the bitcoin.conf file. It is always ignored

Are you putting the bitcoin.conf file in the right place? Are you restarting Bitcoin between attempts to configure it? Can you use -conf at command line to manually set the path to the configuration file?

I already did all of that hundreds of times ...

@smoumou Do you literally mean you added "-rpcuser" and "-rpcpassword" by themselves as command line options?  Or do you mean that you put the actual username and password?  Or the options followed by the username and password?  I searched and don't see any documentation on those command line options so not sure how I should implement them to fix the same 401 problem.

$bitcoin = new Bitcoin("rpcuser","rpcpassword","localhost","80");
Port 80 is HTTP - it should be 8332 (or 18332 for testnet) unless you have set another RPC port in the configuration file

I tried several ports : 8332 8333 80


text:
Do I need to pay taxes if I sit on (do not use) bitcoins?
I've done some reading on the IRS bitcoin guidelines and I'm a bit confused how the capital gains taxes works. If I buy some bitcoins in Jan, the value of the bitcoins double by the of the year but I still keep them, do I need to pay a tax on those? Or do I only need to pay tax if I buy something with them/convert them to fiat?
I'm in the USA by the way.

No. Assuming you are not a miner or receiving bitcoin in exchange for services, there are no taxes that you need to pay on the bitcoins until you sell or transfer them. When you sell or transfer them, you need to pay taxes on the difference between the value of the bitcoins and your tax basis in the bitcoins.
The value of the bitcoins would be what you sold them for if you sold them. If you traded them or did not get full value for them the value for tax purposes is their fair market value.
Your basis in the bitcoins is what you paid for them. If you mined them, it's probably their value at the time you acquired them assuming you treated them as income. Otherwise, it gets complicated. (In particular, you should either treat your basis as zero or consult a tax professional if you sell or otherwise dispose of bitcoins you received as a gift!)
If you held the bitcoins for more than a year, this is a long term capital gain. If you acquire and sell bitcoins on a regular basis, the rules get tricky for which sells you have to match to which buys.
I am not a lawyer. Please check with your own tax professional if you need advice you can rely on.

This answer needs an update now that the IRS rules have changed in 2018.

@JoseCifuentes I don't think there's any change that affects this answer. Am I missing something?

I read this post from Turbotax:
https://ttlc.intuit.com/questions/4138638-how-do-i-report-cryptocurrency-mining-income
It looks like the simple action of mining is a taxable event, even if you don't sell and just hold the coins. For example, if I mine throughout the year and hold, I still have to pay taxes for that year based on the coin prices on the dates they were mined.

No, but you do need to keep track of how much they were worth when you bought them. Then, once you sell them or trade them for goods or services, you pay taxes on the profit.
So, for example, if you bought BTC at $400, then sold them at $450, you pay tax on the $50 difference, because you made a profit.
If you lost money in the transaction, there is no profit, there fore there is no tax. This is because BTC is treated as property, not currency.
If the transaction is under $600 they do not care about the tax.
The whole rule set is pretty short, it sounds like they did not know how to proceed with BTC and threw something together quickly.
This all assumes that you wish to operate within existing tax law. BTC of course makes operating outside the tax system very easy, that is an ethical choice you need to make for yourself.
If you wish to get out of fiat, and never report anything after the purchase, but you still feel obligated to pay taxes, you could pay the tax on the full purchase price and then be done with it, but that again is an ethical choice.  Bitcoins, when used correctly with TOR and purchased without a paper trail in cash, are for practical purposes untraceable. Whether to engage with the tax system at that point is purely an ethical matter, since you have no reasonable expectation of getting caught.
We all know there is a lot of corruption in government, and much of your tax dollars are probably wasted outright, or spent on things with which you disagree. However, our taxes fund everything from the roads we drive on to the parks we use, to the retirement check you will get, to the underfunded schools which we use to educate children.
Sort that out within your own mind. Up to you.

you don't need to pay any tax on your bitcoins, simply sell them for cash, and no one can even prove you had any bitcoins in the first place. there are a lot of people willing to buy BTC in exchange for cash.

Even if you sell Bitcoins for cash, you are still required to pay tax on your capital gains.  If you don't, you're committing tax evasion, a federal felony.  It might be somewhat more difficult to catch you if you use cash, but it's never impossible.


text:
Transaction with Multiple Inputs having Same Address
Why do transactions have multiple inputs with the same address? Is it because the amounts were obtained in the address through multiple separate transactions. Shouldn't the amounts be clubbed to a single input since the addresses are the same. An example is this one.
Shouldn't the inputs be 1LS1h8UJFgAFqRsw8WqjszBdJWDQg3hj6d with 0.01580432 BTC instead of repeating the same address with 0.00396188 BTC and 0.01184244 BTC.

While the question is different, my answer here explains why the inputs don't collapse: Can receiving money make a transaction fail?

@Murch From your answer, UTXOs having the same address don't merge together since they are still distinct on their transaction indices.

Yeah, they are tuples of (txid, vout), where the first refers to the transaction the UTXO originated from, and the latter gives the position in the output list. The address isn't part of the UTXO identity. It only defines who will be able to spend the UTXO as it restrains what signature would be valid.

On second thought, I made this an answer. :)

The UTXO that are being used as inputs are tuples of (txid, vout), where the former refers to the transaction the UTXO originated from, and the latter gives the position in the output list.
The address isn't part of a UTXO's identity. It is part of the content, defining who will be able to spend the UTXO as it restrains what signature will be valid.

The transaction output list will have to be stored with an ordering in the ledger. Why not specify it as a (txid, address) tuple?

That wouldn't be guaranteed to be unique. You could have multiple outputs in one transaction to the same address. Also, there are other types of transactions that don't use an address to identify the recipient.

Inputs do not refer to addresses, but rather unspent transaction outputs (UTXOs).  If there are multiple UTXOs payable to the same address, then a transaction spending those UTXOs will have to list them individually, and cannot lump them together into a single input.  The fact that all the UTXOs are payable to the same address doesn't matter; they still need to be listed as inputs separately.

This was a design decision in Bitcoin. Bitcoin makes transaction outputs primary and makes addresses essentially a convenience with no real notion of an account. Other systems make the opposite decision. For example, Ripple makes accounts primary and transactions adjust account balances. There are advantages and disadvantages to each model.

@DavidSchwartz Interesting, could you please elaborate on the pros and cons of the two models here.

In the transaction you just listed 1LS1h8UJFgAFqRsw8WqjszBdJWDQg3hj6d is both an input and a change address.
Most of the transaction funds were sent to 187SRqCeXctTbfaqErNqUN5kDzv2PjHVeQ and the rest went back to 1LS1h8UJFgAFqRsw8WqjszBdJWDQg3hj6d
with 0.01580432 BTC, https://blockchain.info/tx/4d3ec229677ec9f6bf2a85c57c691bc648e7f4911453d3167a2e8d2fed44dc94
This is a bad practice for privacy reasons. Someone watching can tell that the sender controls 1LS1h8UJFgAFqRsw8WqjszBdJWDQg3hj6d (used as input and change address).
If no address reuse was present then someone could not tell which was the destination address and which was the change address.
Always create new addresses for change.


text:
Specification of Transaction Inputs - Bitcoin vs Ripple
In Bitcoin, the transaction inputs (UTXOs) are specified as a tuple (transaction index, vout) since there is no notion of an account in the bitcoin system and the address (pointed to by vout) alone would not be sufficient. Instead transactions are primary entities.
Ripple on the other hand makes an account a primary entity with transactions changing the account balance. This makes it possible to specify the (account) address alone as an input to a transaction.
These are design decisions. What are the pros and cons of the two models? What was the motivation behind them?

Nit: vout is just the index of an output in the output list of a transaction. It's just an integer. The address is part of the output script that is contained in the UTXO. The tuple that you are referring to is the unique identifier of a UTXO, not the complete UTXO.

Advantages of UTXO/blockchain approach:

You don't have to pay to addresses that refer to accounts. Transactions can pay to unique rules or conditions that can exist only as the rule to claim a particular transaction output.
Transactions are more independent in execution, not contending for access to the same account structures.
All you need to know about a transaction is that it succeeded. There's no "additional information" such as the previous balance and the new balance.

Advantages of account/ledger approach:

Accounts exist as primary structures and so can have properties, both persistent/configured and dynamic/reported.
Transactions are more independent in formation, not contending for access to the same transaction outputs.
There is no UTXO database to maintain and synchronize and attacks on the UTXO set do not work. (Though there are other ways you can defend against attacks of this type.) More sophisticated transactions can be supported without creating the risk of disagreement on the UTXO set.

Bitcoin's design naturally fits the UTXO approach. Transaction results are simple, and there's no need for account parameters.
That approach would not have worked in Ripple for a variety of reasons:

Because Ripple supports arbitrary assets, many of which can be worthless, there has to be a way for recipients to indicate which assets they'll accept as payment. This means something has to have that as a property, which requires an account.
Something has to issue those assets, which requires accounts to act as issuers.
Cross-currency payments can produce complex results, trying to map those deterministically onto UTXO operations is not a natural fit. Adjusting an account's balance is simpler than choosing UTXO's to consume and create at transaction processing time. Ripple's transactions could not have, for example, specified which UTXOs they'd consume because that isn't known at transaction formation time. (How do you know know who will offer the best rate when your transaction executes? If everyone competes with transactions hardcoded for the juiciest liquidity, the majority of transactions will fail.)
The more complex network state requires a more complex structure to ensure the network agrees on that state. Bitcoin's structure has no way to protect against UTXO divergence, which would be catastrophic, other than keeping transactions simple enough that a mistake of this type is unlikely. Ripple's more complex transactions need a powerful defense against divergence or small bugs in the code could cause catastrophic results.
Because Ripple transactions have more complex outputs, they tend to be larger. Ripple's approach makes it easier to discard transaction history because all you really need is the current status of all accounts and other persistent structures.

You can pretty much meet any requirements with either approach. There are ways to work around each of these issues without changing the approach. But it's often easier to start with the design that most naturally fits your requirements, rather than shaving and jamming to get a round peg into a square hole.


text:
How much bitcoin can be mined with intel core i5 pc with external graphic card?
I know ant miner is required to earn some cash, but am curious to know that how much bitcoin can be mined per day with a pc if it has the configuration like :
processor= Intel Core i5 6600K 3.50GHz 6th Gen. Processor
motherboard= MSI B150M Mortar DDR4 6th Gen. LGA1151 Socket Mainboard
ram= Twinmos 8GB DDR4 2400 BUS
graphics card= MSI GTX 950 2GB
-Thanks.

It is effectively zero. The days of GPU mining are long past, sorry.

sorry to know that, so the x11 coins can be mined beside cryptonote coins ?

Less than the money that it will cost to you for sure.
I think It would take you a bunch of nights to get the minimun to get paid by the mining pool so you could even earn 0 Bitcoins.


text:
Are crypto tokens a subset of cryptocurrencies?
I'm having a little bit of trouble with these terminologies regarding some crypto assets. From what I understand, cryptocurrencies are the superset; i.e. both crypto coins and crypto tokens are different types of cryptocurrencies. But there are many sites that consider tokens to be different from cryptocurrencies; i.e. they only consider crypto coins to be cryptocurrencies.
Which is correct?

I don't think you will get a consistent answer on this. I would say cryptocurrencies are intended to be used as a currency (e.g. Bitcoin) in the broader economy to exchange and transfer value. They aren't attached to a particular use case (e.g. decentralized storage, messaging, browser usage) or "equity" in a particular business model or protocol. In these cases I would call the asset attached to the blockchain a token rather than a cryptocurrency. We don't call fairground tokens or shares in a company (e.g. Apple) "currency" in the conventional economy.
For some historical context there was a ICO (Initial Coin Offering) craze in 2017 where a number of projects (Filecoin, Tezos, Kik etc) raised tens or hundreds of millions of dollars for tokens you would need to use their incomplete protocols. Almost without exception these turned out to be terrible investments.
The latest thing venture capitalists are very enthusiastic about is NFTs (non-fungible tokens). In this case you purchase a token representing ownership in digital art (e.g. a jpeg). Digital art is easily replicable and these NFTs do not represent anything legally (no copyright or trademark rights).


text:
What is the backup plan for the social organization surrounding Core development?
The question of GitHub alternatives has been raised and closed. Alternative, backup repos exist.
That said, I have not seen any contingencies for planning the social move to those repos and organizing developer efforts for maintaining Core in the face of a GitHub ban.
It seems inevitable, given the recent experiments with banning individual developers or entire projects.
Existing guidelines for contributing to Core seem to exclusively revolve around GitHub.

Contributing to Bitcoin Core
A Gentle Introduction to Bitcoin Core Development
Bitcoin Core PR Review Club

In the event of GitHub banning Core maintainers or Core itself, where do developers gather to communicate and collaborate for reliable development and maintenance of Bitcoin?

laanwj already wrote about GitHub being a risk, almost two years ago, if not any earlier

To date GitHub has restricted developer accounts from Iran, Crimea, Cuba, North Korea and has taken down certain projects (e.g. an Ethereum open source privacy project Tornado Cash though Tornado Cash is now back up). GitHub is owned by a US corporation (Microsoft) and is clearly at a minimum bound by US law and US sanctions. There seems to be evidence that it is willing to take actions beyond what it is required by US law and US sanctions though as you suggest.

I have not seen any contingencies for planning the social move to those repos and organizing developer efforts for maintaining Core in the face of a GitHub ban.

No such plans have been made public as far as I'm aware. Recall that no maintainer or no contributor can bind the project to a particular future contingency plan even if they drafted such a plan.

It seems inevitable, given the recent experiments with banning individual developers or entire projects.

It is certainly a possibility but I would say "inevitable" is a bit strong. The best case scenario is GitHub realized that taking down Tornado Cash was an error, reversed that decision and won't pursue similar actions in future for other privacy projects, let alone full node implementations. The worst case scenario is GitHub takes down Bitcoin Core, all other Bitcoin open source projects and restricts the accounts of maintainers and contributors to these projects. Clearly if the worst case scenario happens a plan will have to drafted and executed but I suspect most maintainers and contributors have their fingers crossed that it won't get much worse than the best case scenario. I don't know of any long term contributors that have been impacted by the Iran, Crimea, Cuba, North Korea etc restrictions.
So thus far the GitHub actions haven't caused enough pain on the project to motivate a serious effort to plan for a move away from GitHub. I'm not saying that this is right or wrong, merely that that's the reality. It would be a headache to execute (choosing the replacement, updating docs, potentially worsening the new contributor experience) and many contributors like the convenience, user interface and funding initiatives on GitHub. If the pain increases and we start to move closer to the worst case scenario and away from the best case scenario I am sure we will see more activity and interest in this area.

In the event of GitHub banning Core maintainers or Core itself, where do developers gather to communicate and collaborate for reliable development and maintenance of Bitcoin?

It would most likely be discussed on Libera IRC (#bitcoin-core-dev channel), the Bitcoin dev mailing list and Bitcoin Core dev mailing list. Bitcoin Optech and bitcoincore.org would also be possible sources of information.
Disclaimer: This is just my personal view, no one can speak for the Bitcoin Core project (and certainly not me) but I hope this is somewhat helpful.
This topic was also discussed at the recent Core dev meeting (Bryan Bishop transcript).

I appreciate your view and acknowledge your disclaimers. I suppose I'm surprised there isn't more urgency in the ecosystem to preempt these possibilities.
"Clearly if the worst case scenario happens a plan will have to drafted and executed"
E.g. wouldn't it be a worse headache - with higher chance of failure - to draft a plan after the worst case has already happened?
It seems like a mismatch to aspire for extraordinary development in financial freedoms while crossing fingers that those entrenched in the existing system will not take extraordinary measures to fight back.

Think through what happens though. The Core GitHub repo is taken down which throws a wrench into the opening of PRs, review of PRs, merging of PRs. Still possible to do these things via maintainers but more friction, will take longer to get comparable amounts of review etc. Possibly the release schedule is pushed back until the project is back up and running elsewhere. Users can still run old versions of Core. The central repo can get taken down for weeks or possibly even months and this doesn't disrupt mining or the validation of the network nodes.

The only really concerning scenario would be if a consensus bug was discovered, an emergency fix was required and GitHub took down the repo at the same time making it harder to distribute the release. Otherwise it is just a pain and disrupts the project for a few weeks.

That's a great point about the existing versions of Core being unaffected. I don't think I was considering that sufficiently in my premise. In the same spirit as your hypothetical bug+takedown, I do think malicious actors could leverage the delay and chaos following a GH ban to launch attacks of varying severity. Such as media disinfo campaigns, impersonating known devs on other platforms, promoting falsified repos, and so on. This could all be countered, as well, though, and I might be leaving the scope of this premise and platform if I try for every imaginable threat scenario. Cheers.


text:
Bitcoin Transaction Builder in Python
is there a python code that helps build raw bitcoin transactions (Legacy and Segwit)?
I have seen javascript but not in python.

Have you tried python-bitcoinlib? https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2pkh-txout.py

hey, thanks! Peter Todd, sounds very familiar...


text:
Why do we need electrs or electrumx alongside bitcoin-core?
I'm running a full bitcoin node. No pruning. Two primary use cases:

Parse the most recent block and all the transactions in it
Fetch any given address balance

Both these can be achieved by just the bitcoind service and using its RPC methods. Coming to the question, why has the community built electrumx, electrs on top of it? I read they make some queries faster. But none of them explain which queries and how much of an efficiency improvement over just running bitcoid.

Fetch any given address balance

This cannot be done with Bitcoin Core. ElectrumX and electrs are examples of software that maintain an address index, which is a database that allows the lookup of the transactions, balance, UTXOs, etc. of any address. Bitcoin Core does not have an address index, and so it cannot be used for any task which requires fast lookup of this information.
You may see RPCs in Bitcoin Core which seem like they would allow for the arbitrary address information lookup. However these are often wallet RPCs and can only do these lookups for anything that the loaded wallets own, not any arbitrary address. There are also some RPCs that can compute this information as needed, but these end up being very slow and so unusable for the tasks that external address indexes are often used for.

Thank you! I have another follow-up. Do you think arbitrary tx lookups are also too slow via bitcoind RPC getrawtransaction? I have txindex enabled in the config. My node would crash after some time as it ran out of memory (because I was quering 5k txns every few mins in 5 batches of 1k). So doubled the memory. It hasn't run out yet, but I'll test it for another week.

getrawtransaction is relatively fast if you have txindex enabled (much faster than scantxoutset or rescanning), but whether it's fast enough for your particular purpose is something only you can assess.

You may also check out this somewhat related question, for details on the problems of using Bitcoin Core to retrieve the balance of an arbitrary address:
https://bitcoin.stackexchange.com/questions/116263/obtaining-balance-utxos-of-an-address-from-bitcoin-core-blockbook-or-some-othe


text:
Create Custom script from bitcoind
I'm able to create multisig with bitcoin-cli with addmultisigaddress
bitcoin-cli addmultisigaddress 2 '["'$ADDR_MITT_1'","'$ADDR_MITT_2'","'$ADDR_MITT_3'"]'

But How can I add extra OP like CLTV or another OP? Can I use bitcoin-cli to generate redeemscript and address?

You cannot. Bitcoin Core cannot reason about arbitrary scripts and does not have the capability to sign for them. As such, it cannot create arbitrary scripts and store them.
You can create the script yourself and import it into a wallet using importmulti. This will only add the script to the wallet to be tracked. This will only let your wallet see transactions and compute a balance. Again, Bitcoin Core cannot sign for arbitrary scripts, it does not know how to. So importing a script does not mean that the wallet will be able to sign transactions that use that script. It is purely for transaction tracking.

what are the standard script? P2PK P2PKH and so on? https://bitcoin.org/en/transactions-guide#standard-transactions

The scripts that Bitcoin Core can reason about are P2PK, P2PKH, Multisig, P2WPKH, P2SH containing the previous scripts, P2WSH containing the previous except P2SH (P2SH cannot be contained within a P2WSH).

nice and with these address I can use signrawtransactionwithkey? instead with customscript I need to create signature by hand?

Yes. With custom scripts you will need to sign and construct the final scriptSig by hand.


text:
Redeem script. script hash, witness script and witness program
I have a little confusion about naming in Bitcoin.
Redeem script is the conditions that will be satisfy.
For example P2PKH inside P2SH
OP_DUP OP_HASH160 <PubKHash> OP_EQUALVERIFY OP_CHECKSIG == redeem script

In P2SH-P2WPKH the redeem script is:

The P2SH redeemScript is always 22 bytes. It starts with a OP_0,
  followed by a canonical push of the keyhash (i.e. 0x0014{20-byte
  keyhash}).

Sometime It call script hash, and during the transaction I need to insert the redeem script in witnessScript. "witnessScript": "hex",    (string) (required for P2WSH or P2SH-P2WSH) witness script
Then the redeem script in segwit environment is called redeem script, script hash or witness script?
Witness program

A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes gets a new special meaning.

Witness program depends on script could be scriptPubkey or redeem script?

The scriptPubKey is the script as it is placed in the transaction output.
The redeemScript (P2SH only) is the script pushed as the last scriptSig item. In P2SH scripts, the scriptPubKey is equal to OP_HASH160 <Hash160(redeemScript)> OP_EQUAL.
The witness script (P2WSH only) is the script in the last witness stack position.
The witness program is Hash160(pubkey) for P2WPKH, and SHA256(witness_script) (not Hash256(witness_script)!) for P2WSH. For native segwit outputs the scriptPubKey is OP_0 <witness_program>; for P2SH-wrapped segwit outputs the redeemScript is OP_0 <witness_program> (and thus the scriptPubKey is OP_HASH160 <Hash160(OP_0 <witness_script>)> OP_EQUAL.

In P2SH-wrapper is OP_0 <witness_program> where OP_0 is the witness version?

Yes, indeed. The OP_0 is the witness version. So far only witness v0 is defined.

the fourth bullet point. The witness program is Hash160(pubkey) for P2WPKH, and Hash256(witness_script) for P2WPKH maybe I think you mean The witness program is Hash160(pubkey) for P2WPKH, and Hash256(witness_script) for P2WSH ?

Yes indeed, fixed.

@PieterWuille I caught what monkeyUser caught too. It doesn't look like the post has been edited with the fix.

Now actually fixed. It's SHA256 too, not Hash256.


text:
Is Whirlpool safe to use?
Looking to potentially run a CoinJoin via Whirlpool in sparrow but am confused how the safety of my funds is guaranteed. While the documentation states that I 'retain full ownership of my funds at all times' I am confused how this is actually the case. It is required that I use a hot wallet to execute, so that Whirlpool can sign the mixing transactions, but I am confused re: safety as a result.

If Whirlpool can sign the mixing transaction couldn't they also sign a txn to a different wallet?
How is ownership retained at all times?

Note: I understand Whirlpool and Sparrow are FOSS but I am not technically sophisticated enough to read through/compile/analyze the code myself to answer these questions.

Whirlpool (and Chaumian Coinjoin in particular) creates a new transaction where your coins are mixed with other users coins while allowing you to ensure you receive the same amount of coins out of the transaction that you put into the transaction (less transaction fees, of course).
The Samourai Wallet team documents how their implementation works quite nicely here.  From that page:

Chaumian CoinJoin was briefly described by Maxwell:
Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.
Simplified workflow:

User provides its input and a blinded output to the Tumbler.
Tumbler signs the blinded output and gives it back to the User.
User unblinds the signed blinded output and provides the server the signed output through a different anonymity network identity.
The Tumbler constructs the CoinJoin transaction and gives out to the Users for signing.

Every mix via Chaumian CoinJoin comes with a guarantee that Tumbler can neither violate anonymity, nor steal bitcoins. Furthermore Chaumian CoinJoin is by no means complex. Its simplicity allows it to be one of the most, if not the most performant on-chain mixing technique. A mixing round can be measured in seconds or minutes.


text:
How can I determine the address from a private key?
From the steps in the wiki, take this example private key:
0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

When I import this into Electrum, I find these values:
Address:
1GAehh7TsJAHuUAeKZcXf5CnwuGuGgyX2S

Public Key:
04d0de0aaeaefad02b8bdc8a01a1b8b11c696bd3d66a2c5f10780d95b7df42645cd85228a6fb29940e858e7e55842ae2bd115d1ed7cc0e82d934e929c97648cb0a

How can I determine the address from the key (without using Electrum)?
I understand that the derivation route is private key -> public key -> address, so I've found a way to generate the public key in Java using BitcoinJ:
BigInteger privkey = new BigInteger("0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D", 16);
byte[] bytes = org.bitcoinj.core.ECKey.publicKeyFromPrivate(privkey, false);
String publickey = new BigInteger(1, bytes).toString(16);
while(publickey.length() < 130){
    publickey = "0" + publickey;
}
Log.d("public",publickey);

It gives the correct public key as shown above, so I just need to find a way to get the address.
I don't know much about different address formats, but my goal is to use the address to check the balance using some public API like blockchain.com. I guess this is the P2PKH-type address.
I tried this:
NetworkParameters params = MainNetParams.get();
ECKey key = ECKey.fromPrivate(privkey);
String address = LegacyAddress.fromKey(params, key).toString();
Log.d("address",address);

Which gives me this address:
1LoVGDgRs9hTfTNJNuXKSpywcbdvwRXpmK

But the address is different.

Do you mean 1... address, that is compressed or uncompressed, or a SegWit native (Bech32) address or SegWit nested legacy compatible 3... adress. Or even an m-of-n multisig address? If you just want an address, this should help: https://gobittest.appspot.com/Address The link to the answer is in your question, how can we help? Where are you stuck?

@MCCCS I added more details, but I want to do it programatically in Java

Does this help: https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/java/org/bitcoinj/examples/PrivateKeys.java#L58-L62 ?

@MCCCS I tried it but it gives a different address with a different balance, so I assume it's an unrelated address. I added my code above

Both "1LoVG.." and the other one are valid legacy (1...) addresses made using the same private key. They are different since one of them uses the compressed public key (you might want to look this up) while 1GAehh7 uses the uncompressed public key. Always use the same compress-format for an address, and it's advisable to create new addresses in compressed format since it saves bytes and transaction fees.
To make the uncompressed-public-keyed address (compressed is the default in BitcoinJ):
ECKey key = ECKey.fromPrivate(privkey);
key = key.decompress();
String address = LegacyAddress.fromKey(params, key).toString();


text:
Having trouble creating a Python function that creates non-hardened HD wallet child keys
I am coding my own keys (not for use in production, strictly for learning). I am successfully creating 512 bit seeds from mnemonic phrases, however I am failing at the step of deriving child keys from these seeds. For reference I am using the following post for testing:
https://learnmeabitcoin.com/technical/hd-wallets
What I will do is use that site to generate mnemonics for me, then using the seed I try to match the child keys in the Child Keys (Basic) section, to no avail. For instance, I have the following phrase:
lash afraid any alter object topic pony deer helmet favorite chuckle carpet

which matches the seed and keys in the post:
Extended key: e8448e8e6ac4ce400951f6d630a0963c40b263208dacee0c53b3a3ccf8be9a1540434b626e34b82f28e4fb60842d5a5470e2f8cc2777a559a3c68ac4e9f2559d
Private key: e8448e8e6ac4ce400951f6d630a0963c40b263208dacee0c53b3a3ccf8be9a15
Chain code: 40434b626e34b82f28e4fb60842d5a5470e2f8cc2777a559a3c68ac4e9f2559d
Public key: 03cf895293b95a0ce2457593b82cc6fd646c757a1e2d393932b70dafddc2d9553b

Here is where I am getting tripped up. My rough python function looks like this:
def create_child_keys(chain_code, public_key, children):
    for n in range(children):
        hex_child_index = hex(n)[2:].zfill(8)
        print(hmac.new(bytes.fromhex(chain_code), msg=bytes.fromhex(public_key + hex_child_index), digestmod=hashlib.sha512).hexdigest())

create_child_keys(extended_key, 3)

This returns different hashes for the first 3 children than the link posted above. For instance, according to learnmeabitcoin the first child should have a private key of:
d547eda1f3d7da655cafec4506d3e333f1add4415968b1994f30bd64b023e2d3

but mine is:
c9dd74741e44fbd9e763f47829f37d1b2165a5ad6e90697c719d95489c409326

Hoping something obvious stands out to those more familiar with this process.

Check out a python implementation here https://github.com/mcdallas/cryptotools/blob/df233dc50cb8adbf28eeff075fa9026626c598d6/cryptotools/BTC/HD/bip32.py#L132-L149

@MikeD Thanks for this! As far as I can tell this code is validating my code - so maybe learnmeabitcoin is erroneous? The code I used to validate, with a print statement in the child method for "I":
m = Xprv.from_mnemonic('flash afraid any alter object topic pony deer helmet favorite chuckle carpet')
print('code:', m.code.hex())
print('msg:', m.key.to_public().encode(compressed=True).hex())
print('index 0:', int_to_bytes(0).rjust(4, b'\x00').hex())
m.child(0)
I'll show print logs in another comment, but they match my findings and not the ones from learnmeabitcoin.

code: 40434b626e34b82f28e4fb60842d5a5470e2f8cc2777a559a3c68ac4e9f2559d
msg: 03cf895293b95a0ce2457593b82cc6fd646c757a1e2d393932b70dafddc2d9553b
index 0: 00000000
child hash: c9dd74741e44fbd9e763f47829f37d1b2165a5ad6e90697c719d95489c40932608b25a850dc4eec62c74bae84b53cfa13ec4dadfa6a9fddd99a73e9de778ee9e

I figured out my issue. I don't know if I'm missing something with the results in learnmeabitcoin, but instead I started using test vectors from the Bitcoin wiki:
https://en.bitcoin.it/wiki/BIP_0032_TestVectors
The results from my python function above match the unhardened tests from that link. One thing I was forgetting to do was to add the master private key with the left 256 bits of the child hash to generate the child private key. I was able to achieve this by storing the above function in variable child_hash, then ran the following:
child_left_hash = child_hash[:64]
child_chain_code = child_hash[64:]
child_private_key = hex(int(child_left_hash, 16) + int(master_private_key, 16))[2:]


text:
Where can I find (free) "deep-dive" materials related to Taproot?
I'm not sure how much bitcoin stack exchange is really meant for questions like this (this is probably more for reddit) but maybe someone can help me. I'm totally fine if the question is closed.
Namely, I'm wondering if any of you have any material that can explain everything related to taproot in the smallest details ("deep dive to taproots")? Something similar to how the Bitcoin Master book explains all the other aspects of bitcoin, so some material that explains taproot in minute detail?

This is a non-exhaustive list but these are some of the best resources to get started:

Bitcoin Optech Preparing for Taproot series
Bitcoin Optech Taproot workshop
Bitcoin Optech Taproot workshop videos
BIP 340: Schnorr signatures
BIP 341: Taproot
BIP 342: Tapscript

There are a number of presentations, transcripts out there for more accessible insights into Taproot than the BIPs including this presentation from Pieter Wuille at SF Bitcoin Devs in 2018 (thanks deyw) and this London BitDevs Socratic Seminar with Pieter Wuille and Russell O'Connor in 2020.
The Q&As on this StackExchange site (tagged taproot) are also a great Taproot resource.
The 3rd edition of Mastering Bitcoin (Antonopoulos, Harding) will cover Taproot and is expected in December 2023.


text:
Question about Bitcoin's Median Time Past
I was currently reading the book Mastering Bitcoin written by Andreas and was pretty confused about the concept called Median Time Past. Hopefully I can get some of your advice.
From my understanding, when creating a new block, its header time must satisfy two primary conditions:

It must be greater than the median time of the past 11 blocks
The time offset between itself and network adjusted time must be less than 2 hours.

This is what I understand about condition #1,  considering 11 blocks with their given header time :
#1 - created at time 1
#2 - created at time 2
...
#11 - created at time 11
When a block #12 is created, based on above rule it is possible to set its header time to 7.
If this happens continually, isn't it weird to have a block's header time going up and down like that ?
Thank you.

It is a bit weird, but it is simply not possible to have everyone's clocks be in sync, and so there must be leeway for a block to have a timestamp earlier than its predecessor. If my clock is a few seconds behind your clock, and I find a block 1 second immediately after yours, my block should not be rejected just because my clock is out of sync with yours. One of the primary purposes of the blockchain is to agree on a "time" (in the form of block height) when clocks cannot necessarily be in sync.
The MTP rule puts a lower bound on the timestamp of the next block. It is guaranteed to always move forward so it allows for time based locktime to work.

I understood that the purpose of MTP is to help reach a consensus on time, but I am still not able to imagine an example of it. Can you give me an example for a new block after 11 blocks with their specific time?

Could you explain why it would be necessary to sync the clocks here? If I find a block 1 second immediately after yours, then either I haven't seen your block (so one of them gets orphaned and the time difference doesn't matter) or I have seen your block and could easily adapt my blocks time to come after yours. Am I missing something here?

@MarcelKrüger: The timestamp on my block may also be incorrect, either because my clock is wrong or because I am trying to cause trouble.  Say I found my block at actual time 9:00, but used 9:45 as the timestamp.  Now you find the next block at 9:07.  Under the current rule, you can use 9:07 as the timestamp and get things back on track.  If timestamps were required to increase monotonically, you'd have to use 9:46 and the error would persist.

@JohnPham Suppose you have a sequence of blocks with the times: 1, 2, 3, 2, 5, 6, 7, 4,  8, 6, 9. The median of this is 5, so the next block must have a timestamp of 6 or greater.

@AndrewChow so supposed that the next block always have header time = MTP + 1, block #12 -> #16 will be [7, 8, 5, 9, 7, 10]. Isn't this conflict with the property that ?

@JohnPham No, MTP is the median, not just taking the timestamp of 6 blocks back. To be clear, in my example, the times are timestamps in the blocks, not their MTP. By taking the median, the order of the blocks does not matter, and so long as the timestamp is greater than the median, the MTP will monotonically increase.

Ahh I see, I always thought that median means taking the middle value without sorting the array. Thanks for your explanation man.

Are there any blocks in the chain that violate that rule?

Because clock of each node can be different with network adjusted time so the network must have a time gap to accept the block timestamp. In your question, your timestamp definitely could be in the past, but must have a limit of late so the network is not be effected to heavy. And this limit is the median time of the past 11 blocks. It implies your timestamp can be maximum in the block 7 in your example. If your timestamp make your block in the 6th, your block will invalid.
Although it's weird, but it's necessary for the safety of the netowrk :D

Thanks for your answer man, really took me time to understand this timing concept.


text:
Does Bitcoin have a legal expert/team that does their work?
Does Bitcoin have a legal expert/team that does their work? (yes, they - a group of interested individuals (the Bitcoin team) even though they have no formal association - are a decentralized network but some of those decentralized networks do have offices, etc., and may have a legal team.)
Are there any private individuals who have (ever) started an action on behalf of Bitcoin?

I'm not quite clear what you are asking.  Bitcoin isn't a "they", of course, and when you say "their work" I don't know what work you mean.  There are plenty of organizations who seek to promote the currency; perhaps the best-known is the Bitcoin Foundation, but there are others, and of course lots of private companies that provide Bitcoin-related services.  No doubt many of them have lawyers.

I suppose that a group of interested individuals (the Bitcoin team) even though they have no formal association could be 'they'. I will re-word a bit.

BITCOIN is a software ecosystem, and not owned by "someone". Similiarily you could put some code [echo "hello world"] on github, and it would be publicly available. Then there is also no "they", or an association managing the code. The bitcoin developpers are a group of loosely coupled "geeks/freaks", and anyone with a good skill set could belong to this group, by participating in coding/translating websides/correcting wording ... For sure you know that. So as this developer team provides (a highly sophisticated) software, they are not dealing with regulations from each country, in which the software could be used. But I think your point goes into this direction:
There are companies using this public domain ecosystem (kraken, bitfinex, hitbtc, bitcoin.de, blockchain.info). These companies (and some miners) provide ramp-ups and -downs, to make it easy for you and me to use the bitcoin eco-system. They are for sure under a jurisdiction, within their appropriate countries. And for sure "they" have legal/compliance teams, that deal with country specific regulations (aka "KYC/KYI/...").
Still I am not clear on what you suppose by "their work". I think it would be fair to say, Bitcoin doesn't need any work at the legal level. Countries and governments (or other power structures over individuals) need such things, so it is up to "them" (these power structures), to make sure, bitcoin is used in a way, that it complies with their rules of keeping tidal waves of change away from their protected environment :-)

"their work" - the work of a loosely associated group of individuals. I am not so concerned about Bitcoin that it might need legal defence. I am concerned about the actions of others, their offensive, misleading and deliberately deceptive tactics and what "Bitcoin" may be able to do about that. Actions of others that harm Bitcoin, harm Bitcoin's reputation and harm consumer, business and community understanding of Bitcoin. And, in those things, harm the value of Bitcoin, harming all holders of BTC and miners of Bitcoin in the process. I am considering an evangelical project...

If my wallet held 1000BTC I would have started several private actions already, in defence of "Bitcoin". I am not concerned by competition, I am concerned by offence.

ahh, I see, you want to have a protection of the efforts, that were spent into this technology. Good point! I am not aware, that there is some people doing this "actively". All the communication/events/forums for sure help, to spread the message (security, independency, reliability, future proof, fork protection, ...). This is not "coordinated" in a way, that I am aware of. That's what you're looking for?


text:
How to check OP_CHECKLOCKTIMEVERIFY?
I try to simply get into the OP_CHECKLOCKTIMEVERIFY opcode and test it. However I get the error
error: Locktime requirement not satisfied

no matter what unix- or blocktime I enter in my btcdeb. I wanted to check out another debugger, but for example the bitcoin IDE does not even know OP_CHECKLOCKTIMEVERIFY...
Can't I just run btcdeb '[<blocksometimeago> OP_CHECKLOCKTIMEVERIFY]'? I mean I know the the error should appear as long as the block- or unixtime isn't reached yet but even if I enter a block from years ago, I get the same error.
THANKS for your help in advance!
Edit: I JUST want to run the verification command, nothing else (no pubkey etc)!

OP_CHECKLOCKTIMEVERIFY verifies, as the name implies, the locktime. It does not verify the time.
In other words, it checks the transaction's nLockTime field against the value provided in the opcode. The current block height or time is irrelevant for the opcode directly.
Of course, the net effect of this opcode is restricting when the transaction can be mined. It does that through a 2-step restriction: the opcode restricts the possible values of the nLockTime field, and the nLockTime field on its turn restricts when the transaction can be mined.

Thank you! Do you have a source for an easy-to-understand documentation with concrete examples? I use this one, but it's tricky to understand from my point of view.


text:
C-lightning configuration to use bitcoin blockchain data from another machine
I currently run a lightning node on umbrel on a raspberry pi. I want to experiment with c-lightning and want to run a new c-lightning node on my ubuntu laptop which utilizes the blockchain data from my existing umbrel node.
Which files do I need to configure for that and in doing that do I reduce my umbrel node's security in any way?
Thanks in advance.

You need to put the following in your conf file and have Bitcoin Core installed on your Ubuntu machine too.
bitcoin-rpcuser=foo
bitcoin-rpcpassword=foo
bitcoin-rpcurl=http://127.0.0.1:18332

Core Lightning will use the bitcoin-cli to make a connection with your bitcoind on the other machine!


text:
Are attempts to spend from a timelocked UTXO rejected?
Background
I was reading a bit about Bitcoin time locked transactions within the context of the Lightning Network. One thing that was never explained is what happens when one tries to prematurely spend the output of a timelocked UTXO.
Example
Alice sends 1 BTC to Bob at address B via transaction T, Output 0. But the transaction is timelocked until the blockheight, currently at H, reaches H+100. So to spend T:0, Bob needs two things:

The private key corresponding to address B
Sufficient time such that the blockheight reaches H+100.

Bob is impatient and tries to spend T:0 when the blockheight H+30. He broadcasts the transaction.
Question
What happens to Bob's transaction? Do the miners ignore it and validators reject it since H+100 hasn't occurred yet? I had always assumed that's what happens; The transaction is simply discarded.
But in researching the Lightning Network, in which timelocked transactions play a key role, it's not unheard of for a channel peer to try and cheat his partner by broadcasting a timelocked TX from a prior state. It's actually up to the innocent party to see this transaction on the blockchain, and somehow use some of the data that's revealed in that transaction as an input their own penalty transaction. And furthermore, that penalty transaction must execute prior to the timelocked cheat transaction going through. And that's what I don't get. How does the innocent party even see this rogue transaction attempt if it's already been rejected by the miners and validators?
Or is my assumption that the miners reject transactions that are dependent upon a not-yet-hit timelocked input incorrect?

I'm going to only address the first part of your question, as I think the root of your confusion can be addressed there.
Time locking in Bitcoin refers to two related and interacting, but fundamentally distinct concepts:

Transactions can have a locktime. This is a per-transaction field (nLockTime) that determines roughly the earliest time or height when that transaction can be included in the chain. A transaction with a locktime in the future is not invalid; it's merely unacceptable for inclusion in the chain until said time passes. Most Bitcoin nodes today do not relay transactions unless they are eligible for mining in the next blocks.
Scripts can enforce a locktime using the OP_CHECKLOCKTIMEVERIFY opcode. That opcode requires that the spending transaction of that script have an nLockTime field not below a provided value. It does not interact directly with the time or height. All it does is require that the spending transaction restricts itself to the future, and a transaction without such nLockTime is unconditionally invalid and cannot ever be mined. The consequence is of course that this output cannot be spent until said time passes, but the relation is split in two.

This separation of the two has a number of advantages. It means that scripts only need to be run once; we don't need to re-run then every time the time/height changes to reevaluate whether they are still valid. It also means transactions cannot invalidate themselves as time passes - once valid (and acceptable to be mined), a transaction cannot become unacceptable unless double-spent.
So the answer to your question depends on how the transaction violates the timelock:

If the transaction has a too low nLockTime field, the transaction is just unconditionally invalid.
If the transaction has a correct nLockTime field, but its time hasn't come yet, the transaction isn't eligible for mining or relay, but when it time comes, anyone can broadcast it and get it mined.

Excellent info. Thanks for the reply!


text:
Problems with multiple wallets on RPC in bitcoin-core
I have been playing around a bit with Bitcoin Core (version 23.0), more specifically connecting to different wallets in Bitcoin Core through RPC in Python. I have found this library and tried to connect to my wallet(s) using this code:
from bitcoinrpc.authproxy import AuthServiceProxy

conn = AuthServiceProxy("http://myusername:mypassword@127.0.0.1:18332/wallet/testingwallet")
print(conn.getwalletinfo())

But when running this i get this stacktrace:
Traceback (most recent call last):
  File "/home/kebab/Desktop/pron/testing.py", line 24, in <module>
    print(a.getwalletinfo())
  File "/home/kebab/.local/lib/python3.8/site-packages/bitcoinrpc/authproxy.py", line 141, in __call__
    raise JSONRPCException(response['error'])
bitcoinrpc.authproxy.JSONRPCException: -18: Requested wallet does not exist or is not loaded

Though what I have noticed is that if i load the wallet using bitcoin-cli -testnet loadwallet testingwallet. Then i can run RPC commands but only get info from that wallet!
And I have created my wallet using: bitcoin-cli -testnet createwallet testingwallet
Any help on this would really be appreciated!

You have to load the wallet into bitcoin core before you can use it. So first, load all the wallets you want to use with bitcoin-cli loadwallet. To verify the loaded wallets, you can use bitcoin-cli listwallets
After you have loaded the wallets you can specify the wallet in the connection. The format is <RPC IP address>:<RPC port>/wallet/<wallet name>, for example https://127.0.0.1:8332/wallet/wallet1.dat.
Info from wiki https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)#Multi-wallet_RPC_calls and this discussion https://bitcointalk.org/index.php?topic=5398213.0


text:
How small can a payment be while still adding value to your wallet?
If you receive 1 satoshi (0.00000001 bitcoin) in a transaction then adding it as an input to a larger transaction would add more than 1 satoshi to the transaction fee. This means the 1 satoshi shows in the total balance for your wallet, but in reality it is not worth anything to you because it would cost more than 1 satoshi to spend. In fact if you need to empty the wallet completely then the 1 satoshi is causing a loss.
So how small can a payment be while still adding value to your wallet?

You generally would not be able to receive a single satoshi.
The Bitcoin Protocol defines something known as a "dust limit".
The exact value of this limit varies based on the receiving address type, but it is defined as the minimum amount of BTC required to spend an input for a given address type.
It is calculated by using a basic 1 input 1 output transaction consuming an input from that address type at the minimum acceptable fee level, and calculating its fee (minimum fee level * tx size).
This works out to 546 satoshis for traditional p2pkh addresses, and 294 for p2wpkh addresses.
Transactions that create one or more outputs under the dust limit will be rejected by the network and you will not be able to broadcast them (even if other outputs in the transaction are above the dust limit). If you're left with a value under the dust limit as change, most wallets will add it to the fee.

from what i read, dust limit is applicable only for output.  How does it applicable to input?

It isn't - if you somehow have an output under the dust limit, you can spend it, but you will need to combine it with another output with a large enough value to be able to pay enough in fees AND create new outputs that adhere to the dust limit

ok noted . tq for the clarification

Good answer with useful details. Dust limit = when a payment amount becomes harmful to your wallet. I would just like to add that I have received 1 satoshi payments many times. Annoying spam transactions.

@Dr.Haribo Can you provide a link to any such tx (not necessarily from your wallet)

@RaghavSood - here is an example with many 1 satoshi outputs, txid: a79dbc3379ceb50291147f714edf2a0c3e5f4f6ddd17faf413fb3476c9e30f3c


text:
What is this 18-word seed of random letters?
I have a seed from a few years ago that looks like this:
this is not the actual seed, but it's random letters just like this:
nasd oasi lksn oifd nwee ckvj osdi pwer asem
pasd werw nase nwqe noas pmrr nolv psme ksdw

How can I recover the wallet?

This sounds like a job for Luke Childs' BIP39 recovery tool, which has now been merged into Electrum. It scans common derivation paths for common seed configurations, in search for previously used addresses and balance.
You can run it offline on your own machine (as you should!), just ensure that the Electrum wallet you download is not compromised.
You can download the Electrum desktop app for most OSs (+ signatures) here

It's an armory backup seed. See https://www.bitcoinarmory.com/. It's a wallet that requires bitcoin core full node so you'll need that as well.


text:
RPC getnewaddress error on v 0.20.0
I would like to new address generate with this command
bitcoin-cli -testnet getnewaddress "adr1" "p2sh-segwit"  but I get this msg:
error message:
Wallet file not specified (must request wallet RPC through /wallet/<filename> uri-path).
Try adding "-rpcwallet=<filename>" option to bitcoin-cli command line.

then I added the -rpcwallet command like that:
bitcoin-cli -testnet -rpcwallet=/home/bitcoin/.bitcoin/ getnewaddress "adr1" "p2sh-segwit"  but I got an error again like this:
error message:
Requested wallet does not exist or is not loaded````

what should I do?

thank you

-rpcwallet takes the name of the wallet, not the path to the datadir (as you appear to have done) or the path to the wallet file.
To get a list of the names of the wallets currently loaded, you can use the listwallets command.

I got the same error and had a hard time trying to figure out where to pass in the -rpcwallet=<wallet_name> flag. For example, I was doing a bitcoin-cli listunspent -rpcwallet=<wallet_name> and was getting the same error, until I changed things around and passed in the flag before the listunspent rpc command.
So always use the -rpcwallet flag before the rpc command you're working with.
For example:
bitcoin-cli -rpcwallet=<wallet_name> listunspent will work, but bitcoin-cli listunspent -rpcwallet=<wallet_name> will return with the same error.


text:
As the Bitcoin price skyrockets, how to avoid getting malware through freeware/FOSS software's updates?
We have a situation now where the vast majority of software I have installed on my computer (Windows 10, since there are no other supported versions of Windows) are either aging one-man freeware applications which haven't changed almost at all for the last 20 years, or open source projects of typically similar stagnation. I can sense the frustration from both of these groups, many of which have entirely abandoned/dropped their projects. Countless are in a seemingly perpetual state of very slowly dying, and all too many are what can best be described as "undead".
As these probably honest idealists watch the years go by with essentially no donations coming in, nobody buying their commercial licenses/support, and big companies just stealing their work without giving any credit and with no regard to the license, then make tons of money from it, and especially now with the Bitcoin price ever increasing to crazy new heights, I can very much imagine that even the most good-hearted but struggling, disillusioned freeware/FOSS developer at the very least has the recurring thought:

Ah! Screw this! Eight million unassigned/unresolved bugs, zero donations for the last 15 years, not one license purchased by any company ever, nothing but demands and rude users... and XYZ has just used my software to make a fortune... I've had it! I'm going to push a piece of malware in the next update so that all those people will get all their wallet.dat files uploaded to me, of course using proxies! Hah! I estimate that at least a few of them will own Bitcoin and have Bitcoin Core running. And those who don't won't ever notice anything anyway! Bwahahahaha! Within a few weeks, I'll be relaxing on my own tropical island, drinking colorful drinks at the beach! No more slaving away at this keyboard for nothing! You'll see! Just you wait... rubs hands with a twisted facial expression

You may say that they have a reputation to uphold and people who do this tend to be very honest and would never seriously get tempted to steal. Sure. But it's still very possible. The more the price goes up, the more scared I become to just see "0.00" balance in Bitcoin Core the next time I look at it. Let's face it: there is zero security in practice. I'm trusting complete strangers every second my PC is powered on to not steal from me. There is no possible reasonable way for me or anyone else to possibly somehow "go through" others' programs, if they even provide source at all, and then locally compile everything. It just isn't reality, even for the most hardcore geeks.
They could even have planted the malware long ago, but are actively waiting until the day Bitcoin is worth over X amount to go through with this. Perhaps they already have detected how many of their users have Bitcoin wallets on their machines, and how much they contain. They can precisely calculate the risk in advance and decide that it's finally worth it to go through with it. And if ever confronted, they can just give the same excuse that all these companies always do when they leak customer data: it was "a bug/technical glitch/we got hacked/we take your privacy very seriously blablabla..." It's not like the "gone evil" developer who does this is going to be standing with a black cape, twirling his moustache while mocking his victim with clever one-liners. He would just be gone, just like our coins. They would deny any involvement, even if it's known exactly who runs the software project or is primarily responsible. (Which is not always the case.)
Even Microsoft themselves (or told by the government) could decide to just have me pay a little "Bitcoin tax" with their next Windows update. And then claim that it was a bug, or that I'm lying. Have you ever tried to get in touch with anyone at Microsoft who isn't a robot, and who actually understands a single word of English? It's impossible, even for a developer. Nobody would ever hear me complain, and even less would believe me.
Here's the problems I have with all predicted solutions:

"Use a dedicated computer (maybe Raspberry Pi) running Linux just for Bitcoin Core stuff." -- Very impractical. I don't have the physical space, plus it would be a horrible pain to actually make any transactions/use it. They also make it impossible in practice to encrypt Linux running on a RPI. (Long story...)
"Use a hardware wallet." -- Costs money to buy, difficult to get home, are not as secure as one would think, also very impractical (though less so), and most of all: it is basically hard proof to the authorities (and burglars) that you own Bitcoin. Plus the recent leak of home addresses and other personal data of tons of customers of Ledger makes it impossible for me to ever trust that company...
"Print them onto paper and keep the papers in a fireproof safe." -- Again a massive problem with authorities, and once seized, there is zero security since the private keys are right there on the paper. Or if the fireproof safe isn't as fireproof as expected...
"Let a third party store your coins for you! Trust the cloud! Web 3.0! Just log in with your Google account!" -- This one doesn't even deserve a comment...
"Use anti-virus and keep your software and OS patched blabla..." -- The issue is not trusting those... both in the sense that they might be malicious themselves, or through incompetence allow others to break in to my system via their broken software.
"Use an app in your phone." -- Please... don't...
"Use Quebes OS." -- Well, I tried, but it doesn't even install on my hardware. My experience with that OS is that it's very frustrating to use, when it does run. Perfect in theory, though. I wish something like that "really" existed, and ran on secure hardware.
"Just be careful." -- This is nonsensical advice. There is no possible way to know or prevent if any given EXE is going to do something bad when it's running unhindered on my host OS. "Being careful" means nothing if, at the end of the day, you are still required to execute a program on your machine which is not completely sandboxed. And sandboxing is apparently the most difficult problem ever to exist, since nobody ever manages to do it properly...
"Use a VM!" -- Well, I do, for some things which I really don't trust on my main OS. However, this is extremely cumbersome and tiresome, and I can't run everything in a VM. I simply have to trust several entities on my host OS which may at any moment decide to "go rogue". Unless there is something which I haven't heard of which solves everything neatly and perfectly...

What to do? If I feel this scared at $40k USD Bitcoin, what kind of nervous wreck will I be when it reaches $1,000,000 per Bitcoin?
I just don't see any solution. I've through extremely long and hard about this and tried so many things, both in reality and inside my head, and none of them work out. I know they are either not secure or so cumbersome that life becomes a massive chore. There's also the problem of having very little physical space and basically only one computer.

Unfortunately, good security isn't always easy.
In this case, your worry is not unjustified, and it is why most security-conscious users will recommend never having privkeys touch an online device. This is, at minimum, required to mitigate against the sort of software-based attacks you've outline above. IF you have an online computer that holds privkeys and is receiving software updates, then you are indeed at increased risk of theft.
The usual ways to deal with this include:

Running a wallet on an offline computer (eg a raspberry pi with electrum is a very low-cost and space-efficient way to accomplish this)
Using a hardware wallet produced by a well-known and trusted manufacturer
Using multi-signature wallets, so that an attacker would have to compromise multiple devices / wallets before they could steal funds

Your objections seem to be about poor user experience of these methods, which is fair. There is a lot of nuance to each of these methods, and they are indeed more cumbersome than just loading up some wallet onto your insecure device, but security is always going to be a game of trade-offs, with no 'one-size-fits-all' sort of solution available. It probably isn't a great idea to secure $20 worth of bitcoin with a $100 hardware wallet, but it probably is a great idea to secure $20,000 worth of bitcoin with a $100 raspberry pi setup (even accounting for the day or two of time you might spend setting the pi up and learning how to run it).
Also worth mentioning: you can compartmentalize your security. Consider the option of setting up a 'cold storage' method that is cumbersome but very secure, and use it for long-term storage of coins you don't plan on spending anytime soon. At the same time, keep a small amount of coins in a less-secure wallet, such that if a malicious software update leads to theft, you haven't lost much. This is analogous to keeping most of your cash in a secure bank, while carrying maybe a couple hundred dollars in your wallet. You certainly wouldn't want to carry your life savings around in your pocket every day, after all!
Of course I do hope that solutions with increasingly better UX will exist in the future, but in any case, you can't have your cake and eat it too. Security takes work, you need to decide how much work you find worth it to undertake.


text:
Help to pending Verification
In cryptofree.casa How Long Take to pending Verification is over please help
My email is:
Hosseinnassari84@gmail.com

Hi Hossein Nassari, could you please edit your question to provide more details? What are we looking at? What is the expected outcome? Who or what are you interacting with? Please note that if you are inquiring about the internal business processes of a company, we likely cannot help you because we don't have insight into that.

Cryptofree.casa its been 15 day in pending Verification

We just had another user ask about that site a few days ago. It doesn't look particularly trustworthy. Either way, we have no insight into the internal processes of sites, and we don't review services, so I'm afraid we can't help you with this one beyond some general advice how to evaluate services.

Can you give me a email or some adress from cryptofree.casa to ask my question from there

They don't seem to have contact details listed on their public site (which is a red flag), and I don't have an account there to check whether it's any different for users that are logged in. Either way, I have no knowledge of this service, so I'm afraid you'll have to dig in yourself.


text:
Why should I mine Bitcoin?
Please teach me why I should mine bitcoins, aswell as how please so I can learn.
Please, I really want to mine!

Buy an ASIC. In this age, it's not profitable to mine using usual computers. These specialized computers are used for mining.


text:
How to enable mining on daemon?
I forked bitocin and created a altcoin.
Now I am running a node of it. There are currently 0 blocks because there are no miners. How can I enable mining on bitcoind?
I tried adding gen=1 with config, but it's not mining.
I believe there was a setgenerate true command, but I am not sure how to use it. How can I make my node mine coins?

I believe you can still use the generate and generatetoaddress commands to mine a certain number of blocks. setgenerate was removed in version 0.13 because mining with bitcoin core on mainnet is useless and has been for a number of years:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md#removal-of-internal-miner

Interesting, I didn't know this worked outside regtest mode, but the code suggests that it does.  (Of course it will be very slow and one might wish to use an external cpu miner instead.)

@NateEldredge yeah I thought the same, but couldn't find any checks in the code and running it on mainnet didn't throw any errors, so unless someone knows something otherwise, I guess it works :)