Bitcoin Forum
November 27, 2020, 02:07:39 PM *
News: Bitcointalk Community Awards
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 570 »
1  Bitcoin / Bitcoin Technical Support / Re: Some questions about Fee per byte and Fee per vbyte on: November 22, 2020, 10:55:20 PM
1. What makes the 2 fee rates the same in one transaction and different in another?
They are the same in transactions that do not involve any segwit inputs. They are different in ones that do.

2. Which of the two is used to calculate the actual transaction fee?
Neither. The transaction fee is absolute with the fee rate calculated from that. Wallets should be using Fee per vbyte because it accounts for segwit data correctly.
2  Bitcoin / Bitcoin Technical Support / Re: Bitcoin core does not show wallet.dat ballance after syncronization and rescan on: November 16, 2020, 02:16:42 AM
How are you putting the wallet file in the directory? How are you specifying to Bitcoin Core to use that file? Please post your bitcoin.conf and any startup options that you are using.
3  Bitcoin / Development & Technical Discussion / Re: How to find the right module in bitcoin core ? on: November 11, 2020, 04:58:21 PM
Bitcoin Core interacts with the outside world primarily through 3 ways: the P2P network, RPC interface, and GUI. The RPC and GUI to roughly the same things, and it's easier to understand RPCs, so I will ignore the GUI for now.

When you want to see what happens when a user does some action, find the RPC for that action. Then you can find the function that handles that RPC in the code, and follow what it does from there. All of the RPCs can be find in the files in src/rpc/, in src/wallet/rpcwallet.cpp, or in src/wallet/rpcdump.cpp. The functions are named the same as the RPC itself so they should be easy to find.

