satoshipay / signature-coordinator Goto Github PK

The re-implementation of the signature coordinator service introduces a new database schema.
There are several changes required to adapt the existing data to the new schema:

• a source_req has to be built from the existing request_uri
• the status has to be derived from completed_at
• the signatures have to be extracted from the existing request_uri and combined with the public key of its signer to populate the signatures table (which is hard because only a "hint" of the public key is available)
• key_weights and key_weight_thresholds have to be fetched from horizon

These changes have to be executed in a certain order: First, create new tables and add/rename columns, then populate new tables and columns based on existing data, eventually drop old columns.

Because of the complexity, we decide not to do this migration but to start with a fresh database for the new signature coordinator service.

No tuple of account ID and has_signed anymore. Return only signers that have signed already, since signers might change while the signature request is pending.

Background: Signers, weights and thresholds might change while a transaction is pending (unlikely, but possible). We should therefore always save all signatures and only on submission decide which ones to include; see #10.

Should only allow a fixed maximum number of signatures, though, to prevent a denial-of-service attack vector.

Use a custom subdomain.

Sign signature requests when storing them in the database.

ACs

• Add keypair to service
• Sign signature requests
• Return public key in index route
• Add public key to stellar.toml file if there is one yet

Consider a multi-sig account with the following keys, weights, thresholds:

Key X: Weight 1
Key Y: Weight 1
Key Z: Weight 2

All thresholds: 3

Key X signs first, then key Y signs, then key Z. Only now the tx is sufficiently signed, but it also has more signatures than necessary. The network might (test that!) reject the tx now, due to superfluous signatures.

Use the timebound to determine how long the tx needs to be stored (= expiry-date + maybe a little bit more time on top). Reject txs that have a timebound too far into the future.

Make sure that the service API is comptabile with https://github.com/stellar/stellar-protocol/blob/4da1e71cda4fb1a287f2f49263ac7a340e04c6df/drafts/draft-0005.md.

Adhere to HAL standard (_links, _embedded) as horizon does, so we don't have to construct URLs to resources on the client.

Make sure we actually verify the signature and not just check for a signature with a matching hint to be present. Here is a sample of how it should be done:

    const channelServiceKeypair = Keypair.fromPublicKey(channelServiceAccountId)
    const channelServiceSignature = refundTransaction.signatures.find(signature => signature.hint().compare(channelServiceKeypair.signatureHint()) === 0)
    if (!channelServiceSignature) throw new Error('Channel service signature missing on refund transaction')
    if (!channelServiceKeypair.verify(refundTransaction.hash(), channelServiceSignature.signature())) throw new Error('Channel service signature mismatch')

• Allow querying signature requests for multiple accounts
• Queries and streamed events both need to return the request and all signers incl. has_signed (no account_role anymore, since that doesn't work when subscribing to multiple accounts)

Scenario: All required signatures have been added to the transaction, transaction has been submitted to the Stellar network, but submission failed (because of network congestion / fees or whatever).

Expected outcome

Can re-submit the fully-signed SEP-7 bundle.

What happens instead

400 Bad Request

{
    "message": "Transaction is already sufficiently signed."
}

How to reproduce

POST https://multisig.satoshipay.io/submit

web+stellar:tx?network_passphrase=Public%20Global%20Stellar%20Network%20%3B%20September%202015&xdr=AAAAAMGkzSBnP9lXuRIcYM%2Bk4%2Ffbv%2FRaMX9MYdlko4MpM6jZAAAAZAFOFksAAAAKAAAAAAAAAAAAAAABAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAbBh5971XB0LoZtQeHBdlfeJCnY%2B7OimBlCmkj0C84%2BEAAAABAAAAAAAAAAIpM6jZAAAAQNyh%2FueSoIEdgJjnlVUBdNKCk6a%2BPfAgCdVcHfuU9S1fceG2AtMUHsvbLDquaLRek2y73GvVq1dJoTpNMgqVhA29RxNxAAAAQB25llfeLKiUujEhDsScfx%2F9wJD6w70ireNqGgs0MxJIEKk3LSh%2FMWatab%2BXyN1ZufnNhyO5ZRIUOtYlOZMBEA0%3D&callback=url%3Ahttps%3A%2F%2Fmultisig.satoshipay.io%2Fsignatures%2Fcollate%2Fef035f20a513194cbba7cd9bc683f672da7f68c6da69f9ceb895ee642bb7d1b4

Can only query by account ID right now.

Store the seq. no. in each signature request's record and check if the account's seq. no. is already greater than that. Mark the request as stale if so.

Left to figure out

• Check periodically?
  • Does not scale that well and signature request status might be updated pretty late
• Make the client check?
• (other solution?)

As a client application I favor an idempotent submission endpoint, so I can just replay a failed submission request without having to care about potentially creating duplicates.

Use the hash of the (original input) signature request URI instead of a UUID, at least for the public API. Normalize signature request URI before by ordering the URI's query parameters.

Idempotency: Make sure that there is no identical signature request present in DB yet (race conditions?). Don't fail if so, return the existing signature request record.

Service was running on port 4000, callback URL in SEP-0007 URI contained port 3000.