text:
Getting a high s value rejection although s < N/2
Using the mempool app on my full node from mynode, when transmitting a raw tx with more than one output I get:
non-mandatory-script-verify-flag (Non-canonical signature: S value is unnecessarily high).
I checked and
s - N/2 = -2.3646232789023417e+76,
so this doesn't seem to be true. Using a public block explorer like blockcypher no error is returned, however the tx is stuck and will not confirm.
rax tx is
0100000001a9b1a5b978a4a6c3f7fb14f0255e2f544cb45d63ab8153b28b8b6fef2095ec3a000000006c493046022100c2036791de6d3a4592b65f180debd314f0f5fc637963711d09da3fe8529e0a2b022100a270c846b69cdf68b0c211b67515f850663a6c448c52e6b940863b450a2bf790012102a74ced31ca71800626bc4e0b317714b8700ba6a2befda55899eb66371b8b26a8ffffffff03e8030000000000001976a914655355fe75f8ef558dbb4dca8f1a38e12cb5b32d88ace8030000000000001976a9143871ad8b05aaf69d37309f319b07b8a6bf6066ae88ac18730100000000001976a9143fa2936ef54e0d47b9f63cafaac4bb9a30325cb088ac00000000

what could be the reason the tx gets rejected?

The S value in your scriptSig is
00a270c846b69cdf68b0c211b67515f850663a6c448c52e6b940863b450a2bf790

Interpreted as a hexadecimal number, that is around 7.347395059744133e+76, or (N/2) + 1.5577905978783233e+76.

Thanks, I look into it.


text:
Is bid value the amount I will get if I sell?
I have looked at links and asked this but, I am confused...and PLEASE DON'T TREAT ME LIKE I AM STUPID (I have had that happen on a few sites by 'Trolls').  Bit of a "Techie Challenged Idiot" so a little confused by the 'language' some use to explain the dollar value verses bid value since I am not so good on making sense of apps and computer stuff and never have been.  For example if I have xyz amount of BTC and it says it is worth so many dollars but, there is a 'Bid Value' that is a great deal higher such as say the dollar amount shows under 100 dollars but, the bid is in the thousands what is the TRUE amount I would receive if I were to sell the BTC? The platform I use hasn't given me a clear answer on this and I am hoping to get one before I make a decision on what I want to do with these coins.  I want to invest however, my financial institution is cracking down on funding and usingBTC so I am hoping to cash out, get my profits before they start locking accounts of people on those sort of plaforms.   Help

Is bid value the amount I will get if I sell?

According to https://www.investopedia.com/terms/b/bid-and-ask.asp

The bid price represents the maximum price that a buyer is willing to pay for a share of stock or other security. The ask price represents the minimum price that a seller is willing to take for that same security. A trade or transaction occurs when a buyer in the market is willing to pay the best offer available—or is willing to sell at the highest bid.

So you might offer your BTC for sale for $1000 and it would only sell if someone bid $1000 or more. If no-one bids that much you would never sell your BTC.
If you find no-one is bidding more than $950 you would only be able to sell by offering to sell at $950.
Note the word bid and offer in this context are not specific to Bitcoin. This is really a question about the terminology used by all marketplaces for financial products. This means you might get more informed answers by searching in money.stackexchange.com or by asking there if there are no existing answers.

say the dollar amount shows under 100 dollars but, the bid is in the thousands what is the TRUE amount I would receive if I were to sell the BTC?

It should be readily apparent whether the specific exchange you are using expresses bid values as a rate (e.g. $17000 for 1.00000 BTC) or as an amount of one currency for a specific amount of another (e.g. $100 for your 0.00006 BTC).
Peronally I think it best to configure your wallet to show its content amounts in units of BTC rather than USD etc. Maybe switching back and forth will make things clearer in your mind?

So in the context of this question, I would understand your answer to indicate that the “bid” refers to the exchange rate (the price of one Bitcoin), while the dollar value would refer to the exchange rate times bitcoins the asker is selling and thus the amount the asker would get, and that would explain why the “bid value that is a great deal higher [than] the dollar amount".

source: Stack Exchange

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

sort: votes


text:
When a block is broadcasted, are all the data of the transactions packed into it or are only its hashes included in the block
Most of the blogs and answers to this question do not give a straightforward answer.
I have a good amount of information regarding bitcoin and would like to simply know if the transactions are packed as a whole inside the block when it is broadcasted or if only the hashes are included on broadcast and then the nodes (if they don't have a few transactions already in their mem pool) query the other nodes to give the transactions corresponding to that hashes?
Regards PL46U3@LTZ

I suppose both transactions and blocks are gossiped independently, and I'd assume only the ids are gossiped, while the contents are fetched only by the node that doesn't have the full data (the raw transaction or the block).

It depends on which protocol is used. The two main ones that are commonly available:

The original getdata/block-based protocol. A node would send getdata message with a block hash, and in return receive block message which contains the full block, including the headers, and all transactions.
The BIP152 "compact blocks" protocol extension, introduced in 2016. In this mode, nodes would ask (again using getdata) for a compact block (cmpctblock), which consists of the block header, the coinbase transaction, and short (48 bits) salted hashes of all the transactions in the block. The receiver would then try to reconstruct said block using the transactions it already has in its mempool (or elsewhere), request missing ones (using getblocktxn), receive those (using blocktxn), try to reconstruct again, and if that still fails, fall back to requesting the full block using the original protocol.

Both of these approaches do require that the receiver is somehow made aware of the block's existence. There are again a number of ways this can be done:

The original inv-based protocol, where new block hashes are announced. Nodes can also ask for large sequences of block headers (for catching up on historical blocks) using getblocks).
The BIP130 "sendheaders" protocol extension. This allows nodes to request that new blocks are announced using their headers (headers message) rather than using the hashes. Headers are 80 bytes, while hashes are 32, so they're slightly bigger, but headers are much more useful for the receiver to make decisions based on (e.g. they can already verify proof-of-work).
The BIP152 compact block protocol also includes a "high bandwidth" mode, where nodes can request that new blocks get announced immediately using cmpctblock, rather than needing a round-trip using inv or headers first.

Nodes may also negotiate ahead of time that cmpctblock messages may be sent unannounced (without corresponding getdata request), to reduce the latency.
Modern Bitcoin Core versions use getdata/block for initial block download, and then compact blocks for newly found blocks (and sendheaders for learning about them).

Thank you so much sir this made me so clear about my query.
I am actually creating a new chain of mine this would help me so much.

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


text:
"Payment address not valid" error on Mycelium
I'm trying to deposit BTC into BitBuy, using a Mycelium wallet. When I use Mycelium to scan the QR code, I get a "Payment address is not valid" error. I'm using Mycelium on iPhone, latest iOS. I'm scanning from BitBuy on a PC monitor. What am I missing?

Have you checked the address is valid using a blockchain explorer?

I have the same problem. Anyone?

What does the address on BitBuy start with? 1…, 3…, bc1q…, or bc1p…?


text:
Is there any statistical evidence that 2 of 3 wallets are indeed the most common one?
I read the following statement:

2 of 3 wallets are the most common multi-signature wallets created. In
this case, the wallet requires three signatures, but only two are
needed to authorize a transaction.

Is there any statistical evidence that 2 of 3 wallets are indeed the most common one? Like some graph etc. Any kind of statistical evidence would be good. I want to use this fact in a research paper I am writing. I need some reference to cite.
Thanks.

Yes, txstats.com has such a graph. From this graph, we can see that 2-of-3 multisigs are by far the most popular multisig types.


text:
Creating a complex raw transaction
I'm using createrawtransaction to get a complex transaction of 2 inputs and two outputs as discussed here: https://developer.bitcoin.org/examples/transactions.html
bitcoin-cli -regtest createrawtransaction '''
     [
       {
         "txid": "'$UTXO1_TXID'",
         "vout": '$UTXO1_VOUT'
       },
       {
         "txid": "'$UTXO2_TXID'",
         "vout": '$UTXO2_VOUT'
       }
     ]
     ''' '''
     {
       "'$NEW_ADDRESS1'": 79.9999,
       "'$NEW_ADDRESS2'": 10
     }'''
0200000002ea34a15b5c6b1ec4d3e9d2a1fdb8f80c29b0aa93d1762359b5ba30b63437973a0000000000ffffffff3d38a74c05e837f87b7a0eb0b7c688396972ffe670fda8b7ba689c76acca24300000000000ffffffff02f028d6dc01000000160014e38542852b468886d97748b4ca3786387e9e9cdc00ca9a3b00000000160014f8dd22acbd0867c5ad1edd3c3ca6e8768845cb1d00000000

I assign this value to RAW_TX as described:
RAW_TX=0200000002ea34a15b5c6b1ec4d3e9d2a1fdb8f80c29b0aa93d1762359b5ba30b63437973a0000000000ffffffff3d38a74c05e837f87b7a0eb0b7c688396972ffe670fda8b7ba689c76acca24300000000000ffffffff02f028d6dc01000000160014e38542852b468886d97748b4ca3786387e9e9cdc00ca9a3b00000000160014f8dd22acbd0867c5ad1edd3c3ca6e8768845cb1d00000000
But then I run into problems. When using the private key I get an error saying it's not a valid sighash parameter. Since signrawtransaction is deprecated I'm using signrawtransactionwithwallet:
bitcoin-cli -regtest signrawtransactionwithwallet $RAW_TX '[]' '''
>     [
>       "'$UTXO1_PRIVATE_KEY'"
>     ]'''
error code: -1
error message:

    [
      "cUS7vndDv6nzJ3qEa5YG74dAzzEwTxRmbBFKXCn2fu2C4GSCbRKa"
    ] is not a valid sighash parameter.

I'm have no idea why it's not working. Please advise!

