public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
@ 2023-05-28  6:02 Ali Sherief
  0 siblings, 0 replies; 19+ messages in thread
From: Ali Sherief @ 2023-05-28  6:02 UTC (permalink / raw)
  To: bitcoin-dev, burak

[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]

Burak, I don't remember if this has been mentioned previously in the conversation about Ark, but a disadvantage in the protocol as it is currently is that "Ark require users to come online and "refresh" their coins every few weeks, otherwise the ASP can sweep the funds." (putting that in quotes because although I copied this from a forum, it may have originally been said on this list.)

However, yesterday I have come up with a scheme to mitigate this disadvantage, in a way that works similar to LN watchtowers.

This watchtower program for Ark would be made that runs on an internet-connected server and inputs your wallet password and the date in the future to perform the refreshing. A child process can then be spawned that acts similar to a cronjob, and stores the wallet password with AES encryption in memory.

The key to this cipher is the time stored in ISO 8601 format as a byte string. It is promptly discarded from memory.

Every second, the watchtower child process will attempt to decrypt the cipher using the current ISO 8601 time looking like "YYYY-mm-ddTHH:MM:SSZ" as the key.

Naturally this will only succeed at the requisite time at which the wallet is to be unlocked by the watchtower child process - following which the coins inside the ASP are refreshed, and the watchtower child process is terminated and the encrypted wallet password destroyed.

Of course, memory scrubbing should be applied to the region that has the decrypted wallet password.
If at any point the user comes online by themselves, they can simply cancel the watchtower refreshing task, which will terminate the watchtower child process without opening your wallet and refreshing coins.

The key feature is that nobody will be able to decrypt the wallet password unless they know the exact time it is to be unlocked as an ISO 8601 string. It cannot be unlocked at any time in the future, just at that particular instant, as long as the key is discarded and the software randomly guesses the decryption by attempting each second the new time as the encryption key. Even if the watchtower is hacked after the task has been made, the hacker still won't be able to decrypt the wallet password unless they brute-force the encryption key by exhaustively trying all timestamps in the future.

Alternatively, instead of encrypting the wallet password, it can encrypt a signed transaction which is used by Ark to refresh the coins. In this case, the wallet password would still need to be collected, but only for the purpose of signing the transaction, after which the password is promptly erased from memory.

How this can be extended to repeatedly arming the watchtower program with refreshes remains to be seen, but using the wallet password as the encryption directly is one option albeit not a secure one A better and more secure option would be to take note of the UTXOs created by the coin refreshing transaction, use those as inputs to a second refreshing transaction that is created immediately after the first one, sign it, and similarly create a third, fourth, etc. as many as are desirable for the user. Then every 4 weeks, one of these transactions can be broadcasted, in the order that they were created obviously.

Looking forward to your feedback on this.
-Ali

