text:
Is it possible to track stolen Bitcoin after exchange
I don't know if someone can help me but I found out someone has stolen several times some crypto of me, mostly bitcoins. He had access to my computer and my phone to do the Google Authenticator because he is my IT guy.
I know who it is and everything is on police investigation but they can not do much on it at this moment.
So I would like to know if there is a possibility to track my Bitcoin transfers after they have been exchanged to another crypto.
When I look on the blockchain we just see 1 transfer and after this no trace anymore.
We already know he exchanged some Bitcoins to Ethereum, but how can we track or trace this exchange?
Is there a possibility to know which Crypto Wallet Company received my stolen Bitcoins?
Thanks for your help.

Does this answer your question? Can bitcoins be traced to scammers OR Can a Bitcoin address be traceable to a crypto exchange?

No this doesn't give an answer on my question. I found the transaction on the BlockChain but probably they exchanged the Bitcoins to Ethereum before they send it to an other wallet. How can I find a trace from the exchange from BTC to ETH??? Is it also possible to know to which wallet (Crypto wallet company) my BTC where send, so I can contact them.

My second link is to an answer which addresses your last question. Even if you could trace an exchange, the exchange may want proof before disclosing information relating to their customer's financial data - they might require a court order.

If tit stops after one transaction then it's probably not exchanged into Ethereum yet. Because you need one deposit transaction into an exchange and then you can see in the blockchain the consolidation of the coins into another address usually. I'd need more details why you think it's exchanged already into Ethereum

I would like to know if there is a possibility to track my Bitcoin transfers after they have been exchanged to another crypto.

There is always a possibility but it is generally beyond the capabilities and resources of a single victim. If you and other identifiable victims have lost the equivalent of millions of dollars then you may be able to get local police engaged. Otherwise you will need to spend large sums of money with blockchain analytics firms and gather evidence that can eventually be built into a legal case that can be used to compel exchanges to divulge confidential customer data. Legal costs may be substantial and involve lawyers in several jurisdictions.
Remember that cryptocurrencies like Bitcoin were designed to make this difficult. Services such as mixers were created to make it even harder. Following money through multiple cryptocurrencies will be harder still.

There were several transfers from your wallet to the thiefs wallet(s). This would be the chance to catch the scammer:

All involved bitcoin addresses needs to be analysed to see if there are more addresses belonging with a high liklihood to the same scammer.
All outgoing transactions from each of the addresses of 1) needs to be traced if they end up in one of the millions of known exchange addresses
If there are evidences then the police should ask the exchange directly (or via help of their peers in the exchanges country) for any information about the scammer which is likely their client. This can be the id, bank account, a bitcoin withdrawal address or an altcoin withdrawal address. In the first two cases you can claim back the lost funds. In the last two cases this is the starting point for a new analysis/tracing

If someone moves bitcoin to an exchange then the follow on activities aren't visible in the blockchain anymore, then the exchanges support is needed.
To be more specific I'd need to see the bitcoin address(es) where the coins went to after leaving your wallet.

I know the thief(s) transfered BTC to another wallet. This is one of the links: 18yQvmCvGH7MvmwzH4uagfa3n7VyoL76f4 from the BTC transactions. But how can I see those BTC are exchanged to another crypto? How can I see to which wallet my BTC were send?

This address received 0.00137400 BTC it's not at an exchange yet. When the bitcoin find its way to an exchange then only the exchange can tell you (or the police) what happened then. So if their client exchanged the bitocoib into Monero then the exchange has it in their books (this isn't visible in the bitcoin blockchain).

So if the thief exchanged this amount of BTC in other crypto I can not track it further? He already admitted to the police that he changed the bitcoins to other crypto but I don't have details at this moment.

If he admitted then I wouldn't care about this anymore. Nobody can make the thiefs transactions unhappen. You only can claim the stolen value back. Nevertheless where the funds are now, if the thief is known you need to claim it back with help of police or a lawyer.

The problem is that I don't know how much he has stolen from my wallet in total and maybe other people. That's why I try to find as much information to trace it.

Do you know how many bitcoin you purchased in total and how many is left in the wallet? Then you would know what is missing. Each wallet has a history where you can see all transfers in and out. There I'd start. And if he doesn't admit it then tracing for all suspicious outgoing transactions would be the next step

I'm listing up the suspicious outgoing transactions but with this I still don't know how I can find to which wallet company my Bitcoins where send and I can not find the exchange transactions between Bitcoin and Ethereum on the other wallet. Is there a possibility to find it out?

May be. But I'd not purely concentrate on the flow of your coins, you have much more chances to find evidences if you follow the thief. E.g. if the thief owns bitcoin address A then analytics might find out that addresses B,C and D belong as well with high likelyhood to the same person. And often it's easier to trace one of those coins.

You need evidences who stole the coins and it's not important where the coins are now. The bitcoin transaction cannot be reverted you can only catch the thief and claim back what you lost. Starting point for this is one or more bitcoin addresses of the thief. I understand if you don't want to publish it here. Just want to point out how the tracing works.

I know who stole the coins but we don't know how much he has stolen. Maybe he also maid other victimes and that's why I'm looking how I can find back all transactions. We only have 1 bitcoin address from thief and he only received Bitcoins on it. That's why we think I directly exchanged them for other crypto or for withdrawal. So my question is how can I find the exchange transaction without having access to the wallet where the exchange has been done?

Without the wallet I have only one idea (which is less precisely): Analystics needs to be done from the one known address to find other addresses belonging very likely to the same person.


text:
How Bitcoin restricts the mining time?
How Bitcoin restricts the mining time?
We know cryptocurrency systems restrict the mining time of a block to a certain limit for security reasons. For example, mining time for Bitcoin is ~10 minutes. Some other cryptocurrency system have different mining time limit like 2-5 mins and so on. That restriction is imposed with a constraint i.e. precondition of number of leading ZEROs in the calculating hash for miners.
The question is how the cryptocurrency algorithm becomes certain that the mining time will be exactly as the imposed limit for miners? Like, theoretically it is never possible to get other miners strength in the network, no? Is it just based on approximation?
If it is based on approximation, then, What if all the miners in a group for a particular block are accidentally chosen poor? In that case the mining time will be more than 10 mins. It can even be 20 mins. Won't it violate the limit constraint?

How Bitcoin restricts the mining time?

The mining time is not restricted at all. Blocks are simply found at random times with an expected interval of roughly ten minutes. Miners perform quintillions of hashes of block candidates per second, each of which has a minuscule chance of resulting in a sufficiently low block hash that is required for a valid block. Every 2016 blocks, the difficulty level gets adjusted to reset the expected interval to 10 minutes: if blocks were faster, difficulty increases, if blocks were slower, difficulty decreases.

What if all the miners in a group for a particular block are accidentally chosen poor?

There is no pre-selection of the miners, all miners are working all the time. Each miner has a separate set of block templates they're trying: the first transaction in a block pays the mining reward to the block's author. Since each miner is trying to pay themselves and they have different recipient addresses, each miner's blocktemplates are unique to themselves and thusly never redo work of another miner.

In that case the mining time will be more than 10 mins. It can even be 20 mins. Won't it violate the limit constraint?

There is no time limit. The next block is found whenever someone finds the next block. This varies wildly, sometimes the network produces five blocks in one minute, sometimes it takes ninety minutes until the next block is found.

Yes, It's based on approximation.
Mining difficulty periodically updated to make sure the block time stay around 10 minutes.

What if all the miners in a group for a particular block are accidentally chosen poor? In that case the mining time will be more than 10 mins. It can even be 20 mins. Wont it violate the limit constraint?

source: Stack Exchange

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

sort: votes


text:
How do extremely difficult vanity addresses get found in the first place?
I haven't found a specific answer to my question so please excuse me when an answer is somewhere out there.
Regarding the '1BitcoinEaterAddressDontSendf59kuE' address. If it would take more than the universe's time to crack such address how did this address get found and by whoem in the first place? Not any and all combinations of characters is a legit address or am i wrong?
Really confused about this, hope someone can clear this out for me!
And are there more longer known messages in exsisting addresses? Love to know about them!
Source: https://miro.medium.com/max/700/0*cg3mwxEbN7vIKbDS.jpg
Edit: What I refer to is a burn (lost key) address instead of vanity (owned key)
Thanks in advance

Funds are spendable by public keys and addresses contain public key hashes. Vanity addresses are created by hashing lots of public keys until the hash is in an expected range. What you mentioned is an example of a burn address, not a vanity address. Burn addresses are crafted by manually editing the public key hash with a specific the corresponding address in mind. Burn addresses do have corresponding public key(s), but since we it is impossible to find the public key from the public key hash, burn addresses cannot spend their funds. They are similar to addresses whose owners mistakenly deleted their wallets, where the funds are in a locked state.
The last digits of burn addresses is random is because addresses also contain a checksum which is the hash of everything else encoded in the address.

Thanks! That explains a lot, so if I'm getting this correctly it's just way easier (due to increased chances) to bruteforce for an exsisting (burn) address without ever knowing the private or public key than you were to bruteforce those keys? Which makes sense!

Sorry, I didn't make it clear in my answer. Burn addresses are not made by bruteforcing. A Base58 address is written arbitrarily with final digits as placeholder digits (to be filled with the checksum later), then converted to a byte array (network byte + public key hash + checksum) and the checksum is calculated from the network byte + public key hash and then the whole address is re-encoded as Base58. There is no brute forcing in burn address creation.

Also, there is one character near the end of the address whose value is affected by both the checksum and the public key hash. If that character is aimed to be set as well, then bruteforcing a small range might be needed.

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


text:
Why is it possible to have multiples addresses in an output of a transaction?
I am trying to load the blockchain into a MySQL database by using the data gathered from RPC calls to bitcoind. I am wondering why the addresses key within the vout array of a transaction is plural. Why can there be multiple addresses receiving bitcoins using only a single output? Below is the result of running

bitcoind getrawtransaction 40d9e9dc25f89b590a26c486c46df9d40a72200080200c8fdf1bdf0562b2fba7 1

