Developer Acquisition
NoM developers contribute to libraries we use.
AZ pays out for it because those libraries then get used for NoM.
Offer ZNN tip to library maintainers and mention decentralized grants.
See who bites.
Once we have PTLCs, we might be able to tip directly on NoM to an existing bip340 pubkey of theirs.
I’m also interested in doing the Bitcoin integration into Syrius if we want to focus on that next. I would first create and design a UX for it and present and discuss it with the community before starting the implementation. Similarly to how the P2P swaps UX was done.
The design would consider the full experience from using the BTC wallet to conducting cross-chain P2P swaps with Bitcoin.
With that said, I want to note that in terms of ZTS <> BTC P2P swaps, I don’t think we necessarily need to integrate a BTC wallet into Syrius where the user stores/sends/receives funds. If you’re coming from Bitcoin into the Zenon ecosystem, it’s an extra step for you to have to first send your BTC into Syrius to swap it. Syrius would use one-time BTC keypairs on a per-swap basis to manage the swap, so from the user’s perspective they don’t need to send BTC in and out of Syrius to swap.
So is a full BTC wallet integration needed right now considering most bitcoiners will probably want to store and manage their BTC in their wallet of choice?
Another option for ZTS <> BTC swaps would be to create a webapp mimicing a “Uniswap experience”. This would require the automated market making clients that George mentioned. Since we now have WalletConnect in Syrius the full UX of the swap could be done in the webapp.
If done correctly this could result in a simple Uniswap-like interface where the user is directly swapping with the automated market making clients without knowing it. From their perspective they’re just magically swapping ZTS and BTC. The same idea could be used for ZTS <> ZTS swaps.
Such a system would of course be much trickier to create since the market making clients and the matchmaking system would have to be developed, and without a doubt there are many pitfalls there.
Well what’s stopping Syrius from eventually being their BTC wallet of choice?
Our long term advantage is that we have a native funding model for wallet development.
Not sure how other wallets are being monetized.
Between BTC ↔ NoM ↔ Extension Chains, the more fluid the experience the better
Wallet hopping breaks the immersion of a single ecosystem
Of course, short term it’s too much
But that’s why I suggested critical flow for now, only supporting modern scripts etc
If you want to have an experience like we have with ZTS-ZTS, then the bitcoin wallet will need to connect to a nom node to verify the htlc, and vice versa
one user will also need to scan the other chain for preimages
there is some design consideration when it comes to who locks first, in particular because of variance in PoW block tines
that complexity might be better managed in a single spot
even with the idea of single use btc keypairs, what happens to those utxos if the swap does not complete? btc fees are real
another consideration as well is that most htlcs in the bitcoin ecosystem are not base layer
they usually happen in payment channels/lightning
from a systematic standpoint, building the base layer capability would make sense, but from an adoption/trend standpoint, integrating with lightning first may be better
mr kaine mentioned civkit before
which users nostr as a decentralized bulletin board of offers
a UI could connect to multiple of these boards and
matchmaking is somewhat taken care of, but with any p2p system, you then have the challenge of trust/reputation when it comes to things like locking first
bitcoin_base seems viable, though it was only published a month ago. We should perform a security evaluation for any such dependencies, as well as rigorous testing to confirm compatibility.
To your first question I’ll answer with one simple fact related to marketing : it’s several orders of magnitudes to onboard users if you don’t force them to change their habits. Don’t let ideology blur your judgement. Allow more paths and more possibles. Don’t alienate userbases. If I use Bitcoin core singe 7 years, I won’t change just because Syrius is fancy. I love it. It’s part of my environment. A lot of people are like that.
We want to onboard, not bet on our wallet being better than others when it’s unnecessary. You’re right about the functionalities but ideology doesn’t change how psychology work. Marketing wise, letting people decide work orders of magnitude better than enforcing unneeded things. ex:People doesn’t use Matrix because they already use TG and Discord.
I understand your point. I am saying there are technical reasons. The only way to let them stay completely within their wallets of choice is to add NoM node connections to it. That is probably nonstarter for other wallets. Even if we write the code, doubt it would get merged in.
What I’m saying is that in the short term if we want a quick path to BTC <> ZTS swaps we don’t necessarily need to spend time focusing on a Bitcoin wallet UX inside Syrius.
I just want to make sure we discuss what the short term goal is before we start implementing a Bitcoin wallet for holding/sending/receiving BTC into Syrius just because.
If such a Bitcoin wallet is integrated, then I would like to see UI designs for how the Bitcoin wallet functions within Syrius from the user’s perspective before implementation is started.
The complexity would be managed in a single spot, in Syrius. Syrius still needs the capability to create BTC keypairs and needs a connection to a BTC node, but the HTLC contract’s P2SH address can be funded from the user’s BTC wallet of choice instead of a BTC wallet inside Syrius.
If the swap is unsuccessful, the user can recover their deposit with Syrius with the swap’s one-time keypair. The user inputs the address they want to receive the recovered funds on. This should work unless I’m missing something.
Base layer vs lightning I’m not sure. That’s up for debate which makes more sense for us. Would base layer have more volume/liquidity?
When I tried out bitcoin_base it had some obvious issues, so it doesn’t seem production ready yet at least.
I read something on twitter recently that Lightning has 5000 BTC on there. So not much. I personally find it hard to use the lightning layer. My recommendation is we use the base layer.
Eventually, we should support both L1 and LN.
Each has their pros and cons in this context, but we can appeal to a larger audience if we prioritize L1.
Hmm… We need to dive into what the actual utxo scripts and unlocking process would be. I’m not 100% sure.
When I say “btc fees are real” I mean that we should not rely on making actual txs to organize utxos into the right wallets. Importing keys is also a pain for the average user.
Let’s say Alice starts with a single utxo “A” that is managed by an existing BTC wallet. She is swapping for Bob’s ZNN.
Case 1: Alice locks first.
Bob must provide Alice a BTC address/keypair to send to. Alice provides Bob a ZNN address. They agree to swap timing parameters.
Alice generates a preimage secret.
Alice broadcasts a BTC tx that looks roughly like:
Inputs
A - must be signed by the existing wallet
Outputs
B - htlc script: within a certain number of blocks, only Bob’s provided key can unlock if he provides preimage to specified hashlock. After that number of blocks, can be can unlocked by Alice’s existing wallet. (I think this script should be possible right?)
A’ - Change that can be unlocked by the existing wallet
Note: Unlike in NoM, Alice does not need to explicitly reclaim her funds if the timelock expires. In fact she shouldn’t as that would require an unnecessary on-chain tx.
Alice’s BTC wallet must be able create such a TX, and recognize utxo B as under its ownership if the timelock should expire. Ideally it should be able to generate/manage preimages as well, or it must be able to easily accept a preimage as a param when creating the htlc. Not sure if we can assume that most wallets have these capabilities.
Alice must inform Bob of the tx she just created or Bob must be scanning the BTC chain. In any case, Bob must be able to interpret the script of B and verify that it is what he and Alice agreed to.
Bob creates an HTLC on NoM using the same hashlock and an expiration time (NOT BLOCK HEIGHT) that is expected to expire before the BTC "time"lock (blockheight lock) expires. This should be the subject of a whole other discussion.
Bob must either inform Alice of the nom htlc or Alice must scan. This is the same as the ZTS-ZTS and the htlc lookup by id can be used. Alice must verify the parameters.
Alice can then unlock Bob’s htlc on NoM. She will need to use the preimage she used for the BTC htlc. How smooth this is would depend on her wallet(s) support for preimage management.
Bob needs to scan NoM for preimages. And then once it finds it, he needs to get it over to his bitcoin wallet, so that it can sweep output B. Again how smooth this is depends on his wallet(s) support for preimage management.
I will do the same analysis in a bit for Case 2: Bob locks first
I think it will be similar but need to be thorough.
Can you explain your understanding of the funding step a little more?
Are you saying that first we will do a simple BTC send to an address managed by Syrius which will then create the BTC HTLC?
It’s an extra transaction which has tx fees ($$)
If we don’t want the extra tx, we either need outside wallets to have direct support for HTLCs.
Even if those wallets can broadcast a raw tx templated by Syrius (not a great ux), I’m not sure they will recognize htlc utxos.
For reclaim/recover, it seems like you are broadcasting an extra tx on chain ($$) which you don’t need to simply for the sake of wallet organization, instead of managing keys.
While this is technically true I don’t think it’s practical to implement. The expired HTLC can only be spent with the refund script, for which you need the HTLC’s details if the script has to be reconstructed. You also need the funding tx’s data. How do we back up that information? If they import their keys to any other wallet they will not have access to the funds.
In the case of an automated market making client this could make sense to manage and backup the expired HTLCs so they could be used as inputs directly, since that BTC wallet and client would be used for one purpose only and managing the refund details could be feasible.
Syrius creates the HTLC script which is converted to a P2SH address that can be funded from any wallet. Outside wallets don’t need HTLC support, they’re just sending a regular transaction to the P2SH address - no extra transactions.
And good point with P2SH - Scipt HASH… External wallet doesn’t need the full script. Just the hash which will be generated by Syrius. Spender will need to provide the script. I was thinking in terms of raw scripts, doh.
So you’re right that even to spend the “reclaimed” utxo you would need the script, and it couldn’t be reconstructed unless you had the full details of the htlc. But is backing up that data in Syirus much complex than backing up preimages in Syrius which we probably have to do in some way already? I guess with preimages, we have things like preimage hash chains.
If you’re doing anything more complex than a p2pkh, won’t there usually be additional data that has to be backed up by the wallet? I wonder if miniscript can help. Miniscript
If blockspace is increasingly competitive, the additional transaction does make a difference. But yeah I see your point.
Probably yes, but if we’re using vanilla HTLC scripts I don’t think there will be big difference in tx fees. There are very few examples utilizing P2TR, so it would require a deep understanding of taproot and BTC transactions in general to get it right.
For ZTS swaps we store preimages in a local database, but that db is just available for that instance of Syrius. This doesn’t really matter on NoM because you can always recover your funds from the smart contract with your address and the HTLC’s ID.
With BTC you need the refund script in order to recover. In case the client’s data storage is wiped out, I’ve seen two ways of managing this in existing HTLC swap clients:
Give the user the option to export the refund script + the swap’s private key into a text file for later use.
Store the refund script encrypted in some external storage that can be accessed and decrypted by a keypair held by the user.
Yes it’s a downside but if the swap is funded from an internal BTC wallet inside Syrius, then the user will have to make an extra transaction to first fund the Syrius BTC wallet. If the swap is funded from an external wallet then at least in the happy case scenario it will only require both parties to pay for one BTC tx.
If the user imports their BTC keys into Syrius, then we couldn’t use the NoM keypair’s entropy to deterministically create the BTC wallet.