[-- Attachment #2: Type: text/html, Size: 4819 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread
* [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
@ 2023-06-11  9:19 moonsettler
  0 siblings, 0 replies; 19+ messages in thread
From: moonsettler @ 2023-06-11  9:19 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

Hi All,

I have a question about the often touted statement that "APO can emulate CTV". From what I have found in the specs and the inquisition codebase:

> BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash.

APO/AS SIGHASH does not commit to the number of inputs (nor obviously the other input outpoints themselves). This has some interesting consequences for Ark, which relies on TXID non-malleability for it's ATLCs.

Either one of these cases seem to be true depending on how the contracts are constructed:

- APO only: Users can double spend the ASP (USER CAN STEAL)
- APO + ASP single sig: ASP can stop users from unilateral exit and sweep funds after 4 weeks (ASP CAN STEAL)
- n-of-n musig on the vTXO tree: trustless, APO however is not needed, full interactivity, analogous to key deletion covenant (NOBODY CAN STEAL)

APO/AS can also not be used for the ATLC itself, as it has to commit to the TX outpoint of the connector transaction.

OP_CTV however commits to the number of inputs explicitly, thus committing to a single input prevents TXID malleability and ensures the ATLC is going to be enforceable.

I would like to ask what the devs who are deeper into covenant research think about this, and if I'm missing something?
- moonsettler

[-- Attachment #2: Type: text/html, Size: 1995 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
@ 2023-06-07 18:20 David A. Harding
  0 siblings, 0 replies; 19+ messages in thread
From: David A. Harding @ 2023-06-07 18:20 UTC (permalink / raw)
  To: Burak Keceli; +Cc: Bitcoin Protocol Discussion

On 2023-06-07 03:30, Burak Keceli wrote:
> If the service provider double-spends a transaction that enforces a
> one-time signature where Bob is the vendor, Bob can forge the service
> provider’s signature from the 2-of-2 and can immediately claim his
> previously-spent vTXO(s).

Hi Burak,

I'm confused.  Bob owns some bitcoins that are timelocked against
immediate withdrawal, but where he can spend immediately with the
cooperation of service provider Sally.  Bob transfers some bitcoins to
Sally contingent on her spending an equal amount of bitcoins (minus a
fee) to Carol.  You already have a mechanism to enforce this contingency
(tx outpoints), so if Carol doesn't receive the bitcoins from Sally,
then Sally also doesn't receive the bitcoins from Bob.  In other words,
you already have atomicity for a single transfer.

Are you describing the effect over multiple transfers?  For example, Bob
previously transferred bitcoins to Sally and she paid users X, Y, and Z
in transactions that are now confirmed onchain, although she hasn't yet
swept Bob's funds.  Now when Sally double spends the payment to Carol,
Bob can not only reclaim the funds he gave Sally to pay to Carol (which
was guaranteed by the atomicity), he can also reclaim the unswept funds
he gave Sally to pay X, Y, and Z.

If so, I don't think that works.  In a private protocol, Carol can't be
sure that Bob and Sally are separate individuals.  If they're the same
entity, then any forfeit that Sally needs to pay Bob is just an internal
transfer, not a penalty.

I'd appreciate any clarification you can offer.  Thanks!,

-Dave


^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
@ 2023-05-26  7:33 jk_14
  0 siblings, 0 replies; 19+ messages in thread
From: jk_14 @ 2023-05-26  7:33 UTC (permalink / raw)
  To: David A. Harding, Bitcoin Protocol Discussion, Burak Keceli,
	Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/html, Size: 8961 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
@ 2023-05-25 12:12 Ali Sherief
  0 siblings, 0 replies; 19+ messages in thread
From: Ali Sherief @ 2023-05-25 12:12 UTC (permalink / raw)
  To: bitcoin-dev, dave; +Cc: burak

Regarding this:

> Users are not so well protected during reorgs, e.g. if Bob double-spends
> a transaction whose funds were later used in a payment to Carol, then
> Carol loses the money. For this reason, Alice will probably want to
> prove to users that no funds they receive in a payment derive from any
> deposit less than safe_confirmation_depth blocks.

I'm of the opinion that any L2 protocol having a similar concept of block mining but for L2 transactions is a pretty good idea, but the reorgs trapdoor you mentioned could theoretically be mitigated ARK nodes considering their settling transactions on L1 as final after say, 3 blocks, or maybe even 6 blocks.

I'm leaning towards the standard 6 blocks, as this delay is invisible to users anyway, and only node operators will really notice it.

It is kind of the same way how miners can't spend coinbase transactions for 100 blocks.

It's a pretty good idea from Burak though, and I can't wait to see nodes in action with this.

- Ali

> Hi Burak,
> 
> Thanks for this really interesting protocol! I tend to analyze
> complicated ideas like this by writing about them in my own words, so
> I've pasted my summary of your idea to the end of this email in case
> it's useful, either to other people or to you in helping understand my
> one concern.
> 
> My concern is the same one I think Olaoluwa Osuntokun mentioned on
> Twitter[1] and (less clear to me) might be related to ZmnSCPxj's
> concern[2]:
> 
> It seems to me that receiving a payment on the protocol, including
> conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting
> for the transaction containing that payment to confirm to a sufficient
> depth (e.g., I'd wait 6 blocks for small payments and longer for huge
> payments). Am I missing something?
> 
> My summary of how I think that part of the protocol works is in the
> sections labeled "Make an unconditioned payment" and "Make a conditional
> payment" below. In short, it's clear to me how the service provider and
> the customer can make instant atomic swaps with each other---they can
> either spend instantly cooperatively, or they have to wait for a
> timeout. But how can a receiver of funds be assured that they will
> actually get those funds unless there's already a timelock and
> cooperative spend path placed on those funds?
> 
> -Dave
> 
> Rough initial summary of Ark protocol:
> 
> Alice runs an Ark service provider. Every 5 seconds, she broadcasts a
> new unconfirmed onchain transaction that pays three outputs (the
> three Cs):
> 
> 1. Change Output: money not used for the other two Cs that gets sent
> back to the the transaction creator.
> 
> 2. Connector Output: an output that will be used in a future
> transaction created by Alice as protection against double spends.
> 
> 3. Commitment Output: a CTV-style commitment to a set of outputs that
> can be published later in a descendant transaction (alternatively,
> the commitment output may be spent unilaterally by Alice after 4
> weeks).
> 
> Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT
> with an input of his and a change output. She updates the PSBT with a
> commitment output that refunds Bob the 1 BTC and a connector output with
> some minimum value. They both sign the PBST and it is broadcast. We'll
> ignore fees in our examples, both onchain transaction fees and fees paid
> to Alice.
> 
> From here, there are several things that Bob can do:
> 
> - Unilaterally withdraw: Bob can spend from the commitment output to
> put his refund onchain. The refund can only be spent after a 24-hour
> time delay, allowing Bob to optionally come to an agreement with Alice
> about how to spend the funds before Bob can spend them unilaterally
> (as we'll see in a moment). For example, the script might be[3]:
> 
> pk(B) && (older(1 day) || pk(A))
> 
> - Collaboratively withdraw: as seen above, Bob has the ability to come
> to a trustless agreement with Alice about how to spend his funds.
> They can use that ability to allow Bob to trade his (unpublished) UTXO
> for a UTXO that Alice funds and broadcasts. For example:
> 
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction. This will ensure that
> any attempt by Bob to double-spend his deposit transaction will
> invalidate this withdrawal transaction, preventing Bob from being
> able to steal any of Alice's funds.
> 
> Also included in Alice's unsigned PSBT is another connector
> output plus the output that pays Bob his 1 BTC.
> 
> - Bob receives Alice's unsigned PSBT and creates a separate PSBT
> that includes his unpublished UTXO as an input, giving its value
> to Alice in an output. The PSBT also includes as an input the
> connector output from Alice's PSBT. This will ensure that any
> attempt by Alice to double spend her transaction paying him will
> invalidate his transaction paying her.
> 
> - Bob signs his PSBT and gives it to Alice. After verifying it,
> Alice signs her PSBT and broadcasts it.
> 
> - Collaboratively trade commitments: as mentioned, the commitment
> output that pays Bob may be claimed instead by Alice after 4 weeks, so
> Bob will need to either withdraw or obtain a new commitment within
> that
> time. To trade his existing commitment for a new commitment looks
> similar to the collaborative withdrawal procedure but without the
> creation of an immediately-spendable onchain output:
> 
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction, again preventing double
> spending by Bob. Alice also includes a new connector and a new
> commitment that again allows Bob to later claim 1 BTC.
> 
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her, with the new connector again being
> included as an input to ensure atomicity.
> 
> - Bob signs; Alice signs and broadcasts.
> 
> - Make an unconditioned payment: using the mechanisms described above,
> it's possible to make either an onchain payment or an offchain
> payment---just have Carol receive the new output or commitment rather
> than Bob. That payment would have no conditions (except its
> atomicity).
> 
> - Make a conditional payment: imagine that Carol knows a secret (e.g.
> a preimage) that Bob is willing to pay for.
> 
> - Alice creates an unsigned PSBT depending on the connector from
> Bob's deposit transaction and creating a new connector. The PSBT
> includes an output paying Carol (either onchain or via a
> commitment) with an HTLC, allowing Carol to claim the funds if
> she
> reveals the secret or allowing Bob to claim the funds after a
> timeout.
> 
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her with the HTLC condition attached and,
> again, with connectors being used to ensure atomicity.
> 
> - Bob signs; Alice signs and broadcasts.
> 
> - Carol can settle her HTLC by either revealing the secret onchain
> or by trading her commitment containing the HTLC clause for a
> commitment from Alice that doesn't contain the clause (which
> Alice will only accept by learning the secret, since Alice has
> to settle with Bob). Alice can then either settle onchain or
> trade commitments with Bob after giving him the secret.
> 
> - Do nothing for 4 weeks: if Bob does nothing for four weeks, Alice
> can claim the funds from the commitment output (i.e., takes his
> money).
> 
> If Bob did actually do something, and if every other user who also
> had an unpublished output in the commitment transaction did
> something, then they all exchanged their portion of the funds in
> this output to Alice, so Alice can now claim all of those funds
> onchain in a highly efficient manner.
> 
> Regarding the connector outputs, although all of the examples above show
> Alice directly spending from the connector output in Bob's deposit
> transaction, atomicity is also ensured if Alice spends from any output
> descended from Bob's connector output. Connector outputs from different
> deposits can be used as inputs into the same transaction, merging their
> histories. This allows all operations made by Alice to be fully atomic,
> ensuring that she doesn't lose any money during a reorg of any length.
> 
> Users are not so well protected during reorgs, e.g. if Bob double-spends
> a transaction whose funds were later used in a payment to Carol, then
> Carol loses the money. For this reason, Alice will probably want to
> prove to users that no funds they receive in a payment derive from any
> deposit less than safe_confirmation_depth blocks.
> 
> [1] https://twitter.com/roasbeef/status/1661266771784126464
> 
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.html
> 
> [3]
> https://min.sc/#c=pk(B) %26%26 (older(1 day) || pk(A))


^ permalink raw reply	[flat|nested] 19+ messages in thread
* [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
@ 2023-05-22  7:54 Burak Keceli
  2023-05-22 13:03 ` ZmnSCPxj
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Burak Keceli @ 2023-05-22  7:54 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 9248 bytes --]

Hi list,
I'm excited to publicly publish a new second-layer protocol design I've been working on over the past few months called Ark.
 
Ark is an alternative second-layer scaling approach that allows the protocol users to send and receive funds without introducing liquidity constraints. This means a recipient can get paid without an onboarding setup, such as acquiring inbound liquidity. The protocol also consumes orders of magnitude less on-chain footprint than Lightning, as there is no concept of opening and closing channels.
 
Ark has a UTXO set that lives off the chain. These UTXOs are referred to as virtual UTXOs or vTXOs in short. Virtual UTXOs are like short-lived notes that expire after four weeks. Users must spend their vTXOs upon receiving them within this four-week timeframe or return them to themselves to reset the four-week timer. Virtual UTXOs live under a shared UTXO and can be revealed on-chain.
 
When a payment is made on the protocol, existing vTXOs are redeemed, and new vTXOs are created, similar to how on-chain funds flow. To improve the anonymity set of the coin ownership, vTXOs values are restricted to a set of sats values ranging from one sat to a million sats.
 
Users can acquire vTXOs from someone who already owns them or use a process called lifting, an atomic two-way peg mechanism that doesn't require trust. Lifting lets users lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO. Users can unilaterally redeem a virtual UTXO for an on-chain UTXO without asking for cooperation. 
 
When sending funds, users coin-select & destroy their virtual UTXOs and create new ones for the recipient (plus change) in an off-chain mixing round. Keys for each new virtual UTXO are tweaked with a shared secret that reveals proof of payment when spent. The payment destination is a dedicated well-known public key similar to silent payments; however, the payment trace is obfuscated through plain tweaking and blinded mixing.
 
Ark enables anonymous, off-chain payments through an untrusted intermediary called the Ark Service Provider (ASP). ASPs are always-on servers that provide liquidity to the network and charge liquidity fees, similar to how Lightning service providers work. ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main job is to create rapid, blinded coinjoin sessions every five seconds, also known as pools. A user joins a pool session to make a payment, initially coin-selecting and registering their vTXOs to spend, registering vTXOs for intended recipients, and finally co-signing from their vTXOs to redeem them.
 
Ark can be built on Bitcoin today, but we have to compromise on non-interactivity to do so. Recipients must be online to sign from n-of-n multisig to constrain the outputs of a shared UTXO, outputs as in vTXOs. With this approach, users won’t be able to receive offline payments; they need to self-host an Ark client (like Lightning). To make Ark work without running a server, we need a covenant primitive such as BIP-118 or BIP-119. 
 
BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash. Other alternatives would be (1) TXHASH, (2) CAT + CSFS + TAGGEDHASH, or (3) XOR + CSFS + TAGGEDHASH combinations. 
 
Ark uses a new locktype primitive called txlock to ensure the absolute atomicity of a transfer schedule. Txlock is a condition in which only the existence of a mutually agreed transaction identifier can unlock the condition. A txlock condition could be satisfied by a hypothetical opcode called OP_CHECKPREVTXIDFROMTHEUTXOSETVERIFY. However, Ark uses an alternative approach to achieving the same outcome using connectors. Connectors are a special output type on the protocol. The primitive is that if we want the Bitcoin script to check if a particular transaction id exists, we simply attach an output from that transaction into our spending transaction and check a pre-signed signature against prevouts of our spending transaction. The connector outpoint in the sighash preimage commits to the transaction id for which we want to satisfy the txlock condition. In the Ark context, this is the pool transaction containing vTXOs of intended recipients. Txlocks are used in Anchor Time Locked Contracts (ATLCs) to provide an atomic single-hub payment schedule.
 
Anchor Time Locked Contracts (ATLCs) are conditional payments used on the Ark protocol. When a vTXO was created in the first place, an ATLC was attached to it, similar to how an eltoo:trigger is attached to a funding output during Eltoo channel formation. When a vTXO is spent, the pre-attached ATLC connects to a connector to form a txlock. 
 
This txlock formation ensures that, for the attached ATLC to be claimed by the service provider, the outpoint context of its connector must remain unchanged. In other words, Ark service providers should not double-spend pool transactions they create. This provides an atomic payout construction for senders, as payout vTXOs nest under the same transaction of connectors. The link between connectors and newly created vTXOs is obfuscated through blinded mixing between those.
 
‍Pool transactions are created by Ark service providers perpetually every five seconds, which are effectively blinded, footprint-minimal, rapid coinjoin rounds. ASP funds the pool with their own on-chain funds in exchange for vTXOs redemptions. Therefore, the pool transaction that hits on-chain has only one or a few inputs the ASP provides. The pool transaction has three outputs: vTXOs output, connectors output, and ASP change. Service providers place vTXOs for the intended recipients to claim (under the vTXOs output) and connectors for senders to connect (under the connectors output) in their pool transactions.
 
The first output of the pool transaction, vTXOs output, contains newly created vTXOs of the coinjoin round. vTXOs are bundled and nested under this shared output and can be revealed on-chain. vTXOs output expires four weeks after its creation, and once it expires, the ASP who funded this output in the first place can solely sweep it. Nested vTXOs under the vTXOs output are expected to be redeemed by their owners in this window period. Nested vTXOs may be revealed in this four-week timeframe if the factory operator happens to be non-collaborative or non-responsive for a long period. Upon revealing a vTXO, a unilateral exit window can be triggered by attaching the pre-signed ATLC, similar to Eltoo. In the optimistic big picture, however, the final result is almost always a pool transaction with few inputs and three outputs where pool content is rarely revealed on-chain. Therefore, vTXOs & connectors remain almost always off the chain.

Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction, just like ATLCs and connectors. The attached HTLCs live under another shared UTXO called the HTLCs outputs, which also expire after four weeks. Ark service providers forward HTLCs to the broader Lightning Network the moment after they them to their pool transaction. This means Ark service providers are also Lightning service providers. Ark users can also get paid from Lightning using HTLC-nested vTXOs.
 
Ark is an open network where anyone can run their own ASP infrastructure. This means a user can have a vTXO set associated with different ASPs. The Ark protocol design allows users to pay lightning invoices from different vTXO sources using multi-part payments (MPP). Upon attaching HTLCs (or PTLCs) to multiple pools operated by various ASPs, HTLCs can be forwarded to the end destination via MPP.
 
A pool transaction can be double-spent by the Ark service provider while it remains in the mempool. However, in the meantime, the recipient can pay a lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for the service operator to double-spend in this case. 
 
A transfer schedule from a sender to a receiver is atomic in nature. ASPs cannot redeem senders' vTXOs if they double-spend recipients' vTXOs under the mutually agreed pool transaction id. A future extension of Ark can utilize a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures to disincentivize double-spending. Users can forge ASP's signature to claim their previously redeemed vTXOs if a double-spend occurs in a pool transaction. This is effectively an inbound liquidity-like tradeoff without compromising on the protocol design.
 
On Ark, payments are credited every five seconds but settled every ten minutes. Payments are credited immediately because users don’t have to wait for on-chain confirmations to spend their zero-conf vTXOs further. They can hand over zero-conf vTXOs to others or pay lightning invoices with them. This is because the ASP who can double-spend users' incoming vTXOs is the same ASP who routes Lightning payments. 
 
You can find more info at https://arkpill.me/deep-dive https://www.arkpill.me/deep-dive.
 
- Burak

[-- Attachment #2: Type: text/html, Size: 11681 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2023-08-06 22:44 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-28  6:02 [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution Ali Sherief
  -- strict thread matches above, loose matches on Subject: below --
2023-06-11  9:19 moonsettler
2023-06-07 18:20 David A. Harding
2023-05-26  7:33 jk_14
2023-05-25 12:12 Ali Sherief
2023-05-22  7:54 Burak Keceli
2023-05-22 13:03 ` ZmnSCPxj
2023-05-23  4:31   ` Burak Keceli
2023-05-23 22:06     ` G. Andrew Stone
2023-05-24  0:40     ` ZmnSCPxj
2023-05-24  0:45       ` ZmnSCPxj
2023-05-24  7:53         ` Burak Keceli
2023-05-24  6:28       ` Burak Keceli
2023-05-24 20:20 ` adiabat
2023-05-24 23:02 ` David A. Harding
2023-05-26 11:56   ` Burak Keceli
2023-05-27 20:36     ` David A. Harding
2023-06-07 13:30       ` Burak Keceli
2023-08-06 22:43     ` Antoine Riard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox