Introducing Ark by Burak \ stacker news ~bitcoin

Introducing Ark by Burak burakkeceli.medium.com/introducing-ark-6f87ae45e272

3815 sats \ 24 comments \ @Rsync25 24 May 2023 bitcoin

217 sats \ 5 replies \ @kevin 24 May 2023

One of the more exciting things about this is the fact that it's supposedly interoperable with LN. I assume via the Ark Service Providers. Kind of like Fedimint but without the custodial risk.

If this works then I think this effectively makes Federated Mints obsolete.

0 sats \ 1 reply \ @m00ninite 25 May 2023

I'm immediately less skeptical about it catching on if it's truly interoperable with lightning. Taking advantage of our existing infrastructure could be multiplacative for the network

0 sats \ 0 replies \ @kevin 25 May 2023

I'm not entirely sure how it works, but I imagine it's a bit like how a federated mint has channels to other LN nodes. Likewise an Ark Service Provider would have channels to other LN nodes. Happy to be corrected if it's not correctly understood though :)

0 sats \ 2 replies \ @Rsync25 OP 24 May 2023

Sidechains like Liquid too.

0 sats \ 1 reply \ @super_testnet 24 May 2023

except liquid does have custodial risk

0 sats \ 0 replies \ @kevin 25 May 2023

I think what they meant is that it will obsolete liquid, not that it doesn't have custodial risk :)

0 sats \ 0 replies \ @xphis05 26 May 2023

Thanks. I did not fully understand the proposal, but could be useful in some scenarios. Inbound liquidity will always be an issue in lightning. However once enough channels are open, the issue will affect less.

IMHO L1 funds are always kept with the keys, and only in the mining process those funds are subject to some risk (near 0 of course) of been taken in an attack (51%, Double spend, etc). Additional consensus instances that will put ownership in the limbo (like liquid or this one) is something I would not like to experiment with.

0 sats \ 0 replies \ @elonmusk 25 May 2023

Amazing work. Lightning was getting too comfortable. Thank you Burak.

0 sats \ 1 reply \ @faithandcredit 25 May 2023

needs a softfork

We are better off building a completely off-chain system, using a normal database to keep track of BTC transactions. Reserves can be audited on mainchain at will. Sure you are going to have bank runs and it sucks. But thats just part of life. ACCEPT IT

284 sats \ 0 replies \ @kevin 25 May 2023

It doesn't need a softfork - only if we absolutely need the ability to receive transactions when offline.

Ark requires BIP-118 or BIP-119 covenant primitives to constrain transaction outputs of a spending transaction to make the receiving on the protocol non-interactive. BIP-118 ANYPREVOUTANYSCRIPT can constrain the 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.

These covenant primitives can be emulated using n-of-n multisig by compromising on non-interactivity. Recipients must be online to sign from the n-of-n multisig to constrain the spending transaction. This interactive version doesn't require any changes to Bitcoin and, thus, something that can be deployed on Bitcoin today.

0 sats \ 7 replies \ @falsefaucet 24 May 2023

honestly this is all mute unless covenants BIP 119 i think gets merged.

lets talk about covenants

whats the SWOT?

55 sats \ 1 reply \ @kevin 25 May 2023

That's not true, it clearly says it's possible without BIP 119 but you lose the "can be offline" feature.

0 sats \ 0 replies \ @falsefaucet 25 May 2023

fair point, i missed this.

thank you

25 sats \ 4 replies \ @shibe 24 May 2023

There's a bunch of applications for BIP 119 on https://utxos.org.

Some that are listed (and I understand, there's some technical stuff on there too which I can't explain fully):

Protect your coins by enforcing for example a list of addresses you can send to from cold storage
Help Lightning increase the HTLC limit by embedding HTLCs in a OP_CTV "tree" of HTLCs, that can gradually be unwrapped on-chain. Right now the maximum outstanding HTLCs any Lightning channel can have at once is 483 (any transaction with more than these can't be relayed). Having more HTLCs at any given time could allow LN nodes to process more transactions per second as well.
Batch channels for Lightning. As far as I can tell this uses OP CTV to "embed" multiple channels into a single output. I guess this could enable channel factories perhaps - not sure about this. But it could also make channels have a smaller footprint on-chain. I wonder if you could open multiple channels for different people using a single UTXO at once, that'd lead to a smaller on-chain footprint
There are a bunch of other examples there too. For example a chain could first put all withdrawals into a single OP_CTV tree when blockspace demand is high, and gradually process those withdrawals later on

The biggest alarm I've seen raised with OP_CTV is that it could lead to censorship, for example the government requiring that all your addresses have OP_CTV scripts that would only allow you to send to approved/KYC addresses or not to blacklisted addresses. But such censorship could be possible through other means too. For example, the government could require that each address have a tapleaf script that allows the government to seize your funds.

0 sats \ 3 replies \ @rijndael 25 May 2023

Blacklist/whitelist through ctv isn’t practical. Other solutions (like AMP) are. This one is bunk

0 sats \ 2 replies \ @shibe 25 May 2023

What is AMP?

12 sats \ 0 replies \ @rijndael 26 May 2023

its a service from Blockstream aimed at regulated assets on Liquid.

The usecase is something like: you want to issue a tokenized security on Liquid. Because of regulatory requirements, only registered investors are allowed to trade that token, but you want it to be freely transferrable between anyone who is "allowed".

So the way that it works is people use an AMP-enabled wallet. That wallet gives them a unique ID. The register that ID with whatever company who then puts them on a whitelist. When you receive an asset into you AMP-enabled wallet, it goes into a 2/2 multisig where you hold one key and the AMP server holds the other key. When you want to send the asset to someone else, your wallet signs and then the AMP server signs but ONLY if the destination address is on the whitelist.

The whitelist can be updated anytime without needing to re-roll all the UTXOs (which is something you'd have to do with a covenant), and is cheap and easy to manage.

It's literally a service to do whitelist-only token transfers for something that's bitcoin-compatible.

The "covenants will create whitelists/blacklists for bitcoin" thing is fud. it already exists.

5 sats \ 0 replies \ @Buki 27 May 2023

Shorthand for Asian massage parlor

0 sats \ 0 replies \ @moel 24 May 2023

I will run this when I see the app in the Umbrel store 😀

0 sats \ 3 replies \ @bitb 24 May 2023

What are the requirements for being an ark service provider?

2 sats \ 2 replies \ @kevin 24 May 2023

Capital (BTC). You trade your liquidity for vTXOs, I assume there's some fee in there as well.