<unnamed>

Public Key

npub136rmper0tszp8xxttyzsa27tjrvx36drtpucg0544mq8cxlha6wshgpezn

Profile Code

nprofile1qqsgapasu3h4cpqnnr94jpgw409epkrgax34s7vy8626asrur0m7a8gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsgj3ska

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:21:55 CEST

- reply

📅 Original date posted:2023-05-26
🗒️ Summary of this message: Ark can be used for mixing coins, paying lightning invoices, and making internal transfers. Onboarding is as simple as funding a Bitcoin address.
📝 Original message:Hi David,
Ark can be used for three purposes:
1. Mixing coins.
Ark is a scalable, footprint-minimal off-chain mixer. People can use Ark to mix their coins with others. This doesn’t require waiting for on-chain confirmations since you’re mixing your own coins with others.
2. Paying lightning invoices
Ark is interoperable with Lightning, and you can use your Ark funds to pay Lightning invoices in a conjoin. This also doesn’t require waiting for on-chain confirmations since you consider your payment “done” when you obtain the vendor's preimage.
3. Making internal transfers
You can use your Ark funds to make internal money transfers without introducing inbound liquidity assumptions. The recipient-end has to wait for several on-chain confirmations to consider their payment “final”, however, their payment has immediate availability to them. Recipients can spend their zero-conf funds to pay Lightning invoices in coordination with their service provider. If we want to enable Lightning-style instant settlement assurances for the internal transfers, we need OP_XOR or OP_CAT on the base layer [1].
I think you get the gist of it, but I lost you after ”Bob wants to deposit 1 BTC with Alice.” sorry.
The initial onboarding phase is non-interactive, and there is no PSBT involved. Onboarding (or lifting) is as simple as funding a Bitcoin address.
Here I have refactored it for you:
Bob wants to deposit 1 BTC with Alice. Bob asks his friend Charlie to send 1 BTC to an on-chain Bitcoin address whose script is:
pk(B) && (older(4 weeks) || pk(A))
From here, there are several things that Bob can do:
- *Unilaterally withdraw:*
If Alice happens to be non-collaborative or non-responsive, Bob can simply take his 1 BTC back after four weeks.
- *Collaboratively withdraw:*
Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC anytime.
- *Collaboratively trade commitments:*
Alice crafts a transaction containing three outputs; (a) a commitment output, (b) a connector output, and (c) a change output. We call this transaction “pool”.
(a) commitment output
Commitment output (either using CTV or n-of-n multisig) constrains its descendant transaction to a set of transaction outputs. To simplify things, let’s say there are no other participants in this transaction besides Bob, and the descendant transaction has only one output. We call this output Bob’s vTXO. Bob’s vTXO also constrains (using CTV or 2-of-2 multisig) its descendant transaction to a single transaction output called Bob’s ATLC. Bob’s ATLC contains the following script:
pk(B) && (older(4 weeks) || pk(A))
As you realize “ATLC” script is identical to the “Funding address” script.
(b) connectors output
Connectors output is simply a single-sig output spendable by Alice herself:
pk(A)
Alice locally crafts a descending transaction from this output, spending “connectors output” to fund a new output. We call this output a ”connector,” which always carries a dust value and is spendable by Alice herself:
pk(A)
In short, Alice crafts a Bitcoin transaction that spends an input that she controls and funds an output that she controls. Alice does not broadcast this transaction and keeps it secret.
(c) change output
money not used for the other two outputs gets sent back to Alice.
1. Alice places one (or more) input(s) to her “pool” transaction to supply funds to commitment output, connectors output, change output, and transaction fees.
2. Bob creates an unsigned PSBT, placing the input that Charlie was previously funded.
3. Bob passes his PSBT to Alice.
4. Alice places one input to PSBT, the ”connector output,” which is a descendant of the (b) connectors output she is crafting.
5. Alice places one output to PSBT, a single-sig output that sweeps all money to herself (pk(A)).
6. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this transaction private. This transaction is not valid yet, since the connector’s outpoint context does not exist.
7. Alice signs her one-in, three-out and broadcasts it.
8. Alice can now claim 1 BTC Charlie has previously funded by revealing the descendant transaction of (b) connectors output. She should claim this before four weeks.
9. Bob now has a 1 BTC worth UTXO representation as a descendant of the (a) commitment output (a virtual UTXO). He can unilaterally claim this 1 BTC by revealing the child (Bob’s vTXO) and grandchild (Bob’s ATLC) of the (a) commitments output, then waiting a 24-hour window period.
So far, Charlie polluted on-chain by funding an address, and Alice by claiming funds from that address. Further steps from here will be footprint minimal.
1. Say, Bob wants to send 1 BTC to Dave.
2. Alice crafts a transaction containing three outputs; (a) a commitment output, (b) a connector output, and (c) a change output. This time descendant of (a) commitment output is Daves’s vTXO instead of Bob’s. Similarly descendant of Daves’s vTXO is Dave’s ATLC. Dave’s ATLC is:
pk(D) && (older(4 weeks) || pk(A))
3. Alice places one connector output as a descendant of (b) connectors output, just like before.
4. Alice places one input to her one-in, three-out transaction to supply funds to commitment output, connectors output, change output, and transaction fees.
5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO from the (a) commitment output descendants that Alice previously
6. Bob passes his PSBT to Alice.
7. Alice places one input to PSBT, the ”connector output,” which is a descendant of the (b) connectors output she is crafting.
8. Alice places one output to PSBT, a single-sig output that sweeps all money to herself (pk(A)).
9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this transaction private.
10. Alice signs her one-in, three-out transaction and broadcasts it.
11. Bob lets Dave know about this transaction (Alice’s transaction id, Dave’s vTXO output index) out-of-band.
12. When Dave comes back online, he sees from the out-of-band message that Bob sent him 1-BTC. He then verifies whether Alice’s transaction id exists, whether his vTXO output index is correct, and a set of other validations.
13. If Dave had been online all this time, he would have had to wait for enough confirmations to consider his payment “final.”
[1] https://eprint.iacr.org/2017/394.pdf

