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 input
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
> A problem with the idea of using one-show signatures as double-spend
> protection is that miner-claimable fidelity bonds don't work as well
> against adversaries that are not just counterparties but also miners
> themselves.
Hey David,
The fidelity bonds in the Ark context are nothing but the
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
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
Hi Burak,
Thanks for your response! I found it very helpful. I'm going to reply
to your email a bit out of order.
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.
You don't ment
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 i
"Alice runs an Ark service provider. Every 5 seconds, she broadcasts a new unconfirmed onchain transaction"Is that means each such instance adding ~15k vB to single block, i.e. every 10 minutes?In such case only 200 of such nodes - would utilize the whole tx throughput of Bitcoin?RegardsJaroslaw
W
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 f
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.
Hi - thanks for the Ark write up; I have a bunch of questions but here's 2:
---
Q1:
"Pool transactions are created by ark service providers perpetually
every 5 seconds"
What exactly happens every 5 seconds? From the 15.44.21-p-1080.png
diagram [1], a pool transaction is a bitcoin transaction, wi
> 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
> 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
Here is an old write-up that should be read by everyone trying to design a
NON-custodial L2: https://zmnscpxj.github.io/offchain/safety.html
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, May 24th, 2023 at 12:40 AM, ZmnSCPxj via bitcoin-dev
wrote:
> Goo
Good morning Burak,
> > 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 rel
Do you have any write up that presents a fully detailed architecture,
including mechanisms like bitcoin scripts, transactions and L2 protocols,
and then derives claims from that base?
On Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > As
> 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 exist
Good morning Burak,
I have not gone through the deep dive fully yet, but I find myself confused
about this particular claim:
> 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 inv
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
mea
19 matches
Mail list logo
