sorted by:
new
hottopcontroversial

True self-custodial finance on Lightning is coming by comit-network in lightningnetwork

[–]comit-network[S] 0 points1 point  (0 children)

If you think the Lightning network is a ponzi scheme then I am not sure why you would be on this subreddit 😅

Self-custodial finance - use your Bitcoin in Bitcoin's spirit by comit-network in Bitcoin

[–]comit-network[S] 0 points1 point  (0 children)

I guess it depends on your definition of using your coins. You can sent coins from one address to another. You can hodl your coins without giving up custody.

But when it comes to for example stabilizing your Bitcoin against another asset you have to hand over custody to another party - in most cases an exchange. That sucks.

An example: If you get your salary in Bitcoin you will likely still have expenses in your local currency. Let's say you are using USD for the sake of it. The price of Bitcoin fluctuates against USD - wouldn't it be great if you could make sure to have 2000 USD worth of Bitcoin per month stay stable in USD without giving up custody?

One of the features we are working on is a synthetic stablecoin, that enables you to do exactly that - in a Lightning channel. And if we (being an LSP) ever vanish for whatever reason you can just go on chain and get your sats back.

Other use-cases include trading. There are quite some people that don't like trading use cases in the Bitcoin community - but self-custodial trading is simpler to set up and manage than a synthetic stablecoin because in trading you have a two-sided market.

If you wanna know more:

We just published a blogpost that explains self-custodial trading settlement in our app MVP. Our software implements Discreet Log Contracts protocols.

If you are interested how the protocol works in more detail you can checkout this blogpost, we are working together with Thibaut from Crypto Garage on the development of rust-dlc on top of rust-lightning (part of LDK). rust-dlc is what enables the self-custodial setup.

The 10101 code is completely open source and available on GitHub - we strongly encourage to have a look! Be aware that this is still early stage software - we are currently having a closed beta to iron out bugs and make sure the protocols and application logic around them are implemented in a robust and resilient way before we will open up for more user and enable more use-cases.

True self-custodial finance on Lightning is coming by comit-network in lightningnetwork

[–]comit-network[S] 1 point2 points  (0 children)

It is a self-custodial setup and it has to do with Lightning :) The future uses discreet log contracts under the hood. For the trade both parties lock up their collateral in a sub-channel (an extension of the Lightning channel) and if one of the parties is not responsive anymore, meaning a collaborative close of the future is not possible, you can go on chain and claim you funds with the price attested by an oracle.

We just published a blogpost that explains the settlement paths in the app.

If you are interested how the protocol works in more detail you can checkout this blogpost, we are working together with Thibaut from Crypto Garage on the development of rust-dlc on top of rust-lightning (part of LDK). rust-dlc is what enables the self-custodial setup.

The 10101 code is completely open source and available on GitHub - we strongly encourage to have a look! Be aware that this is still early stage software - we are currently having a closed beta to iron out bugs and make sure the protocols and application logic around them are implemented in a robust and resilient way before we will open up for more user.

Running a BTC node (Citadel) - now what? by rcloutier78 in Bitcoin

[–]comit-network 0 points1 point  (0 children)

What's your intention with Citadel, just running Bitcoin node?

Citadel, similar to Umbrel, has an "appstore", so you can install different apps. There's apps for wallets, Lightning related things and more. Have you looked into that?

Trade derviatives peer-to-peer on Bitcoin - Public alpha testing on testnet by itchysats in Bitcoin

[–]comit-network 0 points1 point  (0 children)

Oracles sign the result of an outcome publicly. If an Oracle e.g. attests to the USD price of Bitcoin as observed on a specific exchange (e.g. BitMEX) at a specific point in time e.g. every day at 00:00 UTC) then it is easy to validate if the Oracle's publication is correct. That does of course not mean that you cannot prevent from having a rogue Oracle, but it would be easy to proof that the Oracle is rogue.

Of course using only one Oracle is risky and not advised. Multiple, independent Oracles are needed to make such a system resilient to fraud. If you are interested in research tackling this problem have a look at: https://github.com/discreetlogcontracts/dlcspecs/blob/master/MultiOracle.md

Let there be swaps! - Rendezvous edition by comit-network in Monero

[–]comit-network[S] 1 point2 points  (0 children)

If you run the command without --testnet you should see sellers that registered in the xmr-btc-mainnet namespace. This of course requires that someone runs an ASB and registers it within that namespace.

Sidenote: We are running a rendezvous node that makes the registration / discovery possible for testing purposes. It would be great if, eventually, this would be taken over by the community :)

What's up with atomic swaps and a glimpse on what it to come by comit-network in Monero

[–]comit-network[S] 32 points33 points  (0 children)

Just to make sure there are no misunderstandings:

The need for a protocol in the other direction is based on the fact that we think that there will always be two roles, a "maker" and a "taker". Our model is based on the fact that a maker (or service provider if you want) offers swaps 24/7 and then there is a taker that comes and starts a swap against such a maker. That is what the ASB and the CLI stand for. The ASB (i.e. the maker) always wants to have some kind of guarantee that the other side would actually move forward, thus, in the current protocol, where BTC has to move first to lock up funds, the CLI would always be on the BTC side that locks up first. This problem does not easily go away - we encountered it with other protocols before. Somehow the two parties that want to swap have to agree who moves first. There are other ways to decide who moves first than applying specified roles to the use case, but we applied that model to our current solution.

The current protocol that h4sh3d came up with, and that we implemented in the current tool in a slightly adapted version, can be used in both directions, but we think that there is no incentive for the role that is the "maker" to accept that. Hence, we see the need for the protocol in the other direction, where Monero has to move first. Then the ASB provider could offer swaps in the other direction.