2023-06-08 01:21:53 CEST

- reply

📅 Original date posted:2023-05-24
🗒️ Summary of this message: Lightning Network's zero-conf channel has risks as users have to wait for confirmation before revealing preimage for payment. Ark's ATLCs ensure atomicity without waiting for confirmations.
📝 Original message:> You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations.
This is not correct. If an LSP opens a zero-conf channel to me, I cannot receive over lightning immediately because I have to wait for that channel to confirm before revealing my preimage for the payment. If I don’t, LSP takes the sender’s money yet double-spends my channel.
This is not the case with Ark. Ark ensures "absolute atomicity" by using ATLCs instead of HTLCs. Users can receive payments and forward them further without waiting for on-chain confirmations. A double-spend attempt breaks the entire atomicity. An ASP cannot redeem senders’ vTXO(s) if they double-spend recipients' vTXO(s).

2023-06-08 01:21:53 CEST

- reply

📅 Original date posted:2023-05-24
🗒️ Summary of this message: 0-conf transactions are risky due to the possibility of double-spending, but Ark may use an opcode to prevent this. Lightning payments can still be made with zero-conf coins.
📝 Original message:> 0-conf transactions are unsafe since it is possible to double-spend the inputs they consume, invalidating the 0-conf transaction.
A future extension of Ark can potentially utilize a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures to disincentivize double-spending. If a double-spend occurs in a pool transaction, users can forge ASP's signature to claim their previously redeemed vTXOs. This is effectively an inbound liquidity-like tradeoff without compromising on the protocol design.
For the time being, you have to wait for on-chain confirmations to consider a payment 'final'. However, this doesn't prevent you from paying lightning invoices with your zero-conf coins. Ark has immediate availability with delayed finality.
Best,
Burak

2023-06-08 01:21:52 CEST

- reply

📅 Original date posted:2023-05-23
🗒️ Summary of this message: Lightning payments are routed through ASPs, which may fail to forward payments on the broader network, causing recipients to be unable to rely on received funds until the next pool transaction is confirmed. However, Ark allows users to pay lightning invoices with zero-conf vTXOs collaboratively. Swap-ins require users to wait for on-chain confirmations to avoid double-spending.
📝 Original message:> As the access to Lightning is also by the (same?) ASP, it seems to me that the ASP will simply fail to forward the payment on the broader Lightning network after it has replaced the in-mempool transaction, preventing recipients from actually being able to rely on any received funds existing until the next pool transaction is confirmed.
Yes, that's correct. Lightning payments are routed through ASPs. ASP may not cooperate in forwarding HTLC(s) AFTER double-spending their pool transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spending their pool transaction.
What makes Ark magical is, in the collaborative case, users' ability to pay lightning invoices with their zero-conf vTXOs, without waiting for on-chain confirmations.
This is the opposite of swap-ins, where users SHOULD wait for on-chain confirmations before revealing their preimage of the HODL invoice; otherwise, the swap service provider can steal users' sats by double-spending their zero-conf HTLC.

2023-06-08 01:21:51 CEST

- reply

📅 Original date posted:2023-05-22
🗒️ Summary of this message: Ark is a new second-layer protocol that enables off-chain, anonymous payments through virtual UTXOs that expire after four weeks, and can be acquired through lifting or from someone who already owns them. The protocol uses an untrusted intermediary called the Ark Service Provider to provide liquidity and charge fees.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230522/2609b1b5/attachment.html>