On Wed, Sep 15, 2021 at 08:24:43AM -0700, Matt Corallo via bitcoin-dev wrote:
> > On Sep 13, 2021, at 21:56, Anthony Towns wrote:
> > I'm not sure that's really the question you want answered?
> Of course it is? I’d like to understand the initial thinking and design
> analysis that went into this
> On Sep 13, 2021, at 21:56, Anthony Towns wrote:
> I'm not sure that's really the question you want answered?
Of course it is? I’d like to understand the initial thinking and design
analysis that went into this decision. That seems like an important question to
ask when seeking changes in an
On Sun, Sep 12, 2021 at 10:33:24PM -0700, Matt Corallo via bitcoin-dev wrote:
> > On Sep 12, 2021, at 00:53, Anthony Towns wrote:
> >> Why bother with a version bit? This seems substantially more complicated
> >> than the original proposal that surfaced many times before signet launched
> >> to ju
> On Sep 13, 2021, at 05:30, Michael Folkson wrote:
>
>
>>
>> Can you explain the motivation for this? From where I sit, as far as I know,
>> I should basically be > a prime example of the target market for public
>> signet - someone developing bitcoin applications > with regular requireme
> Can you explain the motivation for this? From where I sit, as far as I know,
> I should basically be > a prime example of the target market for public
> signet - someone developing bitcoin applications > with regular requirements
> to test those applications with other developers without
> jum
> On Sep 12, 2021, at 00:53, Anthony Towns wrote:
>
> On Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoin-dev wrote:
>>> AJ proposed to allow SigNet users to opt-out of reorgs in case they
>>> explicitly want to remain unaffected. This can be done by setting a
>>> to-be-reorged
> Sometimes that reorg could be deeper if you would be lucky enough to get
a block with more work than N following blocks combined
Each block is credited for its contribution to total chainwork by the
difficulty target, not the hash of the block itself.
On Sun, Sep 12, 2021 at 10:42 PM vjudeu via
> - 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
Anyone can do 1 block reorg, because nonce is not signed, so anyone can replace
that with better value. For example, if
On Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoin-dev wrote:
> > AJ proposed to allow SigNet users to opt-out of reorgs in case they
> > explicitly want to remain unaffected. This can be done by setting a
> > to-be-reorged version bit [...]
> Why bother with a version bit? This see
> Huh? Why would the goal be to match mainnet? The goal, as I understand it, is
> to allow software to
use SigNet without modification *to make testing simpler* - keep the
header format the same to let
SPV clients function without (significant) modification, etc. The
point of the whole thing is to
On Fri, Sep 10, 2021 at 11:24:15AM -0700, Matt Corallo via bitcoin-dev wrote:
> I'm [...] suggesting [...] that the existing block producers each
> generate a new key, and we then only sign reorgs with *those* keys.
> Users will be able to set a flag to indicate "I want to accept sigs
> from either
Fwiw, your email client is broken and does not properly quote in the plaintext copy. I believe this
is a known gmail bug, but I'd recommend avoiding gmail's web interface for list posting :).
On 9/10/21 12:00, Michael Folkson wrote:
Huh? Why would the goal be to match mainnet? The goal, as I un
On 9/10/21 06:05, Michael Folkson wrote:
I see zero reason whatsoever to not simply reorg ~every block, or as often as
is practical. If users opt in to wanting to test with reorgs, they should be
able to test with reorgs, not wait a day to test with reorgs.
One of the goals of the default
> I see zero reason whatsoever to not simply reorg ~every block, or as often as
> is practical. If users opt in to wanting to test with reorgs, they should be
> able to test with reorgs, not wait a day to test with reorgs.
One of the goals of the default Signet was to make the default Signet
res
On 9/7/21 09:07, 0xB10C via bitcoin-dev wrote:
Hello,
tl;dr: We want to make reorgs on SigNet a reality and are looking for
feedback on approach and parameters.
Awesome!
AJ proposed to allow SigNet users to opt-out of reorgs in case they
explicitly want to remain unaffected. This can be don
On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> The reorg-interval X very much depends on the user's needs. One could
> argue that there should be, for example, three reorgs per day, each 48
> blocks apart.
Oh, wow, I think the last suggestion was every 100 blocks (every
If you make the to be reorged flag 2 bits, 1 bit can mark final block and
the other can mark to be reorged.
That way the nodes opting into reorg can see the reorg and ignore the final
blocks (until a certain time? Or until it's via a reorg?), and the nodes
wanting not to see reorgs get continuous
Hello,
tl;dr: We want to make reorgs on SigNet a reality and are looking for
feedback on approach and parameters.
One of the ideas for SigNet is the possibility for it to be reliably
unreliable, for example, planned chain reorganizations. These have not
been implemented yet.
My summerofbitcoin.o
18 matches
Mail list logo