I tried adding more input but I get the following result:
>     [
>       {
>         "txid": "'$UTXO1_TXID'",
>         "vout": '$UTXO1_VOUT',
>         "scriptPubKey": "'$UTXO1_OUTPUT_SCRIPT'",
>         "value": '$UTXO1_VALUE'
>       }
>     ]'''
error code: -3
error message:
Missing amount for CTxOut(nValue=21000000.00000000, scriptPubKey=001492718ece477c2053ebee50dc7e)


text:
Why has Bitcoin Core stopped shutting down when Windows cleanly shuts down?
Every night, I do this to turn off my Windows 10 machine:
shutdown /s

Note that there is no "forcing flag" or anything (/f).
Up until recently, Bitcoin Core appeared to always get the signal and cleanly shut down, just like every other application.
However, recently, whether it was a new version of Bitcoin Core or an update to Windows 10, Bitcoin Core has stopped shutting down when it gets the signal. The reason I'm convinced of this is that, every day when I turn the machine back on, Bitcoin Core (and only that program) appears to have been uncleanly shut down/killed suddenly, as it keeps having to resync the last several days. (Perhaps just verifying the local data rather than actually downloading it.)
I even tried keeping the Bitcoin Core GUI window open while shutting down one day, and I noticed that it didn't say the usual "Shutting down" text.
Whether this is Bitcoin Core's fault, Windows 10's fault, or a combination, the fact remains that this happens every single time now, and it's very annoying and worrying.
Is this issue known? Is it being worked on? What could be causing it? Would MS really change something fundamental about how applications are signaled when shutting down the OS in a minor update? (Not unthinkable.)

That sounds like a bug, and is very unlikely to be Windows' fault. Can you file an issue on https://github.com/bitcoin/bitcoin/issues? Be sure to include information on which version of Bitcoin Core you're using, and which one was the last one that you know worked fine.

Related: https://bitcoin.stackexchange.com/q/99188/5406

@PieterWuille Actually, I literally cannot file an issue on Github. The site has not allowed me to register for years, much like virtually every other website. I have no idea how anyone uses the Internet anymore.

@Prayank I don't have any other machine or the ability to sit and test stuff. But I did look in the Bitcoin Core log (again) and this is what it said the last before starting up again today: warning='63 of last 100 blocks have unexpected version'

According to https://github.com/bitcoin/bitcoin/issues/20052#issuecomment-702659790 you can use the PowerShell Stop-Computer cmdlet.


text:
NBitcoin Transaction sign(secret, bool) is giving error. Instead of bool it says to pass Coin Object
I am using NBitcoin (I'm new to it) to sign a transaction. Here Transaction sign(secret, bool) method is giving error. (I've searched the Internet, but got no help.) Instead of bool it says to pass Coin object, I'm using the latest stable version of NBitcoin. How should I do this? Here's my code:
var fee = Money.Coins(0.0001m);

        Transaction payment=Transaction.Create(bitcoinNetwork);
        payment.Inputs.Add(new TxIn()
        {
            PrevOut = new OutPoint(fundingTransaction.GetHash(), 1)
        });

        payment.Outputs.Add(new TxOut()
        {
            Value = amount-fee,
            ScriptPubKey = toAddress.ScriptPubKey
        });

        var output = fundingTransaction.Outputs[0];

        payment.Outputs.Add(new TxOut()
        {
            Value = output.Value - amount - fee,
            ScriptPubKey = output.ScriptPubKey
        });

        var message = "Thanks :)";
        var bytes = Encoding.UTF8.GetBytes(message);
        payment.Outputs.Add(new TxOut()
        {
            Value = Money.Zero,
            ScriptPubKey = TxNullDataTemplate.Instance.GenerateScriptPubKey(bytes)
        });

        Console.WriteLine(payment);

        payment.Inputs[0].ScriptSig = fundingTransaction.Outputs[1].ScriptPubKey;

        payment.Sign(secret, false); // the problem arises here

        using (var node = Node.Connect(Network.Main))
        {
            Console.WriteLine("Doing version handshake");
            node.VersionHandshake();
            Console.WriteLine("Sending message");
            node.SendMessage(new InvPayload(InventoryType.MSG_TX, payment.GetHash()));
            node.SendMessage(new TxPayload(payment));
            Thread.Sleep(500);
        }


text:
Corrupted old bitcoin wallet. !!!file unknown has LSN!
I have a corrupted UN-ENCRYPTED bitcoin wallet from 2013.
what I have tried so far with both wallet:
1, with old and new version of bitcoin client the wallet just creating a .bak file and not showing any amount/transaction.
2, i also try bitcoin-qt.exe -salvagewallet - that is creating a bak + epoch time. and the db.log saying
file unknown has LSN 91/5547280, past end of log at 1/1042
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
wallet.dat.1608587747.bak: DB_VERIFY_BAD: Database verification failed
3, pywallet installed correctly and working fine under ubuntu for me with different wallets that not corrupted, (dumping all data just fine)
but when i trying to dump the corrupted once python2 pywallet.py --dumpwallet --datadir=./ im getting the "ERROR:root:Couldn't open wallet.dat/main. Try quitting Bitcoin and running this again."
4, i have try the python2 dbdump.py --wallet --wallet-tx --datadir=./    (getting "ERROR:root:Couldn't open wallet.dat/main. Try quitting Bitcoin and running this again.")
Kind of run out of stuff now, how i go more deeper in this to get those private keys and addresses?
If any of you can successfully help me, reward will be issued for sure.

Without seeing the wallet file, there really is no way to know what is wrong with it and how to salvage it. Frankly, any automatic salvaging solution is not going to be sufficient because there are so many possible things that could have gone wrong to corrupt the wallet file.

well this is the thing, I'm asking advice how to find out what's wrong with it. Any tools or technik's recommendation. I think you understand sending out unencrypted wallet not an option.

A technique with which I've had success in the past:

db5.3_dump corrupted_wallet.dat | db5.3_load fresh_wallet.dat

(obviously replacing corrupted_wallet.dat with the actual filename, and making a backup first).
and then trying to load fresh_wallet.dat into a modern Bitcoin Core
These tools are in the Ubuntu package db5.3-util.
Note: you'll need a Bitcoin Core that is compiled against libdb5.3++-dev to open this file (as it'll be using BDB 5.3, while release builds use BDB 4.8). You can do the equivalent and just use BDB 4.8 tools everywhere, but they're harder to find.

how i go more deeper in this to get those private keys and addresses?

Well the basic process I would start with would be

Don't use the computer that contains the damaged file
Use a bootable USB to make a copy of the file onto external media
Lock the computer away until you have repaired the file or extracted keys on a new computer
make copies of the damaged file and work only on those copies.
keep some unaltered copies in some safe places.
make a hex dump of the wallet.dat file
study the defined file format used by Bitcoin core in 2013

perhaps by searching for documentation of the file format.
perhaps by studying the source of PyWallet.
perhaps by getting a 2013 set of Bitcoin-core's source code from GitHub.

compare the defined file format with a hex dump of a working wallet.dat of 2013
make small changes to a working 2013 wallet.dat, make new hex dumps and study the differences.
compare the defined file format with a hex dump of your damaged wallet.dat
attempt repair
perform some forensic recovery process of all data in unallocated space on a bitwise copy of the original computer's hard disk(s) or equivalents. Repeat process on data to try to identify fragments of wallet.dat data.

This would be slow difficult work. You will find differences that don't make sense and you may have to invent new content to insert and also decide what parts to delete. You may need to find tools, or create tools, that allow you to make the changes to a copy of the wallet.dat to repair it. Or you may be able to identify the private keys in the hex dump and just extract those.
If the wallet contains a small amount I wouldn't bother. If it contains an amount equivalent to a years wages say - then, in your shoes, I would probably spend some time on this.

There's no safe way to have someone else work on this. It's easy for a stranger to say they found nothing and walk off with your wallet's money. It's easy for conmen to slowly gain your trust until you pay them various fees for working on this for you.

Wallet.dat file have always been BDB (LevelDB is only used for the block/chainstate database). Bitcoin Core 0.21.0 adds an experimental option for SQLite wallet files, but is still compatible with every BDB-based wallet.dat for as long as we know.

@Pieter, thanks, updated accordingly (removed mention of LevelDB)

If your wallet has't opened then download and install bitcoin core wallet 0.18.1
Open the bitcoin directory, copy and paste your corrupted wallet.dat in bitcoin directory.
Watch the video about how to dump it without passphrase - https://youtu.be/C_yNMPnnqS0?si=I6SWI87YStbQbgLp
Hope its helped you.


text:
how to connect to bitcoin node in javascript without running a local node
I am trying to get some bitcoin network data and I am using bitcoind-rpc library.
If i just run their example:
var run = function() {
  var bitcore = require('bitcore');
  var RpcClient = require('bitcoind-rpc');

  var config = {
    protocol: 'http',
    user: 'user',
    pass: 'pass',
    host: '127.0.0.1',
    port: '18332',
  };

  // config can also be an url, e.g.:
  // var config = 'http://user:pass@127.0.0.1:18332';

  var rpc = new RpcClient(config);

  var txids = [];

  function showNewTransactions() {
    rpc.getRawMemPool(function (err, ret) {
      if (err) {
        console.error(err);
        return setTimeout(showNewTransactions, 10000);
      }

      function batchCall() {
        ret.result.forEach(function (txid) {
          if (txids.indexOf(txid) === -1) {
            rpc.getRawTransaction(txid);
          }
        });
      }

      rpc.batch(batchCall, function(err, rawtxs) {
        if (err) {
          console.error(err);
          return setTimeout(showNewTransactions, 10000);
        }

        rawtxs.map(function (rawtx) {
          var tx = new bitcore.Transaction(rawtx.result);
          console.log('\n\n\n' + tx.id + ':', tx.toObject());
        });

        txids = ret.result;
        setTimeout(showNewTransactions, 2500);
      });
    });
  }

  showNewTransactions();
};

I need to provide the data of my local node.
But I have problems downloading bitcoin node mostly because I do not have enough space.
Is there another way I can access the node without downloading full node localy?

The RPC interface is way of interacting with your Bitcoin node. If you don't run one, then no, you can't just use someone else's. But as @Prayank says, you can run a pruned node, which has lower disk requirements. There are other solutions if you're willing to trust someone else's node, but they involve other protocols than RPC.

Since you mention nodejs you might be interested in bcoin:
https://bcoin.io/
https://github.com/bcoin-org/bcoin/
Bcoin is modular and configurable in weird ways. See this other answer on how bcoin can be modified to download arbitrary blocks even in pruned mode:
How do I get old blocks while running a pruned node?


text:
How to do experiments on bitcoin blockchain?
I come up with a protocol that can enhance the privacy of bitcoin. I want to do some simple experiments on the bitcoin blockchain. However, doing experiments on the real bitcoin blockchain seems expensive and unrealistic. Is there any way to simulate a bitcoin blockchain so that I can do an experiment on it?


text:
Will ECDSA be less and less popular when Schnorr signature can be used in Bitcoin?
Schnorr signature is simpler than ECDSA, and it enjoys the linearity property, which brings more efficiency to Bitcoin. Will ECDSA be less and less popular when the Schnorr signature can be used in Bitcoin? Or more extremely, will ECDSA be replaced by Schnorr signature? Is there any advantage of ECDSA over the Schnorr signature?

Will ECDSA be less and less popular when the Schnorr signature can be used in Bitcoin?

You need to use SegWit v1 (Taproot) addresses to be able to use Schnorr signatures on Bitcoin. A desire to use Schnorr signatures will drive that adoption to some extent but there are other considerations like desire to use Taproot Merkle trees of scripts and whether your wallet supports sending and receiving to SegWit v1 addresses. One would expect usage of SegWit v1 addresses to increase over time as more wallets support it and hence usage of Schnorr signatures to increase.

Is there any advantage of ECDSA over the Schnorr signature?

This is partially answered here. As far as I know the Schnorr signature scheme is strictly superior to the ECDSA signature scheme but as the linked answer states there are reasons to still use ECDSA today like standardization and more widespread library support for ECDSA.


text:
Is it possible to recover a wallet from Address and Password?
I had an Electrum wallet on my laptop that broke, contrary to the usual "forgot my password" questions, I do have my password but I don't have the seed and the laptop is on repair and the data is not guaranteed to be intact, is there a way to access my wallet without the seed, but with the password and address?

If after the laptop repair your data are not intact and the seed is lost , there are a lot of hard disk data recovery services which might be able to recover your seed. This is possible because deleted data on hard disk are not actually deleted , they remain on hard disk until overwritten by new data .

You need either

the seed

the wallet file and password

Nothing else will do, unfortunately.

What's the seed? Is "getwalletinfo.hdseedid" the seed?


text:
bitcoind syncing headers but not blocks
I have bitcoind version 23.0 running on a machine in regtest mode.
I then start another instance on another machine and perform addnode "x.x.x.x:xxxx" "add" to connect to the first instance.
The result: the new instance connects fine, syncs block headers, but not blocks.
getpeerinfo shows:
[
  {
    "id": 0,
<snip>
    "network": "ipv4",
    "services": "0000000000000408",
    "servicesnames": [
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "last_transaction": 0,
    "last_block": 0,
    "bytessent": 1045,
    "bytesrecv": 1329,
    "timeoffset": 0,
    "version": 70016,
    "subver": "/Satoshi:23.0.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 110,
    "synced_headers": 110,
    "synced_blocks": -1,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 1,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
<snip>
    "connection_type": "manual"
  }
]

My bitcoin.conf looks like this:
listen=1
server=1
prune=2000
regtest=1
rpcauth=<snip>
port=<snip>
rpcport=18443
rpcbind=127.0.0.1
rpcallowip=127.0.0.1

getblockcount returns 110 on the first machine and 0 on the second, confirming that no blocks were synced.
Why is this happening and how to get block sync going?

A synchronizing node will look for a peer that announces the NODE_NETWORK service flag which indicates that a node has all blocks and can serve them.
Pruned nodes will only ever serve the newest 288 blocks, which is signaled via the NODE_NETWORK_LIMITED service flag. Since pruned nodes tend to not have the earliest blocks (except if there are so few as in your test), a synchronizing node will not request blocks from a pruned node.
As you're running on regtest and your blocks are probably mostly empty anyway, you could mitigate your issue by turning off pruning.
peerbloomfilters turns on support for BIP37 bloom filters, which permits thin clients to request that a full node searches blocks for them and notifies them about relevant transactions. If both of your nodes are full node instances, this feature will not be used and should not impact your success.

Going to answer my own question.
Looks like it is the prune= option that disables the NETWORK service and stops the node from participating in block sync.
After removing it the setup started working as expected, headers and blocks are being synchronized correctly.
In addition, setting peerbloomfilters=1 resulted in connection_type: outbound-full-relay.


text:
What is the relativity between ECDSA public keys, if any?
Wondering if there is any relative connection between public keys?
I know that they are a function of G, but is there any other connection they share?
Is it possible to calculate how many G are between two public key points?
Thanks in advance.

Is your question if, given two points A and B, you can compute x such that A + xG = B, the answer is no.
That would be equivalent to solving ECDLP (elliptic curve discrete logarithm problem), which is assumed to be computationally infeasible: just apply it with A a public key of your own (which you know the private key to), and B the point whose DL you want to compute. The resulting x plus the DL of A is the DL of B.


text:
I invest 5000 PHp in bitcoin and to ask me i need to pay the transfer fee

List item

I invest 5000Php in bitcoin but after the mining my invest he ask i need to pay a transfer fee .is it normal to pay that because im from Philippine

Please answer me do i need to pay that tranfer fee to claim my profit ?

No, its a scam, you have been tricked by criminals.


text:
Long-term present in a form of cryptocurrency for newborn
Lets go...
I am relatively new to to world of crypto. Have some experience with Binance, last few weeks. My friend had a son, and I want to give him a little different present - crypto investment in a box. I was looking buy him Cardano or Bitcoin of some value, and put all the info needed to reclaim all of that crypto in 18 years time. Is it possible to have all-non binary information for him to retrieve crypto, in a form of paper/wood or physical.???
I am not an expert, so I would like to ask you. In year 2039, could you retrieve paper information to real Bitcoin or Cardano, and do you need third party information like some kind of wallet or something that will maybe vanish in 10, 20 years. Please only people who know this world very well , respond! Thank you!

Paper wallet is discouraged. https://en.bitcoin.it/wiki/Paper_wallet.

Thanks, so it seams digital ones-and-zeroes are only way to go...

I would get a wallet to generate a BIP-39 seed phrase, stamp the seed phrase onto durable metal, send money to the wallet and destroy the wallet, deleting all data.

Is this a metal paper wallet?

@Mercedes, most of the problems associated with paper wallets don't apply to seed-phrases punched into metal and which are intended to be used to recreate a hierarchical deterministic wallet.

If you don't want it to be timebound then suggestions in other answers like passing mnemonic phrases, paper wallets etc would be great. One nifty solution you can look at is - https://opendime.com/ (I am no way promoting their product, so pls look at it yourself).  According to my study, This comes close to a physical version of Bitcoin, which can be given to someone.
If you really want it to time bound like he should be able to retrieve only after 18 years then you will have to rely upon bit more than just the seed phrases. You will have to create a pay to script address and send coins there. I am still learning how to easily create that, may be more knowledgeable folks here can help.


text:
Bitcoin-qt exits silently after syncing blocks until before 24 hours
I shutdown bitcoin-qt (version: 23.0) around two weeks back. Now when I relaunch it, it syncs blocks until 24 hours and then silently exits. debug.log file contains the following as last line -
2022-09-26T13:28:01Z Leaving InitialBlockDownload (latching to false)
I removed all the wallets to see if that is causing any issue, but that was in vain. Any help will be appreciated.
Best.

Hi, is there anything uncommon in how you set up your node? Are you running your node with some uncommon startup options or config? Is it running in pruning mode? It would help if you could tell us a bit more.

Nothing specific. I have been running nodes for more than a year now, never faced this issue. Only thing uncommon would be Tor onion, though I don't think that is uncommon.

I tried to run bitcoind as well, but that also exited after syncing until 24 hours.

Here is the content of bicoin.conf
daemon=1
txindex=1
server=1
listen=1
proxy=127.0.0.1:9050
bind=127.0.0.1
onlynet=onion
walletbroadcast=0

I sorted it out in kind of hacky way. I watched the behavior of Bitcoin-qt during multiple sync attempts I did. The moment it used to come at 24 hrs mark, it used to get stuck there for few minutes. My guess was, it may be in some code path which will cause it to exit after some time. So I decided to perform some operation just as a hunch. And it helped.
Here is what I did - I launched the bitcoin-qt and it started to sync. When it reached 24 hours mark, I waited for a minute or so and then I created a blank wallet using the UI. It did the magic, this time sync moved beyond 24 hours and synced the whole way through. Bitcoin node is now up again and running successfully.


text:
Is it only out of sheer luck that all my "txid"s are unique? How should I handle multi-vout transactions?
I have created a database table simply copying the information from listsinceblock from Bitcoin Core's API. I have a UNIQUE constraint set to "txid + vout", as I'm supposed to. But when, as I'm trying to understand how Bitcoin works at least on a surface level, I do this:
SELECT txid, count(*) FROM "Bitcoin Core transactions" GROUP BY txid;

Then it is revealed that not one of my txids have more than one vout. The count column says "1" for each txid, meaning they all have only one vout.
I've made numerous Bitcoin transactions. Why has none of them ever used more than one vout? And what happens the day this happens? I'm using this table's data in order to automatically update my separate bookkeeping of all my Bitcoin transactions ("transactions" here meaning actual transactions -- not some internal "txid + vout" concept). I obviously don't want some internal Bitcoin logic to result in two different "bookkeeping posts", when it's really just a single Bitcoin transaction!
I'm starting to wonder if I'm simply stupid for not understanding this, or if Bitcoin is deliberately designed to be as confusing as possible. How should I handle the possibility that there will at some point be one transaction which is listed as the same txid but multiple different vout ids?
If it weren't for the fact that my future and survival is dependent on this, I would have long ago given up on Bitcoin and rejected it as "cryptic nonsense". I don't understand what the problem is with just having a clear interface for the actual Bitcoin transactions. I don't care about some complex internal logic and don't want to be exposed to it. I can't escape the feeling of still having missed something important, in spite of all this endless reading and asking questions for years and years.
Using any kind of "intermediate" service or software would destroy the point of Bitcoin. Why can't Bitcoin Core just clearly list the human-relevant information instead of exposing internal mechanisms to the "end user"/programmer? Or is it?

Why has none of them ever used more than one vout?

If each of your transactions only sends Bitcoin to one receiver, then there's going to be only one receiver output in each of those transactions. Hence you only see a single vout per txid.
You can create transactions which send to multiple receivers. You should see multiple vouts for those. You can make them by using the sendmany command or by clicking the Add Recipient button in the GUI.

And what happens the day this happens?

Nothing should happen except that you will see multiple txids with different vouts. In the end, it all depends on your software and how it is handling that. Since it sounds like you have dealt with the uniqueness constraint correctly, nothing should happen.

Why can't Bitcoin Core just clearly list the human-relevant information instead of exposing internal mechanisms to the "end user"/programmer?

If you want human relevant information, use the GUI. The RPC interface is intended for developers and advanced users. The whole point of the RPC is to allow people to build software that use Bitcoin Core and they are going to need to understand and access all of this additional information.


text:
determining the address a transaction comes from
Currently im trying to build an explorer and im stuck on the block/listing transactions.
Currently this is my code.
foreach($info['tx'] AS $key => $value){
            $txinfo = callBTC("getrawtransaction",array("\"$value\"",true));
            echo '
';
            print_r($txinfo);
            echo '
';
            echo '

Hash

'.$value.'

';
            echo '

Time

'.date("Y-m-d H:i:s",$txinfo['time']).'

';
            echo '

From

';
            foreach($txinfo['vin'] AS $key2 => $value2){
                if(!empty($txinfo['vin'][$key2]['coinbase'])){
                    echo '
COINBASE - Newly Created Coins
';
                }else{
                    $from = callBTC("getrawtransaction",array("\"$value2[txid]\"",true));
                    echo '
';
                    print_r($from);
                    echo '
';
                    echo $from['vout'][0]['scriptPubKey']['addresses'][0].'
';
                }
            }
            echo '

';
            echo '

To

';
            foreach($txinfo['vout'] AS $key3 => $value3){
                if(!empty($value3['scriptPubKey']['addresses'])){
                    foreach($value3['scriptPubKey']['addresses'] AS $key4 => $value4){
                        echo ''.$value4.'
';
                    }
                }
            }
            echo '

';
            echo '

Fee

';
            echo '

Amount

';
        }

i got the to addresses fine but whne it comes to the from field i struggle to determine which is the valid address to use.
Lets use block 2092235 for example
https://www.blockchain.com/btc-testnet/block/000000000000003f69d7c8cb4943df2d7a273883eb72024f3305122ed2dc7271?page=1
I use blockchain.com to check against my site to ensure im displaying the proper data.
but when i spit out the transaction for the tx id ac709fc580430d51ab741e339edd184c349306c9881f95085851eef0652b1fb6 i get this...
Array
(
    [txid] => ac709fc580430d51ab741e339edd184c349306c9881f95085851eef0652b1fb6
    [hash] => b388c750f3d15f1fcdb320fbc3398a65a34a3eb6933ca1738729f22a4a8a5924
    [version] => 2
    [size] => 222
    [vsize] => 141
    [weight] => 561
    [locktime] => 2092234
    [vin] => Array
        (
            [0] => Array
                (
                    [txid] => 122e916b2236fb1d6c5d21e886ffe72b3834ca3d81bed51686aa91d5c069ed5c
                    [vout] => 1
                    [scriptSig] => Array
                        (
                            [asm] =>
                            [hex] =>
                        )

                    [txinwitness] => Array
                        (
                            [0] => 304402201c4ff3fa6d7d212760db2c03e39bc824756c10bbac77a10db7665c383e16600b0220146f62d2c0a28d335ecad0f38227259ead389d409259f3af693628443695bbf401
                            [1] => 0258471daabd690819d6cbb34b8ca75f98ba24604960301ce7c90cc5131ab07280
                        )

                    [sequence] => 4294967294
                )

        )

    [vout] => Array
        (
            [0] => Array
                (
                    [value] => 0.01905871
                    [n] => 0
                    [scriptPubKey] => Array
                        (
                            [asm] => 0 2cda63f440de6ab858cf2550daf3b25522d6c66f
                            [hex] => 00142cda63f440de6ab858cf2550daf3b25522d6c66f
                            [reqSigs] => 1
                            [type] => witness_v0_keyhash
                            [addresses] => Array
                                (
                                    [0] => tb1q9ndx8azqme4tskx0y4gd4uaj253dd3n0386xkn
                                )

                        )

                )

            [1] => Array
                (
                    [value] => 72.44723495
                    [n] => 1
                    [scriptPubKey] => Array
                        (
                            [asm] => 0 e179ad3cb0d3bc53cba564cc2e05bc2dc18de1ab
                            [hex] => 0014e179ad3cb0d3bc53cba564cc2e05bc2dc18de1ab
                            [reqSigs] => 1
                            [type] => witness_v0_keyhash
                            [addresses] => Array
                                (
                                    [0] => tb1qu9u6609s6w798ja9vnxzupdu9hqcmcdtvm87gx
                                )

                        )

                )

        )

    [hex] => 020000000001015ced69c0d591aa8616d5be813dca34382be7ff86e8215d6c1dfb36226b912e120100000000feffffff02cf141d00000000001600142cda63f440de6ab858cf2550daf3b25522d6c66f27b5d1af01000000160014e179ad3cb0d3bc53cba564cc2e05bc2dc18de1ab0247304402201c4ff3fa6d7d212760db2c03e39bc824756c10bbac77a10db7665c383e16600b0220146f62d2c0a28d335ecad0f38227259ead389d409259f3af693628443695bbf401210258471daabd690819d6cbb34b8ca75f98ba24604960301ce7c90cc5131ab07280caec1f00
    [blockhash] => 000000000000003f69d7c8cb4943df2d7a273883eb72024f3305122ed2dc7271
    [confirmations] => 1418
    [time] => 1631039838
    [blocktime] => 1631039838
)

then i get the tx id from the vin field to get info on the transaction for that address(the from field) and i get this.
Array
(
    [txid] => 122e916b2236fb1d6c5d21e886ffe72b3834ca3d81bed51686aa91d5c069ed5c
    [hash] => 5fb52307d771c7dadf9f06006340a0acb5ff9ebe15d215d98f08e749d0ee2e59
    [version] => 2
    [size] => 222
    [vsize] => 141
    [weight] => 561
    [locktime] => 2092232
    [vin] => Array
        (
            [0] => Array
                (
                    [txid] => 2739adc2b59de66a9e707ec3e102549dc56a8432e38ef471cb961976a27739be
                    [vout] => 0
                    [scriptSig] => Array
                        (
                            [asm] =>
                            [hex] =>
                        )

                    [txinwitness] => Array
                        (
                            [0] => 3044022077216db352b3024fbb92ff798b618dc3a45fe727077872d2ee5e699ea8fc839d02207dde0f94b0d2cd8900dda6c189134c5d7614278a582e2e1f131c0e16be86534e01
                            [1] => 036e8d75e18796979cdfebcc82d44930d5265ad3820156932194bd7cda5192296a
                        )

                    [sequence] => 4294967294
                )

        )

    [vout] => Array
        (
            [0] => Array
                (
                    [value] => 0.01275647
                    [n] => 0
                    [scriptPubKey] => Array
                        (
                            [asm] => 0 184337352372a5fa6218dd57ea1057305d39c77d
                            [hex] => 0014184337352372a5fa6218dd57ea1057305d39c77d
                            [reqSigs] => 1
                            [type] => witness_v0_keyhash
                            [addresses] => Array
                                (
                                    [0] => tb1qrppnwdfrw2jl5cscm4t75yzhxpwnn3mamh6ff8
                                )

                        )

                )

            [1] => Array
                (
                    [value] => 72.46645714
                    [n] => 1
                    [scriptPubKey] => Array
                        (
                            [asm] => 0 c4520316f8d1dee0a19acde950d0540701d3d013
                            [hex] => 0014c4520316f8d1dee0a19acde950d0540701d3d013
                            [reqSigs] => 1
                            [type] => witness_v0_keyhash
                            [addresses] => Array
                                (
                                    [0] => tb1qc3fqx9hc680wpgv6eh54p5z5quqa85qn35meep
                                )

                        )

                )

        )

    [hex] => 02000000000101be3977a2761996cb71f48ee332846ac59d5402e1c37e709e6ae69db5c2ad39270000000000feffffff02ff76130000000000160014184337352372a5fa6218dd57ea1057305d39c77dd209efaf01000000160014c4520316f8d1dee0a19acde950d0540701d3d01302473044022077216db352b3024fbb92ff798b618dc3a45fe727077872d2ee5e699ea8fc839d02207dde0f94b0d2cd8900dda6c189134c5d7614278a582e2e1f131c0e16be86534e0121036e8d75e18796979cdfebcc82d44930d5265ad3820156932194bd7cda5192296ac8ec1f00
    [blockhash] => 00000000000000d299298de1cfb14276667b7d55e8a1cf43c9dc825babadf058
    [confirmations] => 1420
    [time] => 1631039256
    [blocktime] => 1631039256
)

by looking at blockchain i know which address it SHOULD take (tb1qc3fqx9hc680wpgv6eh54p5z5quqa85qn35meep)...but when i use php and check for last key in array its not always the correct address in other transactions as sometimes the address i need is in a different index(same array tho just different index).
How can i programmatically determine the right address consistently?

Bitcoin transactions do not have a well-defined "from" address. Transactions have inputs, and each of those inputs may or may not have an identifiable address the spent coins were previously assigned to. The result is zero, one, or more "from" addresses, but these don't correspond to any real-world property; in particular, they cannot be used to identify the sender, or to find a refund address. Multiple people can (and do) sometimes jointly produce a single transaction that moves funds belonging to all of them, for example.

agreed but not the question i was asking. i provided the txid to pull the information regarding the from address. please reread it again i have already explained it,

Yes, I'm not trying to answer your question, only pointing out that what you're trying to do is meaningless. If someone wants to answer your actual question, they can.

its not meaningless when you are trying to build an explorer. Its helpful to know what address the coins came from.

https://www.blockchain.com/btc-testnet/block/000000000000003f69d7c8cb4943df2d7a273883eb72024f3305122ed2dc7271?page=1
Blockchain uses it and i understand it fine. Ofcourse there is no from and to its vin and vout. If you looked at the code you would know that i understand this.


text:
In bitcoin core can ScriptToUniv give us wallet address of public key?
a few days ago I created a PR https://github.com/bitcoin/bitcoin/pull/27546
where I proposed ScriptToUniv can give us wallet address of public key But some guy commented
"Concept NACK
Sorry, no. P2PK outputs do not have an address. It's an outdated and confusing practice to refer to them as their corresponding P2PKH address"
as far as my understanding
see we have
private key --> secp256k1 -- > public key --> sha256 --> RIPEMD160 --> Hashed Publickey --> hashed Publickey + checksum = wallet address
and we have the flow of ExtractDestination
PUBKEY -->passed to --> EXTRACT DESTINATION -->PKHash returned
PUBKEYHASH -->passed to --> EXTRACT DESTINATION --> PKHash returned
we pass this PKHash to EncodeDestination which passes it to DestinationEncoder which returns us the wallet address
https://github.com/bitcoin/bitcoin/blob/master/src/core_write.cpp#L165
can someone please guide me where I am getting it wrong ?

See also https://bitcoin.stackexchange.com/a/117426/208

There is no address format that can produce a P2PK script. You can produce a P2PKH address from a pubkey with the process that you describe, but that address will result in a P2PKH script. This is a different script from a P2PK script and cannot be used to make a P2PK script as there is a hash involved. Therefore it is misleading to return an address for a P2PK script as such an address does not exist, and any address that would be returned does not actually map to the P2PK script.

Yes you are right but if we want to know the wallet address of P2PK then we convert this P2PK into PKHash and get the address because this is the only way to find out the wallet address of person which can be already done by the functions ExtractDestination and EncodeDestination in L165 of core_write.cpp so why don't just remove that check  type != TxoutType::PUBKEY and let the bitcoin core return the address of person instead of instead of just ignoring the address field in PUBKEY case . ?

P2PK and P2PKH are two distinct output types. There is no address standard for P2PK outputs. Returning the P2PKH address produced from the same public key is misleading and not helpful.


text:
Using bitcoinlib created wallet on exchanges
I am trying to get familiar with crypto trading, and I know enough Python to be dangerous. Including the ability to created HD wallets using bitcoinlib. My question is, can I use my bitcoinlib created HD wallet(s) to trade on an established exchange e.g. Coinbase? Thank you.

Yes you do, if you generate valid addresses. I still recommend you use a well known and tested wallet instead, like Bitcoin Core it self, Electrum or Sparrow.


text:
Why does the locking script for MultSig contain PubKeys instead of PubKeyHash?
I am reading "Mastering Bitcoin" by Andreas Antonopoulos. In the transactions section, the locking script for normal account(single address) is
OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG
Which I'm sure that <Cafe Public Key Hash> is the address of the recipient. But the locking script for multsig account is,
2 <Public Key A> <Public Key B> <Public Key C> 3 CHECKMULTISIG
My question is that why does the locking script for multsig address contain their public keys instead of PubKeyHashes(addresses)? And also isn't it dangerous for the receiving party(multsig owners) to reveal their public keys to senders..Long shot but if ECDSA breaks, they can't be secure with SHA256 and RIPEMD160 right?

Are you talking about bare multisig (where the locking script with pubkeys goes into the scriptPubKey directly), or about P2SH/P2WSH multisig, where the scriptPubKey only contains a hash of the locking script? Both are possible, but the former is very uncommon (as it doesn't have a corresponding address type, so most wallets can't be instructed to create such outputs).

Yes, I'm aware of P2SH addresses of the multsig scipt. But I'm interested in knowing why the underlying raw script has PubKeys instead of addresses.

My question is that why does the locking script for multsig address contain their public keys instead of PubKeyHashes(addresses)?

Why would it?
The reason for using a hash of the public key in P2PKH is because it resulted in shorter addresses (in Satoshi's time, before compressed public keys, public keys were 65 bytes, so using a 20-byte hash was significantly shorter). Such an argument does not exist for bare multisig, because there exists no address for bare multisig.
In P2SH (or P2WSH) multisig, the issue does not apply either, because what is given to the sender is an address that only contains a hash of the locking script. Whether or not that script uses pubkeys or pubkey hashes does not affect the size of that hash. Using an additional redirection inside the script there would also just be a waste of resources (because at spend time, both the pubkey hashes (inside the locking script) and the full public keys (as inputs to it) would need to be passed).

And also isn't it dangerous for the receiving party(multsig owners) to reveal their public keys to senders

There are certain cases where the senders will know the receiver's public keys, but in general, this is not the case. As said, no bare multisig address type exists, so most commonly, P2SH or P2WSH multisig is used. In that case, the sender only receives the script hash from the recipient.
Regarding the security reduction, my own (and apparently somewhat controversial) opinion is that the pubkey hashing does not meaningfully contribute to Bitcoin's security, and while it is frequently repeated, this is cargo cult. Reasons are:

If ECDSA is broken, any attacker cooperating with miners can already exploit it (because unconfirmed transactions reveal public keys).
Millions of BTC are stored in outputs with publicly known public keys. You can't realistically hope that BTC holds any value after it's assumed ECDSA is broken (as long as ECDSA is commonly used).
Tons of interesting use cases involve revealing public keys to other parties (such as Lightning, or even just multisig between the signers). If we were seriously concerned about ECDSA's security, we shouldn't just be discouraging these, but going as far as outlawing them. That doesn't happen, because ECDSA is part of Bitcoin's security assumptions. Dealing with it being broken is done by migrating to something else, not by patching it up.

There are other answers on this site which go into more detail about it.

Thanks for clarification!


text:
Question: Docker alternative to Tails OS for generating Bitcoin addresses securely for cold storage
I am exploring options to generate Bitcoin private keys and addresses in most secure ways, using Ian Coleman's BIP39 tool. https://iancoleman.io/bip39/
The most recommended OS seems to be Tails OS for using this tool in completely offline mode.
If I used any other minimal linux image in docker, such that it never connects to internet , wouldn't that be equally safe ? We can also ensure to destroy the container and image from local storage after the address generation.
Do I really need Tails OS for this specific use case ?

It would not be equally safe because you are running the container on a machine that is connected to the internet. Even if the guest is not compromised, the host could be, and that would compromise the guest.
Furthermore, docker containers are not even fully fledged virtual machines. They share the host's kernel as well as a lot of other components from the host system.
In the end, the software that you run in a docker container gets executed by something in the host OS, and that has the potential to leak information to an attacker who has compromised the host.

Running Tails on an offline machine removes any existing OS as a factor since Tails is itself a fully fledged OS running on bare metal. You can ensure that the Tails you are running is that which is officially distributed, thereby ensuring that there isn't something else which has compromised it (of course there is the risk that Tails itself is compromised, but that's a different discussion). By physically disconnecting the device from the internet, there is no way for anything to leak to the internet.


text:
bitcoinpaperwallet.com scam lost 14.5 BTC
Last night I made the mistake of using the website (while offline) to generate a wallet. I sent 0.1 then 14.5 BTC to it, and then 1 min later 14.51 was sent out to another paper wallet
here is the wallet I created and you can see the transactions
https://www.blockchain.com/btc/address/1BxPiuddFh7vz83BCFM9ZKUV75jUJyvJUv
any advice on what I can do. I've accepted the loss and the lesson (should have used the offline generator) but want to make sure this doesn't happen to others

Which is the website?

@LucaBlight in the title

"I just lost half a million dollars.... but I've accepted the loss and the lesson".   I don't think even Buddah would be calm under these conditions.

Does this answer your question? What did I do wrong that caused me to lose bitcoin? - the asker of that question used bitcoinpaperwallet.com and a comment says "The site bitcoinpaperwallet.com was sold in April 2018 github.com/cantonbecker/bitcoinpaperwallet And after this time many people wrote that their bitcoins were stolen."

I am really sorry for your loss, unfortunately, there is no way to get those Bitcoins again.
I have seen other people who got scammed by this website like this one: https://www.reddit.com/r/CryptoCurrency/comments/cyd6uj/bitcoinpaperwalletcom_scam_or_not_4_btc_stolen/
The best way to make the private key offline is using trustworthy software and when the computer will never connect to the internet again, otherwise, it will be possible to send the private key created to someone else when the computer is online again.

The funds are still in the scammers wallet as of this moment, as such I'd hold off on paying any experts just yet. It's when it starts to move that something can be traced. I'd report it to law enforcement and get a crime reference. This way when the funds start moving, if it is identified that they have gone to an exchange you might be able to do something (very small chance but still). Basically you or someone you employ can try to contact the exchange, explain the theft and provided the law enforcement reference. The exchange may then freeze funds awaiting a further input from law enforcement, at this point you can then try to get the local police to actively investigate the matter through engaging with the exchange. It would also be worth submitting a report on bitcoinabuse.com as this is used as an open source data repository for risk assessment tools by some entities.

If you have been scammed out of that much money, you might be able to afford to hire a Bitcoin tracking expert where they get a cut of any returned funds, perhaps, just a suggestion.
Forensic experts for Bitcoin do exist. There were people investigating the Mt Gox collapse for instance. They will help you gain evidence, and then you can go to law enforcement to catch the suspect.
Also, the domain name may be a way to find out more about the person, if you can prove criminal activity, then you may be able to get info from the domain registration company.
If you correctly find out the domain is a scam, then it can be reported in a Google Phishing Report, so that this does not happen to others.


text:
how to find name wallet with a btc adress
I sent Bitcoin from one address to another, but I no longer remember the name of the digital currency wallet.
Is there any way to find out its name using a Bitcoin address?
please help me

On Mac: ~/Library/Application Support/
On Windows: %appdata%
If any of the following folder are present, you need to download that wallet software:

Multibit
Bitcoin (Core)
Armory
Electrum


text:
Unconfirmed transaction for over five days
I sent a transaction to someone that makes use of quidax wallet, from my blockchain, and for over five days it has not being confirmed, what could Happened and is it possible for me to get back my fund

Fee=0.00004115 BTC
Fee per byte=5.049 sat/B
Fee per weight unit=1.262 Sat/WU And i got information like received at 09:21 yesterday and i don't know what it means and who received,? Although my confirmation is still 0 of 6

fd998def26c5cd66990e973df62fc128d05a49ed2cab0c3d4a20a0b5ae7396ef

I saw something like : 20,000 5sat/vbyte But i don't know what it means please explain

So i will only be verified when they must have finished with the 51,000 other confirmations,? And again what if new transaction is done on a higher rate after now will they still b ahead of me. And how do i know how many people that will be verified first before me

I am not familiar with this site.. please is their any media like Facebook or Whatsapp you can help chat me frk.


text:
What is Best Address to use to receive multiple payments?
I plan on attaching my Bitcoin Addresse to a program that will pay me multiple times. I plan on setting it and using only one. So which address is the best to use, the one that starts with BC or the number 1?
My fear is that if I put the one BTC address that keeps changing onto the program, then I may not receive multiple payments. Because the address wouldn't be good.
Share Edit Flag

All those addresses have the same structure (a public key hash) and are used the same way.
The difference is, bc1 addresses keep transaction signatures in a separate place in the blockchain than 1 addresses. That is, there's a fee discount when you spend from bc1 addresses. Without any doubts, the newer bc1 addresses are superior.
The reason 1 addresses are still in use is, legacy codebases that aren't updated for bc1 compatibility. Use bc1 whenever possible.

So the BC1 will never change? I plan on leaving it for everyone on my platform, to pay me continuously. So once I set, I dont have to worry?

No, all addresses change, but you can still pay to the previous address without any doubt. You'll always receive it


text:
Running bitcoin-qt as client
I want to configure bitcoin-qt to work as a 'client' for parallel bitcoind server (the same way as bitcoin-cli), but I don't see any relevant configuration options. In my PC bitcoind has folowing configuration: data directory is /var/lib/bitcoind, it is run as 'bitcoin:bitcoin' user (with the same data permissions in /var/lib/bitcoind). Running bitcoin-qt from main desktop user does not work because bitcoin data directory permission differs, running gui app from 'bitcoin' user also does not work.
I want to work sometimes with bitcoind, sometimes with bitcoin-qt. The problem with bitcoin-qt is that there are no separate bitcoind/bitcoin-cli programs. In case of bitcoind I can preserve normal 'bitcoin:bitcoin' data directory permissions and connect to bitcoind with bitcoin-cli. Bitcoin-qt documentation mentions 'rpc_connect' options, but they seem to apply to possible bitcoin-qt clients, not bitcoin-qt acting as a client to bitcoind.
Curently I see the only way to archive what I want: change data directory permissions to main user (who starts bitcoin-qt). But this method is hackish because it requres modification of systemd bitcoind.service file, data permission changes, etc, which I would like to avoid. Perhaps I am missing some way to configure bitcoin-qt properly?

I have found solution which does not require configuring bitcoin-qt (it is not possible according to the answer below) and which still achives what I want. It appears my assumption about impossibility of running GUI app in linux from another (bitcoin) user was wrong: it is possible to do with 'xhost si:localuser:bitcoin' command (allows 'bitcoin' user to access linux graphical server). This method allows to run bitcoin-qt via 'sudo -u bitcoin bitcoin-qt -conf...' on data directory having 'bitcoin' permissions. However, this information belongs to linux stackexchange rather than here.

There’s simply no support for using the Bitcoin-QT application as a RPC client, it needs far more access to state than is provided by that interface to operate.
There’s no real reason to try to separate users like that either way, if the desktop user has access to RPC, what is the difference to it just running the daemon itself? Assuming that loss of the bitcoin wallet is game over, it doesn’t change much.

I disagree with the part "There’s no real reason ..." because it does not address my issue. It was not about loss of wallet, or separating users. I want to run both bitcoind and bitcon-qt (not in parallel) on the same data directory. It is doable if default data access permission are changed to the user running bitcoin-qt, but this method is somewhat 'dirty' - that's why I was asking whether it is doable with bitcoin-qt configuration. Still, I marked the reply as answer because it addresses the question about bitcoin-qt configuration (that it is not possible).


text:
bitcoin feeless transactions
The mobile application cashapp specifically says I can send bitcoin to any address anywhere in the world for free.
Coinbase also says they can do off the network transactions instantly and for free as long as both parties have a coinbase address...how does this work ? Does a miner check these transactions ?
Where does the concept of average transaction fee come into place ?
https://ycharts.com/indicators/bitcoin_average_transaction_fee

These transactions don't go through the bitcoin network, it’s just coinbase/cash app crediting one users account and debiting another.

So I'm assuming coinbase and cashapp have something like a bitcoin core main node, with child nodes and they can issue addresses.... credit and debit how ever they want ?


text:
What is the standard logic behind the ordering of outputs in the vout array for a transaction?
This question and its answers discussed the meaning and purpose of the vout array of a transaction in good detail. However, I have so far not been able to find any good information about how outputs in vout are ordered.
For example, suppose a collaborative transaction involves two inputs and three outputs, where two of the outputs are change utxos that are sent to the respective parties who owned the inputs, would the 0-index vout always be the non-change output? Alternatively, would it be the highest value output (i.e. outputs are arranged in descending value order)? If neither is accurate, what is the vout ordering logic?
For a general transaction, are there any constraints in Bitcoin's consensus/conventions surrounding the ordering of vouts (and I suppose inputs, while we're on the subject)? I.e. is there a possibility that a transaction could be rejected by nodes for having an 'invalid' vout ordering?

For normal transactions¹, there are no constraints on the order of outputs. The general standard seems to be that people randomize all inputs and outputs after assembling their transaction before signing. There is also a Bitcoin Improvement Proposal (BIP69) which suggests a lexicographical order for inputs and outputs. Uniform sorting is meant to help transactions from various wallets look more alike. It is explicitly declared as optional, since it interferes with some other use cases and some respondents considered it worse than just randomized order.

¹There are some exceptions, for example if you use the sighash_single sighash flag, your input will only commit to the one output with the same index.


text:
Does `listsinceblock` show coinbase transactions on a watch-only address?
If I have a wallet where I've imported someone's address "A" as a watch-only address, and I run listsinceblock (the specific parameters may be irrelevant to this question), would I be able to see the coinbase transactions where the output was "A"?


text:
How to get bitcoin transaction nonce from transaction signature?
Subj.
Looking for a code for calculate/get bitcoin transaction nonce. Help me please.
???
Thank you.

You cannot. If you could compute the nonce of a signature, you could also compute its private key.

I'm going to assume by 'nonce', that you're referring to the value that, when hashed with the rest of the data in the block, equates to a value that's lower than the "target" (difficulty) for the epoch.
If that is the case, then you can get this information from a block explorer website like Blockcypher (url - https://live.blockcypher.com).
As an example, I chose to look at the block submitted and validated most recently (block height 706,890).

Clicking the hyperlinked block height # in the screenshot above will take you here - https://live.blockcypher.com/btc/block/000000000000000000067119c310ecee2c2f4b79b96e2a616ff93bf31236e1d6/
Once you arrive at that page, you have to click the 'Advanced Details' button, which will pull expand the information you get shown.

Once you do this, you just need to scroll down the page a bit and you'll be able to see that block's "winning nonce".

Boom, that's it.
If this isn't what you were looking for, just write a comment to this 'answer' clarifying and I'll see if I can clear anything up for you.

Nonce of a block is same nonce of bitcoin transaction ? Thank You.

I believe this answer is confused; OP is asking about the ECDSA nonce in signatures, not about the block mining nonce.

Hey @PieterWuille , I don't disagree with you (at first glance looking at the question), but given the asker's unfamiliarity with how Bitcoin works (from a distance), I was a bit skeptical that they were asking about something as involved as the deterministic nonce generated per signature on the protocol. A question like that would likely be more appropriate for the (pure) cryptography StackExchange


text:
How to calculate modulo (%) of bitcoin publick key?
Good day.
How to calculate modulo (%) of bitcoin publick key ?
Absolutely any methods are welcome, please.
Br


text:
Are Bitcoin/cryptocurrency trades or earnings taxed in Albania?
Are Bitcoin/cryptocurrency trades or earnings taxed in Albania as of the beginning of 2020?
I've also seen some news of a European standard that countries are adopting. This may hold the answer to the question. I also understand Albanian law changed in the middle of 2020.

I’m voting to close this question because this is not the appropriate place to ask for tax advice.

This isn't for free legal or tax advice. It's for student research.

Similar questions related to taxes have been accepted and answered . Policy should be conistent


text:
wallet seem to be encrypted or corrupt
I found my wallet but i cannot access it tryed with bitcoin core. But gives error i think i encrypted or corrupted file. I openend with WinHex but only see 2020 in it.try to find hash but no succes. i will upload printscreen all help with be appriced.

Your entire file seems to contain just spaces, based on that hex dump. There is no key material in there.

is it maybe encrypted? wallet.dat file is 180mb

I cannot tell based on what you're showing here.

i understand what do you need

only see 2020 in it.

Hexadecimal 20 is the ASCII space character. If your file contains nothing but 20  then it contains no useful data and no useful data can ever be extracted from it†.

is it maybe encrypted?

Encrypted data generally looks like a completely random sequence of hexadecimal values between 00 and FF. If your file contains nothing other than repeats of 20, it is not encrypted.

wallet.dat file is 180mb

Then I guess you might not have looked at every byte to verify that all are hexadecimal 20. I would use a program or script to see if somewhere in that 180 MB is any byte sequence other than repeats of hexadecimal 20. But the likelihood of recovery seems small.

https://superuser.com/q/559772/52492 (od -x wallet.dat | head e.g in WSL)
https://www.codeproject.com/Tips/720458/Counting-Occurrences
https://www.perlmonks.org/?node_id=1159245

† you could encode a small number, e.g. 7458 as a byte and a count of repeats but this is irrelevant in the context of recovering a Bitcoin wallet file


text:
Connecting a Hardware wallet to a full node
I'm trying to connect my hardware wallet to my personal full node for the sake of privacy. I need to know the node's IP, port, and RPC credentials. The first two are easy, I can see my full node in bitcodes.io that's up and running. I added the
rpcuser=xxx
rpcpassword=****

to the bitcoin.conf file. But When I try to connect through my hardware wallet application, it says: The node is not reachable. I'm not sure whether the bitcoind is reading the rpc inputs from the config file or not. Is there anyway that I could try to reach to my node to make sure it's reachable using the rpc credentials.
Here is the content in the bitcoin.conf file:
prune=0
txindex=1
server=1
daemon=1
rpcuser=letsbegin
rpcpassword=*****
externalip=xx.xx.xx.xx

What hardware wallet software?

It's the Ledger Live

How to connect your hardware wallet to a full node depends heavily on what wallet software you're using. But assuming your software connects to a full node via the bitcoind RPC interface:
By default, the RPC listener only listens on localhost. If you want to connect to the RPC service from another computer, you'll have to allow other connections by including these lines in your bitcoin.conf (replace:
server=1
rpcallowip=<add the IP you are connecting from here, or rpcallowip=* to allow all IPs>
rpcport=8332

If you want to simply test whether your bitcoind RPC is accessible, you can simply make an HTTP request to the RPC host at port 8332 from the computer you're trying to connect from.

So, here is the issue: Both the connecting computer and my node are within the same network i.e., same IP address! I added the commands that you suggested, still I can't reach to my node even when I make an HTTP request!!!

By same network do you mean same computer? If so, then make sure you use "127.0.0.1:8332".

No not the same computer. Two different computers connected to the internet at my home. When I run the get networkinfo command:"name": "ipv4",
"limited": false,
"reachable": true,
"proxy": "",
"proxy_randomize_credentials": false
},
{
"name": "ipv6",
"limited": false,
"reachable": true,
"proxy": "",
"proxy_randomize_credentials": false
},
{
"name": "onion",
"limited": true,
"reachable": false,
"proxy": "",
"proxy_randomize_credentials": false

When I check the external ip address for both the computers I get the same ip! Should I use internal IP address assigned to my node?

@Pishi - yes, use the internal IPs for this.

I still have the issue of not being able to connect to my node. Even when I enter the local IP address for my node in a browser with the port (8332) still I can't connect. Do you think it's a firewall thing imposed by the Ubuntu running on my node? The node is running on a static IP with the port forwarded in my router. The node currently has 55 connections and roughly sends 10G of data daily!!

Did you add the line rpcallowip=<the local IP address of the computer you're connecting from>?

Yes, I added and for the IP I added the external IP and the Internal IP but none worked.


text:
Is there something in a debug.log from 2011 that would tell me if there are BTC in an old wallet.dat?
I took an old laptop out of storage today because I recalled trying to mine BTC years ago. I remember giving up quickly because, whatever the UI was, it showed that I had mined 0. I'd like to confirm that.
Is there anything in any of these files that would confirm that there's 0 BTC in these? debug.log seems to be the only plaintext file.
Date modified on these files are in the range of 05/2011 ~ 06/2011
/user/AppData/Roaming/Bitcoin
-database/    (9MB)
-.lock        (0KB)
-__db.001
-__db.002
-__db.003
-__db.004
-__db.005
-__db.006
-addr.dat    (18MB)
-blk0001.dat (279MB)
-blkindex.dat(133MB)
-db.log      (0KB)
-debug.log   (3MB)
-wallet.dat  (104KB)

What I would do in this case (the easiest approach):

Copy wallet.dat to a new directory called Bitcoin in %appdata%
Run latest Bitcoin core
Open the console and do
dumpwallet C:\Users\yourusername\Desktop\wallet.txt
Quit Core and delete your new Bitcoin directory. (Don't forget to delete it, it might become larger than 100 MB, to save space)
Save my script with Ctrl + S and name it dumpwallet.html. Open it in your browser. Copy the wallet.txt output here so that only the private keys are listed.
Import wallet to Electrum: "New wallet > Import private keys > Copy from the webpage output"

Then you can see your balance or spend from it.
The tedious approach is to use db_dump of db-util to dump all the transactions and calculate the final balance by yourself. I would not bother doing it this way.

Thank you. The old computer is extremely slow. Can I move these files to a new computer and do this, or is there something tied to that machine?

Yes, you just need to copy wallet.dat to new folder named Bitcoin in %appdata% on your new computer. Then when you launch Core, it'll show 0 BTC however that doesn't mean anything, so just follow the steps above then. I can also write in more details on "import wallet to electrum" once you come to that step

Thanks. Was able to follow these steps. Looks like the best block at time of backup was mined on 2010-03-21, and there are 1000 lines in here. One with label= and the rest with reserve=1. If I did this correctly, I'm looking in Electrum and they indeed all have a balance of 0 and Tx of 0.

reserve means unused, so yes.

Thanks. When I run Bitcoin core, will it ask for a passcode? Because I don't have it.

@user114196 If the wallet.dat has one, yes.


text:
How can one make a transaction that any address can claim it just by solving the scriptPubKey?
I just learned that Mike Hearn created a Bitcoin Puzzle transaction where the first person to solve its scriptPubKey, could claim that transaction's amount as a reward.
The thing is... Aren't all the transactions forced to have a destination address? So, even if the winner solves the scriptPubKey, how can then he/she divert the funds to another destination address?

Aren't all the transactions forced to have a destination address?

No.
Transactions never contain addresses. Transaction outputs contain only a locking script and a numeric amount.
There are no addresses in the Bitcoin blockchain.
Addresses are a way for a payee to construct a barcode that can be shown to a payer, from the barcode the payer can construct a standard locking script that only the payee can unlock.
To spend an output as an Input in a new transaction you only have to write an unlocking script that sets up values in the stack that cause evaluation of the locking script to produce a boolean value of true.
It is trivial to create a locking script that always evaluates to true.I
See

In what format does a block store the transaction data?

In Bitcoin coins are not send to addresses. Instead, coins are locked with locking scripts. You own the coins that you can unlock.
Addresses are how receiving wallets inform paying wallets on how they want their coins locked.
For example, if I'm paying you and your wallet send me this address 1N9Cby5NDPsLDnLnTEsYXP4eyWGrfuen7C she's telling my wallet that she wants their receiving coins locked in a P2PKH (Pay to Public Key Hash) with the public key hash e7e7a79d7d9d23b9dc7dcbd81fead779b2d7167d
So, my wallet will broadcast a transaction, which will unlock some previous coins I have, and lock them to the following script:
OP_DUP OP_HASH160 e7e7a79d7d9d23b9dc7dcbd81fead779b2d7167d OP_EQUALVERIFY OP_CHECKSIG
Your wallet will be pooling the mempool/blockchain waiting to see this transaction there. The second it sees it, it will tell you "paid" or "confirmed".
Address prefixes indicate the type of script:

starts with 1 = P2PKH
starts with 3 = P2SH
starts with bc1q = segwit
starts with bc1p = taproot


text:
Doesn't storing the "recovery seed phrase" for a wallet defy all logic?
I've heard many times that you are supposed to write down a "recovery seed phrase" (a series of English dictionary words) on a piece of paper and store that securely so that you can recover your coins when you inevitably lose access to your wallet.dat.
But doesn't this defy all logic? If this phrase alone can recover the wallet.dat (which feels like magic to me, but I'll accept it as the truth), what happens if:

There is a fire and it burns your coins with the paper?
A burglar steals the paper and takes your coins?
The government seizes the paper and takes your coins?

Even if you say "I'll buy one of those fireproof metal plates where you put in the seed phrase with the little metal letters", that only protects against the first hazard.
And even if you put the piece of paper (or metal plate) inside a fireproof safe, that only stops (at best) number 1 and 2. The government will not be scared to force-open the safe or make you do it under gunpoint, and there's your recovery phrase.
And if you put your coins on a hardware wallet and secure that, and still store your seed phrase in your computer, then somebody could grab that remotely through one of the numerous security holes that computers/OSes/software have today, restore the the wallet and take your coins before you ever know.
It seems that storing the recovery phrase ONLY protects against your own clumsiness and hardware dying, but not against all the other serious threats.
I've spent so long thinking about every possible method to keep my Bitcoins safe, but I just can't find a single method which I'm not myself able to quickly poke huge holes through...

Sure, for every backup scheme there exists a disaster which defeats it.  Nothing is 100% effective.  Writing down and storing the phrase mitigates some common risks, at the costs of increasing some others which are less common.  If you don't think it's worth the tradeoffs, you can come up with something that fits your risk profile better.  But you do have to actually evaluate those risks and their severity, rather than insisting on eliminating every single risk that you can imagine.

Bitcoin's motto "Be your own bank" requires it that everyone takes responsibility over their coins. Bitcoin wasn't designed as an infallible asset. It instead aims to be something between a payment system (like SWIFT) and easily transportable gold.
If you think banks are safer than your home for money (that is, you don't want to take responsibility) banks are a better option for you.
What might make Bitcoin better for you could be an encrypted mnemonic seed system. There is no proposal, famous enough to make me aware of. It's definitely technically possible, and easy enough for Bitcoin techies to implement on their own.

The government seizes the paper and takes your coins?

Check out brain wallet. Who said that you needed a physical backup?
Though I would, instead, use a cascade of multiple hashing algorithms that I have chosen and memorized with their order, along with a passphrase that I have chosen. This requires less memorization.

I truly hope that nothing whatsoever about my question indicates that I would trust a "bank" for one nanosecond, because that's completely incorrect. The concept of "brainwallets" fascinates and disturbs me. I would never be able to memorize that, not even if my life directly depended on it.

@M.Bartol I wrote "you" as "one", so don't take it personally :) In general it seems backup encryption solves the most of your problems.


text:
How are txns sorted correctly in Merkle trees between nodes and validated via Proof of Work
I am interested in exactly what happens to transactions in the pending block (block that is being mined at the time). From what I understand, transactions are the stored as a Merkle tree hash inside the block, along with the parent hash, timestamp and nonce. During mining, the miner is hashing the block data with a different nonces' trying to achieve the target hash. I assume what they are hashing is all the block data including the merkle root. But the merkle root must be different to each miner/node due to transaction order and the generation transaction, so how do other nodes come to consensus if their transactions are different. There is a hole in my understanding.
Furthermore, when transactions are broadcasted across the network, nodes will receive them at different times due to network latency etc. and miners can rearrange the order of transactions due to fee incentives, but this changes the merkle root. I understand that miners prove they have done the work to validate the transactions, but what steps do other nodes take to go 'looks legit'. I imagine they would use the nonce provided by the block creator to hash their own copy of the block and see if it in within the target.
Also, If PoW is done on the block data with the merkle root, how can new transactions be added to the block? Wouldnt the tree have to be hashed again and the PoW would have to start from the beginning. Does a miner wait for the block size limit to be reached before performing PoW? I don't understand how PoW can be done on a dynamic flow of transactions, and how every node can have the exact same set of everything to do PoW on.
Can someone please explain what I am missing? How are transactions sorted by different nodes? How do transactions enter the merkle tree? How do other nodes validate the new block?
Thank you heaps.

But the merkle root must be different to each miner/node due to transaction order and the generation transaction,

Correct.

so how do other nodes come to consensus if their transactions are different.

They don't. Every miner is fully responsible for the choice of their own transactions. There is no need for different miners to agree on the transaction selection. The winning miner decides the contents of the winning block, and others go along with it, accepting their transaction selection (unless the included transactions are objectively invalid, which makes the block invalid - to miners and other nodes).

I imagine they would use the nonce provided by the block creator to hash their own copy of the block and see if it in within the target.

There are many block validity rules that are performed by all nodes, including the verification of proof-of-work, like you say. Other rules include verifying that all transactions are valid, that no theft occurred, that no double spending occurred, that no money is printed by the block (beyond the permitted subsidy), ...

Wouldnt the tree have to be hashed again

Yes.
There are a number of layers involved to updating a miner's candidate block. Each is much faster than the previous one, but done much more often:

Typically the mining software will occasionally (say, every few seconds) build a new block template to work on, which includes transaction selection.

An intermediate layer changes the coinbase transaction (which includes payout address, as well as an "extra nonce") every so often. Every time this happens the Merkle root changes. However, by caching the inner nodes of the Merkle tree that are just right of the leftmost branch in the tree, this is just O(log(n)) work in the number of transactions (e.g. a block with 2048 transactions only needs 11 hashing steps to recompute the Merkle root).

The lowest-level hardware layer cycles through the 232 nonces in the block header, all with the same Merkle root. This is extremely efficient.

and the PoW would have to start from the beginning.

Yes, but this is irrelevant. PoW doesn't have "progress". You don't lose anything by starting over, as long as you're still trying hashes all the time. Every candidate block you try (combination of tx selection, coinbase tx, nonce) has an independent chance of meeting the PoW target (a chance equal to 2256 / target). If that chance is 1/c, and you perform h hashes per day, you will find h/c blocks per day - regardless of which transactions those attempts are for.

Thank you Peiter! Very helpful answer indeed. I understand that blocks are assumed legitimate unless rejected afterward, which causes a fork. How do nodes get transaction information from the block that has just been mined to validate them? Do full nodes have to store transactions in plain text, and other nodes request this information. I don't understand how transactions can be found from a merkle root, it would have to be "unhashed". As for confirming transactions via cryptography, is this done nodes before they are appended to the merkle tree? Or in the mempool somehow? Thanks

Adding to my comment; I understand that the merkle root is part of the block header and txns are stored by full nodes. Nodes can verify transaction inclusion in a merkle tree just from its root? How is this possible when the root is a hash that is one-way? Similarly, how do blockchain explorers gain the information of transactions (input, output etc.) with only the transaction ID?

Nodes request the full block data from each other when relaying a new block. They verify the Merkle root by recomputing it from the transactions.


text:
51% attack, miners, nodes or both
If 51% of the hashrate was controlled by bad actors mining invalid blocks, this would become the longest chain. Where do nodes come into the 51% attack? The canonical chain is the longest chain. Is this true even if less than majority of the nodes accept it. I assume that the canonical chain is the one which majority of full nodes accept as the canonical chain, but how does this fut into block height. Would a 51% attack have to be 51% of hash power and nodes or just hash power? If so, why?

A 51% attack involves just 51% of the hashrate, no nodes are involved.
With a majority of the hashrate, miners can construct a new branch in the chain that overtakes the chain that was previously accepted.
It has to be an otherwise valid chain, as otherwise nodes would reject it. The attack doesn't let the 51% attackers make the network accept any invalid transactions - it can just roll them back.

Thank you. But aren't 51% attacks for producing invalid transactions, otherwise what is the point of an attacker? And how is it an attack? I assume it has to do with the protocol. Also, don't invalid transactions cause forks all the time in the blockchain? If this is true, wouldn't that produce the longest chain temporarily. I know that nodes accept the valid blocks, and the legitimate blockchain is the longest one. How do you have two competing chains with all valid transactions, what is the point? How does node know which block to add it it's own copy if there are two valid blocks?

The point of a 51% attack is reverting transactions: taking money back after paying someone, and then spending it again. Or it can be used to censor a transaction from being confirmed. A 51% attacker also gets 100% of block rewards, which may be an incentive. But in no case can it be used to force the network to accept invalid transactions. The money must exist, and the sender has to have the key to spend it.

As for choosing between valid chains: the rule is that (a) among all fully-valid chains (b) the chain with the most work (typically: longest chain) is taken and (c) in case of ties, the chain with the first-seen tip is preferred.

Invalid transactions do not cause forks; they're just immediately ignored by the network and dropped on the floor. The same is true for blocks that contain invalid transaction, and any chain that contains such a block.

Thank you for the detailed response Pieter! Understood. However, as for nodes, since they can't prevent 51% attacks, do they contribute to security by participating in consensus of the validity of transactions? I understand the more nodes, the more secure the network. I know they help validate blocks, is there some consensus mechanism between nodes of what is valid? Though transactions are objectively valid or invalid, so I can't see how that works. And do nodes actually contribute to decentralisation?

Nodes matter through economic effects only. Miners aren't going to be inclined to try producing invalid blocks if there are economically relevant independent nodes verifying the blocks they produce. But the effect of that is hard to quantify (when is a party running a node sufficiently relevant?). It's easier to just see it as an everyone for themselves: if you don't want to be tricked into accepting invalid blocks, use a full node yourself. If you do, you don't need to worry at all anyone about what anyone else is using.

Thank you! About to set one up, keen to dive into it.


text:
Can I see the workings (console) of my bitcoin full node?
I have just completed the IBD of my bitcoin full node on Bitcoin Core on Linux. When I open Bitcoin Core, i just get the basic wallet interface. It there anyway of seeing what the node is doing behind the scenes through some sort of console and interface where I can search through the blockchain too?
If not, Is it possible on Ethereum clients?
Thank you

You mean something like tail -f ~/.bitcoin/debug.log (in a terminal)?

You are running the Qt version of Bitcoin, which includes the GUI. If you have bitcoind, you can quit the Bitcoin application and type bitcoind into your terminal.
Otherwise, type tail -f ~/.bitcoin/debug.log in your terminal to see then end of the debug file, which will show you when new blocks arrive.
Alternatively, you can install bitcoind from Bitcoin.org. This is a different package than Bitcoin-Qt. Bitcoind only runs "in terminal" so there is no GUI.


text:
Y coordinate of PubKey on elliptic curve prefix
Public keys in the form of 04[x,y] can be compressed since the x axis is symmetrical. Hence we only need the x-coordinate with the 02/03 prefix which states if Y is odd or even. I don't understand the latter, are odd/even on an elliptic curve the same as pos/neg on a Cartesian plain? This makes sense since negative integers can't be expressed in keys. So would the 'negative' Y-coordinate correspond to an 'odd' (03 prefix). If so, how are these coordinates differ in odd/even if the x axis is symmetrical?

Yes and no.
The X and Y coordinates of points on the secp256k1 curve are integers modulo p = 2256 - 232 - 977. Positive/negative don't exist there, as modulo p it holds for every a that -a = p-a.
So, we need another criterion to distinguish the two solutions for y for the equation y2 = x3 + 7.
There are a number of possibilities:

High/low: we could simply distinguish them based on whether they are below/above p/2. If *a < p/2, then its "negation" p-a will be > p/2. As p is odd, no point is equal to p/2 itself.
Even/odd: what the standard picked is looking at the parity of a when brough to range [0, p). Because p is odd, negating any number except 0 will change its parity. And it can be shown that no solutions for y=0 exist.
A third possibility is using quadratic residuosity as a tie-breaker. It turns out that of the two solutions for y, one will always be a square modulo p, and the other won't be. This is perhaps most similar to solutions in the real numbers and their sign: the postive numbers in R, just like the quadratic residues mod p, have a square root - and their negations don't.

So yes, it is somewhat like positive/negative for real solutions, but that "somewhat" is just a property that is true for half the domain, and which is complemented when negating the coordinate.

Thanks Pieter! To fully digest that i will need to learn some more EC arithmetic. Also, how does the modulo function work here? So are the number of possible points on secp256k1 the remainder of y^2 = x^3 + 7 divided by p = a large proven prime less than 2^256?

The curve consists of all points (x,y) for which y^2 = x^3 + 7 (mod p), or in other words: y^2 - x^3 - 7 is a multiple of p. And yes, p = 2^256 - 2^32 - 977 is a prime number.

The number of points satisfying such an equation was an unsolved problem for a long time, but since 1985 a reasonably efficient algorithm exists: https://en.wikipedia.org/wiki/Schoof%27s_algorithm (warning: not easy). Without this, elliptic curve cryptography wouldn't be possible.

Fascinating, thanks again!


text:
Appending txns to merkle tree on PoW efficiency, true hash rate
As I understand, when miners add transactions to their candidate block from their mempool, they append the txn to the merkle tree, which requires more hashing, as well as the hashing/maths involved with validating transactions. Wouldn't all this waste some hash power for the PoW?
While writing, I am realising that obviously, there is an incentive to add more txns for fees, and also that blocks will probably fill up quickly, and all the computation required for the block and validation is insignificant in comparison to PoW. Is this true?
What portion of all the computational power (hashes) is for PoW, in comparison to other things?

The current network hashrate is around 150 EH/s, which means you need to compute around 90,000,000,000,000,000,000,000 hashes for every block. This is an incredible amount of computation with energy costs comparable to smaller countries.
Creating a merkle tree from mempool transactions and validating them, on the other hand, can be done easily even on a low-end consumer laptop. Now, there are multiple miners and mining pools doing that, but it doesn't change the overall picture. Proof of work easily dominates all other computation done in the bitcoin network.


text:
Are a new set of keys created for each UTXO, or can multiple UTXOs be locked by the same PubKey?
I understand that each transaction, new pairs of keys are generated, usually derived from a master key say in an HD wallet. If your change for a transaction or received BTC Is in multiple UTXOs, are separate pairs of keys made for each?
Is my understand a bit wrong? Because when you receive BTC, do you generate a completely new address (from newly generated keys), or one tied to UTXOs? I imagine the former. If so, then do wallet providers to minimise the amount of UTXOs? Say that combine all the BTC in my wallet into one UTXO, with one set of keys far down the HD derivation path.

You can have multiple transactions sent to the same address (address reuse), it is just not recommended as it is not good for your privacy. (In this case you have multiple UTXOs that can be spent using the same private key.) A chain observer can see your increasing effective balance at that address rather than you receiving funds to multiple addresses and those multiple addresses not being linked.

Because when you receive BTC, do you generate a completely new address (from newly generated keys), or one tied to UTXOs?

Newly generated keys from your HD wallet.

If so, then do wallet providers to minimise the amount of UTXOs?

Wallet providers do consider UTXO or coin selection when spending UTXOs. There is generally a trade-off between privacy and minimizing the number of UTXOs in your wallet (and hence the future transaction fees you will have to pay).

Say that combine all the BTC in my wallet into one UTXO, with one set of keys far down the HD derivation path.

You can always create a transaction that sends all your UTXOs to a single UTXO (UTXO consolidation) but as I said earlier this isn't great for privacy as a chain observer now knows all prior transactions and the total balance are associated with a single individual.


text:
How do nodes contribute to security when the power comes from mining and what is the chain of transaction validation?
Blockchain security comes from the decentralisation of hashing power by miners. They append transactions to a block, perform PoW and add them to the blockchain when that validate blocks. How do nodes contribute to this? Doesn't all the validation power come from the longest chain, which is decided by miners. And how do miners detect an invalid block that has been added to the blockchain?
When transactions are broadcasted, I though that public key cryptography is used to verify the transaction. At what level does this happen? Do nodes do this, and if so, is it every single node? When a block is added, do miners perform steps on the block to make sure they are legit. And what does an illegitimate transaction look like?
Thanks

Miners offer up blocks to the network hoping that their offerings will be accepted. Other nodes may accept or reject such blocks. A node that accepts a block adds that block to their copy of the blockchain. Nodes that don't accept a particular block don't add it to their copy of the blockchain and don't pass on that block to anyone else. Any miner that is consistently a source of bad blocks is likely to be ignored thereafter.
Miners can't spend income from a block until a further 100 blocks have been added on top of their block. So miners have a great incentive to only offer up blocks that are acceptable to everyone.
All nodes validate blocks and the transactions in them. This consists of checking that the blocks and transactions conform to a set of common rules. These rules are often called the consensus rules. The rules protect the interests of the buyers and sellers in transactions.
Nodes will eventually be ostracized if they consistently apply different rules and attempt to pass on blocks that meet their different rules but don't meet the mainstream rules.
All nodes called "full nodes" do check hashes and perform cryptographic checks on signatures. Some nodes (Simplified Payment Verification or SPV nodes) rely on other nodes to do much of this work, but they will still perform some checking themselves.
The classic example of an illegitimate transaction is one that attempts to spend money that has already been spent in a prior transaction. A trivially illegitimate block would be one whose independently calculated hash is greater than the current target value (inverse of difficulty)