Re: [bitcoin-dev] L2s Onchain Support IRC Workshop

[Gloria Zhao via bitcoin-dev]

Hi Antoine,

Thanks for initiating this! I'm interested in joining. Since I mostly live
in L1, my primary goal is to understand what simplest version of package
relay would be sufficient to support transaction relay assumptions made by
L2 applications. For example, if a parent + child package covers the vast
majority of cases and a package limit of 2 is considered acceptable, that
could simplify things quite a bit.

A small note - I believe package relay and sponsorship (or other
fee-bumping primitive) should be separate discussions.

Re: L2-zoology... In general, for the purpose of creating a stable API /
set of assumptions between layers, I'd like to be as concrete as possible.
Speaking for myself, if I'm TDDing for a specific L2 attack, I need test
vectors. A simple description of mempool contents + p2p messages sent is
fine, but pubkeys + transaction hex would be appreciated because we don't
(and probably shouldn't, for the purpose of maintainability) have a lot of
tooling to build L2 transactions in Bitcoin Core. In the other direction,
it's hard to make any guarantees given the complexity of mempool policy,
but perhaps it could be helpful to expose a configurable RPC (e.g. #21413
) to test a range of
scenarios?

Anyway, looking forward to discussions :)

Best,
Gloria

On Fri, Apr 23, 2021 at 8:51 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> During the lastest years, tx-relay and mempool acceptances rules of the
> base layer have been sources of major security and operational concerns for
> Lightning and other Bitcoin second-layers [0]. I think those areas require
> significant improvements to ease design and deployment of higher Bitcoin
> layers and I believe this opinion is shared among the L2 dev community. In
> order to make advancements, it has been discussed a few times in the last
> months to organize in-person workshops to discuss those issues with the
> presence of both L1/L2 devs to make exchange fruitful.
>
> Unfortunately, I don't think we'll be able to organize such in-person
> workshops this year (because you know travel is hard those days...) As a
> substitution, I'm proposing a series of one or more irc meetings. That
> said, this substitution has the happy benefit to gather far more folks
> interested by those issues that you can fit in a room.
>
> # Scope
>
> I would like to propose the following 4 items as topics of discussion.
>
> 1) Package relay design or another generic L2 fee-bumping primitive like
> sponsorship [0]. IMHO, this primitive should at least solve mempools spikes
> making obsolete propagation of transactions with pre-signed feerate, solve
> pinning attacks compromising Lightning/multi-party contract protocol
> safety, offer an usable and stable API to L2 software stack, stay
> compatible with miner and full-node operators incentives and obviously
> minimize CPU/memory DoS vectors.
>
> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial
> for an attacker to partition network mempools in divergent subsets and from
> then launch advanced security or privacy attacks against a Lightning node.
> Note, it might also be a concern for bandwidth bleeding attacks against L1
> nodes.
>
> 3) Guidelines about coordinated cross-layers security disclosures.
> Mitigating a security issue around tx-relay or the mempool in Core might
> have harmful implications for downstream projects. Ideally, L2 projects
> maintainers should be ready to upgrade their protocols in emergency in
> coordination with base layers developers.
>
> 4) Guidelines about L2 protocols onchain security design. Currently
> deployed like Lightning are making a bunch of assumptions on tx-relay and
> mempool acceptances rules. Those rules are non-normative, non-reliable and
> lack documentation. Further, they're devoid of tooling to enforce them at
> runtime [2]. IMHO, it could be preferable to identify a subset of them on
> which second-layers protocols can do assumptions without encroaching too
> much on nodes's policy realm or making the base layer development in those
> areas too cumbersome.
>
> I'm aware that some folks are interested in other topics such as extension
> of Core's mempools package limits or better pricing of RBF replacement. So
> l propose a 2-week concertation period to submit other topics related to
> tx-relay or mempools improvements towards L2s before to propose a finalized
> scope and agenda.
>
> # Goals
>
> 1) Reaching technical consensus.
> 2) Reaching technical consensus, before seeking community consensus as it
> likely has ecosystem-wide implications.
> 3) Establishing a security incident response policy which can be applied
> by dev teams in the future.
> 4) Establishing a philosophy design and associated documentations (BIPs,
> best practices, ...)
>
> # Timeline
>
> 2021-04-23: Start of concertation period
> 2021-05-07: End of concertation period
> 2021-05-10: Propositi

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[Greg Maxwell via bitcoin-dev]

I endorse Harding's recommendations.  On the point about mirroring,
one thing to keep in mind is that the other repositories may go
offline.

