Comments (10)
I think this is in general an interesting request.
This way would be possible to do multiple NamePreclaim -> NameClaim in parallel.
this example is bad because the NamePreclaim only exists for front-running protection. if we want to get rid of front-running protection, then we need to remove NamePreclaim completely and anyway have only NameClaim left.
if you broadcast both in parallel, the front-running protection is lost.
from aeternity.
It is an interesting idea - but one I am not sure how to implement efficiently?! You'd still want nonces to be unique, right? (Or else it would be trivial to re-run profitable transactions) That means we need to store all used nonces for an account?
from aeternity.
I think it is a little bit of overkill and can be solved on client side, too. (it maybe is already for the "normal usecase"
NamePreclaimTx is a special case anyway where the following NameClaimTx will only be considered valid if a new keyblock is mined.
from aeternity.
Sequential transaction order is very important for double spending If I'm not mistaken
from aeternity.
In general, using single account for parallel transactions in multiple processes sounds like a bad idea that does not fit the nonce idea.
Clients should track nonces as well as batch processors/multiple processes IMO.
Users should be encouraged to use separate addresses for different wallets as well.
Using the node/API a nonce lock/sync mechanism also sounds wrong to me. An app should sync once (i.e. during startup) and keep track of the nonce.
from aeternity.
You'd still want nonces to be unique, right? (Or else it would be trivial to re-run profitable transactions)
Sequential transaction order is very important for double spending If I'm not mistaken
It is enough to ensure that the node won't apply transactions with the same hash multiple times. I don't see a problem if transactions with different fields would have the same nonce. So we don't need unique nonces, but transaction hashes.
I think it is a little bit of overkill and can be solved on client side
It can be, but random nonces would be easier to use.
Clients should track nonces as well as batch processors/multiple processes
Currently, it doesn't work well using sequential nonces #3803
from aeternity.
A random nonce would make the TX considerably larger, not sure that is preferrable - and at the end of the day the node would have to check for TX-uniqueness either by storing all Tx-hashes and checking or by storing something per account. Just mentioning the downsides.
Also with random nonces, how would you make sure that two transactions are applied in the correct order if that actually is necessary. 🤔
from aeternity.
A random nonce would make the TX considerably larger
It can be an arbitrary-size value so the user may decide its size. Also it can be used as a sequential nonce but without validation on the node side. Aepp can set nonce to 1 for each transaction and increase it only in retry in case tx hash is already taken (also it can increase fee the same way 🙃).
If we create 100k transactions with the same fields and 5-bytes nonce then the probability to get the same tx hashes (nonces) about 0.5% according to https://bdayprob.com (it appears to be tricky to calculate by myself).
Regarding reducing transaction size I would propose to do denomination in a way to make gas price equal 1 e.g. to have 9 decimal digits instead 18. This way we would save ~7 bytes for each SpendTx 😃
the end of the day the node would have to check for TX-uniqueness either by storing all Tx-hashes and checking
Isn't node already doing it? There is an endpoint to get a transaction by hash, so it is not expensive. Node can check if the hash of posted transaction is already registered and reject it if so. Probably it already works this way.
by storing something per account
I don't see it necessary
Also with random nonces, how would you make sure that two transactions are applied in the correct order if that actually is necessary.
I have two approaches:
- we can add a flag to tx specifying whether is it a sequential nonce or random
- if necessary, tx can include a hash of the transaction that should be mined before, so multiple independent sequences can be defined (mentioned in the first post)
I see that overall we discussing significant changes in the protocol, but I'm not sure that the value would be the same significant. At last, the next we would have issues with nonces I would refer to this thread :D
from aeternity.
There is no uniqueness check for transactions as far as I know? @velzevur or @uwiger can correct me here, maybe? It could be done, I guess, but I'm not convinced it is a great idea.
Side note: Wouldn't you save ~3 bytes on the denominator change? (1 byte to store 1e9 instead of 4) - then, the protocol allows for 1e6 as the minimal gas, so I guess that should be the denominator. But, that is a good, though separate improvement suggestion I think.
from aeternity.
Yep, I've counted 3.5 bytes for the amount and the same for fee of spend tx. 7 bytes overall.
from aeternity.
Related Issues (20)
- GC runs even during maintenance mode
- Allow mining NameClaimTx immediately HOT 4
- Announce capabilities in ping object
- Sort transactions in the pool by actual fee scaled by the minimum fee HOT 1
- Ensure that the delegation signature can't be used as a transaction signature
- Encode entity type into delegation signature
- OTP26 build fails due to `argparse` dependency
- Allow for configurable hard-fork directories
- Inconsistent tag naming in openapi
- Provide a state version along with every response HOT 3
- provide API to return account balance only & return 0 for non-existing accounts HOT 4
- POI proof based on block hashes
- Snapshot sync
- [CERES] support changes in `Crypto.verify_sig`
- Dry-run fails with 500 code if it can't parse transaction
- Ceres (v6) gas consumption much higher than on Iris (v5) HOT 2
- Remote calls events not sorted on transaction call log right after contract creation HOT 1
- Allow running blockchain with non-1 protocol from the beginning HOT 2
- Rejected NameClaim immediately if no corresponding NamePreclaim HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aeternity.