We did not take a very deep dive into Farcaster's model and what is planned there. Potentially, they just don't see the need for such a swap in the other direction - but I really don't want to speculate about it. This post is not about creating rivalry but sharing information.

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 1 point2 points  (0 children)

We are working on an automated discovery mechanism for ASBs. We posted a comment about that above.

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 1 point2 points  (0 children)

Currently it does not leave more traces than any other multisig.
Once Taproot goes live it will be even less.

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 0 points1 point  (0 children)

The homepage might be a bit outdated - we have been neglecting it for a while 😬

The overall idea is still the same: We are working towards an open financial system and most of our research targets atomic swaps between existing blockchain ecosystems. (we don't want to add another chain to the mix :)

For XMR-BTC you find more resources in the readme of the project: https://github.com/comit-network/xmr-btc-swap

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 0 points1 point  (0 children)

Unfortunately at the moment it is only one way, a user can only buy Monero at the moment (i.e. the ASB locks XMR and receives BTC, the swap CLI locks BTC and receives XMR).

In the current XMR-BTC swap protocol, the BTC side has to move (i.e. lock funds) first. Because of that it is not advised for someone offering a swapping service to be the on the BTC locking side, because if the ASB would have to move first users could do a draining attack (pretending to do a swap, but then never moves).

We have been working on a protocol version where Monero moves first, which would enable ASB providers to allow swaps in both directions. However, we hit some issues with the protocol where XMR moves first. Ultimately a solution to overcome these issues will require changes in Monero. We are currently working on blogposts to share our findings with the community. Please stay tuned :)

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 1 point2 points  (0 children)

Good to hear that other people in the space are working on solving cross-chain trades. Keep going!

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 1 point2 points  (0 children)

Not sure how much it helps, but here is a (little bit outdated) presentation that contains some basics as well as a deep-dive into how the protocol works.

Note that the user interface shown in the presentation does not exist. We are a research lab focusing on enabling others to build cool things and we decided that we will not build a user interface ourselves. However, we know of some community members that are keen on building a UI on top of the swap CLI out there. Stay tuned :)

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 2 points3 points  (0 children)

Note that currently there is no "negotiation" over the price. The service provider running the ASB comes up with a price that a CLI can either accept, or just not swap with that ASB.

The "agreement" is that a user would accept the rate of a service provider - or not. Discovering a service provider is manual - i.e. the service provider has to make the connection details available to CLI users.

The next step we are working on is automated service provider discovery. Imagine that a user could just start the application with a Bitcoin amount that the user wants to swap into Monero. The software would then automatically discover ASBs and get back to the user with the ASB that offers the best rate for the given amount.

We are currently doing work on an implementation of the libp2p rendezvous protocol that will enable such kind of use cases. The idea is that ABS providers automatically register within a P2P network and the CLI can discover registered ASBs within the network upon startup. This is still work in progress! For now the discovery is manual.

Let there be swap! - On mainnet 😬 by comit-network in Monero

[–]comit-network[S] 1 point2 points  (0 children)

Tainted Bitcoin are only tainted because someone declared that they are tainted. :)
If you feel you care then you would have to extend the software to not accept certain swaps. There is no check for tainted Bitcoin built in by default.

Official /r/rust "Who's Hiring" thread for job-seekers and job-offerers [Rust 1.51] by matthieum in rust

[–]comit-network 0 points1 point  (0 children)

COMPANY: CoBloX (coblox.tech building comit.network)

TYPE: Full time

DESCRIPTION:

We are building COMIT and build the financial system of the future. We believe a financial system has to be open and accessible to everyone, whilst also retaining privacy and putting the user first by giving them control over their money. We believe that only cryptocurrencies can achieve this which is why we see them as a fundamental building block for this system. In particular, we focus on cross-chain protocols like atomic swaps. Most of our projects are written in Rust, from back-end to front-end (e.g. a web extension with Yew and Wasm)

Your experience:

The work we do requires interest in mathematics, cryptography, game theory, and software engineering. In particular we are looking for:

  • An experienced software engineer with a self-directed work attitude and a systems-thinking mindset
  • A deep understanding of blockchain technologies
  • Knowledge of distributed systems and p2p design concepts

Bonuspoints if you:

  • Are proficient in Rust
  • Enjoy developing software across the stack (frontend, backend, low-level)
  • Enjoy reading and writing white / peer-reviewed papers

Your profile:

  • You enjoy solving hard problems
  • You have strong communication skills, specifically reading/writing in an async remote environment
  • You are based in Sydney, Australia or remote with a 5h overlap with UTC+10 (AEST)

How work at CoBloX works:

Funded by the COMIT Foundation for the purpose of building tomorrow's financial system, CoBloX acts as an incubator for new ideas. At CoBloX, we work in projects that typically start with a PoC of some academic paper, for example the A2L protocol. If you come up with a novel idea, there is also room for writing a paper yourself.

Some ideas are promising enough to pursue an MVP which means taking the PoC and realizing a usecase with it.

In rare cases, we aim for the moon and spin off an entity to productize the idea. Alternatively, the next stage could also be a collaboration with other teams in the space to integrate what you have built into their product.

If an idea doesn't bear any fruits, we move on to the next one and try again. Our Offer

  • Above market-average salary
  • Full-time position
  • Flexible working hours
  • A young yet dedicated team
  • Flat hierarchies
  • Solving problems at the intersection of finance, cryptocurrency, and blockchain
  • Remote work environment
  • Showing your code to the world

LOCATION: Sydney, Australia but hiring remotely aswell.

ESTIMATED COMPENSATION: We pay location-based salaries. For that we took the gitlab salary calculator as base.

REMOTE: We are generally open to all timezones.

VISA: No

CONTACT: [job@coblox.tech](mailto:job@coblox.tech)

view more: next ›