I launched a new bitcoin signet, feel free to check it out

So, the testnet's block production has been kinda shaky lately, and getting sBTC from the old signet isn't that straightforward. To help out developers, I set up a new signet network that has: 1. Three nodes for block mining; 2. A mempool-based browser made from open-source code; check it out at: https://signet.sathub.io 3. An electrumx service; 4. A node for RPC and syncing; 5. A signet faucet (coming soon); You can see how everything connects in the documentation here: https://docs.sathub.io/sathub-docs/connect The main site for the service is: https://sathub.io Everyone's welcome to use it, no costs involved; it's still in testing, so if you're interested in joining in, hit me up on Telegram: https://t.me/+QO2WDLnHkBgyZDI1; IMPORTANT: from now on, please don’t reply to this thread (starting 01/01/2025). I’m committed to putting in the work to give the community more choices.

Hi there, welcome to bitcointalk. Looking at your block explorer, it's clear it's different from Signet network (by Bitcoin Core dev) where both network only have same genesis block. I haven't tried it, but did you create this as additional option for software developer or do you happen to offer feature which isn't exist on other Signet network (by Bitcoin Core dev)?

This is a brand-new Bitcoin network in signet mode; its features are completely consistent with the mainnet, and no new features have been added for the time being; some new features may be added in the future with reference to BIPs; This signet network only speeds up the block generation speed, which is currently about 3 minutes. I don’t think it is necessary to wait for 10 minutes. For development, what developers need is to be able to quickly see the execution results of transactions.

That makes sense, people would rather not wait 10 minutes (multiplied by total required confirmation) if possible. Did you have any specific consideration when choosing 3 minutes or is it arbitrary number?

Good question. In my past development experience, the largest P2P network transmission delay I have ever encountered was about 3 minutes. One machine was on Alibaba Cloud and one machine was on Microsoft Cloud. That was in 2020; therefore, I choose 3 minutes.

hi ethan, thanks for your great job. will you please send me a little sBTC? I want to try. MY SIGNET ADDRESS: tb1qudr5u98mx4k04x6xudeh0xgmulx3uy4gd86289 Thanks again.

Hi, sBTC has been sent with amount 0.1. If you meet some question, feel free to contact me. https://signet.sathub.io/tx/12e0c063429a853b19bea4baba4f044887539028decea1ab97c4912a7e181d21

hi thank you for sharing. will you please send me a little sBTC? I want to try. MY SIGNET ADDRESS: tb1qq64arjc7tez3ta9xvwrx69x0s2tyqjuwexgyn2 Thanks again.

Sorry, I just saw your message and 1 sBTC has been sent;   txid:  https://signet.sathub.io/tx/99d8401db5f972f49ab4ed9108f3ea197001e72542b93233cdd0041e4e0bbe60 If you meet any question, please feel free to contact me.

So, what is the purpose? Running testnet4 will give developers roughly the same outcome (and also the ability to mine their own blocks on their CPUs). It depends, what do you want to test. In some cases, I even increased the time of the block into one hour or one day, for example to batch transactions from other chains, and summarize them every sometimes. And in case of a sidechain, something like "a block per three months" is also acceptable. Also, surprisingly, regtest seems to be more stable, than I previously thought. It cannot produce more than 43,200 blocks per two hours, which is one of the reasons, why I consider opening some regtest-like network to the outside world. If things are properly notarized, then it is possible to avoid "172,8 GB per two hours scenario", because nodes can start with regtest difficulty, then self-adjust to produce one share per 10 minutes, and then it doesn't look that bad.

could you send me some please? tb1plp6jnqp4yzpym55jt3nd9cj7zux76368zujecz0l3pmytgkeld0qu0y2wa

Hi Friend，1 sBTC has been sent. txid: https://signet.sathub.io/tx/8843b6ae668f3755a8a31a6df7f57294759e5760851d0d86fea6203b99fcc67d