Modification confusion could be avoided by recording what revision
(commit hash) was current at the time of inclusion, but the document
going offline can only be protected against by maintaining a copy
somewhere.


On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev
 wrote:
>
> On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote:
> > In general, I think its time we all agree the BIP process has simply failed
> > and move on. Luckily its not really all that critical and proposed protocol
> > documents can be placed nearly anywhere with the same effect.
>
> I recommend:
>
> 1. We add additional BIP editors, starting with Kalle Alm (if there are
>no continuing significant objections).
>
> 2. We seek Luke Dashjr's resignation as BIPs editor.
>
> 3. We begin treating protocol documents outside the BIPs repository as
>first-class BIP documentation.
>
> The first recommendation permits continued maintenance of existing BIPs
> plus gives the additional maintainers an opportunity to rebuild the
> credibility of the repository.
>
> The second recommendation addresses the dissatisfaction of many BIP
> authors and potential authors with the current editor, which I think
> will discourage many of them from making additional significant
> contributions to the repository.  It also seems to me to be a better use
> of Luke's talents and interests for him to focus on protocol research
> and review rather than procedurally checking whether a bunch of
> documents are well formed.
>
> The third recommendation provides an escape hatch for anyone, such as
> Matt, who currently thinks the process has failed, or for anyone who
> comes to that same conclusion in the future under a different editing
> team.  My specific recommendations there are:
>
> a. Anyone writing protocol documentation in the spirit of the BIP
>process can post their idea to this mailing list like we've always
>done and, when they've finished collecting initial feedback, they can
>assign themselves a unique decentralized identifier starting with
>"bip-".  They may also define a shorter alias that they encourage
>people to use in cases where the correct document can be inferred
>from context.  E.g.,
>
>   bip-wuille-taproot (bip-taproot)
>   bip-towns-versionbits-min-activation-height (bip-vbmah)
>   bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
>
> b. The author then publishes the document to any place they'd like, although
>they are strongly encouraged to make any document source available
>under an open license to ensure others can create their own
>modifications.
>
> c. Implementations of BIPs, whether original repository BIPs or
>decentralized BIPs, link to the BIPs they implement to ensure
>researchers and developers can find the relevant protocol
>documentation.  E.g.,
>
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
>
>  (It may also be advisable for implementations to mirror copies of
>  the BIPs they implement so later modifications to the document
>  don't confuse anyone.  For this reason, extremely liberal
>  licensing of BIP documents is encouraged.)
>
> d. To help maintain quality and consistency between documentation, the
>BIP editors provide a BIP document template, guidelines similar to
>the existing BIP2, and an easy-to-run format linter.
>
> I think this decentralized BIPs alternative also helps address some
> longstanding problems with the BIPs system: that many casual Bitcoin
> users and developers think of documents in the BIPs repo as
> authoritative and that there are some development teams (such as for LN)
> that have already abandoned the BIPs process because, in part, they want
> complete control over their own documentation.
>
> The recommendations above were developed based on conversations I had
> with a few stakeholders in the BIPs process, but I did not attempt a
> comprehensive survey and I certainly don't claim to speak for anyone
> else.  I hope the recommendations are satisfactory and I look forward to
> your feedback.
>
> Thanks,
>
> -Dave
> ___
> 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

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[David A. Harding via bitcoin-dev]

On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote:
> In general, I think its time we all agree the BIP process has simply failed
> and move on. Luckily its not really all that critical and proposed protocol
> documents can be placed nearly anywhere with the same effect.

I recommend:

1. We add additional BIP editors, starting with Kalle Alm (if there are
   no continuing significant objections).

2. We seek Luke Dashjr's resignation as BIPs editor.

3. We begin treating protocol documents outside the BIPs repository as
   first-class BIP documentation.

The first recommendation permits continued maintenance of existing BIPs
plus gives the additional maintainers an opportunity to rebuild the
credibility of the repository.

The second recommendation addresses the dissatisfaction of many BIP
authors and potential authors with the current editor, which I think
will discourage many of them from making additional significant
contributions to the repository.  It also seems to me to be a better use
of Luke's talents and interests for him to focus on protocol research
and review rather than procedurally checking whether a bunch of
documents are well formed.

The third recommendation provides an escape hatch for anyone, such as
Matt, who currently thinks the process has failed, or for anyone who
comes to that same conclusion in the future under a different editing
team.  My specific recommendations there are:

