pull down to refresh

I write all my longer posts here on Libre Office Writer, and use the spreadsheets for my business.
Broadly, I want to highlight that while some of the comments here have focused on "why not just run a full node on your RPi at home", that's simply not realistic for normies. Unless we want ~everyone to be stuck using custodial providers, things like Mutiny are absolutely critical to getting people onto Bitcoin/Lightning. Mutiny is still super new, and there's been some hiccups, but the rate they've been shipping has been impressive and they've definitely fixed a boatload of issues over the past month or two.
LDK still have some issues with opening channels with other implementations and you can get force closing channels if you do not use so often your Mutiny node. But I understand this that is not Mutiny team fault entirely and is fixable.
I want to respond a bit to this, because this implies that there's some general node compatibility issues here, but that's not really the case. These days we don't really see any issues between LDK and CLN or LDK and LND regarding general compatibility issues.
Mutiny has suffered from several force-close issues, sadly, but I understand they've made good progress on several of them (including contributing upstream to LDK the API tweaks they required to have the flexibility they needed for their improvements!)
a) Until recently LDK did not fully support anchor channels, CLN, which Mutiny's LSP currently uses, only supports anchor channels as a development feature, and Mutiny has not yet had the bandwidth to integrate anchor channels. Without anchor channels, lightning nodes to have to enforce the feerates on the channel as within a range that their feerate estimator gives them, as otherwise the channel is not enforceable on-chain. LDK is relatively strict about this, other lightning nodes have loosened their enforcement here to avoid force-closes and instead risk on-chain enforcement can fail. Of course anchor channels addresses this, but in the mean time Mutiny has contributed upstream to LDK to give more flexibility to users to let them loosen the enforcement, which I understand Mutiny now has.
b) Mutiny doesn't generally have the users' private key online, and many users receive HTLCs which are set to expire soon and then they close the site and don't reopen it for a week. Sadly, at this point on startup the channel has timed out and we have an HTLC which the lightning protocol mandates we go to chain to enforce. We've chatted a bit with Mutiny about how we might go about working around the Lightning protocol's requirements, and I'm quite confident we'll figure things out, with better initial sync steps in LDK and Mutiny, and looking towards the future with things like async payments.
c) Mutiny has been taking advantage of a beta feature in LDK where storage is asynchronous, as well as built a lot of infrastructure around supporting the same wallet/node running on several different machines at the same time. This is an impressive bit of engineering, but still has some kinks we're working out.
It is a culture that was formed on Twitter. It is a culture that is unique in its entirety to Twitter. You have Bitcoin, and you have Bitcoin related communities on various platforms who may have developed their own customs. "Bitcoin maxi" is nowhere near the right description for this group.
So the madness is going to end and we will never know who won?
You guys need to rethink this for next year. It's a fun event but might need some tweaks. Sats prizes shouldn't be so top heavy. Not complaining here but I have probably increased my time spent on SN by 20-30% and I am going to end up with probably 30k less rewarded sats for the month than I typically get. I know it's quality not quantity but that feels intuitively wrong. My current estimated rewards are not too bad compared to some really prominent stackers I see lower down the leaderboard who are estimated to get only a few thousand sats for an entire month. I also think the rewards should have been split between the contest and some daily rewards.
Also, this should have been a great way to attract new users. Tying into march madness and alluring them with an opportunity to win a nice chunk of sats but instead has just been a contest to increase engagement from super users.
Fun event. Needs some re-evaluation for next year to make it better.
For tax purposes for "exit price", using end-of-day / closing price should be sufficient. Since this is an ad-hoc, real-time report, you might be generating the report before the end of the day, so maybe using the open price at the beginning of the trading day works better.
As long as it is consistently used is key.
Where an approach doesn't pass muster is where a trader, for example, uses the open price for one trade, and then actual trade price for the next trade, and then maybe closing price for a third trade -- each chosen because it was advantagious for minimizing reported gains. That is what they don't want to see.