Re: [bitcoin-dev] Is Signet Bitcoin?
I would also like to agree that Signet should be a BIP. Problem: Testnet is unreliable. *Testnet is used often for development of Bitcoin*. Proposal: To improve the dev environment for Bitcoin, let's create a new kind of testnet that is more reliable. I would also like to hear the logic behind "Testnet is Bitcoin" but "Signet is not Bitcoin"... both are not 100% compatible with mainnet consensus processes. -Jon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Chain width expansion
On 10/12/19 10:56 AM, Joachim Strömbergson via bitcoin-dev wrote: > [...] First you provide proof of your best block height via coinbase [...] So I don't think you can use the height in the coinbase for that purpose, as it's not possible to validate it without the previous headers. That's common for more than just the height. > [...] to generate much longer chain with superslow timestamp increase (~5 > blocks in 1 second) without increasing difficulty (i.e. staying at min. > diff.). [...] In that case, it would take about 7 minutes of block time seconds for the next retarget period, every 2016 blocks, and the difficulty would adjust. The difficulty would adjust in that case as if 2 weeks of blocks had been mined in 7 minutes. For the difficulty to remain the same the time between blocks needs to be 10 minutes. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Chain width expansion
On 10/12/19 9:27 AM, Tier Nolan via bitcoin-dev wrote: > [...] > > I think parallel downloading would be better than focusing on one peer > initially. Otherwise, a dishonest peer can slowly send their headers to > prevent moving to parallel mode. > > [...] As implemented, there is a timeout for that loader peer based on the amount of time it should take to request all the headers. The time period is defined as a base time plus the number of expected headers times an expected amount of time per header. For example, the timeout would be 25 minutes with a base time of 15 minutes, 1 millisecond per header and an expected 60 headers. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Is Signet Bitcoin?
Indeed, Signet is no less (or more) Bitcoin than a seed format or BIP 32. It’s “not Bitcoin” but it’s certainly “interoperability for how to build good testing for Bitcoin”. > On Oct 14, 2019, at 19:55, Karl-Johan Alm via bitcoin-dev > wrote: > > Hello, > > The pull request to the bips repository for Signet has stalled, as the > maintainer isn't sure Signet should have a BIP at all, i.e. "is Signet > Bitcoin?". > > My argument is that Signet is indeed Bitcoin and should have a BIP, as > this facilitates the interoperability between different software in > the Bitcoin space. > > Feedback welcome, here or on the pull request itself: > https://github.com/bitcoin/bips/pull/803 > ___ > 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
[bitcoin-dev] Is Signet Bitcoin?
Hello, The pull request to the bips repository for Signet has stalled, as the maintainer isn't sure Signet should have a BIP at all, i.e. "is Signet Bitcoin?". My argument is that Signet is indeed Bitcoin and should have a BIP, as this facilitates the interoperability between different software in the Bitcoin space. Feedback welcome, here or on the pull request itself: https://github.com/bitcoin/bips/pull/803 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
