pull down to refresh
Based on historical returns, she would have 1.0787 BTC. However, this can fluctuate depending on Bitcoin volatility (higher volatility = higher premiums). The strategy tends to have several months of very low returns due to lower volatility, followed by a couple of months of very high returns. So depending on where we are in the cycle, her returns could be higher or lower.
Generally if it’s something trading related, it should stay closed source. If it’s Bitcoin related, it should eventually be open source.
The reason for this, is if you open source your trading strategy for example, it’ll no longer be profitable. Whereas for Bitcoin tools, people expect open source, as they should.
Currently we’ve already open sourced a bunch of our libraries, like node-dlc, bitcoin-abstraction-layer, etc. We plan on open sourcing the app as well when we do our full public release on the app store. We don’t have an exact timeline for this right now - but it is certainly something that’s very important to us.
No need for us to move from testflight to app store currently since we can invite up to 10k users to the app using testflight. However eventually we'll need to move to app store.
We would investigate PWA, however the main concern here is security of funds. PWA compared to secure enclave on iOS is not even close.
We'd likely look at building a desktop folks people could download or build themselves.
For users, one of the nice things, is even if the app gets removed from app store, they can still recover their funds using any BIP39 compatible wallet, so there's not a concern of apple locking you out of your funds.
I'm not too familiar with Zenon tbh. It looks like a new L1?
I've spent quite a bit of time working on cross-chain in the past. I previously worked at Liquality working on Atomic Swaps between BTC <> ETH. I think there's a ton of challenges with doing things cross-chain. You run into issues like free-option problem. Much easier to build on only one chain. And DLCs can do almost all the things you need for Bitcoin when it comes to financial tools.
PTLCs are cool, and a great upgrade to lightning. They will enable DLCs to be routed over LN (although this involves significant capital lockups).
As for VC I think this question answers it: #207366
Great question!
I think Ethereum will have a hard time scaling. Since the state is all on-chain, it'll be increasingly difficult to scale over time. Not to mention that all the scaling solutions all have their own token, and don't interoperate with each other well.
Also, there seems to be increasing centralization concerns now that Ethereum is PoS.
The surface area of attack for Ethereum smart contracts will never be a problem for Bitcoin, since DLCs on-chain are simply a 2-of-2 multisig, so the surface area of attack is minuscule.
DLCs can scale using DLC Channels (basically a lightning channel for DLCs).
When we ask ourselves the question of what's going to be around in 20 to 30 years, I feel really confident in Bitcoin. Ethereum not so much.
We also wrote a blog post containing more of our reasoning as well: https://atomic.finance/blog/an-atomic-pivot/
Re: Moon
No plans for a token ever! Moon for us means ATH TVL in DLCs!!! or Bitcoin ATH 😄 (so Bitcoin going to a million by 2030 right...? or am I too bearish 😂 )
Also tyty for the kind words 🙏 !
Re: Android
Yes, we plan to make Atomic.Finance available on Android one day. Unfortunately no ETA at the moment. We're still pretty focussed on iterating the iOS version currently and improving that first!
However, if you have an iPad or M-series MacBook by chance, you'll still be able to use it 🤙
No plans at the moment. We've built out a pretty extensive suite of backtesting tools for Bitcoin options.
We're definitely open to partnerships that could help in this area but would need to explore further.
On a side note, there's a great series on Bitcoin and space by Dhruv from Unchained Capital. If you haven't read it I recommend checking it out: https://unchained.com/blog/law-of-hash-horizons/
Nope, the strategy picks the covered call trades for you automatically. In our strategy, we use TA filters to determine when it's a good time to sell a call, and it will sell a weekly call option if it deems it appropriate.
You can verify by checking the transaction created (the DLC) after you've entered to see exactly where your Bitcoin is locked (it's locked for a month at a time).
Every time a position is entered, we also send you a notification, which you can double-check as well.
At the end of the month, you can check your returns against the positions entered, to verify the DLC executed properly.
Absolutely! Although we recommend doing your own research, the app is extremely easy to use and is as simple as setting up any Bitcoin wallet with 12 words.
Simply create your wallet, deposit your Bitcoin, click one button, and you're invested! You can get set up in under 5 minutes!
This is definitely something we've thought of, especially with the higher network fees experienced last month.
We've actually already changed "half month" cycles to "1.5x month cycles" and are considering allowing folks to invest for 2 months at a time. Likely on the medium-term roadmap.
The advantage of using Atomic.Finance covered call strategy is there's a potential for higher profit (7.87% APY historically), whereas joinmarket liquidity is < 1% APY IIRC.
The downside is you take on more risk. There's the chance that Bitcoin price goes above the strike price and you end up with less Bitcoin. However this strategy is quite conservative, and the historical max drawdown was 1.14% for a single trade.
Generally, this strategy works by using TA filters to see market trends, and sell a call during a downtrend, and do nothing during a price upswing.
By "previously mentioned companies" are you referring to the market of "BlockFi" / "Celcius" or something else?
Lightning is on the roadmap! It definitely makes a lot more sense to open a channel with the market maker, and use that for the next 3 or 4 months, instead of having to create an on-chain tx every month.
This can be done with DLC channels.
We'll likely be focused on this early next year.
One of the nice things with this, is Atomic.Finance will also become a lightning app in the process of implementing this.
Yes, we plan to make Atomic.Finance available on Android one day. Unfortunately no ETA at the moment. We're still pretty focussed on iterating the iOS version currently and improving that first!
The yield comes from selling covered calls. When you sell a call, you get a premium, for the obligation to sell your Bitcoin if it rises above a certain price.
In our strategy, we use TA filters to determine when it's a good time to sell a call, and it will sell a weekly call option if it deems it appropriate.
Users lock their BTC in a DLC for a month at a time, and the strategy goes to work.
Of course, there's no free lunch in Bitcoin, so there's a chance Bitcoin price will go above the strike price, which will result in getting less Bitcoin back.
So far the max drawdown for a single trade has been 1.14% and the historical APY is 7.87%.
One of the nice things with covered calls is no matter what, you're up in USD terms of Bitcoin terms.
[REPOST - for better visibility]
Hi list,
TLDR; LN/DLC split channels but cheaper by using less transactions.
Discussing recently with the 10101 team, it became apparent that the approach to LN/DLC channel currently implemented in rust-dlc suffers from having a too big on-chain footprint when force closing. In the following I summarize the current situation and propose improvements that could help alleviate this issue.
The two approachesThe two approaches
As discussed previously on this list[1], there are mainly two possible ways of implementing LN/DLC channels. The first is to add an extra output to commitment transactions, the second splits the channel in two independent sub channels.
Extra outputExtra output
The extra output version simply adds an output to the commitment transaction and attaches the CETs to that output. The upside of this approach is that the number of transactions is low(er). The downside is that it requires double the number of adaptor signatures to be generated since each party holds a different commitment transaction and will thus need a different set of CETs. In addition, adaptor signatures have to be re-generated every time a commitment transaction is updated. But since the discussion here is around reducing on-chain footprint, let’s note that in the worst case, a force close with this approach requires three transactions to be broadcast: the commitment transaction, the spend of the commitment transaction and the CET closing the DLC.
Split transactionSplit transaction
The split transaction attaches a transaction to the funding output, splitting the funds into two: one allocated to the Lightning Channel, the other allocated to a DLC channel. The upside of this approach is that both channels can be updated independently (except for rebalancing the amounts between both). The downside is that it uses more transactions, and is thus more costly to force close. Indeed, going on-chain requires broadcasting six transactions: the split transaction, the glue transaction, the commitment transaction, the spend of the commitment transaction, the buffer transaction and finally the CET.
(To get more details about this approach, have a look at [2]).
Improvement to the split transaction approachImprovement to the split transaction approach
Getting rid of the glue transactionGetting rid of the glue transaction
At the moment, a “glue” transaction is used between the output of the splittransaction and the commitment transaction in order to circumvent the factthat the Lightning protocol makes use of both the nSequence and nLockTimefields. While the implementation implications are unclear, it istheoretically possible to get rid of this glue transaction by finding adifferent mechanism to number commitment transactions attached to a splittransaction.
(Almost) getting rid of the buffer transaction(Almost) getting rid of the buffer transaction
The buffer transaction’s main purpose is to prevent, during the renewal of a contract in a DLC channel, one party from being able to choose between closing the previous contract and the new one, while the other party is only able to close the new one because of having revoked the CETs for the previous one. If the party that already revoked the previous contract doesn’t receive the revocation from their counterparty, they can broadcast the buffer transaction and force the closing of the channel on the new contract. However, once both parties have revoked the previous contract, the buffer transaction doesn’t really serve any purpose anymore. Thus one possibility is for both parties to exchange a new set of CETs that directly attach to the split transaction. Note that this means having to generate adaptor signatures two times, similar to the extra output approach, but the channels are kept independent.
Going further: the summary transactionsGoing further: the summary transactions
We are now down to five transactions in the worst case (when we need to broadcast the buffer transaction), and four in the best case (when we don’t need to). Can we do better? What about closing the channel with a single transaction? Wouldn’t that be ideal? One idea would be for parties to create yet another set of transactions, whose outputs would be the sum of the lightning channel balance and that of the CETs.The parties would then exchange adaptor signatures for these transactions in the same way as they do for the CETs, giving them the possibility to unlock one of them once the attestation for the event of the contract setup in the DLC channel is released. I coined these transaction summary transactions as they summarize the amounts that each party can obtain on force closing the whole channel. These transactions must of course be revocable, and could be revoked together with the commitment transactions. One limitation is that I cannot come up with a way to incorporate HTLCs in the picture at the moment, so these summary transactions could only be used when there is no in-flight HTLC in the channel. Still it feels like this could be a very nice thing to have as it would enable force closing the entire channel with a single transaction (though not in all cases).
ConclusionConclusion
The two currently possible approaches to implementing DLC/LN channels both have pros and cons. While I think it would be interesting to have an implementation of the extra output version to be able to compare it properly, I tried to propose some possible improvements to the split transaction version that could hopefully make it more viable even for contracts with lower value, and I would love to hear feedback or criticisms on these!
Cheers,
Thibaut