a. Anyone writing protocol documentation in the spirit of the BIP
   process can post their idea to this mailing list like we've always
   done and, when they've finished collecting initial feedback, they can
   assign themselves a unique decentralized identifier starting with
   "bip-".  They may also define a shorter alias that they encourage
   people to use in cases where the correct document can be inferred
   from context.  E.g.,

  bip-wuille-taproot (bip-taproot)
  bip-towns-versionbits-min-activation-height (bip-vbmah)
  bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)

b. The author then publishes the document to any place they'd like, although
   they are strongly encouraged to make any document source available
   under an open license to ensure others can create their own
   modifications.

c. Implementations of BIPs, whether original repository BIPs or
   decentralized BIPs, link to the BIPs they implement to ensure
   researchers and developers can find the relevant protocol
   documentation.  E.g.,
   
https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md

 (It may also be advisable for implementations to mirror copies of
 the BIPs they implement so later modifications to the document
 don't confuse anyone.  For this reason, extremely liberal
 licensing of BIP documents is encouraged.)

d. To help maintain quality and consistency between documentation, the
   BIP editors provide a BIP document template, guidelines similar to
   the existing BIP2, and an easy-to-run format linter.

I think this decentralized BIPs alternative also helps address some
longstanding problems with the BIPs system: that many casual Bitcoin
users and developers think of documents in the BIPs repo as
authoritative and that there are some development teams (such as for LN)
that have already abandoned the BIPs process because, in part, they want
complete control over their own documentation.  

The recommendations above were developed based on conversations I had
with a few stakeholders in the BIPs process, but I did not attempt a
comprehensive survey and I certainly don't claim to speak for anyone
else.  I hope the recommendations are satisfactory and I look forward to
your feedback.

Thanks,

-Dave


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[W. J. van der Laan via bitcoin-dev]

On Friday, April 23rd, 2021 at 4:09 AM, Luke Dashjr via bitcoin-dev 
 wrote:

> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.

ACK on adding Kalle.

I'm happy to finally see someone else interested in BIP maintainer role, for 
years no one really seemed to care about doing this mostly 
procedural/bureaucratic function, which is (part of) the reason Luke-Jr ended 
up as the only BIP maintainer for such a long time.

And I disagree that a bot could do this just as well. Auto-merging would open 
it up to all kinds of DoS attacks, vandalism, and low-effort scams that a 
person can easily ward against.

-W
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[James O'Beirne via bitcoin-dev]

ACK for Kalle.

On Mon, Apr 26, 2021, 09:55 Sjors Provoost via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> ACK for adding Kalle.
>
> Recent drama aside, having a single editor is not ideal. There's currently
> 110 open pull requests to the BIPs repo.
>
> - Sjors
>
> > Op 23 apr. 2021, om 04:09 heeft Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> >
> > Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> > assist in merging PRs into the bips git repo.
> >
> > Since there is no explicit process to adding BIP editors, IMO it should
> be
> > fine to use BIP 2's Process BIP progression:
> >
> >> A process BIP may change status from Draft to Active when it achieves
> >> rough consensus on the mailing list. Such a proposal is said to have
> >> rough consensus if it has been open to discussion on the development
> >> mailing list for at least one month, and no person maintains any
> >> unaddressed substantiated objections to it.
> >
> > A Process BIP could be opened for each new editor, but IMO that is
> > unnecessary. If anyone feels there is a need for a new Process BIP, we
> can go
> > that route, but there is prior precedent for BIP editors appointing new
> BIP
> > editors, so I think this should be fine.
> >
> > Please speak up soon if you disagree.
> >
> > Luke
> > ___
> > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Sjors Provoost via bitcoin-dev]

ACK for adding Kalle.

Recent drama aside, having a single editor is not ideal. There's currently 110 
open pull requests to the BIPs repo.

- Sjors

> Op 23 apr. 2021, om 04:09 heeft Luke Dashjr via bitcoin-dev 
>  het volgende geschreven:
> 
> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.
> 
> Since there is no explicit process to adding BIP editors, IMO it should be
> fine to use BIP 2's Process BIP progression:
> 
>> A process BIP may change status from Draft to Active when it achieves
>> rough consensus on the mailing list. Such a proposal is said to have
>> rough consensus if it has been open to discussion on the development
>> mailing list for at least one month, and no person maintains any
>> unaddressed substantiated objections to it.
> 
> A Process BIP could be opened for each new editor, but IMO that is
> unnecessary. If anyone feels there is a need for a new Process BIP, we can go
> that route, but there is prior precedent for BIP editors appointing new BIP
> editors, so I think this should be fine.
> 
> Please speak up soon if you disagree.
> 
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev