At the lowest level of the protocol transactions are always processed, meaning they collect the fee and update the sequence number.
The layer above that, still done by validators, does the same checks done during consensus but actually removes the bad transactions that it will send out to consensus to reduce the chance of collecting fees for failed ...
It can contain up to 64 bytes.
When it comes to data structures in Stellar you can always check XDR definition files in stellar-core repository. For example DataValue definition looks like this:
typedef opaque DataValue<64>;
You can add as many data entries to the account as you want but the account needs to hold a minimum balance required by the ...
The friendbot takes care of funding accounts on the testnet. All you have to do is to send him your public key address.
You can do it manually via curl
or just look at one of the code examples in the official doc
Some devs have been proposing to add 'Delayed payments' options to secure accounts against hackers, so people could create 'vaults' that can not send out payments if they have the 'delay' flag on paired with a 'delay-days' for n days to wait for payments once the flag has been removed. The flag itself gets removed n days after setting it off to avoid hackers ...
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 ...
No. Inflation voting cannot be chained
This isn't explicitly mentioned in the documentation so by default you have to fall back to looking at the code for the current implementation.
Reading the follow AccountFrame::processForInflation method from the source code:
Accounts are selected initially by the following query
sum(balance) AS votes, ...
Accounts, offers and data entries are eventually rows in each node's Postgres DB.
To prevent anyone from creating billions of accounts and unnecessary consuming resources of node operators - base reserve is required as a refundable deposit. It serves the same purpose as fees, but doesn't really cost anything to users.
Current value of base reserve is 0.5 ...
Your question is similar to how the stellar documentation describes customer accounts, which has two recommended methods:
Maintain a Stellar account for each customer. When a customer deposits money with your institution, you should pay an equivalent amount of your custom asset into the customer’s Stellar account from your base account. When a customer ...
There is nothing strange in this situation. Account GAL…ZTB was created by GAA…WN7, then merged into GAE…WFK, then funded (created) again by GAS…C6E. Check detailed account history here.
Are the two accounts (GAL) the same?
Yes and no. The keypair is the same, but accounts are not associated because once an account is merged, it does not exist for ...
Using the payments by account endpoint of Horizon we can see that the from account has since been merged into GCXELXZUHZEZFT5E63P2R2HMXJ3MPPIVR3TI2MDBP244ECRBQEFBVKCG.
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. ...
Accepted answer has great explanation how the process work, so let me add some practical examples to make it more concrete.
Doesn't bump sequence
operations have obviously invalid parameters (negative amounts, invalid accountId, etc.)
insufficient transaction fee
source account has insufficient balance to cover transaction fee
sequence number of source ...
Account data is encoded with base64.
Note that the key must be a string but data can be any kind of binary data (in addition to a string), so that's why many APIs return it base-64 encoded.
Some examples of decoding this value in various languages:
var decoded = atob('YmFy'); // 'bar'
decoded, err := base64.StdEncoding.DecodeString("...
Even though you can generate keypairs(The seed and the public key) for an account...it will have 0 lumens to start with.
For funding purposes, you can use the friendbot. It will add 10000 Test lumens which can be used for testing purposes on the test network.
Stellar Friendbot Link
It's always 56 for the current encoding scheme. And there is no intention to change the keypair generation mechanism in the nearest future, as far as I know.
The invention of the relatively cheap quantum computers with more than 100 qubits may lead to cryptography schemes reconsideration. But they won't be available for at least 2-3 years.
Therefore, you ...
You need to understand how transaction sequence numbers first.
Every transaction has a source account, which pays for the operations contained inside it. To stop replay attacks, every transaction also has a sequence number, which must match the sequence number of the source account. (To be more specific the transaction sequence number has to be equal to the ...
As of the time of this writing, it's 20. This is specified in the XDR for AccountEntry for the size of the signers collection:
AccountID accountID; // master public key for this account
int64 balance; // in stroops
SequenceNumber seqNum; // last sequence number used for this account
There are no specific requirements regarding issuing account locking. It's up to the issuing entity whether to lock account or not. Master key weight can be changed at any time, thus most anchors prefer to lock account only when everything was double-checked and the asset is ready for the tokensale.
Also consider changing account thresholds instead of ...
As far as I can understand it from the feature description, it has nothing to do with the lightning network.
The only effect from the mentioned operation is a bump (increment) of the account sequence number, which can be useful for complex use cases.
A typical use for this is to allow invalidating large ranges of transactions that were pre-shared with ...
The first two JS examples are equivalent to the Lab tool here: https://www.stellar.org/laboratory/#account-creator?network=test
Basically the first one generates your account keys (public and secret).
Then the second one sends an API request to the "Friendbot" who lives on the Testnet that gives you free Lumens to create the account. This is necessary ...
Federation support is reccomended by SDF (see SEP-0002), but not mandatory.
Some clients do not support federation addresses, for example, exchanges like Bittrex or Poloniex. So it would be better if you provide an account address alongside with the federated address. Make it smaller or semi-opaque, but give your users a choice to use both.
The whole point of setting the master key to 0 is to guarantee that you won't be able to make new transaction with the account. This proves that the configuration and amount of an asset won't change in the futur. This is true only when the account have no alternative signer.
Unfortunately, this means you won't be able to change anything to the issuing ...
To create a new account you issue a transaction with the CreateAccount operation. It's very similar to a Payment operation, but has the side-effect of creating a new account. This is essentially what friendbot is doing.
You can test this approach on testnet via the laboratory.
Generate an account (but don't use friendbot to fund it).
Create a new ...
If you want x and y to trust the same asset (not issued by either x or y) then you will need an account a to serve as the issuer account.
If you want to continue to distribute tokens issued by the issuer account a after the issuer account has been locked then you will need a fourth account b to serve as the distributor account, which initially holds all ...
The first account was created on the ledger 1 alongside with the Network initialization. It looks like GAAZ...CWN7 was the first Stellar account("genesis" account in blockchain terminology), with 100,000,000,000 XLM on it. Then funds were transferred to the distribution account GALP...MZTB, and the genesis account was locked.
Actually, the above statement ...
It's simple really. When you set up a new network you just pre-populate the SQL accounts table of the first network node with a single row for the genesis account containing the total initial supply of the native asset.