On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
Lightning is covered by BIPs already. There's no need for a separate
repository, and the existing BOLTs should be submitted to the BIPs repository
too.
On Sunday 22 July 2018 13:45:21 René Pickhardt via Lightning-dev wrote:
> Hey everyone,
>
> in the grand tradition of BIPs I propose that we
On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
>
BOLTs should be BIPs too. Ideally, the authors should be the ones to migrate
them, but mirroring is fine - just nobody's taken the time to do it yet.
Please stop promoting lies about the BIP repo. I did not "steelman" anything.
Adding a third BIP editor more involved with Lightning sounds like
Yes, many systems doesn't really make sense. We can add editors and revise the
BIP process as needed (BOLTs might prefer to use markdown?). Even aside from
Lightning BIPs, there are several improvements that can be made, so it makes
sense to address everything at once.
Or just use BIPs instead of further fracturing...?
On Jun 30, 2021 10:10 AM, Ryan Gentry via Lightning-dev
wrote:
>
> Hi all,
>
>
> The recent thread around zero-conf channels [1] provides an opportunity to
> discuss how the BOLT process handles features and best practices that arise
> in the
On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> Still during August 2021, the Bitcoin Core dust limit was actively
> discussed on the mailing list. Changes of this dust limit would have
> affected the ongoing development of the mitigations.
The "dust limit" is arbitrarily decided by
On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > The "dust limit" is arbitrarily decided by each node, and cannot be
> > relied upon for security at all. Expecting it to be a given default value
> > is in itself a security vulnerability
>
> Reality is that an increasing number of funds
