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 ...
Transaction is a unit of work on the Stellar ledger. It contains a set of operations that either complete entirety or have no effect if any of them fails. Each operation is an individual command that mutates the ledger.
From the official docs:
Among other things, Transactions are used to send payments, enter orders into the distributed exchange, change ...
Each transaction can contain up to 100 operations (this number may be changed in the future). For the most basic operations (peer-to-peer funds transfer, orders on the Stellar exchange) it's almost always a 1:1 ratio.
However, there are a lot of cases when anchors or any other applications combine multiple operations into the single transaction. For ...
You are right, the scheme you described is far from being secure. User should sign the transaction on the client-side.
I can see three options for your case:
Build and sign the transaction in the browser (that's what the most wallets doing). You can check the source code of existing web wallets for reference, most of them are open-source.
Prepare a ...
On Google's cloud servers they managed 36,000,000 transactions per second hour. Visa handles 24,000. So as far as time goes I suspect it will take the same amount of time as it does now unless it gets way way bigger than Visa. Even then there are likely still ways it can be better optimized but we haven't gotten to the point where it's a concern.
The fee is ...
While I'm not sure why this happens, this is not a different hash, its just encoded in base64
>>> import base64
The only spam protection currently in place is the transaction fee of .00001 XLM. This is very cheap, and doesn't totally prevent spam, as we saw in the case of the recent stellarpool spam. It is, however, (hopefully) enough to make it somewhat expensive to spam the network enough to cause congestion.
To take fiat currency in the first place seems to involve a a bit of financial regulatory work and keeping things in order ( Coinbase , Kraken ) while it is much easier from a compliance standpoint to open up a crypto to crypto exchage.
This does mean it cuts down on the number of exchanges that can offer USD pairings.
Coinbase currently offers ETH/USD , ...
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 ...
Stellar transactions are non-reversible. A solution to prevent fraud when buying a physical product is to use multi-signature and have both the buyer and the seller agree on an impartial mediator. The principle is the same as Bitcoin 2-of-3 multisig transactions.
The developer documentation has an example on how to set up a multisig accounts on the Stellar ...
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 ...
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 ...
The developer guide has a link to a Medium post that details how it works using a lunch analogy that does it's best to explain this quite complicated topic. You can read it in full here https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949
The ELI5 version is that the individual nodes rely on peer pressure from trusted nodes to come to a ...
Stellar provides standard way of handling compliance, but it's not part of the core protocol, because it is not required for all transactions on the network.
Works as a second layer basically, using core protocol primitives. And now to your questions:
It can simply refund all unknown / unauthorized payments.
Not for XLM. For assets anchor can control who ...
Transactions can contain one or many operations being payments one of them, so your payment should be in the transaction history but you have to look for it whether in code following the links provided, with an explorer, or fetching the operation directly by its Id using the Stellar RPC url.
XDR is a binary encoding of structured data. It is represented as a base 64 encoded String in transaction responses.
You can decode base 64 encoded XDR using the laboratory.
If you can use the Scala SDK you can call SignedTransaction.decodeXDR(base64)(...
If you want to write a Stellar-powered solution, start with Stellar Development Guides.
All tasks from your list are very basic and all of them are described in the documentation, so without any doubts you will be able to implement your case. Just copy-paste a few blocks of code from docs, change some constants here and there (like token name or issuing ...
If you need to store some information attached to any account you can use ManageData operation to store key/value pairs, more here https://www.stellar.org/developers/guides/concepts/list-of-operations.html#manage-data
Please note that ManageData operation will store information for the account, which can be edited/deleted, and not attached to a particular ...
This is as per design.
Operations are executed in order as one ACID transaction, meaning that either all operations are applied or none are. If any operation fails, the whole transaction fails.
As noted on the Fees page in the docs:
Stellar deducts the entire fee from the transaction’s source account, regardless of which accounts are involved in each operation or who signed the transaction.
"Source account" is defined as such:
This is the account that originates the transaction. The transaction must be signed by this account, and the ...
I hadn't run any benchmarks myself, but you can estimate the performance based on the few parameters.
Cryptography is the most CPU-consumptional part of SDK. Stellar JS SDK depends on Ed25519, SHA and CRC. And Ed25519 is the main concern, because the key derivation and signing are implemented on Ed25519 elliptic curves.
If you open stellar-base ...
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 ...
Transaction envelope XDR itself does not contain the timestamp field (see example of decoded tx envelope here). Therefore created_at equals parent ledger timestamp, the same as value in closed_at field for data entries fetched from /ledgers endpoint.
Transaction fees are calculated over the number of operations into a transaction
Each operation "costs" a base fee (currently* 100 stroops -> 0.00001 XLM) regardless of operation type or operation content
So if you have a transaction with only one payment operation, you will always* pay 0.00001 XLM. This apply both if you send 100XLM or 1B XLM
More info ...