Hydra is a decentralized network for signature aggregation on Stellar. It takes the pain out of the process of passing around signatures, and synchronising transaction signing, while opening up for interoperability between different wallets. The obvious use case would be to sign transactions for shared, multi-signature, accounts, but thanks to the sophistication of transaction envelopes in Stellar, it can be used for much more than that. Some examples are: Off-exchange swaps between two parties, Alice sends 1,000,000 XLM to Bob Bob sends 37.5 BTC to Alice Setting up new anchor accounts Anchor creates new user account User trusts anchor asset Anchor sends asset to User Since transactions in Stellar are atomic, the operations within a transaction envelope either all pass, or all fail, taking a lot of risk out of the equation. For signing requests there are four types of messages (signed by end-user, and verified by the hubs before passed on), create a signing request approve a signing request reject a signing request cancel a signing request and these get replicated throughout a network of hubs, where end-users can connect to any hub in the network.

Cajga I really like that it is decentralized. I hope it gets a huge adoption and will have a stable network. I don't think it can be done any other way, really. Multi-sig was very much exotic previously, although more and more wallets are coming onboard now. But: Stargazer has its API Interstellar.exchange has its API Firefly has its API Etc. And they don't talk to each other. We need something that: Won't go down because one central server crashes Lets wallets interoperate

Hydra - decentralized multi-sig aggregation

dzham

Hydra is a decentralized network for signature aggregation on Stellar.

It takes the pain out of the process of passing around signatures, and synchronising transaction signing, while opening up for interoperability between different wallets.

The obvious use case would be to sign transactions for shared, multi-signature, accounts, but thanks to the sophistication of transaction envelopes in Stellar, it can be used for much more than that.

Some examples are:

Off-exchange swaps between two parties,
- Alice sends 1,000,000 XLM to Bob
- Bob sends 37.5 BTC to Alice
Setting up new anchor accounts
- Anchor creates new user account
- User trusts anchor asset
- Anchor sends asset to User

Since transactions in Stellar are atomic, the operations within a transaction envelope either all pass, or all fail, taking a lot of risk out of the equation.

For signing requests there are four types of messages (signed by end-user, and verified by the hubs before passed on),

create a signing request
approve a signing request
reject a signing request
cancel a signing request

and these get replicated throughout a network of hubs, where end-users can connect to any hub in the network.

Cajga

dzham I was/am waiting for this to be released ?
I really like that it is decentralized. I hope it gets a huge adoption and will have a stable network.

I would have few questions on the implementation:
1) What are you doing with stale requests which stays there for long time?
2) Do you use some mechanisms to prevent Denial of Service?
3) Do you deal with notifications somehow?
4) if I am not mistaken you use IPFS in the background. Did you encounter any issues with it during development (they do not recommend it for production use yet)?

StellarGuard

Looking forward to seeing the details of this. I'd be interested in contributing if you need any help with it, as well as running a hub.

brewaa

I like the idea. It seems necessary. I was working on payment requests recently. It will be a pain in the arse for implementors though. Just the spam my nature of it all. Are you proposing a SEP?

dzham

Cajga
1) What are you doing with stale requests which stays there for long time?

Timeouts... I'm leaning towards a 24h timeout right now.

I feel like that ought to be plenty of time for all the signers of a transaction to make a decision.

2) Do you use some mechanisms to prevent Denial of Service?

Not yet, but it's on the radar. Rate-limiting, most likely.

3) Do you deal with notifications somehow?

Clients connect to a hub, where they
1) subscribe to messages related to their account(s) through server-side events
2) submit messages to a REST api endpoint

4) if I am not mistaken you use IPFS in the background. Did you encounter any issues with it during development (they do not recommend it for production use yet)?

I do. Nothing so far, it's been smooth sailing pretty much.

I'm using OrbitDB, which is a layer on top of IPFS that implements a distributed database using conflict-free replicated data types (CRDTs). OrbitDB has a database type called "feed", which is basically a (trimmable) message log. I just open up a number of those; one per network, one per transaction, one per signer.

dzham

Cajga I really like that it is decentralized. I hope it gets a huge adoption and will have a stable network.

I don't think it can be done any other way, really.

Multi-sig was very much exotic previously, although more and more wallets are coming onboard now.

But:

Stargazer has its API
Interstellar.exchange has its API
Firefly has its API
Etc.

And they don't talk to each other.

We need something that:

Won't go down because one central server crashes
Lets wallets interoperate

overcat

HI, I have implemented a simple Demo on Firefly before, let me share what I did. Account A can create a payment with multi-sign account X as the payer (and need support more other actions), after receiving the request, the server checks the list of signers of account X (obtained signers from horizon), we assume that the signers list contains account B and account C, when account B or account C requests a list of signatures from the serve, the server will send the previous payment to them, they can view the payment details, and then choose to sign or ignore it, if the user chooses to sign, the server will need to perform a series of checks on the new XDR to ensure that the XDR is not written down and that the newly committed XDR is more weighted than the current XDR on the service side, when the server receives a weight of XDR that is higher than the weight it needs, it will be submitted to the horizon network(This requires a timeout retry mechanism.). We inform the users of the result and XDR changed through websocket.

In addition, I think can ask the transaction initiator(Account A) to pay 1.001 XLM to the service party(this can also be provided by the service provider itself.), then the service party uses this XLM to create a new account to submit this transaction, after the transaction completes, returns to the transaction initiator. This will resolve the transaction failure caused by the initiator sequence changes.

https://galactictalk.org/d/1565-multisig-tools-multi-signature-app-on-firefly

Cajga

@dzham
Few more questions:
Will the full transaction be uploaded to Hydra (so one will be able to verify it without anything additional before signing it)?
If yes, will it be possible to upload transactions without any signature yet?
How can we address the hubs (and what if few are down) and how do we know the list of the hubs which are participating in the network?
How do you make sure that a malicious hub will not replace the transaction though its HTTPS gateway (still participating fine in the network but what it returns in the REST API is different than what it stores in IPFS/OrbitDB ).

dzham

Cajga

Cajga Will the full transaction be uploaded to Hydra (so one will be able to verify it without anything additional before signing it)?

Full transactions will be uploaded, otherwise the system won't be able to figure out who your cosigners are, and your cosigners won't be able to review the transaction they are about to sign.

Cajga f yes, will it be possible to upload transactions without any signature yet?

You need at least one (valid) signature when submitting a signing request. Having the ability to submit unsigned requests would just lead to the sending malicious transactions to people.

Cajga How can we address the hubs (and what if few are down) and how do we know the list of the hubs which are participating in the network?

There will a number of seed hubs, and the API will have a way of getting to know more of them.
Hubs appearing/disappearing won't really affect much, unless you're talking to a hub while it goes down.

How do you make sure that a malicious hub will not replace the transaction though its HTTPS gateway (still participating fine in the network but what it returns in the REST API is different than what it stores in IPFS/OrbitDB ).

All messages passed through the system are signed, and signatures are validated by each hub before being acted upon, i.e., used to update the internal data structures for a hub, or passed on to others.

Cajga

Hydra was not even mentioned in the results. Did you submit it finally?