for some arbitrary transaction with hash 40d9e9dc25f89b590a26c486c46df9d40a72200080200c8fdf1bdf0562b2fba7. If you look at the bottom you'll see the transaction's vout array with two outputs. The addresses values for each of those outputs are 127W9E5BVn6KxVCV2iiVbJmQrVoUd8xmu3 and 18AQDxusBQTJiNSG6EszPUfi85RhDpo7Qf respectively. Is there some future plan by the core developers to allow multiple addresses to receive bitcoins from a single output? As you can see I am confused by the use of the plural here.
{
    "hex": "0100000005f5cdbc9dc70fae996a991a08e8f9ca4000fc1cd07f98ef7af14b7b8337c1e010570000008a47304402206104041c8f9330103a1c3b77714b95e61ec90769b7f54cba426baaf8e676256402204134829de0e0ac24f340a680655b35747fbad26ab517d5324a22e20505130ba8014104ec3619fb20e737d551489c16b2df50bf91fb95b1d7b15a7835f752b9aeb5bcb4337c40aef04e39962c95e1a8630c793c158ee464d93a80b14cfb0ce9f8039d25ffffffff0238484550f656494ed81189447a256c3abddea3305c5a4fa21b275cefcd1c6e000000008b48304502210092bd8b04c5df3c23e9bf3516c1434ff4cdde8aff42d14ec18eea16393de900ad022008a005f46fdee01c17032fc3688af311c8413ca2c866e8bc95f6c4e955816697014104d1a7f146aa464889c80286b105739bdfe05c186d4d1bc0737898f28d4e1c17a99d5a3c71ada20873916d0d5d75a92db2aaab37b8a14a18338b7b223727f5d417ffffffff37d00652b664deb37d20f7764c4d1b85a19e608024c2343f5449d2beef8576a9020000008b4830450221009ba99d89a15ccd7cefb499c42c0d94ed5e41a18d11007ba6d9d3edd479ec20bb02206c002e270c17190ab5f8d7fef33a73509aea518fae2671e21cdb3aa8dedf53ce0141049a56e83820ad23350de1b1fa3b2686ef053c75c2a01dcae4e777e057e985aa94e8d2a5d7d158c970b10097249dcaa4ec34748f4402a5c4c8eb7a61a27cf3ba80ffffffffb6cf6633a550b4d262c7c37f0fb795f82e091f951cec152ff532deee0f87d9b4010000008c493046022100cb5b6ba715d77876adcd39f5ecc315cd8bd79c29bb56970b9650603decd3f243022100ac157b1ccd55dc53afac81424d8bcadc371e70660659e4b1d2ac38dfd54e008601410408ddf2624fcd9a76b6821768d901d136c72df5cfdeca960f698bbec2a24ce6fe65dc2795c4106db990f40674215c0badc15547749e1098ebf1acc23bfa164299ffffffff405d52e2368d0dbbda25b28c9eec5b48ca25141ec60a94b2dd982550289cfb19010000008b483045022070d50be3affd2201bd8c7cf800c2610b4b1dc8b0edd3292c88b1a9abca272d69022100b60eef3992902992032087c51e6487115dd54ec35ecd75b0e83804f7dcc61a5d01410403f8182f373e43770c0edcf5d793ec1e19d8600a4ef19d90860a5ed8ecd7fc445c4edb315e78db4a80f6aa2fe89e99a88e780bcf964af2b505abe7aefd2039c6ffffffff02104a0f00000000001976a9140c32f2aac46ffdcc2f02048c5f18e1b24b9be3b188ac8035bd00000000001976a9144e900299bc94a699aef0fbf2dbbeabd3a3cb03e888ac00000000",
    "txid": "40d9e9dc25f89b590a26c486c46df9d40a72200080200c8fdf1bdf0562b2fba7",
    "version": 1,
    "locktime": 0,
    "vin": [
        {
            "txid": "10e0c137837b4bf17aef987fd01cfc0040caf9e8081a996a99ae0fc79dbccdf5",
            "vout": 87,
            "scriptSig": {
                "asm": "304402206104041c8f9330103a1c3b77714b95e61ec90769b7f54cba426baaf8e676256402204134829de0e0ac24f340a680655b35747fbad26ab517d5324a22e20505130ba801 04ec3619fb20e737d551489c16b2df50bf91fb95b1d7b15a7835f752b9aeb5bcb4337c40aef04e39962c95e1a8630c793c158ee464d93a80b14cfb0ce9f8039d25",
                "hex": "47304402206104041c8f9330103a1c3b77714b95e61ec90769b7f54cba426baaf8e676256402204134829de0e0ac24f340a680655b35747fbad26ab517d5324a22e20505130ba8014104ec3619fb20e737d551489c16b2df50bf91fb95b1d7b15a7835f752b9aeb5bcb4337c40aef04e39962c95e1a8630c793c158ee464d93a80b14cfb0ce9f8039d25"
            },
            "sequence": 4294967295
        },
        {
            "txid": "6e1ccdef5c271ba24f5a5c30a3debd3a6c257a448911d84e4956f65045483802",
            "vout": 0,
            "scriptSig": {
                "asm": "304502210092bd8b04c5df3c23e9bf3516c1434ff4cdde8aff42d14ec18eea16393de900ad022008a005f46fdee01c17032fc3688af311c8413ca2c866e8bc95f6c4e95581669701 04d1a7f146aa464889c80286b105739bdfe05c186d4d1bc0737898f28d4e1c17a99d5a3c71ada20873916d0d5d75a92db2aaab37b8a14a18338b7b223727f5d417",
                "hex": "48304502210092bd8b04c5df3c23e9bf3516c1434ff4cdde8aff42d14ec18eea16393de900ad022008a005f46fdee01c17032fc3688af311c8413ca2c866e8bc95f6c4e955816697014104d1a7f146aa464889c80286b105739bdfe05c186d4d1bc0737898f28d4e1c17a99d5a3c71ada20873916d0d5d75a92db2aaab37b8a14a18338b7b223727f5d417"
            },
            "sequence": 4294967295
        },
        {
            "txid": "a97685efbed249543f34c22480609ea1851b4d4c76f7207db3de64b65206d037",
            "vout": 2,
            "scriptSig": {
                "asm": "30450221009ba99d89a15ccd7cefb499c42c0d94ed5e41a18d11007ba6d9d3edd479ec20bb02206c002e270c17190ab5f8d7fef33a73509aea518fae2671e21cdb3aa8dedf53ce01 049a56e83820ad23350de1b1fa3b2686ef053c75c2a01dcae4e777e057e985aa94e8d2a5d7d158c970b10097249dcaa4ec34748f4402a5c4c8eb7a61a27cf3ba80",
                "hex": "4830450221009ba99d89a15ccd7cefb499c42c0d94ed5e41a18d11007ba6d9d3edd479ec20bb02206c002e270c17190ab5f8d7fef33a73509aea518fae2671e21cdb3aa8dedf53ce0141049a56e83820ad23350de1b1fa3b2686ef053c75c2a01dcae4e777e057e985aa94e8d2a5d7d158c970b10097249dcaa4ec34748f4402a5c4c8eb7a61a27cf3ba80"
            },
            "sequence": 4294967295
        },
        {
            "txid": "b4d9870feede32f52f15ec1c951f092ef895b70f7fc3c762d2b450a53366cfb6",
            "vout": 1,
            "scriptSig": {
                "asm": "3046022100cb5b6ba715d77876adcd39f5ecc315cd8bd79c29bb56970b9650603decd3f243022100ac157b1ccd55dc53afac81424d8bcadc371e70660659e4b1d2ac38dfd54e008601 0408ddf2624fcd9a76b6821768d901d136c72df5cfdeca960f698bbec2a24ce6fe65dc2795c4106db990f40674215c0badc15547749e1098ebf1acc23bfa164299",
                "hex": "493046022100cb5b6ba715d77876adcd39f5ecc315cd8bd79c29bb56970b9650603decd3f243022100ac157b1ccd55dc53afac81424d8bcadc371e70660659e4b1d2ac38dfd54e008601410408ddf2624fcd9a76b6821768d901d136c72df5cfdeca960f698bbec2a24ce6fe65dc2795c4106db990f40674215c0badc15547749e1098ebf1acc23bfa164299"
            },
            "sequence": 4294967295
        },
        {
            "txid": "19fb9c28502598ddb2940ac61e1425ca485bec9e8cb225dabb0d8d36e2525d40",
            "vout": 1,
            "scriptSig": {
                "asm": "3045022070d50be3affd2201bd8c7cf800c2610b4b1dc8b0edd3292c88b1a9abca272d69022100b60eef3992902992032087c51e6487115dd54ec35ecd75b0e83804f7dcc61a5d01 0403f8182f373e43770c0edcf5d793ec1e19d8600a4ef19d90860a5ed8ecd7fc445c4edb315e78db4a80f6aa2fe89e99a88e780bcf964af2b505abe7aefd2039c6",
                "hex": "483045022070d50be3affd2201bd8c7cf800c2610b4b1dc8b0edd3292c88b1a9abca272d69022100b60eef3992902992032087c51e6487115dd54ec35ecd75b0e83804f7dcc61a5d01410403f8182f373e43770c0edcf5d793ec1e19d8600a4ef19d90860a5ed8ecd7fc445c4edb315e78db4a80f6aa2fe89e99a88e780bcf964af2b505abe7aefd2039c6"
            },
            "sequence": 4294967295
        }
    ],
    "vout": [
        {
            "value": 0.01002,
            "n": 0,
            "scriptPubKey": {
                "asm": "OP_DUP OP_HASH160 0c32f2aac46ffdcc2f02048c5f18e1b24b9be3b1 OP_EQUALVERIFY OP_CHECKSIG",
                "hex": "76a9140c32f2aac46ffdcc2f02048c5f18e1b24b9be3b188ac",
                "reqSigs": 1,
                "type": "pubkeyhash",
                "addresses": [
                    "127W9E5BVn6KxVCV2iiVbJmQrVoUd8xmu3"
                ]
            }
        },
        {
            "value": 0.124,
            "n": 1,
            "scriptPubKey": {
                "asm": "OP_DUP OP_HASH160 4e900299bc94a699aef0fbf2dbbeabd3a3cb03e8 OP_EQUALVERIFY OP_CHECKSIG",
                "hex": "76a9144e900299bc94a699aef0fbf2dbbeabd3a3cb03e888ac",
                "reqSigs": 1,
                "type": "pubkeyhash",
                "addresses": [
                    "18AQDxusBQTJiNSG6EszPUfi85RhDpo7Qf"
                ]
            }
        }
    ],
    "blockhash": "000000000000034a7dedef4a161fa058a2d67a173a90155f3a2fe6fc132e0ebf",
    "confirmations": 104243,
    "time": 1348310759,
    "blocktime": 1348310759
}

