|
Title: [initial connection] Some questions at the start of designing a bitcoin client Post by: jackg on December 17, 2018, 04:16:03 PM I'm designing a bitcoin client for myself and hopefully to release. I'm trying to make the design and publish it using the waterflow model in the hope that other people will be able to use it and know how bitcoin functions, but I have a few questions.
https://en.bitcoin.it/wiki/Protocol_documentation#version based on this and this https://en.bitcoin.it/wiki/Protocol_documentation#Network_address Is version and block height the same? Does the user_agent have an unlimited size or should I check the source code? Hypothetically as this will all be in one network packet, it can have an unlimited size I just wanted to check. What's service number? Finally, as field size is bits and some of the fields are bigger than what is allowed for, do we just take the end of the values? I.E the nonce is 8 bits but the uint64 is obviously 64 (or are those values in bytes)? EDIT: Ahhhh, IPv7 got invented, its bytes but does that mean the last 8 bits are set to 1. Title: Re: [initial connection] Some questions at the start of designing a bitcoin client Post by: achow101 on December 17, 2018, 05:14:21 PM Is version and block height the same? No. There are protocol version numbers which indicate support for various features. Block height is completely unrelated as the p2p protocol is not related to consensus state. A list of protocol version numbers and their descriptions is available here: https://btcinformation.org/en/developer-reference#protocol-versionsDoes the user_agent have an unlimited size or should I check the source code? Hypothetically as this will all be in one network packet, it can have an unlimited size I just wanted to check. It's unlimited but there are size constraints on messages. Don't make it super long.What's service number? I assume you mean service bits. Service bits are used to indicate what services a node supports. These include things like NODE_NETWORK (bit 0) which indicates that you support sending the complete blockchain. A list of service bits and their descriptions is found in the code (https://btcinformation.org/en/developer-reference#protocol-versions)Finally, as field size is bits and some of the fields are bigger than what is allowed for, do we just take the end of the values? I.E the nonce is 8 bits but the uint64 is obviously 64 (or are those values in bytes)? The field size is in bytes. 8 bytes is 64 bits. No field has a type that is larger than it's field size or vice versa.Title: Re: [initial connection] Some questions at the start of designing a bitcoin client Post by: Coding Enthusiast on December 18, 2018, 04:51:41 PM Don't forget to check out BIP14 (https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki) for userAgents.
By the way, how is your "code conversion" going? Title: Re: [initial connection] Some questions at the start of designing a bitcoin client Post by: jackg on December 18, 2018, 05:03:41 PM Don't forget to check out BIP14 (https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki) for userAgents. By the way, how is your "code conversion" going? I've decided to rewrite a lot of the code taking on people's advice. I'm in the designing stage (of the algorithms and data structure). I want a full design or as close to it as I can possibly get. I started doing some of the more hardcore stuff a few days ago as I was short of direction and motive for a while due to a lot of coursework that was due. The version messages are probably fine to be completely copied over and I'll work out where they are in the source later (although hopefully I can get some specific ones for my client that can cut corners a bit). I don't actually have a name but I guess I can just chuck anything with it and hope for the best, it's just a name that allows other nodes to blacklist it in case I completely mess up the source and it starts spawning random chain forks ;D. I'm wanting to use something similar to the electrum seeds and I'm hoping to try to generate an xpub and zpub, derive the native addresses from the zpub and the non-native segwit and legacy addresses from the same seed (I'm thinking of letting people use all three from the same seeds at the same time to make it much easier to make it compatible with other clients that aren't going to include native segwit). Lightning, dandelion and wimblewomble will have to be ignored for the moment however along with a few other things but hopefully I can add them later. Also, thanks for the link I'll have to check them all. I'm hoping once I get a desing that is full and will be updated while I'm writing the code, someone else can easily copy it and put it into a new language fairly easily in comparison to how it is at the moment. Hopefully I can publish a book (I can probably push something to amazon, github and my own site for free but I might have to publish under my own name so might disappear for a few weeks about that time to keep the mystery alive ;D). I'm hoping that someone can come along (maybe me) in a few years and if the document is regularly updated they can put it into Go if that language turns out to be faster than C# by that time or maybe there'll be a new quantum oriented language by that time. I've never put two and two together before now :( https://i.imgur.com/WukeD09.png Based on that, I'm guessing dots are necessary - I haven't moved onto blocks yet though? |