For example, if you want to learn how message signing works, you would first look at the list of RPCs using the help RPC. Then you would see a command called signmessage. You can even look at the help text for signmessage by doing help signmessage. This would tell you that this RPC is what you would use to sign a message. Now you can search for a function named signmessage in the code. You can do this with git grep. Because it is a function, you can append a parentheses to filter out other uses of signmessage. So you would do git grep -n "signmessage(" (the -n tells git grep to print out the line numbers too. The result is that you see that there is a function signmessage() in src/wallet/rpcwallet.cpp. Now you can go there, find the function, and trace what it calls.

The other way in which Bitcoin Core receives data is through the P2P network. All of the handling of network messages is done in src/net_processing.cpp in a function named ProcessMessage. This function has several ifs to identify what type of message each message is and apply the appropriate processing. So you can search within this function for the network message that you want and trace from there how that is being handled.

For example, if you wanted to learn how blocks were processed, you would look in ProcessMessage for the block message. You would look for if (msg_type == NetMsgType::BLOCK). Once you find it, you can just trace the code to see how blocks are being handled and processed.
4  Bitcoin / Development & Technical Discussion / Re: How to do MuSig verify ? on: November 09, 2020, 06:11:14 AM
I can see pubkey (EllipticCurve Point) belonging to the bitcoin address in standard signatures. but I could not see it in the signature.
Public keys are not part of the signature. They are found alongside signatures, but can be specified in many different ways in Bitcoin that are not directly next to signatures.

actually i was wondering, this is 3LpvrH24YmEAmJ1MUfawDu6pPsm14r2FtV address pubkey
No. This is a P2SH address. It encodes the hash of a script. This script can specify many things, including pubkeys for a signature.

The P2SH address corresponds to the scriptPubKey (output script) OP_HASH160 d1e97b7dbe9a6579c88b529561643e1361c4ed13 OP_EQUAL. This specifies that the scriptSig (input script) must push to the stack a script whose hash160 is d1e97b7dbe9a6579c88b529561643e1361c4ed13. For this address, that script is 0020af6ec7b21e884eda9630f95a8d4c30b9f25e3286f62f666e61d4e8226c4bda50.

This script is  P2WSH script which means that it specifies another script. If we decode the opcodes, it is OP_0 af6ec7b21e884eda9630f95a8d4c30b9f25e3286f62f666e61d4e8226c4bda50. This indicates that the top stack item of the scriptWitness must have a sha256 of af6ec7b21e884eda9630f95a8d4c30b9f25e3286f62f666e61d4e8226c4bda50.

That script is 52210325937706eb4d50c16fc2f0ab3ee0b53e1513ebf14e0509bc5b4b09abd395c90a21022a1f8 e2169dfc64655fa0657537e70d32c584013dd2b8da9a53ab2d260c79ad32102cfc77d383647a007 03250f53339bfc2885668daeee3f6c0d34d9f1b2f7a740ab53ae. This can be decoded to OP_P2 0325937706eb4d50c16fc2f0ab3ee0b53e1513ebf14e0509bc5b4b09abd395c90a 022a1f8e2169dfc64655fa0657537e70d32c584013dd2b8da9a53ab2d260c79ad3 02cfc77d383647a00703250f53339bfc2885668daeee3f6c0d34d9f1b2f7a740ab OP_3 OP_CHECKMULTISIG. This is the mlutisig script. The public keys are found in this script. The remaining items in the scriptWitness are the signatures.

The signatures, in order, are 3044022071f1950fc6dfa95d4466164e6a8ed7bded41f723733a9799e4e371a868fd3c780220010 820bfbaf0591116076799ba7d30c7e6cd5fa02090de0deb6926a4f7f49e4701 and 3044022017beb671b4a2e7688fc357b7ade7f72bf24eff073bb42950d0fc23c6a7f2af630220317 41ae73667b21ea0229cb8950b9d950d248c26cef0f4871506ff1c47b6e0b901.

When this input is being verified, first the hash of the script in the scriptSig is checked. Then the hash of the script in the scriptWitness is checked. Then the signatures are verified. Since the pubkeys are not directly next to the signatures, the script interpreter does a bit of guessing to figure verify them.

The script interpreter will try the first signature with the first pubkey. If this fails, it then tries the next pubkey, and so on until either no pubkeys remain, or the signature verifies. Once the signature verifies, it goes to the next signature and tries the next pubkey. For example, it will try sig 1 with pubkey 1, and suppose this fails. Then it will try sig 1 with pubkey 2, and suppose this passes. Then it will try sig 2 with pubkey 3. If there were a pubkey 4, and verifying with pubkey 3 failed, then it would move to pubkey 4. But because there are only 3 pubkeys, if pubkey 3 failed, then the whole script fails.
5  Bitcoin / Development & Technical Discussion / Re: How to do MuSig verify ? on: November 09, 2020, 03:53:09 AM
Do you mean multisig? MuSig is a particular scheme that uses Schnorr signatures and is not available in Bitcoin. The transaction that you refer to is a standard Bitcoin multisig, not MuSig.



Multisigs are verified as normal ecdsa signatures. There are multiple signatures and each one verifies with one of the pubkeys in the multisig. Verification is just normal ECDSA.
6  Bitcoin / Development & Technical Discussion / Re: Did I find a bug in the Bitcoin Core wallet? on: November 08, 2020, 06:29:53 AM
The log file indicates that each of the wallets that has the transaction in question contains it because it matches against the wallet. The lines that say
Code:
AddToWallet 7b12e1df59224bfbc9b0b8f29085f9b1364ca0bd06379a2a9bb7e751aab86bb7  new
indicate that.

Would you be willing to send me the wallet.dat files so I can investigate this further?



It looks like all of these wallets contain the address 3ABxGuyibTGH4n1Y3NMKNWP8477VBGTjCs which also paid you, which is why you see the same 2 transactions show up in both. I think what is happening is that all of the fake wallets were made from the same base wallet that had send you money.

I have one address only: https://ibb.co/LgFR58B
I donít know anything about this address: https://blockchain.com/btc/address/3ABxGuyibTGH4n1Y3NMKNWP8477VBGTjCs
Maybe this is my client who once paid for a collection of wallets through the satoshidisk.com service, I no longer use this service and deleted all links.
Here are the two files that started my research: https://dropmefiles.com/eK4Hy
6 days left...
Yes, it is as I thought.

Both wallets are almost identical. Each wallet has 203 keys, of which 202 of them are identical. One of those keys that are the same is for the address 3ABxGuyibTGH4n1Y3NMKNWP8477VBGTjCs. This address has also sent money to you at 3QjnBKZAdUK3MVfekycu2FhCpT3hvmYa5X. Because both of these wallets contain the key for 3ABxGuyibTGH4n1Y3NMKNWP8477VBGTjCs, both wallets also contain the transaction made to you, thus you see them.

What likely happened is that whoever gave these wallets to you started from the same base wallet. From this wallet file, they then inserted extra records for the addresses that have the balance that you care about. At some point they sent money to you from the base wallet, perhaps to prove that the wallets have money. Regardless, the wallets are nearly identical and the reason that the transaction appears in these wallets and in your wallet is because they all contain keys involved in that particular transaction.

Therefore there is no bug and you are working with maliciously crafted wallets.
7  Bitcoin / Development & Technical Discussion / Re: Did I find a bug in the Bitcoin Core wallet? on: November 07, 2020, 05:39:51 PM
The log file indicates that each of the wallets that has the transaction in question contains it because it matches against the wallet. The lines that say
Code:
AddToWallet 7b12e1df59224bfbc9b0b8f29085f9b1364ca0bd06379a2a9bb7e751aab86bb7  new
indicate that.

Would you be willing to send me the wallet.dat files so I can investigate this further?



It looks like all of these wallets contain the address 3ABxGuyibTGH4n1Y3NMKNWP8477VBGTjCs which also paid you, which is why you see the same 2 transactions show up in both. I think what is happening is that all of the fake wallets were made from the same base wallet that had send you money.
8  Bitcoin / Development & Technical Discussion / Re: Did I find a bug in the Bitcoin Core wallet? on: November 07, 2020, 06:46:22 AM
Can you explain exactly what you do when you replace the wallet file? And by exactly, I mean every step, including shutting down Bitcoin Core, copying the file in, any other files you copy, and any files you delete.

For example:
1. Shutdown with File > Exit
2. Open data directory
3. Delete wallet.dat file
4. Copy new wallet.dat file
5. Start Bitcoin Core by double clicking shortcut.

Can you also upload the entire debug.log file (the entire thing, not just a snippet, and not just a screenshot). You can copy and paste it in, or if it is too big, upload the file somewhere or copy it's contents to a paste site like pastebin, then provide the link.



If you are shutting down and replacing the file incorrectly, it is possible that some database stuff from one wallet ends up in another wallet because the database system that the wallet uses creates more files than just the wallet.dat file. However a clean shutdown will cleanup and remove them, so there shouldn't be any problems there. Note that if this is the problem, there isn't really anything that Bitcoin Core can do other than stop using this DB system, which we are in the process of doing. In that case, there isn't a bug, just a really strange edge case and you should doing things properly to not run into it.
9  Bitcoin / Development & Technical Discussion / Re: Did I find a bug in the Bitcoin Core wallet? on: November 06, 2020, 11:32:58 PM
However, that still doesn't explain why loading one of those wallets was showing transactions for a public key that they shouldn't have (ie. a public key from your wallet). Either the scammer knows your address and was using it to troll you or Bitcoin Core did indeed pickup some cached transaction from somewhere and included it with the "new" (fake) wallet.dat info.
It is possible for a wallet to contain transactions which do not pertain to the keys in the wallet. This cannot happen under normal operation, but a scammer who is directly modifying the file can cause this to happen. There is no caching nor any bug here, OP has "fake" wallet.dat files.

Even though there are unrelated transactions in the wallet, the balance remains "correct" because the balance is computed by searching every transaction and counting up the values of the outputs that pass the IsMine check.
10  Bitcoin / Development & Technical Discussion / Re: Did I find a bug in the Bitcoin Core wallet? on: November 05, 2020, 09:52:18 PM
when I replacing the wallet.dat file, the program shows transactions that were not actually on the network.
Which transactions? What are the txids? Just posting screenshots is not helpful; we don't know what they are supposed to look like. We don't know what's in your wallet and nothing about the screenshots indicate that there is anything wrong. Furthermore, the balances are correct.

You are probably just being confusing by the transaction timestamp that Bitcoin Core reports. There is confusing behavior around the timestamp reporting which can result in incorrect and misleading timestamps. However the all of the transactions you see should be found in block explorers unless marked otherwise (i.e. they are conflicted or abandoned). Check the transaction ids, not the timestamps.

it is possible that when replacing a file, the program needs to clear some cache or something, I don't know.
Nope.
11  Bitcoin / Development & Technical Discussion / Re: Did I find a bug in the Bitcoin Core wallet? on: November 05, 2020, 09:04:44 PM
Everything is fine in the explorer, but there is some mistake in the wallet program (Bitcoin Core version v0.20.1).
What is the mistake? All the addresses you listed match with the screenshots.
12  Bitcoin / Bitcoin Technical Support / Re: Bitcoin getrawtransaction address array in vout on: November 01, 2020, 04:02:06 PM
That is clear to me now. What I don't understand yet is why there is no address in VOUT for a coinbase transaction. I am referring to the getblock rpcapi that is somehow not consistant with getrawtransaction (verbosity 2).
The same code is used for address decoding. Not all outputs correspond to addresses, so not all outputs will have an addresses field. This is especially true for old coinbase outputs because those made P2PK outputs and those don't have addresses.

The only place where one can see the output "sent" to is in VOUT in the address array correct? is there any other field containing this information?
Yes.
13  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core GUI not showing wallet functions on: November 01, 2020, 03:57:59 PM
In the Info tab, do you see a line that says "Using BerkeleyDB Version"? If you don't this means that you have a version compiled without wallet support. If you do, then you do have wallet support, but have a configuration option somewhere that disables it.
14  Bitcoin / Bitcoin Discussion / Re: Overview of lightning network nodes owned by forum users on: October 28, 2020, 05:12:53 AM
Finally setup a permanent node.

Code:
User: achow101
URI: 03e9e5a2ae70e42d012c2cecc5a2662630b97efeb13c4080168e19f23a518051c5@btcpay.achow101.com:9735
Onion UR: 03e9e5a2ae70e42d012c2cecc5a2662630b97efeb13c4080168e19f23a518051c5@grfgrvtmeokf3dyj5uimt233bue6zhae5ioijzzuyk5ajjwiy6hfnwyd.onion:9735
15  Bitcoin / Bitcoin Technical Support / Re: Is it possible to move P2PK Bitcoin using Bitcoin Core v.20.1 ? on: October 27, 2020, 03:11:13 AM
@achow101: Thx for the answer. So if I understand correctly, the coins (non genesis) are invisible because of the missing address of the p2pk script. But there is no difference inside a wallet. Am I right?
Yes.
16  Bitcoin / Bitcoin Technical Support / Re: Is it possible to move P2PK Bitcoin using Bitcoin Core v.20.1 ? on: October 26, 2020, 11:37:22 PM
Now, the fiction is over and I have a question : after reading "#16725 Donít show addresses or P2PK in decoderawtransaction" on this page https://bitcoin.org/en/release/v0.19.0.1#rpc-and-other-apis
Is it still possible to see old Bitcoin in your wallet and possibly move them into a Segwit wallet? All this without using the console command or manipulating the source code ?
Yes. The PR you refer to only changes display to the user for a particular RPC command. It does not effect wallet functionality.

Creating a watch-only wallet with Satoshi genesis block address gave me a total of 18,xx BTC in place of 68,xx.
There are 2 problems with that.

The first is that the genesis coinbase output is not spendable. It is not in the UTXO set. The wallet knows this special case so the rescan will not scan the genesis block.

The second is that importing an address will not give you the pubkey necessary for a P2PK output as those scripts don't have addresses. To add P2PK outputs as watchonly, you will need to import the public key directly.
17  Bitcoin / Bitcoin Technical Support / Re: Bitcoin getrawtransaction address array in vout on: October 26, 2020, 09:38:20 PM
The multiple address output there is misleading and never should have been added in the first place.

The multiple addresses mean that it is a multisig so that txout requires some number (defined by the scriptPubKey) of the specified pubkeys to sign the spending transaction. There are no multiple UTXOs nor does the UTXO magically split for the cosigners. It is a single UTXO that requires multiple people to spend it. It's the same thing as a normal multisig in a P2SH or P2WSH, just that the "redeemScript" is in the scriptPubKey of the output, rather than the hash of it.
18  Bitcoin / Development & Technical Discussion / MuSig2: Simple Two-Round Schnorr Multi-Signatures on: October 14, 2020, 07:00:30 PM
New paper from Jonas Nick, Tim Ruffing, and Yannick Seurin for a 2 round Schnorr Multisignature scheme based upon the original 3 round MuSig scheme.

Quote
Abstract: Multi-signatures enable a group of signers to produce a single signature on a given message. Recently, Drijvers et al. (S&P'19) showed that all thus far proposed two-round multi-signature schemes in the DL setting (without pairings) are insecure under concurrent sessions, i.e., if a single signer participates in multiple signing sessions concurrently. While Drijvers et al. improve the situation by constructing a secure two-round scheme, saving a round comes with the price of having less compact signatures. In particular, the signatures produced by their scheme are more than twice as large as Schnorr signatures, which arguably are the most natural and compact among all practical DL signatures and are therefore becoming popular in cryptographic applications (e.g., support for Schnorr signature verification has been proposed to be included in Bitcoin). If one needs a multi-signature scheme that can be used as a drop-in replacement for Schnorr signatures, then one is either forced to resort to a three-round scheme such as MuSig (Maxwell et al., DCC 2019) or MSDL-pop (Boneh, Drijvers, and Neven, ASIACRYPT 2018), or to accept that signing sessions are only secure when run sequentially, which may be hard to enforce in practice, e.g., when the same signing key is used by multiple devices.

In this work, we propose MuSig2, a novel and simple two-round multi-signature scheme variant of the MuSig scheme. Our scheme is the first multi-signature scheme that simultaneously i) is secure under concurrent signing sessions, ii) supports key aggregation, iii) outputs ordinary Schnorr signatures, iv) needs only two communication rounds, and v) has similar signer complexity as regular Schnorr signatures. Furthermore, our scheme is the first multi-signature scheme in the DL setting that supports preprocessing of all but one rounds, effectively enabling a non-interactive signing process, without forgoing security under concurrent sessions. The combination of all these features makes MuSig2 highly practical. We prove the security of MuSig2 under the one-more discrete logarithm (OMDL) assumption in the random oracle model, and the security of a more efficient variant in the combination of the random oracle and algebraic group models.

