Hi Peter,
> Obviously a local replacement cache is a possibility. The whole point of
my
> email is to show that a local replacement cache isn't necessarily needed,
as
> any alturistic party can implement that cache for all nodes.
Sure, note as soon as you start to introduce an altruistic party
Hi John,
While the idea of using sliding reaction window for blockchain congestion
detection has been present in the "smart contract" space at large [0] and
this has been discussed informally among Lightning devs and covenant
designers few times [1] [2], this is the first and best formalization
Hi Johan,
> Is this a concern though, if we assume there's no revoked state that
> can be broadcast (Eltoo)? Could you share an example of how this would
> be played out by an attacker?
Sure, let's assume no revoked state can be broadcast (Eltoo).
My understanding of the new covenant mechanism
Hi Peter,
> Altruistic third parties can partially mitigate replacement cycling(1)
attacks
> by simply rebroadcasting the replaced transactions once the replacement
cycle
> completes. Since the replaced transaction is in fact fully valid, and the
> "cost" of broadcasting it has been paid by the
Hi Johan,
Few comments.
## Transaction recycling
The transaction recycling attack is made possible by the change made
to HTLC second level transactions for the anchor channel type[8];
making it possible to add fees to the transaction by adding inputs
without violating the signature. For the
> IIRC correctly, in your scenario, you're dealing with Carol -> Bob ->
Alice.
> Mallory can only replace an HTLC-timeout transaction if she's directly
> connected with the peer she's targeting via a direct channel. She cannot
> unilaterally replace any transaction in the mempool solely with
Hi all,
I think any valid consensus-change based solution to the pinning and
replacement cycling issues for Bitcoin L2s should respect the following
properties / requirements (ideally):
- non-interactive with contribution of your off-chain counterparty
- minimize level of fee-bumping reserve and
> No, that's not a general underlying issue. You've found two separate
issues.
> Furthermore, revoked states are clearly different than HTLCs: they're
> fraudulent, and thus in punishment-using protocols they are always
associated
> with high risks of loss if they do in fact get detected or
Thanks for the write up and thanks to the bitcoin-dev mailing list
moderation team for their work along the years.
If we can pick up a communication platform where platform moderators /
infra maintainers have low-risk of being targeted by subpoena + gag order
or "injonction administrative" (the
Your two latest mails.
> The problem that OP_Expire aims to solve is the fact that Carol could
prevent
> Bob from learning about the preimage in time, while still getting a
chance to
> use the preimage herself. OP_Expire thoroughly solves that problem by
ensuring
> that the preimage is either
Hi Zeeman,
> Neither can Bob replace-recycle out the commitment transaction itself,
because the commitment transaction is a single-input transaction, whose
sole input requires a signature from
> Bob and a signature from Carol --- obviously Carol will not cooperate on
an attack on herself.
The
> I think you are misunderstanding a key point to my OP_Expire proposal:
because
> the ability to spend the preimage branch of the HTLC goes away when the
refund
> branch becomes available, replacing cycling or any similar technique
becomes
> entirely irrelevant.
> The situation where Carol
Hi John,
I think lightning and other second time-sensitive layers being hit by
safety issues whenever the blocks are full is common knowledge as the issue
is being described in the paper under the "forced expiration spam" issues
arising spontaneously within an environment with high block space
> The idea with package relay is that commitment transaction fees will
> be zero and that fees will always be paid via CPFP on the anchor
> output.
Yes, even if multiple commitment transactions are pre-signed with a RBF
range of more than zero, an attacker can always select the lowest fees
> To be clear, are you talking about anchor channels or non-anchor channels?
> Because in anchor channels, all outputs other than the anchor outputs
provided
> for fee bumping can't be spent until the commitment transaction is mined,
which
> means RBF/CPFP isn't relevant.
I think the distinction
Hi list,
As I received a lot of feedback on the full disclosure of the 16th week of
October and the following posts, some accurate, I'm taking time to address
a few of them.
I think one of the most recurring feedback is the fact that the replacement
cycling issue laid out in the initial full
5:57:36PM +0100, Antoine Riard via bitcoin-dev
> wrote:
> > Here enter a replacement cycling attack. A malicious channel counterparty
> > can broadcast its HTLC-preimage transaction with a higher absolute fee
> and
> > higher feerate than the honest HTLC-timeout of the
Hi,
I think if Gleb Naumenko and myself allocate our research time on this
issue, we should (hopefully) be able to come with a strong sustainable fix
to the lightning network, both systematically solving pinnings and
replacement cycling attacks (and maybe other mempools issues or things
related
Hi,
As I've been shown offline Twitter posts misrepresenting my previous mail,
I think it's good to correct them. The security flaws are not "intentional
backdoor" or whatever misrepresentation that would question the competence
and know-how of the Bitcoin and Lightning development community.
Hi,
After writing the mail reply on the economics of sequential malicious
replacement of honest HTLC-timeout, I did write one more test to verify the
behavior on core mempool, and it works as expected.
https://github.com/ariard/bitcoin/commit/30f5d5b270e4ff195e8dcb9ef6b7ddcc5f6a1bf2
Responsible
> As the CLTV
> delta deadline approaches, the fees in case 2 may be 50%, 80%, even
> 100% of the HTLC value under such a scorched earth policy.
A replacement-cycling attacker can afford to pay 100% of the HTLC value
under the defender scorched earth policy and still realize an economic gain.
Hi Matt,
This mitigation is mentioned in the attached paper (see subsection 3.4
defensive fee-rebroadcasting)
https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
As soon as you start to have a bit of a mempool backlog and the defensive
fractional fee
Hi Bastien,
Thanks for your additional comments.
> Yes, they can, and any user could also double-spend the batch using a
> commit tx spending from the previous funding output. Participants must
> expect that this may happen, that's what I mentioned previously that
> you cannot use 0-conf on that
Hi Bastien,
Thanks for the answer.
If I understand correctly the protocol you're describing you're aiming to
enable batched withdrawals where a list of users are being sent funds from
an exchange directly in a list of channel funding outputs ("splice-out").
Those channels funding outputs are
The disclosure mails noted a 3rd mitigation beyond mempool scanning and
transaction re-signing / re-broadcasting, namely bumping CLTV delta.
Generally bumping CLTV delta is a basic line of mitigations for a lot of
lightning attacks, as it gives opportunity to node operators to intervene
and
Hi Bastien,
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user
> We have conducted one so far, multiple scenarios to look at.
_*none*_ so far. typo of mine - apologize english is not my native language.
We discussed conducting experiments pre-disclosure in an e-mail of the 11th
August 2023.
"If someone is down to setup a "black box" Lightning infra on
Hi Zeeman,
> At block height 100, `B` notices the `B->C` HTLC timelock is expired
without `C` having claimed it, so `B` forces the `BC` channel onchain.
> However, onchain feerates have risen and the commitment transaction and
HTLC-timeout transaction do not confirm.
This is not that the
Hi Ziggie,
> thanks for this detailed explanation. This class of pinning attacks sound
not too unlikely especially if the attacker targets channels with high
capacity and very loose channel policies (allowing the full htlc
> amount to be the channel capacity). Could you add more details about the
Todd a écrit :
>
>
> On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >(cross-posting mempool issues identified are exposing lightning chan to
> >loss of funds risks, other multi-party bitcoin
(cross-posting mempool issues identified are exposing lightning chan to
loss of funds risks, other multi-party bitcoin apps might be affected)
Hi,
End of last year (December 2022), amid technical discussions on eltoo
payment channels and incentives compatibility of the mempool anti-DoS
rules, a
Hi Zeeman,
> Basically, the big issue is that the actuary needs to bond a significant
amount of funds to each participant, and that bond is not part of the
funding of the construction.
>
> Other ways of ensuring single-use can be replaced, if that is possible.
> Do you know of any?
As explained
al coinpool utxo.
>
> * assuming Eltoo in case an offline user comes back online and double
> spends the UTXO.
>
> - Johan
>
>
> On Wed, Sep 27, 2023 at 12:08 PM Antoine Riard via bitcoin-dev
> wrote:
> >
> > Hi Zeeman,
> >
> > See my comments at the
Hi John,
Thanks for the additional insightful comments. See new questions at the end.
> "My main point is that there's a huge pool of potential users that just
want payments to work, and they don't want to devote time or hardware
resources to making them work (if they can away with that)"
Sure,
rning Antoine,
>
> Does `OP_EVICT` not fit?
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Monday, Sep
Payment pools and channel factories are afflicted by severe interactivity
constraints worsening with the number of users owning an off-chain balance
in the construction. The security of user funds is paramount on the ability
to withdraw unilaterally from the off-chain construction. As such any
Hi Salvatore,
Thanks for the additional insights.
> At this time, my goal is to facilitate maximum experimentation; it's safe
to open Pandora's box in a sandbox, as that's the only way to know if it's
empty.
> Concerns will of course need to be answered when a soft-fork proposal is
made, and
cient to avoid being attacked in this way.
>
> The addition of most forms of covenant does not assist any of these
> attacks afaict because they already make assumptions rendering them invalid.
>
>
> Symphonic
>
> --- Original Message ---
> On Monday, August 14th, 20
Hi Zeeman
> What we can do is to add the actuary to the contract that
> controls the funds, but with the condition that the
> actuary signature has a specific `R`.
> As we know, `R` reuse --- creating a new signature for a
> different message but the same `R` --- will leak the
> private key.
>
Hi John,
Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to be
> adopted by casual users who want to send and receive bitcoin, but > who do
> not want to go to any effort in order to provide the infrastructure for
is way.
>
> The addition of most forms of covenant does not assist any of these
> attacks afaict because they already make assumptions rendering them invalid.
>
>
> Symphonic
>
> --- Original Message ---
> On Monday, August 14th, 2023 at 3:00 AM, An
Hi Salvatore,
> This also allows inspection of other inputs, that was not possible with
the original opcodes.
I think cross-input inspection (not cross-input signature aggregation which
is different) is opening a pandora box in terms of "malicious" off-chain
contracts than one could design. E.g
Hi Burak,
Thanks for the interesting Ark proposal.
>From my understanding the protocol is played between 3 entities: the
sender, the receiver and the ASP and you have 3 types of transactions:
- the pool_tx
- the ATLC-connection_tx
- the ATLC-refund_tx
The pool_tx spends an on-chain funding
is thread to walk away with the impression that they are two
>> independent efforts as covenants can significantly contribute to LN's
>> maturity. When and how should they be prioritized? Unfortunately I don't
>> feel able to comment on that at this time. All I know is that Lightning
>
at this time. All I know is that Lightning
> would almost certainly benefit substantially from having a covenant
> primitive.
>
> Cheers,
> Keags
>
> On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
&g
Hi list,
Last year amid the failure of the CTV speedy trial activation and intense
conversations about a rainbow of covenant proposals, I introduced the idea
of a new community process to specify covenants [0]. This post is to resume
the experiment so far and officially mark the process
Hi Joost,
> Hopefully this further raises awareness of the on-chain ephemeral
signature backup functionality that the annex uniquely enables.
>From my perspective, if vault applications can be made more robust by
on-chain backing up of ephemeral signatures, this can be rational to make
the annex
learingcustody.fidelity.com/trade-execution-quality>, which
> then draws more market activity since they are providing better prices.
>
> >Somehow mass front-running on the board is a "champagne" issue I'll be
> happy to have.
>
> This. Frontrunning is a good proble
Hi Bitcoin Devs,
Proud to announce the first release of CivKit Node, a basic Nostr relay
with additional features to have a functional peer-to-peer market board,
written in Rust [0]. This is a very raw release as since we published the
paper back in April, we've been reached out by a bunch of
Hi Greg,
> Going to need a citation for this.
Sorry for the confusion, this was in reply to Joost's point on "Opt-in
annex (every input must commit to an annex even if its is empty) -> make
sure existing multi-party protocols remain unaffected"
What is unclear to me is if we're talking about
Hi all,
> * Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected
By requiring every input to commit to an annex even if it is empty, do you
mean rejecting a transaction where the minimal annex with its 0x50 tag is
Hi Joost,
> However, the primary advantage I see in the annex is that its data isn't
included in the calculation of the txid or a potential parent commit
transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would
Hi Joost,
Thanks for detailing why a '0' as free-form, without any additional
constraints offers valuable engineering properties as of today.
>From a taproot annex design perspective, I think this could be very
valuable if you have a list of unstructured data use-cases you're thinking
about ? As
Hi Lorban,
The RFC is very clear and consistent on presenting payments pools in
the context of non-custodial mining pools, congrats to the authoring
team.
Few feedbacks, on the technical definition of a payment pool, the
common idea between all payment pools ideas presented so far
(Joinpool,
Hi list,
One obvious usage of zero-knowledge proof cryptosystems in the Bitcoin
ecosystem (e.g Bulletproofs) is the construction of privacy-preserving
UTXO ownership proofs. UTXO ownership proofs are already used in
production across the Lightning ecosystem to authenticate the channels
Hi all,
One of the most relevant feedback I received on the paper publication
was the lack of underscoring front-running resistance as a fundamental
property wished for a peer-to-peer marketplace.
It is expected the level of front-running resistance aimed by the
market participants to be heavily
Hi list,
I'm proposing Tuesday 18th April at 18:00 UTC, i.e today in function of
your timezones for the
6th Bitcoin contracting primitives WG meeting (the third Tuesday of April
month, as done previously).
Made a soft proposal for the agenda, pinning ANYPREVOUT+OP_VAULT and
use-cases like
Hi John,
Thanks for the read!
> Agreed that signing updates and monitoring the blockchain both create
always-online requirements that are not compatible with casual users'
desires. I think
> it's helpful to separate these two cases, as they affect different
parties and their solutions differ.
>
Hi list,
We have been working since a while with Nicholas Gregory (Commerce Block),
Ray Youssef (the Built With Bitcoin foundation) and few others on a new
peer-to-peer market system to enable censorship-resistant and
permissionless global trading in all parts of the world. While the design
aims
Hi list,
I'm proposing Tuesday 21st March at 18:00, i.e one week and half from now
for the 5th Bitcoin contracting primitives WG (the third Tuesday of March
month, as done previously).
There is an issue if anyone would like to propose an agenda topic in
advance in an open fashion:
Reminder: this is happening this _upcoming_ Tuesday.
Looking forward to the fourth session to roam over things like anyprevout,
the annex, vault primitive, annexcarrier!
Issue opened if anyone would like to propose an agenda topic:
> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.
> However, I do think the adversary model should be broadened, as there
> is a potential positive
Hi Yuval,
> Since the absolute fee amount is already committed to by the provided
> (`SIGHASH_ALL`) signatures but the total transaction weight is not,
Mallory can
> broadcast any valid signatures up to the maximum standard weight and
minimum
> relay fees, or in collusion with a miner, up to
Hi list,
I'm proposing Tuesday 21st February at 18:00, i.e 2 weeks from now for the
4th Bitcoin contracting primitives WG meeting (the third Tuesday of
February month, as done previously).
As mentioned during the previous session, there is an issue if anyone would
like to propose an agenda topic
Reminder: this is happening this _upcoming_ Tuesday.
Looking forward to the third session to roam over all the contracting
protocol use-cases and then listen to everyone doing research in the
contracting primitives/covenant spaces, where they would like more brain
power!
Best,
Antoine
Le ven. 6
Hi AJ,
> The idea behind this is that then you can use a signature to link a
> set of inputs and outputs via a signature in a way that's more general
> than SIGHASH_ANYONECANPAY (since you can have many inputs attesting to
> the same subset of outputs), SIGHASH_SINGLE (since you can attest to
>
Hi list,
I'm proposing Tuesday 17th January at 18:00 UTC, i.e week from now for the
3rd Bitcoin contracting primitives WG meeting (the third Tuesday of January
month, as done previously).
As a soft proposal for an agenda, it would be to start with the leftover of
the last meeting agenda. Namely,
Reminder: this is happening this _upcoming_ Tuesday.
Looking forward to the second session to roam over all the contracting
protocol use-cases and primitives and then listen to everyone doing
research in the contracting primitives/covenant spaces, where they would
like more brain power!
Best,
Hi list,
I'm proposing Tuesday 20th December at 18:00 UTC, i.e 1 week from now for
the 2nd Bitcoin contracting primitives WG meeting.
As a soft proposal for an agenda, the first part could be to roam over all
the contracting protocol use-cases and corresponding primitives, to ensure
there is
Hi John,
Thanks for expressing your thoughts on the current state of
`-mempoolfullrbf`, from the perspective of a merchant and zero-conf
proponent. First and foremost, we're dealing with a nuanced and rich topic,
implying not only the inner workings of Bitcoin Core mempool policy rules,
the
Hi Daniel,
>From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the
Hi Daniel,
>From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the
Hi list,
1st meeting did happen this afternoon with like ~10 attendees, we browsed
the covenant interests of everyone: state channels, universal settlement
layer, transaction introspection covenants, vaults/self-custody, MATT
covenants, logical label covenant like transaction inherited IDs,
Message -------
> On Monday, November 14th, 2022 at 7:51 AM, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Reminder: this is happening this _upcoming_ Tuesday.
>
> Looking forward to the first session, listening to everyone's thoughts
>
Reminder: this is happening this _upcoming_ Tuesday.
Looking forward to the first session, listening to everyone's thoughts
about what could be the scope discussed by this new community process:
anyprevout, recursive covenants, introspection, new malleability flags, ZK
rollups, new contracting
Hi Salvatore,
Thanks for bringing forward this MATT proposal!
Here my (rough) understanding of the protocol, the participants decompose
the entire computation into a number N of steps, each assigned a tapleaf,
each computation is a triplet (state_start, operation, state_end), the
tapleaves are
Hi Peter,
> We can ensure with high probability that the transaction can be
> cancelled/mined
> at some point after N blocks by pre-signing a transaction, with nLockTime set
> sufficiently far into the future, spending one or more inputs of the
> transaction with a sufficiently high fee that it
Hi AJ,
Adding a few more thoughts here on what coinjoins/splicing/dual-funded
folks can do to solve this DoS isse in an opt-in RBF world only.
I'm converging that deploying a distributed monitoring of the network
mempools in the same fashion as zeroconf people is one solution, as you can
detect
Hi Suhas,
>From my understanding, the main crux of the reasoning exposed in your post
would be to solidify the transaction-relay paradigm we have been following
during the last years, e.g introducing the carve-out rule specifically for
lightning commitment transactions, or more recently version=3
Hi list,
Reading Suhas's post on mempool policy consistency rules, and the grounded
suggestion that as protocol developers we should work on special policy
rules to support each reasonable use case on the network rather to arbiter
between class of use-cases in the design of an
unified set of
Hi list,
After I have been asked offline the exact date when those meetings were
actually starting, I'm proposing Tuesday 15th November at 18:00 UTC, i.e 2
weeks from now. Thinking about a monthly frequency for now (from my
experience attending dlcspecs/lighnting specs meetings/core dev meetings
52, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :
> Hi *,
>
> TLDR: Yes, this post is too long, and there's no TLDR. If it's any
> consolation, it took longer to write than it does to read?
>
> On Tue, Jun 15, 2021 at 12:55:14PM -0400, Ant
Hi Dario,
Thanks for providing more thoughts to the discussion!
> Notice that #26323 (option 5 in the OP) has the advantage of getting us
to a
> reliable full-RBF network the fastest (in particular, much faster than the
> current opt-in deployment) while not threatening zero-conf applications
>
> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these
and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could
Hi Dario,
Thanks for this analysis of full-RBF deployment methods!
The subject was widely discussed at today Bitcoin Core IRC meetings:
https://gnusha.org/bitcoin-core-dev/2022-10-20.log
Personally, I still think deferring full-rbf deployment, while it sounds
reasonable to let existing services
Hi Sergej,
Thanks for the insightful posting, especially highlighting the FX risk
which was far from being evident on my side!
I don't know in details the security architecture of Bitrefill zeroconf
acceptance system, though from what I suppose there is at least a set of
full-nodes
er results from a lack of communication of the Core project, I'm still
wondering on those subjects. And note again, I didn't deny the option 3)
approach as you laid out was zero-risk for 0conf operators.
All that said, if we think as a project we should offer a "zero-risk"
process towards 0co
Hi Greg,
Thanks for proposing forward the "ephemeral anchors" policy change.
> In Gloria's proposal for ln-penalty, this is worked
> around by reducing the number of anchors per commitment transaction to 1,
> and each version of the commitment transaction has a unique party's key on
> it. The
Hi John,
I hear your worry about RBF issuing concerns for 0conf acceptance
merchants. I don't think it has been denied in the first communication of
this opt-in rbf proposal back in June. Merchants/0confs builders have been
invited to bring voices to the surface at that time [0]. So this new
Hi AJ,
> 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> payments indefinitely
>
> 2) Draw a line in the sand now, but give people who are currently
> accepting unconfirmed txs time to update their software and business
> model
>
> 3) Encourage mainnet
Hi Dario,
Sorry for the latency in reply to the reaction about the full-rbf setting
I've initially pushed in 0.24, TABConf week has been a busy one.
>From my understanding, there is no disagreement from Muun wallet about the
gradual deployment of full-rbf by Bitcoin Core nodes, this is more a
Hi,
Recent advances in the development of Eltoo Lightning channels have
envisioned the usage of the Taproot annex as a transaction endpoint where
to store specific protocol payload. [0] Further, during the past years,
some use-cases such as SIGHASH_GROUP/SIGHASH_BUNDLE have been proposed that
Hi all,
Following up my September's mail on the setting of a new decentralized,
open and neutral community process dedicated to covenants R, a.k.a
"Bitcoin Contracting Primitives WG", few updates.
After collecting feedback on the adequate communication channel, a low
access bar and pseudonymous
Hi Jeremy,
Thanks for bringing back to awareness covenant-based drivechain designs
again!
I'm not super familiar with the thousands shades of sidechains, and
especially how the variants of pegging mechanisms influence the soundness
of the game-theory backing up the functionaries execution.
Hi Gloria,
Thanks for the progress on package RBF, few early questions.
> 2. Any descendant of an unconfirmed V3 transaction must also be V3.
> 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
If you're a miner and you receive a non-V3, second descendant of an
unconfirmed
Hi James,
Thanks to bringing to awareness the atomic mining pool thing, it's
interesting.
> I'm not a mining expert and so I can't speak to the efficacy of the
> paper as a whole, but direct-from-coinbase payouts seem like a
> desirable feature which avoids some trust in pools. One limitation is
Hi AJ,
Thanks to setup a new laboratory for consensus upgrades experiment! Idea
was exposed during the last LN Summit, glad to see there is a useful fork
now.
While I think one of the problem particular in the current stagnation about
consensus upgrades has been well scoped by your proposal,
Hi Buck,
> First just wanted to thank you for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of
Hi Devrandom,
> Agreed, anything that requires a phone number makes it difficult to be
> pseudonymous.
>
> I recommend Matrix, since it doesn't require any privacy invasive
> information and has e2ee by default for 1-1 conversations.
Yeah sounds like people are opting for either Matrix or IRC
Hi all,
Following up on my July's mail proposing to setup a new community process
dedicated to covenant R, after aggregating all the feedbacks received
online/offline, I've started a repository to collect the use-cases and
known design constraints:
1 - 100 of 209 matches
Mail list logo