Multisig transactions might have multiple addresses. For an example I found on webbtc's list of multisig transactions, see 055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9 (using insight-api, since it's handy).
{
    "txid": "055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9",
    "version": 1,
    "locktime": 0,
    "vin": [
        {
            "txid": "b187426f2fdd5a7ac2f49d822f68e07f48486ee53a8a45de2494f12acb37a0d8",
            "vout": 3,
            "scriptSig": {
                "asm": "3046022100d78c31a20fa11533475be893b229eb4d252e600dcc2a0735d360c541b6aec813022100e3eaa72c915ef47d94ccbd18c2ba6d9ae5b98be6e9fbf968d4bbbb003e06d68701 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc"
            },
            "sequence": 4294967295,
            "n": 0,
            "addr": "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
            "valueSat": 1114144,
            "value": 0.01114144,
            "doubleSpentTxID": null
        }
    ],
    "vout": [
        {
            "value": "0.00010860",
            "n": 0,
            "scriptPubKey": {
                "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 20434e545250525459000000140001a9e0e85838b5000000174876e800010053b6 2 OP_CHECKMULTISIG",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
                    "1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E"
                ]
            }
        },
        {
            "value": "0.00010860",
            "n": 1,
            "scriptPubKey": {
                "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 20a3c3000000000000000000000000000000000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
                    "1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E"
                ]
            }
        },
        {
            "value": "0.00010860",
            "n": 2,
            "scriptPubKey": {
                "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 100000000000000000000000000000000000000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao",
                    "1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E"
                ]
            }
        },
        {
            "value": "0.01061564",
            "n": 3,
            "scriptPubKey": {
                "asm": "OP_DUP OP_HASH160 a2f2d251cc06ec1e789800127e3fa6ed9e515651 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs": 1,
                "type": "pubkeyhash",
                "addresses": [
                    "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao"
                ]
            }
        }
    ],
    "blockhash": "0000000000000000491fdff68a1c99de7798278a791e461b8d5bebdd9df9de46",
    "confirmations": 1,
    "time": 1401911255,
    "blocktime": 1401911255,
    "valueOut": 0.01094144,
    "size": 433,
    "valueIn": 0.01114144,
    "fees": 0.0002
}

So when the script stored in the value of "asm" is run in the next transaction, it will verify the signatures of BOTH addresses? That's how I'm understanding it.

This particular example appears to be a "1-of-2" multisig, which means that either of the addresses can spend the coins. Blockchain.info calls this output an escrow (which probably means that's the most likely reason you'd do a 1-of-2 multisig).

If you look at transaction https://blockchain.info/tx/56214420a7c4dcc4832944298d169a75e93acf9721f00656b2ee0e4d194f9970, this has a 2 of 3 raw multisig address.

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


text:
How exactly does bitcoin code change happen in a decentralized system
I have long been under the assumption that bitcoin was just a "protocol" or a "contract“. Different nodes run their own implementation, on different hardwares. Some are efficient, some not, and they have to agree to the bitcoin protocol to function in this ecosystem.
But I found out there is actually a centralized bitcoin code base that's frequently updated! How do they even ensure that every nodes update to the newest code? And how do they ensure that the code compiles for every single hardware? Or, I guess most imporantly, were there any backward incompatible changes in the history that require every node to update?

@Prayank yes, thanks, mostly. I guess just one more question: were there any backward incompatible changes in the history that require every nodes to update?
bitcoin-core

I have long been under the assumption that bitcoin was just a "protocol" or a "contract“. Different nodes run their own implementation, on different hardwares. Some are efficient, some not, and they have to agree to the bitcoin protocol to function in this ecosystem.

That's correct. There are dozens of implementations of nodes, wallets, and various other pieces of software that speak the P2P protocol.
There are optional features, and new things that get added to the protocol, but these are almost exclusively done in a compatible way: negotiated between peers that support them, and falling back to older alternatives between peers that don't.
Part of this is negotiated through the protocol version, which used to be just the version number of the Bitcoin client, but since Dec 2011 these are separate.
Most Bitcoin protocol implementations these days are compatible back as far as the Bitcoin 0.2.10 release (from June 2010, a time when there was just a single implementation), when checksums were added to the protocol. Using a protocol adaptor (a node that speaks both the old and new version), software written today can even speak with the very first code (Bitcoin 0.1.0, January 2009).

But I found out there is actually a centralized bitcoin code base that's frequently updated!

Bitcoin Core is a project that maintains an implementation that is an evolution of the original codebase by Satoshi. It is often called a reference implementation, and a focal point for development. However, it is not the only implementation, not even the only fully validating node implementation, and it does not decide what the protocol rules are (though there are some optional protocol features that are only implemented in Bitcoin Core).

How do they even ensure that every nodes update to the newest code?

They don't; strictly speaking there is no need. The protocol rules and rules about which blocks are valid don't really change. There are good reasons to update (e.g. security improvements, speed improvements, new features), but that's anyone's individual choice. Bitcoin Core very deliberately does not have an auto-update feature, as that is deemed to give too much control over the network by the client's maintainers.

And how do they ensure that the code compiles for every single hardware?

Extensive continuous integration testing. All code changes are tested on a variety of platforms, including Windows, MacOS, Linux (for ARM32, ARM64, x86_64, RISC-V, POWER), and since recently also Android. More systems may work, but are not guaranteed to.

Or, I guess most imporantly, were there any backward incompatible changes in the history that require every node to update?

Yes, but they are very rare (and ancient history by now).
Bitcoin 0.2.9 (protocol version 209) introduced checksums in every protocol message. Initially these were negotiated, like very other protocol feature. However, Bitcoin 0.2.10 (June 2010), the feature was implemented so that as of February 2012, the checksum would become mandatory - and included in the messages used for negotiating versions themselves. This meant that by February 2012, node software before 0.2.9 stopped working.
Another source of incompatibility is the network's consensus rules. These are the rules that determine which transactions and blocks are valid, and the most complicated part of the system. The entire network has to effectively implement them identically, or there is a risk that the network splits into separate currencies. There are many questions on this site on this topic, if you want more information, but the short summary is that almost all changes to these rules are now done as so-called "soft forks": rules that only tighten which blocks are valid, which implies the network is safe from splits as long as a majority of the hashrate also enforces these rules. Other changes are called hard forks, and apart from an debatable one in 2013 (due to a change in the database layer, see BIP 50), there have not been any of these since August 2010. For more information, see https://blog.bitmex.com/bitcoins-consensus-forks/.
Disclaimer: I'm a contributor and maintainer for Bitcoin Core, and have been involved in some of the changes mentioned. The protocol 209 checksum change was before my time.

Thanks. Curious were there significant backward incompatible changes in other notable cryptos like ethereum? I just wonder how the community ever agreed to a backward incompatible change, once the currency grows big enough. In 2012 bitcoin was still small.


text:
Electrum Bitcoin Wallet from Google Play Store
I recently found out that although the version was exactly the same, the Electrum wallet downloaded from the Play Store is heavier than the app downloaded from the Electrum website.
This raises the question of whether the Google Play Store is fundamentally trustworthy?
Even though they are not verifiable right now.


text:
How many python bitcoin wallets are there?
Is there a list of legit Python Bitcoin wallets or even other cryptocurrencies?
I did a Google search and got no clear results.

Hi AirGap, I've been seeing a few of your questions not really fit well in the scope of topics we collect here. Please check out our [tour] to get an overview what sort of content we collect.

Electrum is one of the oldest Bitcoin wallet that is still maintained and it is written in python: https://github.com/spesmilo/electrum
Armory is another one but it is no longer maintained:
https://github.com/goatpig/BitcoinArmory


text:
To run a full node, should I get a static IP address from my ISP?
I have a router connecting my home LAN to the ISP. After opening port 8333 on the router, and forwarding it the computer running the node, bitnodes.io confirmed the node was reachable. However, bitnodes.io sees the IP address the ISP is currently assigning to my router on the trunk (Internet) side, which may change over time.
Do I need to ask my ISP for a static IP address, to be assigned to my router, trunk-side?

You can get a dynamic dns service that will maintain a single IP even though your ISP is constantly changing it.

@m1xolyd1an dynamicDNS services allow a static hostname, not a static IP. To have a static IP with the ISP changing it, you would have to proxy through a server with a constant IP.

To run a Bitcoin full node you don't need to have a static IP address as when your IP address changes you should still be able to find peers and connect to them. However, if you want to maintain the same peers getting a static IP address is a good idea. Your connection to existing peers will drop if your IP address changes and you will either reconnect to them with your new IP address or connect to different peers. This isn't generally a problem because you are only receiving information on transactions and blocks from other nodes rather than in Lightning's case having funds locked up with them.
If you are planning to run a Lightning node it is much more important that you have a static IP address as you will have funds in a channel with another peer that identifies you using that IP address. Changing the IP address for your Lightning node poses greater challenges at this point.


text:
Algorithm behind Bitcoin Core's hashes/s metric
The call bitcoin-cli getmininginfo returns a metric networkhashps among others. It shows how many hashes the entire Bitcoin network generates per second.
This metric however, is not directly stored within the Blockchain, resp. it is not communicated over the gossip network.
Consequently it must be derived; I assume that it takes the difficulty and also checks the time it took between blocks.
But how does the algorithm behind this exactly look like?

The hashing power is estimated from the number of blocks being mined in the last 24h and the current block difficulty. More specifically, given the average time T between mined blocks and a difficulty D, the estimated hash rate per second H is given by the formula H = 2exp32 D / T


text:
Triying to help grandpa recover his bitcoins
Back in 2013 my grandfather bought BTC. Wallet.dat file was lost most likely due to pc formatting. He would like to recover his wallet or bitcoins or whatever is possible I don't understand much about this topic.
I don't know the details, but here is all I know:

The supposed date of transaction
Wallet was most likely created using Bitcoin-qt
I have a snapshot of the transaction made back in 2013 where his
public address appears
I have access to the same laptop supposedly used to create the wallet
Laptop was probably formatted at some point
I found a file I don't know what it is that weighs around 6mb, and
consists of only Alphanumeric strings and a headers for Msftedit
5.41.21.2510 (copy paste?)
Searching laptop does not yield any wallet.dat file but lots of
bitcoin related files

Using a file recovery tool is a last resort due to the laptop being formatted (is that word correct?) part and I just don't want to go there yet.
He is very cautious (except for not backing up wallet.dat lol) and that weird file is stored in a folder named BITCOIN along with a file holding the voucher of his transaction so even if it is not the wallet it should be related to bitcoin.
1 Does anybody know what could be done?
2 Does any body know what that weird file is?
I created a wallet with Bitcoin Core to see what the creation process is and there was a message stating that if the wallet was being created from a backup file then the security phrase would be the same for that backedup wallet. This hints that there is a way of restoring backup files but I didn't come across it.
3 Would that recovery process help? What file do I need?
EDIT
In answer to David Schwartz:
Yes the string appears in the file. These are the firs lines of the file, for easy ilustration:

