Hunter.Liu (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
|
July 02, 2024, 06:45:10 AM Last edit: August 22, 2024, 04:58:29 AM by 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.io3. 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/connectThe main portal for the service is: https://sathub.ioEveryone 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
Legendary
Offline
Activity: 3052
Merit: 8016
Crypto Swap Exchange
|
|
July 02, 2024, 09:18:11 AM |
|
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 (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
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
Legendary
Offline
Activity: 3052
Merit: 8016
Crypto Swap Exchange
|
|
July 02, 2024, 09:55:55 AM |
|
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 (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
|
July 02, 2024, 10:32:36 AM |
|
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
Newbie
Offline
Activity: 1
Merit: 0
|
|
July 07, 2024, 02:04:52 PM |
|
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.
|
|
|
|
|
502413008@qq.com
Newbie
Offline
Activity: 2
Merit: 0
|
|
August 13, 2024, 06:12:31 AM |
|
hi thank you for sharing. will you please send me a little sBTC? I want to try.
MY SIGNET ADDRESS: tb1qq64arjc7tez3ta9xvwrx69x0s2tyqjuwexgyn2
Thanks again.
|
|
|
|
|
vjudeu
Copper Member
Legendary
Offline
Activity: 893
Merit: 2216
|
|
August 20, 2024, 11:56:01 AM |
|
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
Newbie
Offline
Activity: 1
Merit: 0
|
|
August 21, 2024, 05:29:39 AM |
|
could you send me some please? tb1plp6jnqp4yzpym55jt3nd9cj7zux76368zujecz0l3pmytgkeld0qu0y2wa
|
|
|
|
|
Hunter.Liu (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
|
August 21, 2024, 06:15:39 AM Merited by LoyceV (4), vjudeu (1) |
|
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 (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
|
August 21, 2024, 08:50:03 AM |
|
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
Copper Member
Legendary
Offline
Activity: 893
Merit: 2216
|
|
August 21, 2024, 08:53:12 AM Last edit: August 21, 2024, 12:54:43 PM by vjudeu Merited by LoyceV (6), paid2 (1) |
|
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: $ ./bitcoin-cli -signet getblock 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a 0 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb2770001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000 2. You grind another header, with a different nonce: $ ./bitcoin-cli -signet getblockheader 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a false 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb27700 $ ./bitcoin-util grind 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e00000000 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c04 3. You submit a slightly modified block to the network: $ ./bitcoin-cli -signet submitblock 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c0401020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000 4. You can then see a different block hash in chain tips: $ ./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: 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 (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
|
August 22, 2024, 03:41:17 AM |
|
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: $ ./bitcoin-cli -signet getblock 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a 0 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb2770001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000 2. You grind another header, with a different nonce: $ ./bitcoin-cli -signet getblockheader 00000336aaef9a23c8c26aaed301ee8dbd56706c1f5abd38231b920c62a59f7a false 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e4bb27700 $ ./bitcoin-util grind 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e00000000 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c04 3. You submit a slightly modified block to the network: $ ./bitcoin-cli -signet submitblock 000000200650e5ac197ded8626635ff33cd8a6de40e3a8a6ec6abecd5ebf34fee9010000a543fb6e381fc83674162e761c2b4204c2aec50ba3c8bb96415295228255b8c626a5c566ae77031e008c6c0401020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03024904feffffff0200f2052a010000001976a914a92e25d7da68b0f86d53780c52f6a3007a95877e88ac0000000000000000776a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf94c4fecc7daa2490047304402205d839e3682fcf85fa6d3d8500e77f9d3027f78af21016de96a2a3bd8b1352d6d02206b891de7d77e7305468d4a0e26adb58d8cda6a22a22a10ab5f8c32047162df8901000120000000000000000000000000000000000000000000000000000000000000000000000000 4. You can then see a different block hash in chain tips: $ ./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: 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
Copper Member
Legendary
Offline
Activity: 893
Merit: 2216
|
|
August 22, 2024, 05:39:55 AM |
|
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 (OP)
Newbie
Offline
Activity: 18
Merit: 30
|
|
August 23, 2024, 09:43:10 AM |
|
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
Newbie
Offline
Activity: 1
Merit: 0
|
|
August 24, 2024, 09:56:43 AM |
|
could you send me some sBTC please? tb1p8na04yg3nscanwgsedm98ygeyrnmxhmzxp0fv2uglyplnpmks25s6csuhr
|
|
|
|
|
|