Glad to receive your reply. I can echo your questions on two aspects: 1. testnet3/4 is a completely open network. Sometimes, mining machines come in for testing, and block reorganization and transaction loss may occur. It is unfriendly to buider's development and joint debugging; in addition, the computing power of testnet3/4 will also fluctuate violently, which are unfriendly to buider's testing too. 2. In the world of blockchain, time is not based on physical time, but on block height. In the process of development and testing, especially for joint development, spending too much physical time waiting for a block to be high is not a good choice. If what I said is Inappropriate, please feel free to comment again

Yes, agree with you. For independent developers, regtest may be enough; but when multiple parties conduct joint debugging tests, a test network that can quickly produce blocks and fully match the characteristics of the Bitcoin main network is still very useful, and at least it will save a lot of  Waiting time, time is wealth

Anyone can try to create a single block reorganization in signet, here is how: 1. You fetch the latest signet block, for example: 2. You grind another header, with a different nonce: 3. You submit a slightly modified block to the network: 4. You can then see a different block hash in chain tips: And then, if some of your peers is on a block 1097, then that peer doesn't know, if the valid block is 00000048c88ac6e72c6b27b21498e5fb5a36a1e60dbcb47ac659af2e6cc03dfb or maybe 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a. Eventually, it will be solved, but you have to wait for the next block, to know that. This trick works mainly because nonces from block headers are not signed. Edit: Also note, that if you have very low minimal difficulty, then there is a huge potential for nonce grinding. Let's calculate it: Which means, that in case of your difficulty, for each and every block, it is possible to create something around 887 alternative block hashes, on average. Which also means, that if the validity of the block is not pre-defined somehow, then malicious actors can spread some block headers to different miners, and they will waste a lot of hashrate, before coming into consensus. As I can see, your signet challenge is 1-of-3 multisig. So, I guess, it is planned to have at least three different nodes, acting as miners. So, it is possible to observe new block headers, and for each and every header, a malicious node can broadcast around 887 different hashes, with different nonces. Then, two other mining nodes may receive those alternative headers, in a different order, depending on how nodes are connected. So, as you can see, reaching reorg-resistance is not that obvious, as it seems to be. But of course, if there is only a single miner at a given time, then it can trust its own blocks, and reject everything else.

Thank you for your detailed and wonderful reply, it’s great; If the signet we build is a completely open network, and each miner node is completely independent, the situations you mentioned will occur, grinding a new block multiple times in a block generation cycle will lead to block reorganization, which will bring great challenges to the stability of the network. On the other hand, according to my understanding, signet is a POA-likes network. We should assume in advance that each miner node is reliable, at least in the grind new block, so as to ensure that the block reorganization of the network is an extremely low probability. Therefore, in the signet network model, which we build for community,  I think two points are very important. 1. Choose honest and reliable partners to run miner nodes; 2. The miner program must be able to produce blocks stably in order. When a miner is not working, other nodes must can detecte the bad node within a period of time and put itself on the waiting list; Your reply reminds me that I should further improve the miner program to make the entire signet network more stable; Thank you again, RESPECT FOR  YOU.

Yes, this attack can be easily avoided, if all other nonces will lead to weaker blocks. So: if you for example always scan all 2^32 nonces, and make sure, that there is only one nonce, giving a valid block hash, then nobody can change it. And if you don't want to burn more power, then another possible change, is to always require a particular nonce, in case of a conflict. For example: you can require putting the lowest possible nonce, if there are two competing ones. Then, even if someone will submit another nonce, it can be easily rejected, by a simple condition, like "if(nonce2>nonce1) rejectBlock();".

good suggestion.

could you send me some sBTC please? tb1p8na04yg3nscanwgsedm98ygeyrnmxhmzxp0fv2uglyplnpmks25s6csuhr

hi, 1 sBTC has been sent, txid: https://signet.sathub.io/tx/3e53b35dcb00076bac146e8fda0868047c68158e004030640c54396de145602f If you have any question, please feel free to contact me.