{\rtf1\ansi\ansicpg1252\deff0\deflang13322{\fonttbl{\f0\fnil\fcharset0
Calibri;}} {*\generator Msftedit
5.41.21.2510;}\viewkind4\uc1\pard\sa200\sl240\slmult1\lang10\f0\fs22{\pict\wmetafile8\picw28152\pich16404\picwgoal15960\pichgoal9300
010009000003380618000000220618000000050000000b0200000000050000000c021440f86d22
061800430f2000cc00000000035605000000001440f86d00000000280000005605000000030000

The file goes on and is around 80k lines long. My grandfather is not very tech savvy so this could be anything, perhaps taken from the website.
Last lines from file are these:

dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9
dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6e9dfd6eee6df9a948ef1ebe5e9
dfd6e9dfd60000030000000000 }\par \pard\sa200\sl276\slmult1\par }

UPDATE 2:
As RedGrittyBrick said, the file was opened correctly using MS wordpad and, as I imagined, it is a capture of the bitcoin core program with the transaction.
So it is no use. Last thing I was thinking, is there any header to bitcoin wallets? The laptop is full of files scattered all over, so if I can run a search for that header on all the file system it might bring something up.
I would very much appreciate your help guys, thanks in advance
Alvaro

Can you tell us more about that file? What do you mean by "a headers for Msftedit 5.41.21.2510" exactly? Does the string "5.41.21.2510" appear in the file?

I was searching around about msft edit and it seems this might be an image my grandfather tried to save using notepad, so no use apparently

