|
The derivation_and_script_type_dialog seems to be called when the wallet is being created using a hardware wallet not from an Electrum seed phrase. That is why path for eg. 'standard', 'legacy (p2pkh)' is being set to m/44'/0'/0' and I know for a fact that it is m/0 for Electrum mnemonics.
|
|
|
|
I just added the recovery option for Electrum mnemonics to The FinderOuter and even though the derivation path could be set manually but it would be simpler if it were set automatically based on mnemonic type selected (or the address type entered).  However I couldn't find what derivation path is used for each mnemonic type above (eg. m/0 for standard) and need help. I'd appreciate it if you could also include the link to code where it is defined. |
|
|
|
Hi Coding Enthusiast, i cant compile it  broken os. could you get a compiled one up and ready to use, for windows 10 probably, thanks a lot, just did fix the not compiling issue, used ps net . Glad it worked out for you but you should know that it is not safe to handle your private keys and other secrets on Windows specifically if the system is what you regularly use for everything else too. This is why I have only released compiled version for Linux. |
|
|
|
You generate a random 128-bit number, then add a checksum in the end for every 32 bits of entropy. A 128-bit number contains 4 times 32 bits. This means that you'll add another 4 bits in the end of the entropy. Now we have 132 bits. For every 11 bits (converted to decimal) we get a number between 0 and 2047. Since 132/11=12 it means that we get 12 words.
That's correct but to cover everything the method is to generate 16, 20, 24, 28 or 32 bytes of entropy then compute SHA256 hash of that entropy, from that hash you add enough bits to your initial entropy to make it divisible by 11. Now I would like to ask, are there any C# libraries that includes a function in which you can convert a BIP39 seed to private keys? I want to build a program that will take a seed and it'll generate me (for example) the 5 first private keys electrum would do.
BIP-39 and Electrum are two different algorithms that are not compatible with each other. Feel free to check my project ( Bitcoin.Net) string mn = "wild father tree among universe such mobile favorite target dynamic credit identify";
var elec = new ElectrumMnemonic(mn, BIP0039.WordLists.English, passPhrase: "pass123");
var bip39 = new BIP0039(mn, BIP0039.WordLists.English, passPhrase: "pass123");
var path = new BIP0032Path("m/44'/0'/0'");
PrivateKey[] elecKeys = elec.GetPrivateKeys(path, count: 5, startIndex: 0, step: 1);
PrivateKey[] bip39Keys = bip39.GetPrivateKeys(path, count: 5, startIndex: 0, step: 1);
You can look at the Tests project for examples: BIP32Tests, BIP39Tests and ElectrumMnemonicTestsI remember forum experts talking about derivation paths (like m/44'/0'/0') but I don't get how I'll put them into code.
The derivation path is defined for BIP-32. Mnemonic ( BIP-39 or what Electrum does) is a deterministic way of generating the seed (entropy) for BIP-32 using a human readable string. |
|
|
|
This list seems to be simply calling the bitnodes.io API to fetch all the IP addresses they have. It doesn't look like a blacklist though. |
|
|
|
If you want to use poem as your private key, it's easier to create a new poem (or modify existing one), then perform SHA256 on that poem and use that hash result as seed.
This is how people end up losing their bitcoins. |
|
|
|
I checked my last week of logs and don't see any "inv sent in violation of protocol", which is what gets logged if a relay=false peer sends an inv.
Thanks for checking. Here is an example IP that is violating it: 13.124.88.142:8333 None of the IP addresses I got from DNS seeds had this issue though. Fake user agent maybe? |
|
|
|
You're either sending the flag wrong,
That is not possible. you're sending a mempool message,
The only messages I send are: version, verack, sendheaders, ping. Anything else that would change relay such as filters depend on my flag to be true so they aren't sent. I also don't have any code for a mempool message. or you're getting confused by fake nodes again.
I have to investigate this but the nodes seem to be real and capable of supplying me with headers which is where I am. Let me dig the DNS seeds and come back to you on that. Update: I can't reproduce this on any of the IP addresses I get from DNS seeds! |
|
|
|
|
It is my understanding that when the relay (the last byte of a version message) is set to 0 (false) the other node is supposed to not send any inv messages containing transactions but they seem to ignore this and at the very beginning of the connection (after handshake) start sending inv messages of type MSG_TX.
Why is that?
Haven't tried all but from those that tested so far: new bitcoin core versions (0.20.1 and 0.18.0) are like this while old ones (0.12.1) aren't. In other words the new versions seem to not respect the relay flag anymore.
|
|
|
|
Version 0.4.2 released.Another minor version focusing on improving P2PNetwork namespace. - Improvements in P2PNetwork namespace (Each node now uses only 2 SAEA that are taken from a pool instantiated in IClientSettings, other improvements in ReplyManager and MessageManager)
- New BIP: Deterministic Entropy From BIP32 Keychains (used in Coldcard) (BIP-85)
- New RNG for nonce generation
- Add a new word-list to BIP-39 (Czech)
- Some bug fixes and code improvements in TransactionVerifier
- Additional tests
Version 0.5.0 released.A major version mainly improving and finishing the TransactionVerifier. - Rewrite of the TransactionVerifier with major improvements and optimization. It now uses the full potential of the powerful implementation of Bitcoin scripts in Bitcoin.Net which improves the efficiency of the transaction verification process.
- Some fixes in custom value types such as CompactInt comparison operators.
- Add new script special types to both PubkeyScript and RedeemScript
- Some improvements in P2PNetwork namespace focusing on MessageManager and ReplyManger
- Various code improvements, bug fixes and additional tests
Version 0.5.1 released.- BIP-39 can now measure Levenshtein distance for any word-list
- Small bug fix in transaction class
- NodeStatus is improved to be a better representative of the status of the connected nodes
- General code improvement and bug fixes in P2PNetwork namespace
Version 0.6.0 released.- Lots of improvements in P2P protocol for handling different messages
- Added new payload types enum
- IClientSettings now contains everything that needs handling by nodes
- Introduction of IStorage
- Big refactor of IConsensus usage
- Miner class now supports concurrency (caller can set the number of cores used for maximum efficiency)
- Addition of a new method in `RandomNonceGenerator`
- Various code improvements, optimization, bug fixes and some tests
A small road-map:The significance of this version is that it marks the end of implementation of anything that doesn't involve IStorage that includes the following interfaces: IBlockchain, IMemoryPool, IUtxoDatabase. Next versions (from 0.6.0 to 0.7.0) will focus on improving these interfaces while adding the implementations to Denovo (some may be added to the library too). That means the work on Denovo will begin and 0.1.0 will be released soon with the testnet miner. At first the old projects such as BitcoinTransactionTool and SharpPusher are going to be merged into Denovo then new features will start coming to it afterwards. |
|
|
|
addr messages contain the addresses of other nodes. It's how IP addresses for other nodes are spread around the network.
That's true most of the times but I'm talking about when nodes send you their own addr message. Let me put it this way, I connect to 185.132.178.23:18333 (satoshi 0.20.0) and send it a version message saying I know you are 185.132.178.23:18333 (in the receiving node address part), I've also connected to it so I already knew that. Then it sends me its own version message that can contain 185.132.178.23:18333 again (but it doesn't but that's irrelevant for now). After the handshake is finished it sends me an addr message saying 185.132.178.23:18333 is an address of a node!  I'm trying to figure out what the reason behind all this repetition is, specifically the last addr part. |
|
|
|
Although the code seems to be sending addr message to outbound connections ( ref) but in my experience it is sending it to inbound connections too. And in both cases I can't think of why it is doing that. When the connection is made specially if it is initiated by the other node, they should know our address and sending it again seems pointless to me. On top of that the addr message is sent after version message (hand-shake) which already contains connection information (ie. the addr message). |
|
|
|
Out of curiosity, how did you actually mine the block?  Did you just manually construct one, then started hashing until you found a nonce that fit the lowest difficulty and waited until a block had not been found for a while and the difficulty reset before broadcasting? (Possibly having to rehash if a new block was broadcast in the meantime) Or are you running a more "traditional" mining setup with a CPU/GPU/ASIC miner and just got "lucky" with the TestNet difficulty? No, this is my own implementation of Bitcoin protocol and since at this point the library part (Bitcoin.Net) is almost finished I'm testing parts that don't have unit tests while improving the API. It is a modified miner using only 2 of CPU cores and I run it only when I'm trying to create new test vectors like my last commit. I'll probably add GPU support when I start adding GPU support to FinderOuter. As for difficulty, I'm simply manipulating it to submit my test blocks. I still have to get lucky to find a good block since I don't produce that much hashrate but it is easier. |
|
|
|
Have you tried adding: acceptnonstdtxn=1 to your bitcoin.conf file before sending the transaction?
AFAIK, that should work in testnet/regtest and will allow some non-standard txns to your mempool (what's not clear is which ones).
I don't run a synced core but it wouldn't have mattered even if I did, the other nodes on the network are rejecting this specific type of non-standard transaction so it won't propagate. Besides I'm already sending them the transaction in a tx message which is no different than what forcing it into your local mempool in core would do. |
|
|
|
It's easier to do in tesnet because you can easily set a configuration to accept non-standard transactions to your mempool.
While in mainnet, the config wont work.
Actually it was not possible in TestNet either. I've tried it and the transaction was rejected, hence mining the block myself. IDK if there're other ways aside from changing the code but if there is
The problem is this flag: SCRIPT_VERIFY_WITNESS_PUBKEYTYPE The way I understand bitcoin core's code is that it doesn't disable or change flags on different networks, it just skips the IsStandard check in validation.cpp on TestNet while the non-standard flag is still used for verification of scripts eg. in interpretter.cpp and rejects this non-standard script. This flag however is not present while verifying a block since it is not a consensus rule. If I'm correct, removing this single line should fix it for accepting the transactions in mempool, or just not use standard flags in any other way that core allows it. |
|
|
|
Yes it was about the other miners / nodes rejecting the block because it contained non standard.
They will never reject a "block" because blocks do not follow standard rules. However, the nodes reject non-standard transactions because mempool enforces standard rules. Yes, that was the topic. Thanks. Since the output is still unspent I sent the starter a PM. But there are numerous people that have the same type of problem and there are a lot of coins that are unspendable.
Could you show me some of the cases, I often visit bitcointalk, reddit and stackexchange and this is the only case I've seen so far. |
|
|
|
I remember a while ago there was a topic on this forum from someone who had a large amount of bitcoin stuck in a P2SH-P2WPKH output that used an uncompressed public key and since it is non-standard it wasn't being relayed or mined and miners they contacted were also worried about their block being rejected if they included this transaction. I can't find the topic though. Well here is an example block with such a transaction on TestNet on block #1836615 ( https://tbtc.bitaps.com/1836615) which I just mined. Maybe this can help. The transaction is the only tx in the block apart from coinbase with hash= 134112254a1d0d687af0c4aa7185e62bbacf191165369d0150206f6c369ca417You can see the uncompressed public key in second witness item (the second PushData): {
"Version": 1,
"TxInList": [
{
"Outpoint": {
"TxHash": "6b16690cdc1f4f8d6a07dd241cc8526bb075b9ad62f3d9d9a9fcc710ba94db16",
"Index": 0
},
"SigScript": "PushData<0014ae456b5f88b76d858802da6996e05d5c4f084314>",
"Sequence": 4294967295
}
],
"TxOutList": [
{
"Amount": 999750,
"PubScript": "OP_DUP OP_HASH160 PushData<db1c22d11851f82e3e463f3b33c83400b15e6ab4> OP_EqualVerify OP_CheckSig"
}
],
"WitnessList": [
"PushData<3044022009c9dca57c6e4212f471169c9c89c6d5e2ef570aa9a48b55dc2dfe4f13c9f0c202205cce77d15a383b29c45deb307cd60bcc848cfd98c52778a9c0c6699390f6889401>
PushData<04576e65bd864ff1dca1116901833d432e1bc096e0a0f037f57cd0a09e9d3f96b3a88c3a627d3f9a4dfab5fff1d0dfcf03a68411722aed8e05cb3850652b4571ee>"
],
"LockTime": "0"
}
|
|
|
|
It took me some time but I finally fixed most of the issues I had with my P2PNetwork implementation so I could come back to this today to mine and submit my first block to TestNet blockchain. Block #1,836,446 https://tbtc.bitaps.com/1836446Block version is weird because it is copied from previous block, the block is empty because I don't have any mempool yet and it is just an experiment at this point. Going to test more things now on TestNet, I'll probably submit some of my RegTest block experiments here too. Thanks again for your help guys. P.S. Interesting thing was that core nodes that I connected to sent me back the same block as Inv message for some reason (highest version was 0.19.0.1). |
|
|
|
|
Show Posts
