From my admittedly rudimentary understanding of Shor's algorithm, computing the discrete log of small curve points shouldn't be any easier than computing the discrete log of any other curve point. It's still bounded by the fact that the order of the curve is 256 bits. What you'd actually need is a curve whose order is fewer bits, which Bitcoin doesn't support.

If you're talking about signature aggregation, that would require another format change, so usage within the current witness data wouldn't really make a difference.

This topic has been moved to Scam Accusations.

https://bitcointalk.org/index.php?topic=5550360.0

This topic has been moved to Beginners & Help.

https://bitcointalk.org/index.php?topic=5549275.0

This topic has been moved to Development & Technical Discussion.

https://bitcointalk.org/index.php?topic=5547636.0

Bitcoin Core has not automatically created a wallet on startup for several versions now. You must explicitly choose to create a wallet by using either the createwallet RPC or through the GUI with the "Create Wallet" menu option or the button that appears when no wallets are loaded.

No.

Policy changes have no effect on the policy rules that other nodes may choose to follow. Consensus changes would be the only changes the could "require" other node software to follow suit, but even then, it's still up to the node operators to decide which consensus rules they want to follow by choosing which software they wish to run.

There are no consensus restrictions on outputs, other than the overall block weight limit. An output can contain any opcodes, even invalid ones, and it can contain an unlimited number of them, until the block weight limit is reached. The only time an output script has any consensus validation done on it is when it is being spent.

Within the standardness rules, the upcoming v30.0 Bitcoin Core release removes the limit by default. Of course, the actual size is still bound by the transaction weight limit standardness rule of 400000 weight units, and the block weight limit if standardness is being bypassed.

Other than that error message, what makes you think the transaction is non-standard?

That error message, although is emitted by standardness checks, does not necessarily mean that the transaction is non-standard. It is often also seen when the transaction is signed incorrectly.

Determining whether an address is change is done by some data being missing from the address book. Explicitly importing a change address will set that data, which means that the address will no longer be considered change. This results in some transactions being shown in a confusing manner where change is shown as a new incoming output rather than elided as change.

No.

Deriving child keys involves hashing the parent key with the index and then adding the public key of that hash to the parent key. The important component in this is knowing the parent key. For hardened derivation, you need to know the parent private key. For unhardned, just the public key. Either way, without knowing information about the parent key, you don't know what points or private keys were added together to form the child key. Quantum computers won't help you with that.

This topic has been moved to 中文 (Chinese).

https://bitcointalk.org/index.php?topic=5546543.0

No, I'm talking about a backup of a HD wallet, made at any time.

I have, in fact, either written or reviewed all of the Bitcoin Core wallet code .

Technically, you can, within some limit of "recent".

If you have a copy of the UTXO set, you can do a balance check even if you are not online. However, this copy of the UTXO set becomes outdated the moment another block is found, although for many people, being within a couple days is most likely okay.

Even so, with a UTXO set copy, you're looking at something that is on the order of several GB of data, which will have to be downloaded from somewhere at some point in time.

Otherwise, any claims of checking a balance offline is probably a scam.

This guide makes no sense. There is no need to call importaddress for every change address; all of the change addresses are already, or will be, in the wallet after keypoolrefill. All that will probably happen is that you confuse users because any of the change that is detected via the import will be shown as watchonly first, until the private key is generated.

If you have a backup of your wallet, all you have to do is perform a rescan. Hell, most of the time you don't even need to explicitly rescan because the wallet will rescan by itself when it sees it is not up to the chain tip. You literally just have to load it and wait.

From what I can tell, Hunter is not a cryptographer, so I take this proposal with a very large grain of salt. It seems though, because he is not a cryptographer, the proposal does not choose 1 signature scheme, but rather gives users the option to choose from many. I think that's a bad idea as expecting users to understand the tradeoffs between different cryptosystems is fundamentally untenable. From a cursory reading, if one of those cryptosystems were broken, user funds could be significantly at risk. This proposal to me seems to be written by someone who strongly cares about quantum security, but is not a cryptographer so went with the classic "we do all these different cryptography things so it must be secure!"

Yes, it can export from descriptor wallets.

Not in a way that you would expect or would get useful results from.

The default mode of operation for descriptor wallets is to have a descriptor which contains a xprv from which the keys for the addresses in the wallet are derived. However, the derived keys are not stored in the wallet like they are for descriptor wallets. Instead, they are derived from the xprv when needed.

The xprv itself is not actually stored as an xprv. The actual private key component of the xprv is stored separately in the same format used for storing private keys that legacy wallets used. The xprv is essentially reconstructed at derivation time by taking the xpub in the descriptor and swapping out the pubkey for the privkey. So if you were to parse the records of descriptor wallet naively, you could create a WIF key that corresponds to the private key component of the xprv. But this WIF key would be absolutely useless to you as it is not directly used as the private key for any of your wallet's addresses, and it is not enough information to derive any of the actual private keys (you need the chaincode from the xpub to do derivation).

If your wallet has a descriptors for things that have the key directly in them rather than deriving keys, then yes, you would be able to get the WIF and have them be usable. But this really only happens if you import those things yourself, or if you migrated a pre-HD legacy wallet.

wallet-manipulator won't be exporting the keys for descriptors as WIF. It will instead reconstruct the descriptors with the full xprv so that users don't shoot themselves in the foot.

I started writing a modern pywallet replacement that may work: https://github.com/achow101/wallet-manipulator. You should be able to install it with pip install . and then the wallet-manipulator should be available. You can then export your private keys with

You can use an additional --importable option after export to get json formatted output that can be dropped directly into a Bitcoin Core importdescriptors command.

However, since you said that these files are recovered rather than the original files, this may not get all of your private keys nor will it necessarily be able to even read the files. It uses my own implementation of a BDB file parser and it generally requires that the file is properly formatted. In possible corruption scenarios, it may not behave as expected.

This topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=5543763.0

This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=5543857.0