The string {\rtf1 suggests this file is in Rich Text Format (RTF) which can be opened using Microsoft wordpad (press Win+R keys together then enter wordpad)


text:
unable to install bitcoind (macOS, M1 chip)
I've been trying to install bitcoind on a new mac (Big Sur 11.4). I followed the instructions in doc/build-osx.md and installed all required dependencies, but when I try to run make, it gives me the following error:
Making all in src
  CXX      bitcoind-bitcoind.o
clang: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument]
In file included from bitcoind.cpp:14:
In file included from ./interfaces/chain.h:8:
./optional.h:10:10: fatal error: 'boost/optional.hpp' file not found
#include <boost/optional.hpp>
         ^~~~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [bitcoind-bitcoind.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Any idea how to fix this?
Edit:
If I run brew install boost, it tells me it's already installed, but typing 'which boost' gives 'boost not found'.

Well I didn't install it myself, but if I try 'brew install boost' it tells me it's already installed.

Is there any other info I can provide that might make it easier to diagnose the problem?

Have you followed the instructions at https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md? Is the mac one of the new ones with the M1 chip or an older one with an Intel processor?

Yep, that's the guide that I followed. And the mac is a newer one with an M1 chip.


text:
How a real mining code treats difficulty?
I have come up recently with "how to mine bitcoin using python" or "how to mine bitcoin using golang" and as I have been observing all these source code, not only I'm confused but also have some questions.
Some developers using python keep saying that difficulty calculates the leading 0s on the hash which after coming to blockchain explorer I think it is not true as the current difficulty is wayy too high to be leading 0s on the hash which determines that "we mined a block". Also bitcoin wiki of difficulty just explains it plain short.
So how does it treats it? Does the mining software puts difficulty in the hashing algorithm?

Does this answer your question? How does solving a block work in relation to the first letter/number after the 0's?.  See also What exactly is mining

@RedGrittyBrick so true man, you are right but I have been said that I shouldn't edit questions once I made one. Tbh that's why I included that edit even after I knew exactly what I wanted to know. Thanks for the link i think it will come in handy.

Hi thecow milk, our site works best when a topic is focused on one question only. You can find a description of how our site works in our [tour]. I think that all of your questions have answers on this site separately, see e.g. https://bitcoin.stackexchange.com/q/8806/5406, https://bitcoin.stackexchange.com/q/23912/5406, https://bitcoin.stackexchange.com/q/5838/5406, and https://bitcoin.stackexchange.com/q/8031/5406.

Please feel free to edit this question to focus on a single topic, if any remain unanswered after you read the linked topics. Please ask additional remaining questions as separate topics. Thank you.

@Murch yea you are right buddy. sorry for asking multiple questions at once but I thought it would clear my thoughts and I will be more careful the next time. I'm pretty confused if I should edit my question because it is stated in the rules that once asked you can't go back because the answers/comments will be irrelevant. I'm requesting to delete this question if possible because it may be misleading in the future. Thanks.

Hi thecow milk, the "do not edit your question substantially" applies when people have answered a question. Especially if your question was closed without answers, editing is encouraged so that the question can be reopened.

@Murch oh say less, thanks im editing right away!

BTW, it's possible that other sites in the Stackexchange network have slightly different rules, each site has its own community with slightly different culture.

@Murch last question just to be sure, may I edit the title as well?

Yes, please. It should fit the question you're now asking.—Thanks for updating your post!

The difficulty is really a human readable expression. Under the hood, the Bitcoin protocol uses the target. The target is a custom 4-byte float value encoding an exponent and a mantissa that is to represent a number used as the upper bound for the block hash of valid blocks.
The target is updated every 2016 blocks after the last block of a difficulty period has been found. It depends on the timestamps of the first and the last block of the difficulty period and the previous target:
new_target = old_target × (t_last - t_first)/14 days

Every full node that has seen these two blocks can calculate the new target.
Miners assemble unconfirmed transactions into block templates, create coinbase transactions and fill up the remaining header fields to produce block candidates, test each block candidate by hashing its header and comparing the candidate's hash to the target to determine whether a block has been found. The current target since height 693,504 is 0x17136aa2 which is a compact representation for 0x000000000000000000136aa20000000000000000000000000000000000000000. If I counted right, this hexadecimal number would translate to a binary number with 75 leading zeroes. At the current hashrate of about 109.7 EH/s, the network will try about 6.6×1022 block candidates until a block is found.


text:
How to compute deposits from the output of listsinceblock?
I am writing a program that, given the JSON outputs from multiple separate RPC calls to listsinceblock, stores valid deposit transactions in a database and then computes the total deposit for every unique address.
From my reading the documentation, I am hoping to confirm if the following are true:

Every transaction is unique on a combination of txid and vout.
Every deposit will have its category be either receive or generate.

Further, I would like to ask:

Should transactions of category of orphan and immature also be counted as deposits?
Is a transaction that has walletconflicts as a non-empty array considered valid?
Are there any other considerations that I have not taken into account if I am trying to compute total deposits for every address that occurs in the listsinceblock transaction list?

Thank you!

Hi! This is an interesting topic. Did you find the solution to yout question?


text:
Low inbound connections and fixed getnetworkinfo score at 4
I spent hours researching for possible solutions, but couldn't find any. I set up my RPi4 bitcoin node about a month ago. It communicates through Tor (see torrc content).
SOCKSPort 9050
Log notice stdout
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
HiddenServiceDir /var/lib/tor/lnd/
HiddenServicePort 8080 127.0.0.1:8080

It took a while to sync the whole network (almost two weeks) and since then I noticed that the number of inbound connection was near to 0 or low (max was around 12 and 5 on average).
In addition, the score value returned by bitcoin-cli getnetworkinfo is still 4 and unchanged since the beginning.
I'm wondering what might be causing this issue and how to solve.
Here the bitcoin.conf, which I think is pretty standard:
#adjust memory usage
dbcache=2000

#transaction validity
assumevalid=0

#settings
rpcuser=[redacted]
rpcpassword=[redacted]
rpcbind=192.168.1.x
rpcallowip=0.0.0.0/0
rpcport=8332

#server settings
#listen=1
server=1

#transaction index
txindex=1

# Allows LND & Bitcoin Core to communicate via ZeroMQ
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

## Tor Settings
proxy=127.0.0.1:9050
debug=tor
onlynet=onion
bind=127.0.0.1
dnsseed=0
dns=0

I've tried to play around with some settings unsuccessfully and ended up reinstalling tor.
Regarding the firewall: I opened and mapped the following ports: 8332,8333, 18333, 28332, 28333 and then for lightning 10009 and 8080.
When opening and forwarding port 9050 and 9051 I observed no improvement.
getnetworkinfo output:
[
    {
        "version": 210100,
        "subversion": "/Satoshi:0.21.1/",
        "protocolversion": 70016,
        "localservices": "0000000000000409",
        "localservicesnames": [
            "NETWORK",
            "WITNESS",
            "NETWORK_LIMITED"
        ],
        "localrelay": true,
        "timeoffset": -3,
        "networkactive": true,
        "connections": 10,
        "connections_in": 0,
        "connections_out": 10,
        "networks": [
            {
                "name": "ipv4",
                "limited": true,
                "reachable": false,
                "proxy": "127.0.0.1:9050",
                "proxy_randomize_credentials": true
            },
            {
                "name": "ipv6",
                "limited": true,
                "reachable": false,
                "proxy": "127.0.0.1:9050",
                "proxy_randomize_credentials": true
            },
            {
                "name": "onion",
                "limited": false,
                "reachable": true,
                "proxy": "127.0.0.1:9050",
                "proxy_randomize_credentials": true
            }
        ],
        "relayfee": 0.00001,
        "incrementalfee": 0.00001,
        "localaddresses": [
            {
                "address": "[redacted].onion",
                "port": 8333,
                "score": 4
            }
        ],
        "warnings": ""
    }
]

I'd be happy to provide more information and thank you in advance for your time.
EDIT: I've done more research:
While using Tor, it's pointless to open ports on router side. Tor handles all the request over the onion service. I tested this and even with closed port, bitcoind was connecting to Outbound peers fine. I get a few inbound connections as well, but the score didn't improve.
So I went into the source code and found out why the default score was 4.
Here the link to Github.
I believe (and might be wrong so please help!) that the following functions are responsible for setting the nScore value:

GetLocalAddrForPeer(CNode *pnode) which return 3 if GetnScore(addrLocal) > LOCAL_MANUAL
AddLocal(const CService& addr, int nScore) which adds a 1 to nScore if !fAlready || nScore >= info.nScore

This yields a 4 and it might make sense. Now, I suppose the function responsible for updating the nScore is the following:
bool SeenLocal(const CService& addr)
{
    {
        LOCK(cs_mapLocalHost);
        if (mapLocalHost.count(addr) == 0)
            return false;
        mapLocalHost[addr].nScore++;
    }
    return true;
}

and here I get totally lost, but I guess that mapLocalHost.count(addr) must always be 0 in my case. My knowledge of C++ reaches this point, so the additional question is what changes mapLocalHost and why doesn't it update when a new peer is added on my machine?


text:
Would a min_fee setting for Lightning channels make sense?
What is a min_fee?
Having a min_fee means changing the fee calculation to max(min_fee, fee_rate * amt), potentially replacing the base_fee. My reasoning behind this is that it prevents 0-fee payments – fees below 1 msat are currently rounded down to 0 – without setting a min_htlc_msat or base_fee.
How does it help?
Not setting a min_htlc_msat makes sure that micropayments can still be routed, while not setting a base_fee ensures a linear fee function for Pickhardt payments.
While my proposed fee function is generally not linear, it can be ensured that it always is linear in practice. I showed this in a reddit thread, responding to Rene Pickhardt. Here's my response in full, if you don't want to go to that reddit thread:

My idea behind max(min_fee, fee_rate * amt) was the fact that for reasonable min_fee and fee_rate settings, the function is linear even for relatively small payments.
More exactly, the function is linear for fee_rate * amt >= min_fee – or equivalently amt >= min_fee / fee_rate (let's call this the fee_ratio).
A wallet/node that uses your flooding algorithm – with, say, a minimum split size of 10k sats – could then heuristically ignore channels that:

Have any base fee
Have a fee_ratio that is greater than 10k sats, which should be incredibly rare

Most channels would probably have their min_fee set to 1 msat, simply to prevent 0-fee htlcs. In my 200 ppm example, the fee_ratio would be 5 sats.
In fact, just 1k sats is a magic number here! When the min_fee is 1 msat, then any channel with a nonzero fee_rate has a maximum fee_ratio of 1k sats (0.001 / 0.000001 = 1000)!
So even all the way down to 1k sat payment splits, any channel with a 1 msat min_fee – and a nonzero fee_rate – has a linear fee function.

Is it a good idea?
Now I would like to know if there are any fundamental issues here that I'm missing.
It seems to me that it could serve as a replacement for the (iirc arbitrary) base_fee setting, while still allowing Pickhardt payments.

Note: Probably this should be a comment, but I don't have enough reputation, so I'll let it grow as an answer.
There is something I don't understand about this: why do you state that the fee function you propose is linear?
Let's say I set 10 msat/sat feerate and 100 msat min_fee. Payments from 1 msat all the way up to 10 sats would all pay a 100 msat fee. Only larger payments would start to pay more. This is not linear: it's constant up to some arbitrary amount and then it becomes linear increasing.
The base_fee + feerate model instead is really linear, starting off at base_fee for 0-amt payments and growing linearly from there.
So: your system is linear only in the special case where you set a really small min_fee, while the currently implemented system is always linear. If you want to solve the fact that small payments pay a too large fee, you can just set a lower base_fee (down to 1msat) and possibly a higher feerate. With such a settings the two systems are practically equivalent.
Now, I'm not familiar with Pickardt payments, so ther might be something there that would change everything.
TLDR: your system is practically linear only in case of very low min_fee and in this case it very much looks like the current system with low base_fee.

f(x) = ax +b is the current fee model. For a function to be linear it is not sufficient that the plot looks like a straight line but rather the following equation needs to hold f(x+y) =f(x) + f(y) now it is easy to see that f(x+y) + b = f(x) + f(y) which only implies linearity if and only if b=0. That being said the proposed function with the max is also not linear and also at f(0) not even convex

Oh, you need the precise notion of linearity. But then you need to have that f(0)=0 and as far as I understood we don't want to have free 0-amt payments. Looks like there's no clear way out then...

of course f(0)=0 is necessary as we don't want to pay channels if we don't send something over them. but maybe I miss your point here. anyway your answer lead me to also write a much longer post on the mailinglist so I drop that here for reference: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003203.html


text:
Does bitcoind need to be up to date to serve blocks to other servers
Using bitcoin-13.2. I have an app that connects through port 8333 and fetches blockchain blocks. Problem is that my app connects and exchanges some info with bitcoin-core but I never receive the requested block from the blockchain. This is an intermittent problem. It appears to happen only when bitcoin-core is not connected to the internet. I m trying to isolate what is causing this behavior.
So, is there anything in bitcoin-core that would prevent an out of sync bitcoin-core from answering a 8333 request?
Thanks

Bitcoin clients are perpetually in a state of "catching up with the network".  There is no definitive point at which they are completely caught up.
If you are requesting a block or transaction that the client has yet to see, it will not be able to respond with that block or transaction.  Make sure that what you are requesting is something that the client has already seen and verified.  If you are sure that the client is aware of the data being requested, then you should continue troubleshooting.

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


text:
Confidential transactions: how can they be verified by the network?
I'm currently trying to understand how confidential transactions would work. I think I was able follow all the explanations about Pedersen commitments and the range checks, but I'm still missing one piece of the puzzle: If the network doesn't know transaction amounts, how can it verify a transaction? It doesn't know whether the account balance is sufficient. How can the network even know account balances when the amount of incoming transactions is hidden?
It would be great if anyone could shed some light on this.

If the network doesn't know transaction amounts, how can it verify a transaction?

That's exactly what Pedersen commitments allow you to do.
Each of the outputs contains a commitment P(v,r) = vH + rG, where v is the value and r is the blinding factr. The network does not know v or r, but does know P(v,r) (and H and G, which are constant).
Pedersen commitments have the property that they're linear in both arguments. This means that P(v1,r1) + P(v2,r2) = P(v1+v2,r1+r2).
For every transaction, a network rule requires that the sum of the output's commitments equals the sum of the commitments of the outputs spent by the inputs. This means that the sum of the output's values must equal the sum of the input's values, and that the sum of the blinding factors must equal the sum of the input's blinding factors.
The range proofs are there to prevent overflow in the value addition.

It doesn't know whether the account balance is sufficient.

There is no 'account' balance in Bitcoin. Transactions create outputs by burning outputs created by other transactions. Your wallet shows the sum of the values of all outputs you can spend. The only requirement is that a transaction does not create more in outputs than it burns in its inputs.

How can the network even know account balances when the amount of incoming transactions is hidden?

It can't. The purpose of Confidential Transaction is to prevent the network from knowing anything about anyone's balances. The only necessity is that individual wallets are able to determine how much they're able to spend. In CT that is solved by sending that information in encrypted form along with the transaction, with the receiver's public key.

Ah, now I get it! I always thought that in order do verify the blockchain, nodes would determine balances for each public key from incoming and outgoing transactions. And I thought transaction inputs were public keys of accounts, not outputs of other transactions. Now everything makes sense. Thanks!


text:
How might I reduce the percentage of rejected shares using an Avalon 741 with NiceHash?
I have an Avalon741 running on NiceHash with CGminer and I'm new to mining. The command I'm running is as follows:
sudo ./cgminer -o stratum+tcp://sha256.eu.nicehash.com:3334 -u <address> -p d=4096

When I run with this, I end up getting usually between 25% and 50% of shares rejected. Why is this? How can I improve the situation and contribute more effectively?
Here are some representative CGminer run statistics:
[2017-06-07 12:57:08.511] Started at [2017-06-07 02:20:49.716]
[2017-06-07 12:57:08.511] Pool: stratum+tcp://sha256.eu.nicehash.com:3334
[2017-06-07 12:57:08.511] Runtime: 10 hrs : 36 mins : 18 secs
[2017-06-07 12:57:08.511] Average hashrate: 5032956.9 Mhash/s
[2017-06-07 12:57:08.511] Solved blocks: 0
[2017-06-07 12:57:08.512] Best share difficulty: 140M
[2017-06-07 12:57:08.512] Share submissions: 7258
[2017-06-07 12:57:08.512] Accepted shares: 5335
[2017-06-07 12:57:08.512] Rejected shares: 1923
[2017-06-07 12:57:08.512] Accepted difficulty shares: 44435456
[2017-06-07 12:57:08.512] Rejected difficulty shares: 15138844
[2017-06-07 12:57:08.512] Reject ratio: 26.5%
[2017-06-07 12:57:08.512] Hardware errors: 11355
[2017-06-07 12:57:08.512] Utility (accepted shares / min): 8.39/min
[2017-06-07 12:57:08.512] Work Utility (diff1 shares solved / min): 94093.46/min

[2017-06-07 12:57:08.512] Stale submissions discarded due to new blocks: 7
[2017-06-07 12:57:08.513] Unable to get work from server occasions: 12
[2017-06-07 12:57:08.513] Work items generated locally: 274339
[2017-06-07 12:57:08.513] Submitting work remotely delay occasions: 6
[2017-06-07 12:57:08.513] New blocks detected on network: 1960

[2017-06-07 12:57:08.513] Summary of per device statistics:

[2017-06-07 12:57:08.513] AV7 0 (5s):32.99G (avg):5.032Th/s | A:44435456 R:15138844 HW:11355 WU
[2017-06-07 12:57:08.513]

If you live in the U.S. you need to connect to the US server.
stratum+tcp://sha256.usa.nicehash.com:3334
NOT
stratum+tcp://sha256.eu.nicehash.com:3334


text:
How to Get UTXO using bitcore-lib?
I am using this library to make a wallet service that runs on a web browser. I use the library and browserify it so its compatible with the rest of my jquery. Now this tells me how to make and sign a transaction. This specifies the parameters used to make a utxo but I don't understand how to get the data for it.
It says

It can take outputs straight out of bitcoind's getunspent RPC call

My understanding is that the UTXO can be obtained only when running a full node and not from the browser, so my plan is
1) Send amount, receiver and sender public address to the server using browserfiy, bitcore-lib and jquery
2) Server then finds UTXO (how?) and returns the raw transaction to the browser
3) Browser then prompts using to enter his private key, which is used to sign the transaction and sent to the server
4) Server then pushes this onto the blockchain and returns the transaction hash
I am not able to achieve point 2.
Now I understand that a lot of online wallets would have a similar structure but I am unable to achieve this. The blockchain used is Bitcoin, server side language is entirely in nodejs.
Could someone please help me out/ tag relevant links.

You can use bitcore explorers module to use Insight send transaction and get utxos data.
Check further https://github.com/bitpay/bitcore-explorers

This works for public blockchain not a private one. However, in this month I have written my own set of APIs and parsers that replicate what Insight does to a desired extent by setting up listeners and interacting with the JSON-RPC calls in a full bitcoin node

I know that I am late to respond you but link helped me allot

My question is for a private network not the public bitcoin one that bitpay-bitcore offers. Either way, I wrote my own block listener that prepares a soft wallet for each address and maps it to users based on their private keys. It maintains its own mempool, utxo and miner reward list , combines them all to provide a soft wallet for any address


