nostr:npub102ca8pnhy26vh2akepgr4vleyew65nuzug5val3sycslfe0wruwqzezyfp imagine photo realistic white fluffy dog sitting inside on a windowsill. Sun shine rain outside
There will inevitably be KYC relays and clients but that is OK. You will always have options here.
This is a good feature. Why use battery when you don't need to?
Gm now that you have had some time for the after BIOs glow to wear off, what mother board would you recommend?
Donate it to OpenSats.
This is so much harder than weight.
Option:
User wants to split. They enter people in the split. Defaults to 1 weight on each. Percentage automatically calculated and displayed. User configures weight. Percentage automatically updates.
Calculating percent is too much to ask people to do.
Technical analysis. TA is to a tech bros what astrology is to the average 17 year old girl.
Modern GPS has a resolution of ~1m. It can very accurately determine speed.
Presumably you can build redundancy into the storage so you are never dependent on one provider?
Sounds awesome. Check out a similar idea for nostr-native file storage enabling a decentralized web powered by Lightning.
We’re bringing it to Iris first. 🌩️ https://www.hornetstorage.com
Love the problem you are addressing. How are you planning to ensure data availability?
I don't believe they have auto updates. If they do that is an issue.
I think we can do better. Surely there is a more graceful way to wind down a drive chain.
Assuming long term all drive chain slots get filled, there needs to be a way for low performing chains to drop off without rugging.
How is the UTXO set (or equivalent) of the side chain handled if it is overwritten?
I don't think a majority of sBTC to BTC volume will be peer to peer but rather will involve a swap provider.
Consider.
1. Anyone can deposit into the side using an M5 Deposit transfer of BTC from-main-to-side.
2. M6 Withdrawals take time and require bundles be proposed and accepted.
This results in a situation where sBTC to BTC pressure can build but BTC to sBTC pressure cannot build. From this I assume sBTC -> BTC fees will be higher than BTC -> sBTC. The fees will attract service providers to arbitrage. They will need BTC to swap for sBTC. To transfer back out to have enough BTC to continue the arbitrage they need to wait for a withdrawal. They are effectively locking up BTC as sBTC to earn the withdrawal fee.
Re: depeg:
Under normal situation sBTC=BTC.
However, if withdrawals freeze due to disagreement on withdrawal bundle progression, I see potential for long (months to years) depegs. I don't fully understand how to resolve side chain controversy. 50% of miners abstaining from any side chain controversy freezes the funds. What next?
Re: Atomic Swaps
I am thinking of the atomic swap providers much the way I think of Fedi lightning providers. The swap providers do not have to be associated in any way with the "side chain controlers" but they do have to trust them. Only difference is the swap providers need to trust the side chain for the duration of up to two withdrawal windows (1year) where as with fedi lightning providers only need to trust until they request an on chain withdrawal. This is a much more intense capital requirement.
Money is like a big record of who has done favors for whom, but a very abstract record which works without knowing the specific identity or favor.