Hi Lautaro, Using regtest is not ideal for public networks, as anyone anywhere can just rewrite the blockchain at their whim by mining a ton of blocks.
On Sun, Mar 10, 2019 at 4:52 AM Lautaro Dragan <lautarodra...@gmail.com> wrote: > > Hi Karl-Johan, my two cents: > > At Po.et we use regtest to simulate reorgs in integration tests in Travis / > CircleCI. It has proved quite useful. > > In general regtest for automated testing has given us all we needed so far, > but I admit we have a rather simple use of Bitcoin right now (colored coins). > > For local development, we sometimes use a script that "mines" blocks in > regtest periodically. It was my goal to also use this method in QA, although > we wound up using testnet and didn't encounter any problems so far. > > Out of curiosity: what limitations did you find in using, for example, a > private network of bitcoin core nodes running regtest? (this gives you the > same power as centralization without any changes or extra functionality > required) > > El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> escribió: >> >> Hello, >> >> As some of you already know, I've been working on a network called "signet", >> which is bascially a complement to the already existing testnet, except it >> is completely centralized, and blocks are signed by a specific key rather >> than using proof of work. >> >> Benefits of this: >> >> 1. It is more predictable than testnet. Miners appear and disappear >> regularly, causing irregular block generation. >> >> 2. Since it is centrally controlled, it is easy to perform global testing, >> such as reorgs (e.g. the network performs a 4 block reorg by request, or as >> scheduled). >> >> 3. It is more stable than testnet, which occasionally sees several thousand >> block reorgs. >> >> 4. It is trivial to spin up (and shut down) new signets to make public tests >> where anyone can participate. >> >> Anyone can create a signet at any time, simply by creating a key pair and >> creating a challenge (scriptPubKey). The network can then be used globally >> by anyone, assuming the creator sends some coins to the other participants. >> >> Having a persistent signet would be beneficial in particular to services >> which need a stable place to test features over an extended period of time. >> My own company implements protocols on top of Bitcoin with sidechains. We >> need multi-node test frameworks to behave in a predictable manner (unlike >> testnet) and with the same standardness relay policy as mainnet. >> >> Signets consist of 2 parameters: the challenge script (scriptPubKey) and the >> solution length. (The latter is needed to retain fixed length block headers, >> despite having an additional payload.) >> >> I propose that a default persistent "signet1" is created, which can be >> replaced in future versions e.g. if the coins are unwisely used as real >> money, similarly to what happened to previous testnets. This signet is >> picked by default if a user includes -signet without providing any of the >> parameters mentioned above. The key holder would be someone sufficiently >> trusted in the community, who would be willing to run the system (block >> generation code, faucet, etc). It could be made a little more sturdy by >> using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers >> disappear. If people oppose this, it can be skipped, but will mean people >> can't just jump onto signet without first tracking down parameters from >> somewhere. >> >> Implementation-wise, the code adds an std::map with block hash to block >> signature. This is serialized/deserialized as appropriate (Segwit witness >> style), which means block headers in p2p messages are (80 + solution_length) >> bytes. Block header non-contextual check goes from checking if block header >> hash < target to checking if the payload is a valid signature for the block >> header hash instead. >> >> Single commit with code (will split into commits and make PR later, but just >> to give an idea what it looks like): >> https://github.com/kallewoof/bitcoin/pull/4 >> >> I don't think this PR is overly intrusive, and I'm hoping to be able to get >> signet code into Bitcoin Core eventually, and am equally hopeful that devs >> of other (wallet etc) implementations will consider supporting it. >> >> Feedback requested on this. >> >> Attribution: parts of the signet code (in particular signblock and >> getnewblockhex) were adapted from the ElementsProject/elements repository. >> When PR is split into atomic commits, I will put appropriate attribution >> there. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