text:
Bitcoin core - get transaction information in PHP
I've using Bitcoin core and I've downloaded denpamusic/php-bitcoinrpc with composer.
I can get block information with this:
$block = $bitcoind->getBlock('000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f');
print_r($block);

But I can't get information directly with transaction ID.
Is it possible to get all information from transaction only with TXID?
Or there is possible terminal method with bitcoin-cli
Thanks


text:
Missing Witness field in p2wpkh decoded tx hex
I have placed together a raw tx hex but when it's unable to be broadcasted as I keep getting an error below
sendrawtransaction RPC error: {"code":-25,"message":"bad-txns-inputs-missingorspent"}

I then decoded the tx hex using https://live.blockcypher.com/btc/decodetx/ to see that I seem to be missing the Witness field as I am using native segwit addresses:
{
    "addresses": [
        "bc1qj3rjxzhlqm6fqesd5fwphjnf457zkww3s5qrv5",
        "bc1qjp3cch0hdvdr0hy99cs76kl9kekmuxv3k9nr6l"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 200,
    "hash": "88420211f5ea53174fc6a708c00ca2e840d687591573d0ecd2464fae20d139a7",
    "inputs": [
        {
            "addresses": [
                "bc1qj3rjxzhlqm6fqesd5fwphjnf457zkww3s5qrv5"
            ],
            "age": 696993,
            "output_index": 0,
            "output_value": 60200,
            "prev_hash": "74e24a2d50ba64abc099126c1c208b5f7156e3ad515b86f3edcca3f3d4291f66",
            "script": "4730440220516e15b6354f17e3f02711107624005e6ccd26cf61ef21b35e91315dfbd33e9f022049dadb73ca3e814de9da0b35ff20a8ca82147dda138ede948ccac5621a5bc1bb01210384485d43e938f8c68c4ac903d4d5a97fe842f66c12b860d8d2e1242d2b01fc1f",
            "script_type": "pay-to-witness-pubkey-hash",
            "sequence": 4294967295
        }
    ],
    "outputs": [
        {
            "addresses": [
                "bc1qjp3cch0hdvdr0hy99cs76kl9kekmuxv3k9nr6l"
            ],
            "script": "001490638c5df76b1a37dc852e21ed5be5b66dbe1991",
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 60000
        }
    ],
    "preference": "low",
    "received": "2021-09-05T10:17:14.395062568Z",
    "relayed_by": "3.82.154.159",
    "size": 188,
    "total": 60000,
    "ver": 2,
    "vin_sz": 1,
    "vout_sz": 1,
    "vsize": 188
}

I then thought perhaps I didn't add a scriptPubKey into the addInput but this code didn't seem to work for me:
const fetch = require("node-fetch")
const bitcoin = require("bitcoinjs-lib")
const url = "https://blockchain.info/rawaddr/"
let MAINNET = bitcoin.networks.bitcoin
pubAdd = "bc1qj3rjxzhlqm6fqesd5fwphjnf457zkww3s5qrv5"

let txb = new bitcoin.TransactionBuilder(MAINNET)
var txid = null
var outn = 0
var transactionhex = ""

async function getPubAddInfo() {
  const response = await fetch(url + pubAdd)
  const data = await response.json()

  txid = data["txs"][0]["hash"]
  outn = data["txs"][0]["out"][0]["n"]
}

async function getTXHash() {
  await getPubAddInfo()

  let WIF = "xxxxxxxxxxxx"
  let keypairSpend = bitcoin.ECPair.fromWIF(WIF, MAINNET)

  var scriptPubkey = bitcoin.script.witnessPubKeyHash.output.encode(bitcoin.crypto.hash160(keypairSpend.getPublicKeyBuffer()))

  txb.addInput(txid, outn, null, scriptPubkey)

  txb.addOutput("bc1qjp3cch0hdvdr0hy99cs76kl9kekmuxv3k9nr6l", 60000)

  txb.sign(0, keypairSpend, null, null, 60200)

  let tx = txb.build()
  transactionhex = tx.toHex()
  console.log(transactionhex)
}

getTXHash()

At the moment I get the error TypeError: Cannot read property 'output' of undefined on the line where i create var scriptPubKey.
Any suggestions as to how I can add the Witness field into the tx? Is it because I am improperly adding the scriptPubKey? I am using bitcoinjs 5.2.0

Are you actually signing the transaction?

@PieterWuille Yes, I have it like this:
let WIF = "xxxxxxxxx" , let keypairSpend = bitcoin.ECPair.fromWIF(WIF, MAINNET) , txb.sign(0, keypairSpend, null, null, 60200)

@PieterWuille I have updated my original question above to show you the full code I am using.

How are you signing it? Also what version of bitcoinjs are you using? Looks like an older one (v3.3?)prior to PSBTs. It might be a little different depending on version. Spending from segwit addresses (p2sh or native) you must specify inputvalue, this is the full value of the unspent output being spent.
txb.sign(0, keypairSpend, null, null, inputvalue);
As of v.4.03 for an example spending from p2wpkh with the latest transaction builder see their github reference docs at https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/test/integration/transactions.spec.ts#L11

I have updated my original question to show you the full code I am using. I am also using bitcoinjs v5.2.0

This is likely a problem with the version of bitcoinjs the OP is using.
A similar issue is discussed on Github.
To fix it, the user had to update.
An alternative might be to update the problem line to something like the old pattern:
var redeemScript = bitcoin.script.witnessPubKeyHashOutput(pubKeyHash)
var redeemScriptHash = bitcoin.crypto.hash160(redeemScript)


text:
How to set up a listener on an address, and trigger events upon receiving transaction?
I have a task where I need to set up some sort of a listener on a particular bitcoin addresses for incoming transactions, and once a transaction arrives, I need to call some function in my web service. Is it possible to have some sort of an event be triggered by the incoming bitcoin transaction that calls my web service? What technologies or tools are available that I could use for this task?
Furthermore, after the function in the web service has completed, I need to forward those received bitcoins to another address using that same web service. The web service can, if needed, be provided access to the private key for the address from which these bitcoins would be sent out. What tools/technologies could I use for this purpose?


text:
I have deleted Bitcoin core but it keeps restarting and taking the storage
I m using Bitcoin Core version v0.21.1. My problem is that even after deleting the Bitcoin folder in the application support, the bitcoin folder reappears in 2-3 days. This morning I saw another bitcoin folder in the application support. It's been going on for about 4 months now. When I checked launchctl list, I saw org.bitcoin.bitcoind. Not sure what this means tho.
Im using Mac os ver 11.5.2
deleted:Application Support/Bitcoin
'Start Bitcoin Core on system login' Not checked in GUI

I added the answers to your question in the OP.


text:
How can I create P2TR addresses with Bitcoin Core 22.0?
I'm trying to test P2TR with Bitcoin Core, and I don't know how to get taproot addresses.
How should I create them using 22.0?

You can experiment on testnet with existing releases e.g. Core 22.0. It just requires importing a descriptor rather than address generation from within the Core wallet.

This functionality in the Bitcoin Core wallet has deliberately not been merged pre activation to prevent users from easily generating and giving out Taproot addresses prior to the Taproot rules being enforced.
You can get around this by importing a Taproot descriptor into the wallet prior to this PR being merged as described here, here, here or here but that does require you to generate a private, public key pair outside of the Core wallet (or use an existing test vector but don't send to this on mainnet). Unless you know what you are doing I would wait until the Core wallet supports easy generation of Taproot addresses with e.g. the getnewaddress RPC for mainnet Taproot address generation.

Thanks! That makes sense!


text:
Can bitcoin script look at the output?
I was wondering if it possible for a bitcoin script check part of the output of the transaction.
Lets say, I want to check that the transaction is splited equaly between 3 outputs, I dont care which.

No. With current script. There is a locking script, and an unlocking script. Basically the locking script (scriptPubKey) in the old transaction puts down the condition to spend BTC. The scriptSig in the spending tx must provide the data to satisfy these conditions. Problem is, that current script language does not provide an access to data „outsides“ the scripting language. So you would have to define conditions in the locking script „upfront“, while creating the tx. But then the unlock script does not allow for operators, and only accepts „push data“, like pushing the signatures or pubkey. This might change in the future, discussions are running to implement a new scripting subsystem, which is currently checked in a side chain. This will allow to access oracle data (not with „simplicity“ though), which could be a previous tx as well.
Keywords: RSK Elements, Ivy, Simplicity, Bitcoin Smart Contracts,  Scriptless Scripts and possibly some more.
Short answer: currently no.

No. Bitcoin script language does not have such instructions.
https://en.bitcoin.it/wiki/Script


text:
Submitting a block
We assume that trying to mine a block as of 2018 is like digging for gold with a plastic spoon. There are chances but remote if any, of success.
That being said, if someone can get the info from Getblocktemplate and decides to mine a block for luck and happen to mine a successful block that meets the target requirements.
Is it enough to submitblock with the appropriate info like this:
bitcoin-cli submitblock 000000205badedd2461eabc2c47aeac53a784fa7fc3b79f2566f27000000000000000000b3433d3f19fb599c34704bd2dede4aeab7d9f1e2658de3b30e6004d44b985411d1637c5af8e961173a3a8db3 1
being the first argument the message and the second a dummy that is being ignored by the network.
1. Should there be any response?
2. Should there be any quotes?
3. Why it always return
error code: -22
error message:
Block decode failed

4. Is there a way to send the block to a relay node that will spread it fast?
Any help would be appreciated and please do not mention again that it is impossible to mine a block alone, it is already known.

Welcome to Bitcoin.SE! It is better to limit to one question per ask as this assists answerers to stay on topic and keeps the focus. See How to ask? for further assistance with asking.

Somehow I discovered that what is missing in my string is the rawtransaction hash after the message I just posted and then it returns the duplicate thingy... as it was supposed to happen.

You can post as an answer and mark as accepted to prevent the question remaining as "unanswered". It is better if you include details of how you solved the problem so that the next person can learn also.

If you run:
>bitcoin-cli help submitblock

It provides some information and says in part:

See https://en.bitcoin.it/wiki/BIP_0022 for full specification.

Which states for submitblock:

This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

Please see this question (findable via a search for 'submitblock') for further information.
It looks like there should be quotes.
When a block is successfully submitted it should be broadcast automatically but, it should build on the tip otherwise it is irrelevant.

Thanks for the answer. This is clear for me, but the fact is that even if you submit a duplicated block the response should be that it is duplicated, but instead the same code -22 is displayed once and again so I was wondering if there is a problem with the structure of the message that needs to be sent with the submitblock command or that error -22 is just stating that the block is not relevant at all, it is duplicated etc. Thanks again.

Following through the linked document, it definitely looks like this is supposed to be used with getblocktemplate. I will make some enquiries and see if I can come up with something more specific for error code: -22 but for the moment it looks from your post like that means 'Block decode failed' which means an error with the input not decoding to something valid.

@abellido a side note, each block to be submitted must include the hash of the block it is building on, the previous tip, and is therefore only valid for ~10 minutes. Also, each block to be submitted must include sufficient PoW.


text:
How to setup Masternode from Beginners?
I need a guide for single masternode, on an Ubuntu 16.04 64bit server (VPS) running headless and will be controlled from the wallet on your local computer (the Control wallet).
Thanks

What is a masternode? Which cryptocurrency or blockchain system?

Here is an example of how to set up a Masternode
https://medium.com/geekcash/how-to-setup-masternode-from-beginners-ea5f60686790

I think the simple way is using Bitcoin Core https://bitcoin.org/en/full-node#ubuntu-1604


text:
How to find my private key! Please help!
Trying to send some BTC payments and don’t know my private key. Can anyone help me and tell me it or tell me how to get it.

which wallet are you using?

Blockchain wallet

Offering payment for answers is generally not okay on Stack Exchange.  https://meta.stackexchange.com/questions/160944/how-to-handle-question-offering-payment

Possible duplicate of I need to recover private key?,

If you never had the private key for the bitcoin account you are trying to use, then you can't just recover or "find" it.
This is one-way algorithm: private key -> public key. You can get public from private, but not another way around.

Isn’t there sites where you pay like 0.03 and you can search any wallets address private key?? Or is that a total scam?

It's a scam. If the site could find the private key for any account, they would be rich by guessing the keys for known accounts with a lot of bitcoins. It will take millions of years to brute-force it.


text:
Passphrase header - Coinbase API
When trying to access the Coinbase API I am getting a header required: passphrase error.
How do I create a passphrase?
On the GDAX website, it states you create your passphrase when you create an API key, however, I just created a new Coinbase API key and could not see any option to create a passphrase.
Thanks in advance

I've experienced the same problem. I can assume that you're creating API keys at https://coinbase.com/.
The passphrase is related to updates they made so far and you have to create API keys at https://pro.coinbase.com/

I tried creating an API key there, I see no option anywhere for a passphrase...


text:
How to prioritize bitcoin transactions when solo mining using CPUMINER?
I am just tinkering. Trying to learn how things work. So making money is not even on my radar at the moment.
Because I am just in the learning stage, I am using CPUMiner on my Ubuntu 17.10 laptop. It was easy to install and get it running against my bitcoin-qt install on the same machine.
So I am already running a full bitcoin node and the miner and it is doing work. I can see that things are moving around.
What I am really struggling to figure out is how blocks are created.
I read everywhere that the full node spits out the work to be done but the miner decides how to prioritize that work so most people work on the node with the largest fee first. That makes sense. But how is that being decided? Where are the rules configured to determine if I want to discard some transactions and process others?
For example, if I really don't care how much money I make and I simply want to process the oldest transactions first (maybe those that have a low fee) just to be helpful, how do I make that happen?
How do I tell either bitcoin-qt or cpuminer (minerd) what my preferences are for what to invest my efforts in?
With this system, there is no chance of making any money but if I can understand the process better and see how it works in the real world and how I can configure it, then I can decide how to scale up (or not).
Thanks!

For this task you do not go solo but using an agent in between called the
Stratum
The node itself is supporting a custom script walletnotify which is executed whenever there is a new transaction found on the network. Then one could customise his stratum code to decide which tx actually to mine (per default they would sort them by the fees) or which ones to ignore.


text:
Bitcoin Core running in a Linux Docker container under Windows doesn't recognise an already downloaded blockchain copied from Windows Bitcoin Core
I run Bitcoin Core under Windows 10. I have now set up a Docker container to run Bitcoin Core under Linux on the Windows computer. I copied the Windows Bitcoin directory (containing all the blockchain data) to another directory and mapped the Docker container to it.
Launching the Docker container Bitcoin Core starts its initial download as if the data is not already there.
Can anyone think of any reason the Windows data would not be acceptable to the Docker/Linux app?

Doh! I had the mapping for the directory wrong in the docker file. It has now started up and is verifying the blocks.
I would delete the question, but knowing this works may be useful to someone.

FFS... I keep seeing my questions and answers edited for 'capitalisation' or should that be 'Capitalisation' -- I guess this is a way of people gaming the system to look good for their edits, while adding NOTHING of any value... I have found stack exchange useful in the past, and tried to add useful info, but it looks like it is past it - taken over by bad people (like wikipedia has been).


text:
Suppose crypto is adopted globally, and 100 years pass. Where would 100 years worth of global transactions/smart contracts be stored?
To my novice understanding the blockchain is stored on all participating computers in the network. Is this to say each computer has the entire chain downloaded onto the hard drive? Or do we merely query the chain from designated nodes? More specifically if I download Daedalus Main net or some other node software will the entire blockchain be stored and constantly updating eating up my memory little by little?

[...] each computer has the entire chain downloaded onto the hard drive? Or do we merely query the chain from designated nodes?

Full-nodes (a node is a wallet etc) typically store a full copy of the transaction journal (blockchain) locally in non-volatile storage - typically a hard-disk. Not in memory (RAM).
Pruning nodes discard transaction data that has been processed and that they no longer need - this greatly reduces their storage needs. It does slightly hamper other new full-nodes processing the full transaction journal - they have to find other, non-pruning, sources for pruned blocks. They need to do this to independently and trustlessly determine the current state (the set of monetary amounts valid for use as inputs in future transactions)
Lightweight nodes, mostly those that use Simplified Payment Verification (SPV), trust other nodes to store the full transaction journal. They don't store a permanent local copy of the transaction journal to any significant extent.
In future it may be that, in the next 100 years, SPV nodes will predominate or that non-volatile storage will be smaller, cheaper and higher capacity, or that changes to the network protocols etc will address this in novel ways.

Suppose crypto is adopted globally, and 100 years pass. Where would 100 years worth of global transactions/smart contracts be stored?

In persistent storage space. The same as now. For Bitcoin particularly, the main chain doesn't grow faster than ~50GB a year, quite sustainable compared to alternative chains with larger maximum throughput, such as the Wright hard fork.

To my novice understanding the blockchain is stored on all participating computers in the network.

Yes. Except any node catching up, and synced pruned nodes.

is this to say each computer has the entire chain downloaded onto the hard drive?

Full nodes have the entire chain in persistent storage, or they are catching up. In theory, they are always catching up, but if the last known good block is young, you could say "it is mostly up to date". You can never know if a new valid block was just mined somewhere.
Pruned nodes start removing old blocks from persistent storage when they reach their target storage use, whatever the number is, e.g. prune every block except last 2GB of block data.

Or do we merely query the chain from designated nodes?

Yes, too. As needed.

More specifically if i download Daedalus Main net or some other node software will the entire blockchain be stored and constantly updating eating up my memory little by little?

If you download a full node software, yes it'll keep eating up your storage space. If you download a pruned node software, it will not.


text:
12 or 24 words for mnemonic?
I do not have reference, but I have heard that there is no use in using more than 12 word for mnemonic, because ECDSA secp256k1 only has 128 bit strength.
Is this correct?
If it is, then does additional passphrase add anything?
Also considering that Taproot added Schnorr signatures, what is its bit security and how to understand it in all of it?

Because you don't need to actually crack the seed phrase but rather find a private key from public key, it holds that 12 words generated just as randomly is as secure as 24 words. They will both produce a 128bit secret key which means they are just as secure as each-other regardless of the permutations of the seed words.
Credit to Pieter for the fix.

In fact, cryptographically speaking, there is no benefit to private keys having more than 128 bits of entropy, as long as there is no pattern in them (e.g. don't use just 128 bit numbers as private keys, that's broken, but using the hash of 128 bit numbers appears to be just fine). The reason for suggesting more is just defense in depth.

This makes sense, my main point was that guessing 24 permutations of words should be more difficult than 12 but I guess it is not an effective increase in difficulty? How many more bits do 24 word phrases have compared to 12 word?

24 words = 256 bits, 12 words = 128 bits. But finding a private key given the public key already costs only 2^128 operations (using e.g. Pollard's rho algorithm, not using brute force of course). So if an attacker can just attack the private key keys that come out directly, there is no reason to try to find the seed.

Very interesting, so theoretically the only way to make it tougher to crack would be to increase the private-key size which ends up increasing the size of the overall elliptic curve scheme?

@PieterWuille
So if I understand it correctly, everything above 128 bit is useless ?Does this include also additional passphrase ? My understand is that it does ?
Let say that it is possible to finding a private key given the public key (Pollard's rho algorithm) how is this related to HD wallets ? My understanding is that still you would not get master seed but just for this address. Is it correct ? I am using terminology from https://github.com/bitcoin/bips/blob/master/bip-0032/derivation.png
Just trying to wrap my head around it.

I think that the password would not add extra entropy in the case of Pollard's rho algorithm, HD wallets prevent a trivial attack that can reveal a parent private key given one of its child public private key pairs. So if an attacker theoretically attacked one HD key it would not allow them to reveal its parent which would mean probably revealing all child keys as well. But in general I don't think its feasible to attack 128 bit keys with pollard's rho in the current state of computing limitations. I believe there is some people attempting to do this at large power costs on btc talk forum.


text:
What is the correct way of formatting pubkey_script in coinbase generation transaction?
This may be a simple question for others but I'm struggling trying to understand pubkey_script in the generation transaction.
In this Python code I'm trying to create a pubkey_script:
from base58 import b58decode_check

wallet_address = '35XJFXPUKGXqMyXZ2jFNSMgZqpfnWNQBQV'
pubkey_script = "76a914" + b58decode_check(wallet_address[1:].hex() + "88ac"
print(pubkey_script)

output:

76a9142a09f90b21e949ccdaa85366d1bad2d841c9054a88ac

But when I try to decode this hex string in RPC 'decodescript'
I am getting this response:
{
    "asm": "OP_DUP OP_HASH160 2a09f90b21e949ccdaa85366d1bad2d841c9054a OP_EQUALVERIFY OP_CHECKSIG",
    "desc": "addr(14qHKyu2mNDTGoq7udan1jKdhJP4u6MQGD)#c7zupad7",
    "address": "14qHKyu2mNDTGoq7udan1jKdhJP4u6MQGD",
    "type": "pubkeyhash",
    "p2sh": "3D7pDTkWYGGeMbH7XEEWFxL1SwuL3fzNhu",
    "segwit": {
        "asm": "0 2a09f90b21e949ccdaa85366d1bad2d841c9054a",
        "desc": "addr(bc1q9gyljzepa9yuek4g2dndrwkjmpqujp223l6h2y)#lz4ua3xn",
        "hex": "00142a09f90b21e949ccdaa85366d1bad2d841c9054a",
        "address": "bc1q9gyljzepa9yuek4g2dndrwkjmpqujp223l6h2y",
        "type": "witness_v0_keyhash",
        "p2sh-segwit": "3BbpKmKS2MdM3tJxT6nsPdvfHRVEyByVpy"
    }
}

From what I see in the decoded response, the original address is nowhere to be seen. I'd like to know what am I doing wrong.

In this python code i'm trying to create a pubkey_script:
...

That code is incorrect, as it is ignoring the version byte in the address, which indicates it's a P2SH address, while the scriptPubKey you're using is for P2PKH addresses.
There are currently 4 different address formats in use in Bitcoin:

The traditional P2PKH ("pay to public key hash") address format, which has existed since the original release of the Bitcoin software in 2009. It is the Base58Check encoding of 00 (the version byte) + the 20-byte hash160 of the public key. The corresponding scriptPubKey is as you say, 76a914 + that 20-byte hash + 88ac.
The P2SH ("pay to script hash") address format introduced in BIP13, in 2012. It is the Base58Check encoding of 05 (the version byte) + the 20-byte hash160 of the script. The corresponding scriptPubKey is described in BIP16, and is a9 + that 20-byte hash + 87.
The native segwit address format introduced in BIP173, in 2017. It is the Bech32 encoding (see the same BIP) with prefix "bc" of the witness version number concatenated with the 8-to-5 bit conversion of the witness program. BIP173 addresses are only used for P2WPKH and P2WSH addresses (defined in BIP141), which have version number 0, and 20-byte (public key hash160, P2WPKH) or 32 byte (script sha256, P2WSH) programs. The corresponding scriptPubKey is 00 plus the witness program.
The amended native segwit address format introduced in BIP350, in 2021. It is the Bech32m encoding (see the same BIP) with prefix "bc" of the witness version number concatenated with the 8-to-5 bit conversion of the witness program. BIP350 addresses are currently only used for P2TR addresses (defined in BIP341), which have version number 1, and 32-byte x-only tweaked public keys as witness program, but BIP350 may also be used for future address types. The corresponding scriptPubKey is byte(0x50 + witness version) plus the witness program.

The version numbers and prefixes listed above are only for Bitcoin mainnet. Testnet and other testing networks like regtest/signet have other prefixes.


text:
Optimistic Multisigs
I had an idea for an optimistic multisig scheme. In a 2/2 multisig where pubkey1 could spend any time and pubkey2 could only spend after a future block number, could you have a condition that allowed pubkey3...n to make the transaction unredeemable before pubkey2 could redeem it? This would give pubkey3...n some time to verify the integrity of the transaction based on exogenous criteria before the funds could be spent.

What you can't do without covenants enabled on Bitcoin is impose restrictions on where funds go assuming the unlocking conditions have been met. Similarly you cannot give a party or multiple parties the ability to cancel a transaction if the unlocking conditions have been met, nor can you cancel one of the possible spending paths without moving the funds to a new output with a new set of unlocking conditions. If you want pubkey3 etc to have control over whether the funds move you have to require a signature from that pubkey in the script. Perhaps you choose to require a signature from pubkey3 in every possible spending path. That's the only way to give individual 3 the ability to impact whether those funds move or not.
Without this all individual 3 can do if they aren't happy with a valid transaction that has been broadcast is enter into a fee race where individual 3 tries to get a transaction into the blockchain satisfying different unlocking conditions to a competing transaction (assuming there are multiple possible spending paths) but this is clearly not an optimal outcome and security of the funds shouldn't depend on the results of such a fee race.
This could change with the introduction of covenants but that would be dependent on the covenant proposal and the exact functionality that you would like in your script.


text:
lost 4 out of 12 recovery phrase
I lost 4 out of 12 recovery phrase
I even cant remember public address
is there a way I can find them back
please help me
thanks a lot

The BIP39 English wordlist contains 2048 entries so, since words can be repeated, you need to try (corrected) 2048 ^ 4  combinations which is 117,592,186,044,416 different phrases to try. If you could test a million guesses a second, that would take up to 204 days.
The first stage of testing would be that the checksum condition is met. This ought to be fast. I imagine the second phase involves using the phrase to generate some reasonable number of HD addresses and checking against a local copy of the blockchain to see if any generated addresses appear in any transaction outputs.
Some wallets  use a different wordlist - I think Electrum is one. Obviously you need to use the right wordlist for your wallet or attempted recovery is a complete waste of time.
There are tools that can help with this, one is btcrecover. I would use this sort of tool only on a new airgapped computer that has no WiFi, Bluetooth, Ethernet or other networking capability.
Obviously you need to be extremely careful about where and how you obtain this sort of tools. There must be many fake or maliciously altered copies around that send your recovery phrase to a thief (before or after recovery).
There is the option of adding a user passphrase to the recovery phrase. If you did use that and can't remember anything about it, I doubt the wallet is recoverable.

Useful resources

BIP39 - including implementations in numerous programming languages
bip39 checksum python

thank you for clear guidance. however I need to try 203920382037*2036 options since 8 words are already in the phrase.  my question is when I try random phrase at https://iancoleman.io/bip39/ it say Invalid mnemonic. therefore most of these options would be invalid. how can I omit these invalid option form  this possible option. and what is the rule for being valid or invalid mnemonic??

There is a checksum computation thus if the last word does not fit the checksum you don't need to test this

Answer corrected/updated accordingly, thanks.

how does this checksum computation work? how can i access it or what is the structure behind it

@lookingforhope: see last link in answer

I created a python script to try exactly this. Check it out here: https://github.com/SachinMeier/MnemonicRecovery
There is certainly no guarantee that this will work, and it's definitely not optimized for speed yet, but if you're only missing four words, it might just work. Currently, it only supports P2PKH addresses. You'll also need to install a virtual environment or have the python bitarray library installed.
The python script has no network functionality, so there's no way I can steal your seed, but you should still run it offline.
Please dm me on twitter @sachinmeier if you need help. I will never ask you for the seed or any bitcoin.


text:
Are BIP39 checksum collisions a thing?
My understanding is that 12th word is a checksum… so why are following mnemonics both valid?

gather video album produce report surge grant buzz buzz jaguar modify occur

gather video album produce report surge grant buzz buzz jaguar modify surge

12-word BIP39 phases only have a 4-bit checksum. In other words, 8 bits of the last word are still "data".

Thanks for helping out… can you please expand on this? Why are occur and surge considered valid checksums for preceding 11 words?

Your premise is wrong. It's not the whole word that is a checksum. The word is an encoding of 12 bits of data. 8 of those bits are data. The other 4 bits are checksum.

Can you please include example of how checksum is derived in answer? Having a hard time understanding how two different words can yield same checksum even if only part of work is checksum (perhaps a naive understanding of your answer).

@sunknudsen if you add a 4 bit checksum to some data there’s still a 1/16 chance that random data will validate the checksum

They may or may not be the same checksum - I haven't checked. The point is that part of the last word is part of the phrase the checksum is computed over. There shouldn't be anything surprising over the fact that two phrases can differ.

Got it… just stumbled upon https://bitcoin.stackexchange.com/questions/69957/bip39-manual-phrase-calculations-how-are-multiple-checksums-valid thanks to your feedback. Guess we can close this one?

That's a better answer!


text:
Support for taproot multisig descriptors
I’m trying to understand the current state of descriptor support for taproot, with a specific focus on multisig wallets (When I say “multisig” I mean k-of-n threshold signing, rather than a schnorr multisignature). I found this PR that introduced taproot descriptors into Core: https://github.com/bitcoin/bitcoin/pull/22051 and it said that support for more interesting scripts had not yet been implemented. Is that still the case, or does anyone know of any docs or examples to do a multisig wallet descriptor?
Thanks!

At the time of writing (January 2022) there hasn't been a descriptor specified for Schnorr/Taproot multisig (using the new OP_CHECKSIGADD opcode specified in BIP 342) or using the key aggregation scheme MuSig.

(When I say “multisig” I mean k-of-n threshold signing, rather than a schnorr multisignature)

A clarification on terminology. In Bitcoin we generally use "multisig" to refer to n-of-n (n=n) and "threshold" to refer to k-of-n (k<n). MuSig(2) refers to a key aggregation scheme where only one key and one signature go onchain despite there being multiple keys involved offchain. Threshold equivalents of MuSig(2) are being worked on e.g. FROST but are not finalized or as mature as MuSig(2). Neither MuSig(2) or FROST have descriptors specified at the time or writing.
Hence if you want to use a multisig or threshold signature descriptor you would use an existing one e.g. multi or sortedmulti that doesn't support a Schnorr/Taproot multisig. A bit confusingly the multi descriptor does support both multisignature and threshold signatures according to the above definitions but not for Schnorr/Taproot.
April 2023 Update
There are now multi_a and sortedmulti_a descriptors supported in the Bitcoin Core wallet for k-of-n policies using the CHECKSIGADD opcode inside the tr() Taproot descriptor. A MuSig(2) descriptor has been discussed and there is an open pull request in rust-miniscript implementing it but it hasn't yet been finalized.

Not related to the question so putting in the comments but Miniscript does differentiate between multisig and threshold sig (multi and thresh) but descriptors allow you to do both multisig and threshold sig using the multi descriptor. That will be confusing when MIniscript gets integrated with descriptors :)

I think traditionally in Bitcoin "multisig" refers to k-of-n using OP_CHECKMULTISIG (so using multiple signatures and multiple keys). In cryptography at large, "multisignature" refers to a single signature with multiple keys (which musig/musig2/musig-dn and other schemes achieve), and "threshold signature" refers to a single signature corresponding to a k-of-n combination of multiple keys (like FROST accomplishes).

@PieterWuille: Ok you may have changed your definitions since https://btctranscripts.com/lets-talk-bitcoin-podcast/2019-06-09-ltb-pieter-wuille-jonas-nick/ :) "k-of-n is say 2 out of 3 where k is different from n" and "When we talk about k-of-n or thresholds"

that's saying the same thing?

Thanks for the answer. I thought within bitcoin, “multisig” traditionally referred to threshold signing, for example: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#multisig . In any case, the clarification is helpful :)

There is a multi_a descriptor now.

@nikicat: Thanks. Updated answer.


text:
Simplicity vs Miniscript
It is clear that both simplicity and Miniscript aims to extend and improve upon the bitcoin script. However what are the differences between them and the pros and cons they both have against the other?