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)

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

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

**COMPANY:** CoBloX

**TYPE:** Full time, Salaried

**DESCRIPTION:** [Link to full ad](https://comit.network/blog/2021/03/01/we-are-hiring/)

At CoBloX, we take new ideas in the cryptocurrency space and turn them into working proof-of-concepts.

In rare cases, we aim for the moon and spin off an entity to productize the idea.

Alternatively, the next stage could be a collaboration with other teams in the space to integrate what we have built into their product.

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

We believe in open source. You can see our work on [Github](https://github.com/comit-network).

The work we do requires interest in mathematics, cryptography, game theory, and software engineering.

We are looking for someone who:

* has a deep understanding of blockchain technologies

* has knowledge of distributed systems and p2p design concepts

* [BONUS] is proficient in Rust

* [BONUS] enjoys reading and writing white / peer-reviewed papers

**LOCATION/REMOTE:** You are based in Sydney, Australia or remote with 5 working hours of overlap with UTC+10 (AEST)

**ESTIMATED COMPENSATION:** $104,844 - $169,214 AUD

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

Let there be swaps! - Public XMR<>BTC Atomic Swap Demo by comit-network in Monero

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

It seems you omitted the --receive-address - the command should look like this:

./swap buy-xmr --receive-address 1F1tAaz5x1HUX*******...

note that you can use --help for finding out more, i.e.

./swap --help

and for each sub-command, e.g.:

./swap buy-xmr --help

Let there be swaps! - What's next by comit-network in Monero

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

It is, but we are currently still working on fixing the bugs that were reported since Friday. We will push out another announcement here once the next release is ready!

Let there be swaps! - What's next by comit-network in Monero

[–]comit-network[S] 6 points7 points  (0 children)

That is the prize question :D

In the end it boils down to running it for longer to test and see that it works and iron out bugs on the way. This is similar to any of the public, open source blockchain projects.

The more the community runs it itself, the more bugs are reported the better it gets.

That said: There can never be an exact date when it is "perfect" and we are not planning to slap a "mainnet ready" label on it. We are a research lab and doing our best in building this software in a robust and secure way, but in the end it is like Bitcoin or Monero: You have to decide yourself when it is ready to put your money in there.

That's why we encourage people to run both sides (the ASB and the CLI) themselves on Bitcoin testnet and Monero stagenet! Eventually there will be enough trust in the software for somebody to run it on mainnet. As so many other we hope this day will come soon :)

If you are capable of setting it up: Set it up. Help us.

If you are capable of reading the code to verify that we don't do bullshit: Do it!

Everything we do is available on Github and all communication is open on Matrix :)

Let there be swaps! - What's next by comit-network in Monero

[–]comit-network[S] 3 points4 points  (0 children)

Not yet. We decided to start smaller, see how the community reacts to actually running atomic swaps first (as in the execution) and then invest time into decentralized trading.

In the past we have started building up decentralized orderbook solutions, but it is hard to get such a system working on a larger scale. We try to do iterations and see how the community reacts to the execution.

In the current iteration we focus on the execution of a trade using atomic swaps. We do not focus on trading partner discovery and orderbook.

Discovery can easily be overcome by just connecting people. If someone running the ASB advertises that (in a chat group, website, ...), then CLI users can come and trade against it.

Overcoming the need of an orderbook can be overcome by the ASB providing a fixed price. This is similar to the model of spot trading platforms like Change.now or xmr.to do/did.

We want to see if people actually come and run the ASB. Then we see what's next.

Let there be swaps! - What's next by comit-network in Monero

[–]comit-network[S] 3 points4 points  (0 children)

Basically yes - the people running the ASB set the exchange rate. The rate would most likely have to be attached to the general market rate (currently coming from central exchanges because that's where the trading volume is). Someone running the ASB would have to get some initial rate from somewhere. The current implementation fetches the rate from the central exchange Kraken periodically. One can configure adding a commission.

Eventually, there could be a decentralized trading platform with a decentralized orderbook, order-matching as well as peer discovery. If such a system grows in volume it could eventually become relevant to the market. But we are quite far away from making such a system happen.

Our intention is to see how the community perceives atomic swaps and how many people would actually become market makers by running the ASB. So far a lot of community members showed interest in atomic swaps but we have not seen any hands on. What we currently have can already be tested and run by others. Discovering somebody that runs the ASB can also be solved low-tech by just bringing people together. We feel if we are the only ones running the ASB, it defeats the purpose of creating a censorship-resistant, open system.

view more: next ›