We’re rewarding the question askers & reputations are being recalculated! Read more.
7

Signatures verification consume significant CPU resources. Of course, using a dozen of signitures for each submitted transaction won't result in the network congestion, however it can slow down ledger closing. Therefore, it's rather a protection from lazy developers which may tend to use as many signers as possible in multisig schemes in order to avoid ...


7

Generally speaking, if you're owning all the accounts and everyone trusts you then I'd suggest adding your own private keys to the accounts instead of taking theirs. If you add your own key that is equally weighted to their key, then you can use that key to sign equal to their own. Further, this means you don't actually have to give them a signing key at ...


6

SHA-256 hash signer type is used for Hash(x) alternate signature type. Here is how it works: You pick a secret x - there are no restrictions on the value of x but for security reasons it should be a random 256 bit value. You calculate the SHA-256 hash of x and add it (the hash of x) as a signer to the account using set_options operation. Let's say that ...


6

A hash(x) signature has no dependence on the transaction itself. As such, it is only a "signer" in the sense that it adds signing weight to a transaction. Once anyone has seen the corresponding hash preimage, they can reuse that preimage to "sign" an arbitrary transaction. The main purpose of hash(x) transactions is to coordinate atomic cross-chain swaps. ...


4

You can do it the way you mentioned (sequential collection), and it is probably the most straightforward way, but one cool thing about multisig is that the only thing that's signed is the hash of the transaction (which does not include the signatures part). That enables 2 possible optimizations: 1) You can broadcast the transaction to all signers at the ...


4

So after some exploration of pre-authorized transactions, I have written a medium post on my findings and an example use case here. Yes, the basic approach is as follows: Create the two pre-authorized transactions with current sequence number + 2 Create a third transaction with current sequence number + 1. This transaction will add the two transaction ...


3

The SHA256 signature is one of the alternate signature types. You can safely use a public key of any Stellar account as a signer with a Set Options operation. Once you add the additional signer account you will be able to use the corresponding private key to sign the transactions on behalf of the source account.


3

No. New tokens on Stellar are created through adding a trustline with a Change Trust operation. You can set up as many trustlines as you want so long as you fulfil the minimum account balance (basically (2+x) * base reserve), and each trustline is affiliated with one issuer account ID; there is no one-to-one mapping between Stellar native currency and ...


3

The field result_xdr decodes to txBadSeq indicating that you've got a bad sequence number on that transaction.


3

It looks like the SignatureHint for hash(x) in your transaction is invalid. Signature hint for hash(x) is the 4 last bytes of the hash, not the preimage. Fix required around: Hint: xdr.SignatureHint(Hint(key)), The sha256 hash is equal: de30cab57041840f20d7df031d9704b2ddafeb408d52f2fe18f0a77aef511df5 So the hint should be equal ef511df5 but it's d7d888f2....


2

I can't speak for the SDF, but since you are asking about this, you probably already have guessed that this is not intended functionality. As such, I wouldn't rely on this behavior being there forever for any particular product you're developing. I would expect this to be addressed if it ever became a widespread problem.


2

There is no difference, practically. No, because you can consume sequence numbers at low threshold just by using the source account.


2

tx_bad_seq error means that current source account sequence doesn't match the sequence specified in the transaction itself. Tx sequence should be equal to account sequence + 1 to pass the verification. The account sequence is effectively a "nonce" intended to prevent transaction replay. It is incremented after each transaction. Failed transactions (for ...


2

You can put multiple operations for different accounts (identified by the 'source' parameter in each operation) into the same transaction. If one operation fails then all operations will fail. Instead of sharing secrets, share the transaction and let everyone append their signature. XDR representation is the way to share a transaction. // tx object to xdr ...


2

Currently it’s done completely off network - you need a way to share the transaction with the other parties and collect signatures. Several wallets and products do their own multisig coordination, and others are working on more generalized solutions right now.


1

It's possible, but you'll need one more Stellar account for this. Account QCHU (original account) will be unable to pay tx fees until you change the low threshold back to 0. Create one more Stellar account (let's call it "auxiliary" account) with minimum balance 1.1 XLM. Using Stellar Laboratory prepare a transaction Use auxiliary account public key as a ...


1

My best guess: To clear any doubt about who exactly is in charge of a transaction. It would not make a technical difference if a 2-of-3 transaction is signed by [A,B], [B,C], [A,C] or [A,B,C] and even common sense would be like "so what, then just every signer is responsible", I can imagine that some legal conditions might get unnecessarily complicated when ...


1

when you get the operations for an account (e.g /accounts/{multi_sig_account_id}/operations) it doesn't show the operations from the transaction submitted using the channel account. I guess it's because you apply operations to the channel accounts, so neither of operations are applied directly to the "multi_sig_account". Therefore, such operations shouldn't ...


1

You are getting an error because of a bad sequence number. I know this because I decoded response.getResultXdr(). Here are some things you should know: When you call sourceAccount = server.accounts().account(source), sourceAccount will have the correct sequence number. When you call build(), the TransactionBuilder will increment the account's sequence ...


1

As far as i know You need to send the XDR one by one after each signer signs it. Or else you can decode the XDR that send by signers and get the signing part separately and integrate with you existing XDR.


1

No difference. 0 === 1. Maybe?


1

As per the tutorial "Signers of this type are automatically removed from the account when a matching transaction is properly applied". What exactly is matching transaction ? Does that mean transaction need to have same operations and if its payment operation does the payment amount also needs to match ? <1> Matching Tx: When someone wants to ...


1

If you can avoid taking the secret key from the user it will reduce your liability and the user will be likely to trust your application or service. SEP-0007 introduces a custom URI Scheme web+stellar: that will allow applications/websites such as yours to delegate transaction signing to wallets. You could generate URIs like what is described in the ...


1

Which sha256 implementation are you using? Both sha.js (bundled with JavaScript StellarSDK) and native node implementation do not require padding.


1

(I'll start anew here) 4 issues spotted: Issue 1 I tried at Laboratory with doing a simple "Payment" from {alice_public_key} to a {second_public_addr}. Signed with and submitted this transaction, returning "op_bad_auth". 2 possibilities: (1) "alice_seed" is not the correct pair for "alice_public_key", (2) Your account already has multisig set up, so ...


1

Not familiar with the Python SDK, but here is the basic idea: Overview Let's create a multi-signature account between two parties, Alice and Bob. This will be a 2-of-2 multi-signature account, requiring each signer's signature to perform any action. ACCOUNT CREATION TRANSACTION (need a source account with XLM and a generated public/private keypair) ...


1

I found solutions by myself. After create Stellar Private Network, We must execute command to upgrade protocolversion to 9. $ stellar-core -c 'upgrades?mode=set&upgradetime=2018-01-31T20:00:00Z&protocolversion=9'


Only top voted, non community-wiki answers of a minimum length are eligible