I setup a new bitcoin signet, welcome to use it

[Hunter.Liu]

Obviously, the testnet's block production is unstable, and the old signet is not easy to get sBTC. In order to facilitate developers, I recently launched a new signet network, including:

1. Three block-mining nodes;
2. A browser based on mempool open source software; website is:  https://signet.sathub.io
3. An electrumx service;
4. An rpc and synchronization node;
5. signet faucet(will be open in the future);

How they are connected can be seen in the documentation，https://docs.sathub.io/sathub-docs/connect

The main portal for the service is： https://sathub.io

Everyone is welcome to use it, it is free; it is currently in the trial operation stage, if you want to participate, please contact me via message box or reply this topic directly and I will give you some sBTC;


I will continue to invest time and effort in this matter to provide the community more options choice；

[ABCbits]

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)?

[Hunter.Liu]

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.

[ABCbits]

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?

[Hunter.Liu]

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.

[ebbe52e5]

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.

[Hunter.Liu]

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

[502413008@qq.com]

hi thank you for sharing. will you please send me a little sBTC? I want to try.

MY SIGNET ADDRESS: tb1qq64arjc7tez3ta9xvwrx69x0s2tyqjuwexgyn2

Thanks again.

[Hunter.Liu]

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.

[vjudeu]

no new features have been added for the time being

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).

I don’t think it is necessary to wait for 10 minutes.

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.

[kuangyu]

could you send me some please? tb1plp6jnqp4yzpym55jt3nd9cj7zux76368zujecz0l3pmytgkeld0qu0y2wa

[Hunter.Liu]

could you send me some please? tb1plp6jnqp4yzpym55jt3nd9cj7zux76368zujecz0l3pmytgkeld0qu0y2wa

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

[Hunter.Liu]

no new features have been added for the time being

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).

I don’t think it is necessary to wait for 10 minutes.

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.

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

[Hunter.Liu]

did you create this as additional option for software developer ?

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

[vjudeu]

Sometimes, mining machines come in for testing, and block reorganization and transaction loss may occur.

Anyone can try to create a single block reorganization in signet, here is how:

1. You fetch the latest signet block, for example:

Code:

$ ./bitcoin-cli -signet getblock 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a 0
000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb2770001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000

2. You grind another header, with a different nonce:

Code:

$ ./bitcoin-cli -signet getblockheader 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a false
000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb27700
$ ./bitcoin-util grind 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e00000000
000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c04

3. You submit a slightly modified block to the network:

Code:

$ ./bitcoin-cli -signet submitblock 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c0401020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000

4. You can then see a different block hash in chain tips:

Code:

$ ./bitcoin-cli -signet getchaintips
[
  {
    "height": 1103,
    "hash": "0000002efba5692bb5069e04619486257292b1f0c963c67f73a2828fa3f2a8bc",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 1097,
    "hash": "00000048c88ac6e72c6b27b21498e5fb5a36a1e60dbcb47ac659af2e6cc03dfb",
    "branchlen": 1,
    "status": "valid-headers"
  }
]

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:

Code:

1d00ffff->00000000ffff0000000000000000000000000000000000000000000000000000
1e0377ae->00000377ae000000000000000000000000000000000000000000000000000000
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff=100000000
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/00000000ffff0000000000000000000000000000000000000000000000000000=100010001
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/00000377ae000000000000000000000000000000000000000000000000000000=49d414
100000000/49d414=377
0x377=887

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.

[Hunter.Liu]

Sometimes, mining machines come in for testing, and block reorganization and transaction loss may occur.

Anyone can try to create a single block reorganization in signet, here is how:

1. You fetch the latest signet block, for example:

Code:

$ ./bitcoin-cli -signet getblock 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a 0
000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb2770001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000

2. You grind another header, with a different nonce:

Code:

$ ./bitcoin-cli -signet getblockheader 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a false
000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb27700
$ ./bitcoin-util grind 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e00000000
000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c04

3. You submit a slightly modified block to the network:

Code:

$ ./bitcoin-cli -signet submitblock 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c0401020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000

4. You can then see a different block hash in chain tips:

Code:

$ ./bitcoin-cli -signet getchaintips
[
  {
    "height": 1103,
    "hash": "0000002efba5692bb5069e04619486257292b1f0c963c67f73a2828fa3f2a8bc",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 1097,
    "hash": "00000048c88ac6e72c6b27b21498e5fb5a36a1e60dbcb47ac659af2e6cc03dfb",
    "branchlen": 1,
    "status": "valid-headers"
  }
]

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:

Code:

1d00ffff->00000000ffff0000000000000000000000000000000000000000000000000000
1e0377ae->00000377ae000000000000000000000000000000000000000000000000000000
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff=100000000
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/00000000ffff0000000000000000000000000000000000000000000000000000=100010001
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/00000377ae000000000000000000000000000000000000000000000000000000=49d414
100000000/49d414=377
0x377=887

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.

[vjudeu]

Your reply reminds me that I should further improve the miner program to make the entire signet network more stable;

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();".

[Hunter.Liu]

Your reply reminds me that I should further improve the miner program to make the entire signet network more stable;

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.

[dreamzxneo@gmail.com]

could you send me some sBTC please? tb1p8na04yg3nscanwgsedm98ygeyrnmxhmzxp0fv2uglyplnpmks25s6csuhr

[Hunter.Liu]

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.