https://eprint.iacr.org/2020/1261
19  Bitcoin / Bitcoin Technical Support / Re: Unit tests return "Test suite is skipped because disabled" | Please Help on: October 14, 2020, 03:58:11 PM
I got the following output for git rev-parse HEAD.

Code:
0b2abaa666d6f3331e3246ffd64dd47946e9dcdf
Possibly a SHA1 hash  Huh
It is, and that's what I was looking for.

The exact version is "Bitcoin Core version v0.20.99.0-0b2abaa66" and I have not changed anything in the code so hopefully there shouldn't be any uncomitted changes.
Code:
Bitcoin Core version v0.20.99.0-0b2abaa66
Copyright (C) 2009-2020 The Bitcoin Core developers

Please contribute if you find Bitcoin Core useful. Visit
<https://bitcoincore.org/> for further information about the software.
The source code is available from <https://github.com/bitcoin/bitcoin>.

This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>
Doesn't look like there are any uncommitted changes.



I built this commit and it tested without any errors. As a basic troubleshooting step, I suggest that you first do make clean and then rebuild and test with make check. If it still fails, then I'll take a look at the config.log you linked earlier.
20  Bitcoin / Bitcoin Technical Support / Re: Unit tests return "Test suite is skipped because disabled" | Please Help on: October 14, 2020, 05:59:42 AM
What commit are you currently building? You can get this information by doing git rev-parse HEAD.

What is the exact version you are using (this will include the shortened git commit id and whether the build contains uncommitted changes)? You can get this by doing src/bitcoind -version, the full version number is in the first line.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 570 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!